Re: [Last-Call] Genart last call review of draft-ietf-idr-bgp-open-policy-18

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




Hi Alvaro

Happy New Year!

Welcome!

On Tue, Jan 4, 2022 at 10:12 AM Alvaro Retana <aretana.ietf@xxxxxxxxx> wrote:
On December 21, 2021 at 8:01:21 PM, Gyan Mishra wrote:

Gyan:

Hi!  Happy New Year!

Thank you for the review!


...
> Summary: ... The new BGP role capabilities mismatch code 2 subcode 8
> discussed on ML seems to have multiple implementations deployed and one
> confined by Cisco. I agree that the authors should request a new subcode
> for the role mismatch notification.

To catch others up:  there is a confirmed case of squatting on the
assigned subcode.  A consultation on the next steps is open on the idr
list and will close tomorrow (Jan/5).

https://mailarchive.ietf.org/arch/msg/idr/RBD3Z9YIboudGAIeJLS8L--p4BU/

Gyan> Thanks for update
...
> Nits/editorial comments:
> Comment related to Gao-Rexford model. The Gao-Rexford Model only has 3 peer
> types North bound upstream Provider, Southbound Customer and lateral same
> tier level peer. With the role capabilities, RS and RS-Client is added which
> makes it slightly different but almost identical. In describing the role
> types would it make sense to have a graphical depiction of Gao-Redford model
> with the role capabilities on adjacent peers to help explain the role
> relationship for local and remote-as. Just an idea to help explain the role
> capabilities.

The role definitions are described in this document, not strictly
carried over from Gao-Rexford.  Nonetheless, a graphical description
on the roles defined here may make sense.  I'll leave it to the
authors to consider (if not too complicated).

Gyan> Perfect 



> In the role correctness section scenario where the peer receives multiple
> role capabilities to send role mismatch notification. What if there is a
> timing issue and the multiple are received after the BGP open and peer is
> established possible sequence of events issue. Is it possible the peer may
> not get a mismatch notification if the peer establishes prior to getting a
> different capabilities where a mismatch or problem exists that is missed
> that could result in a route leak. I am thinking of possibly false positive
> or negative or negative during BGP open capabilities exchange

All capabilities are signaled in the OPEN, so there's no possibility
for receiving a Role Capability afterwards.

Gyan> Agreed.  The multiple capabilities received is mentioned in the text, however as it’s signaled in the open how would multiple capabilities be received.  As the role capabilities are sent in the open , how can the possibility of multiple capabilities occur?


Alvaro.
--


Gyan Mishra

Network Solutions Architect 

Email gyan.s.mishra@xxxxxxxxxxx

M 301 502-1347


-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux