Martin Duke has entered the following ballot position for draft-ietf-bess-srv6-services-11: 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/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bess-srv6-services/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- (3.2.1) "BGP speakers that do not support this specification may misinterpret, on the reception of an SRv6-based BGP service route update, the part of the SRv6 SID encoded in MPLS label field(s) as MPLS label values for MPLS-based services. Implementations supporting this specification MUST provide a mechanism to control the advertisement of SRv6-based BGP service routes on a per-neighbor and per-service basis. The details of deployment designs and implementation options are outside the scope of this document." The idea that BGP hosts are going to be made non-interoperable because you're re-purposing the MPLS label, and so hosts are just going to have to remember who it's OK to exchange this TLV with, sounds unsatisfactory to me. Is there no way to negotiate this? Perhaps the solution John Scudder proposes in his second DISCUSS would solve this problem too: just have a new type for these overloaded MPLS labels. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This document was very difficult to follow without a thorough grounding in the references, but I managed to have some comments anyway: - I support John Scudder's second DISCUSS. - Please expand VRF, SLA, RIB, NLRI, and all other acronyms on first use. (3.2.1) " The Transposition Offset MUST be less than LBL+LNL+FL+AL The sum of Transposition Offset and Transposition Length MUST be less than LBL+LNL+FL+AL" The second condition makes the first redundant for all Transposition Length >= 0! It makes me think there's a typo. (5) and (6) "The SRv6 Service SID SHOULD be routable within the AS of the egress PE" SHOULD? Under what circumstances would it be OK for it not to be routable? [I see Alvaro also commented on this, but I'd like to call out that Sec 6 does the same thing] _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
