Re: [bess] Alvaro Retana's Discuss on draft-ietf-bess-mvpn-fast-failover-13: (with DISCUSS and COMMENT)

[Jeffrey Haas <[e-mail]>]

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