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

[Greg Mirsky <[e-mail]>]

Hi Jeff,
your comments and suggestions are much appreciated. Please find my answers
and notes in-lined below and tagger by GIM>>.
Attached, please find the diff and the new working version of the draft.

Regards,
Greg

On Wed, Dec 16, 2020 at 1:04 PM Jeffrey Haas <[e-mail]> wrote:

> Alvaro,
>
> Thanks for drawing our attention to this document.
>
> On Tue, Dec 15, 2020 at 03:09:54PM -0800, Alvaro Retana via Datatracker
> wrote:
> > Alvaro Retana has entered the following ballot position for
> > draft-ietf-bess-mvpn-fast-failover-13: Discuss
> >
> > When responding, please keep the subject line intact and reply to all
> > email addresses included in the To and CC lines. (Feel free to cut this
> > introductory paragraph, however.)
> >
> >
> > Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-fast-failover/
> >
> >
> >
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> >
> > (1) This document describes several methods to determine the status of a
> > tunnel (in §3), none of which "provide a "fast failover" solution when
> used
> > alone, but can be used together with the mechanism described in Section
> 4"
> > (§1).  §3 also says this:
> >
> >    An implementation may support any combination of the methods
> >    described in this section and provide a network operator with control
> >    to choose which one to use in the particular deployment.
> >
> > While §3.1 is clear in the fact that it is not a requirement for all
> > downstream PEs to use the same mechanism, there are no guidelines to aid
> the
> > operator to chose which mechanism to use.  Some cases may be obvious
> (e.g.
> > §3.1.3 applies to tunnels of a specific type), but others are not.  I
> would
> > like to see deployment considerations related to the
> advantages/disadvantages
> > that each method may have in specific situations (including their
> possible
> > combination).
> >
> >
> > (2) The BFD Discriminator Attribute has a very narrow application in this
> > document when compared to the potential other uses given the
> extensibility
> > possibilities related to bootstrapping BFD.  I have serious concerns
> about
> > the attribute being defined in this document, amongst a series of other
> > mechanisms.
>
> I have the following comments about the BGP Path Attribute in question:
>
> - BGP Packet space is sometimes at a premium.  The initial 3 octet reserved
>   padding should be removed.
>
GIM>> Agree. Removed

> - The TLVs having a required length of multiples of 4 similarly are space
>   wasting.
>
GIM>> Agree. Updated the check on the receipt accordingly.

> - The attribute does not make adequate provision for more than one type of
> a
>   BFD Mode.  This likely limits the general purpose re-use of this
> attribute
>   for other purposes.
>
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 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].

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

>
> The IANA allocation strategies for the Path Attribute and the Optional
> Sub-TLVs seems reasonable.  Note that Experimental code points have proven
> to be poorly used in BGP and that their use in the public Internet may
> result in unexpected discard of the attribute.
>
>
> >
> > (2a) The tunnel can be monitored without the new BGP Attribute (assuming
> > proper configuration of course).  Why is that option is not even
> mentioned in
> > the document?
> >
> > In fact, the document recommends deleting the BFD session if the
> Attribute is
> > not present.  Why is that recommendation in place, and what are the
> cases when
> > it can not be followed?
> >
> >
> > (2b) The fact that BFD monitoring can be achieved without the new
> attribute
> > makes me think that the bootstrapping of BFD using BGP would be better
> served
> > in a document produced by the BFD WG.  One of the editors has expressed
> the
> > same opinion [1] [2].  Has a discussion taken place in the BFD WG (or at
> least
> > with the Chairs) about this work?  Why was it not taken up there?
> >
> >
> > [1]
> https://mailarchive.ietf.org/arch/msg/rtg-bfd/T1jVpgyXuPatTpuD_wA0JC3CT1c/
> > [2] https://tools.ietf.org/wg/bess/minutes?item=minutes-96-bess.html
>
> I will not speak for Reshad, but I don't recall this issue.  I may simply
> be
> forgetting the e-mail brought to the list, if so.
>
> The meta desire here is that communication of the BFD Discriminator for
> p2mp
> sessions requires protocol help - in this case BGP.  While this could also
> be discovered via provisioning, that would limit the flexibility of the
> deployment of this feature.
>
> For this specific internet-draft's purpose, dissemination of the
> Discriminator is tightly scoped.  The fact that this happens under an
> AFI/SAFI that is not expected to hit general purpose Internet routes limits
> the blast radius of its use.  However, as you note, Alvaro, there may be
> more general purpose desire to use this attribute for.
>
> > (15) §3.1.6: "The BFD Discriminator attribute MUST be considered
> malformed if
> > its length is not a non-zero multiple of four."  Ok, except that the
> > specification of the attribute doesn't mention the length (only the
> length of
> > the TLVs).  Please specify the length and any considerations related to
> the
> > Extended Length bit.  Also, given that this is a new attribute, with an
> > unspecified potential number of TLVs, and that the length is apparently
> > unbounded, all leading to the potential need for extended messages,
> please
> > specify how to handle peers that cannot accommodate more than 4k octet
> > messages (rfc8654).
>
> Note: I wouldn't put special requirements here on the Extended Length bit.
> That's core RFC 4271 Path Attribute behavior.
>
> Similarly, overflow of Path Attributes is a general BGP consideration and
> it
> is inapropriate to require this document to solve that.
>
>
> -- Jeff
>