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

[Jeffrey Haas <[e-mail]>]

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.
- The TLVs having a required length of multiples of 4 similarly are space
  wasting.
- 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.
- 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.

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.

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