Hi Jeff, thank you for your quick detailed response. Please find my follow-up notes in-line tagged by GIM2>>.
Regards, Greg On Mon, Dec 21, 2020 at 5:42 AM Jeffrey Haas <[email protected]> wrote: > Greg, > > On Sun, Dec 20, 2020 at 04:25:21PM -0800, Greg Mirsky wrote: > > GIM>> In Section 7.2 we're requesting IANA to create a new sub-registry. > > New types of a BFD session can be bootstrapped using the BGP BFD > > Discriminator attribute. For example, draft-ietf-bess-evpn-bfd > > < > https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-bfd/?include_text=1> > may > > introduce a new BFD Mode value. Would you suggest larger field for BFD > Mode > > or an alternative method to signal the type of the BFD session to which > the > > value in the BFD Discriminator field is applicable? I thought that, in > some > > cases, a new value for p2mp with Active Tail Unsolicited Notifications or > > p2mp Active Tail with Polling would be added. > > The property I'm talking about here is that the BFD Discriminator attribute > is not repeating. You can have exactly one BFD mode in the Path Attribute. > > If the intent was to permit more than one type, the BFD Mode would be > followed by a length field - likely 2 octets long. > GIM2>> At this time I don't see a use case for the same BGP speaker advertising more than one type of BFD session. > > > > > > > > - The length handling text is likely not correct: > > > "The BFD Discriminator attribute MUST be considered malformed if its > > > length is not a non-zero multiple of four." > > > The implication is a length of four, which would have no BFD > > > Discriminator, should be considered a valid PDU. Note that the > length > > > considerations are further compounded by the padding issue for > optional > > > sub-tlvs in the prior point. > > > > > GIM>> Thank you for pointing this case out. I agree, that is not what we > > wanted. Following updates noted above the new text is as follows: > > NEW TEXT: > > The BFD Discriminator attribute MUST be considered malformed if its > > length is smaller than five octets or the value of the BFD Mode field > > is unrecognized. If the attribute is deemed to be malformed, the > > UPDATE message SHALL be handled using the approach of Attribute > > Discard per [RFC7606]. > > The 5 octet minimum length is probably worth having as a condition. > > The unrecognized doesn't follow BGP philosophy very well. Incremental > deployment of BGP features often requires some devices that are simply > transporting the routes, but not utilizing them, to pass things they don't > fully understand. > > I suggest dropping the "or the value of the BFD Mode field is > unrecognized". > GIM2>> Agree. > > Having text that says "if Optional TLVs are present, but not well formed, > the entire Path Attribute is malformed and should be handled using > Attribute > Discard". > GIM2>> Could it be used to replace the "unrecognized value" clause to make the updated text as follows: NEW TEXT: The BFD Discriminator attribute MUST be considered malformed if its length is smaller than five octets or if Optional TLVs are present, but not well-formed. If the attribute is deemed to be malformed, the UPDATE message SHALL be handled using the approach of Attribute Discard per [RFC7606]. > > The implication is that if there's more than one BFD Discriminator that any > BFD Mode TLV (if the change is made above for multiple) that is malformed > is > reason to discard the entire feature. > GIM2>> Do you see as useful a reference to clause g in Section 3 of the RFC 7606 that states: If any other attribute (whether recognized or unrecognized) appears more than once in an UPDATE message, then all the occurrences of the attribute other than the first one SHALL be discarded and the UPDATE message will continue to be processed. > > > Since a BFD discriminator is 4-octets, I'm curious as to what > discussion > > > the > > > working group may have had with regard to using a BGP Extended > Community > > > instead? In particular, the BGP Extended Community's Transitive bit > might > > > be useful in many multicast VPN scenarios operating over a single AS to > > > limit the distribution scope of this Discriminator. > > > > > GIM>> I agree that the BGP Extended Community attribute can address the > > immediate problem and be used to bootstrap a p2mp BFD session. It would > > even have space for the BFD Mode field. But because the length of the BFD > > Extended Communities attribute is fixed, it seems that no further > > extensions (e.g., providing the MultipointHead's source IP address) be > > possible. > > There we go - a motivation. :-) > > > -- Jeff >
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
