Hi Jeff, RE: the use case for multiple BFD discriminators listed in the BGP BFD Discriminator attribute. As I understand BFD and S-BFD, a discriminator value a node would advertise has different contexts in BFD and S-BFD. In the former case - that is the value node would use as My Discriminator, while in the latter- a remote S-BFD system must use as Your Discriminator. Additionally, I don't think that S-BFD has been defined for p2mp networks (I'm not sure it can work in p2mp). And there's draft-ietf-idr-bgp-ls-sbfd-extensions <https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-sbfd-extensions-04> that defines extensions to the BGP Link-state address-family to carry the S-BFD Discriminators information via BGP. As I understand it, to advertise a Discriminator for S-BFD, a node will follow the mechanism defined in draft-ietf-idr-bgp-ls-sbfd-extensions. What do you think?
Regards, Greg On Mon, Dec 21, 2020 at 3:28 PM Jeffrey Haas <[email protected]> wrote: > Greg, > > On Mon, Dec 21, 2020 at 01:08:26PM -0800, Greg Mirsky wrote: > > > 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. > > Consider the example where BFD or S-BFD were options. Consider that S-BFD > might be preferred, but regular BFD was being offered as an option. How do > you encode that? > > > 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]. > > That text is better. Thanks. > > > > 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. > > I wouldn't cite that one. Its intent is that if you had more than one BFD > Path Attribute present in the Update, not that there may be more than one > BFD Mode in the BFD Path Attribute. > > -- Jeff >
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
