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
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
