Hi Martin, Thanks for your review and your feedback/comments. We have posted an update to address some of the comments and please also check inline below for responses.
https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-12 On Wed, Feb 23, 2022 at 7:02 AM Martin Duke via Datatracker < [email protected]> wrote: > 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. > KT> As explained on other threads, this mechanism/technique is not being introduced for the first time in BGP. This is a well-known, implemented, and well-deployed technique for BGP services for other encapsulations as well. We've clarified and provided pointers in the updated version. Please also see this discussion thread: https://mailarchive.ietf.org/arch/msg/bess/SwXz7Ya0jyZ1g2TSf2ABsEoRz4g/ > > > ---------------------------------------------------------------------- > 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. > KT> Agree that the first condition is redundant and we've fixed this. > > (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] > KT> We've added clarification with a reference to RFC8986 as to why it is not necessary for all SRv6 SIDs to be routable. Thanks, Ketan
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
