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

[Reshad Rahman <[e-mail]>]

 
Thanks Alvaro, Jeff. Please see inline.
 
 On 2020-12-16 4:21 p.m., Jeffrey Haas 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.
- 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. 
 
I tried to dig this up and here's the summarized history:
 
 There was some discussion right after IETF96 (I was at the BESS meeting): 
https://mailarchive.ietf.org/arch/msg/rtg-bfd/-D0iRI2aMSD9tkMWGObsmKGiXow/
 
 
Greg did bring this draft to the attention of the BFD WG in 2018 but there was no discussion:
 
 
https://mailarchive.ietf.org/arch/msg/rtg-bfd/wQOhY6p9L3Z7f29VpNx_yRsCTZg/
 
AFAIK BFD WG wasn't involved in WGLC. 
Note that draft-ietf-bess-evpn-bfd reuses the mechanism for signaling BFD discriminator.

Regards, 
Reshad.
 
 
 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