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

[Greg Mirsky <[e-mail]>]

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 <[e-mail]> 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
>