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

[Jeffrey Haas <[e-mail]>]

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.



> 
> > - 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".

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".

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.

> > 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