Gunter, I have removed the sentence using BCP-14 terminology and published revision 15 addressing your comments.
Thanks, Rishabh. On Wed, Sep 10, 2025 at 1:31 AM Gunter van de Velde (Nokia) < [email protected]> wrote: > Hi Rishabh, > > > > Thanks for digging all the way through the review email. It was a lengthy > task. > > > > Only one tiny item remaining. Look for the inline “GV2>”. > > > > I’ll progress the draft when you posted the new version, > > Thanks again for taking the comments into account > > > > Be well, > > G/ > > > > *From:* Rishabh Parekh <[email protected]> > *Sent:* Tuesday, September 9, 2025 10:04 AM > *To:* Gunter van de Velde (Nokia) <gunter.van_de_velde= > [email protected]> > *Cc:* [email protected]; BESS <[email protected]> > *Subject:* [bess] Re: [Shepherding AD review] review of > draft-ietf-bess-mvpn-evpn-sr-p2mp-14 > > > > > > *CAUTION:* This is an external email. Please be very careful when > clicking links or opening attachments. See the URL nok.it/ext for > additional information. > > > > Gunter, > > Responses inline @ [RP] > > > > I have attached ver 15 with proposed changes and the diff. Please let me > know if it addresses your comments and I will publish it. > > > > Thanks, > > Rishabh > > > > On Tue, Sep 2, 2025 at 4:28 AM Gunter van de Velde (Nokia) > <[email protected]> wrote: > > Hi Authors, > > Please find here some review comments as Shepherding AD on this document. > Many thanks for this piece of work. It took longer as expected to dig > through the condensed procedures in this document. > > # Gunter Van de Velde, RTG AD, comments for > draft-ietf-bess-mvpn-evpn-sr-p2mp-14 > > # The line numbers used are rendered from IETF idnits tool: > https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-bess-mvpn-evpn-sr-p2mp-14.txt > > # GENERAL > # ======== > > # The draft has 6 authors, please reduce to 5 authors, or justify the > reason why 6 authors are absolutely necessary. > > > > [RP] Will move a recent author to contributor > > > # Shepherd write-up informs that IPR poll was requested, but lacks a IPR > poll result summary. Similar for implementations. Often drafts have an > implementation section that is removed during rfc editor step, but this > draft does not have such section. It helps to prove that the claim of > implementation is real and not false claim. > > > > [RP] I will add an implementation section. I am not sure about the IPR > poll result summary; I assume the WG chairs are responsible for adding the > summary for the document. > > > # This document uses quite a bit of BESS- and multicast-specific > terminology, which may make it difficult for reviewers to follow. Adding a > dedicated terminology section, or at least clear references to where each > term is defined-would make the text much easier to navigate. > > > > [RP] Most of the terms for MVPN procedures are primarily from RFC > 6513/6514 and EVPN from RFC 7432. These documents are normative references > because the reader has to be familiar with them to follow this document. > Some other terms are from draft-ietf-pim-sr-p2mp-policy. This expectation > is made clear in the last paragraph of the Introduction section. I have > modified this paragraph to list the terms and the references. > > > > > # Most of the comments are requests for clarifications and more > prescriptive language. It was first time I read this document and my > observations should be seen through that lens. > > # DETAILED COMMENTS > # ================== > > 101 1. Introduction > > GV> There is terminology used (e.g. leaf nodes, CPs, etc) in the next few > paragraphs which is defined in draft-ietf-pim-sr-p2mp-policy-20. Suggest to > add reference for this terminology in the text top nail them down correctly. > > > > [RP] Added reference to the draft. > > > > > 112 instantiate P-Tunnels for MVPN. SR P2MP P-Tunnels can be > realized. > > > GV> What does 'realized' exactly mean in this context? I saw the same > wording was used later in the document also. > Does it mean initiated, used, installed? (maybe my non-native English is > causing unnecessary questioning) > > > > [RP] P-tunnels is the generic term for Provider-tunnels in RFC 6513/6514. > These P-tunnels can be created/signalled using different > underlay technologies listed in RFC 6514 such as PIM, MLDP, RSVP-TE P2MP > etc. In this sense, "realized" is "instantiated". I will replace "realized" > with "instantiated" to make it more clear. > > > > > 117 defined by a SR P2MP Policy and instantiated via a a controller > such > > GV> typo: "a a" > > 121 the P2MP tree. A unique Identifier, called Tree-SID, is > associated > 122 with a P2MP tree. This Tree-SID can be an MPLS label or an IPv6 > 123 address. > > GV> draft draft-ietf-pim-sr-p2mp-policy-20 seems to speak about a Tree-ID > as identifier? Is the text here really trying to say Tree-SID? > > > > [RP] Yes, Tree-SID is a unique data plane identifier for a SR P2MP tree > instance. But I see how this does not really belong to the introduction > section. I will remove the last couple of sentences. > > > 133 SRv6 P2MP trees. SRv6 P2MP trees can also be used to support > 134 Multicast in Network Virtualization over Layer 3 [RFC8293]. > > GV> While the srv6 p2mp trees comment is correct, is this something that > is relevant for this draft? > If it would be deleted, would it cause an issue for the narrative? > > > > [RP] I agree. I will delete this sentence. > > > > > 136 The reader is expected to be familiar with concepts and > terminology > 137 of [RFC6513], [RFC6514] and SR P2MP drafts. > > GV> Please be very explicit where the concepts and terminology is defined. > Its better that the reader does not have to go on a treasure hunt for these > if unsure what a specific term means. > > > > [RP] Added text about which specific terms refer to respective RFCs. > > > > > 141 For MVPN or EVPN, Provider Edge(PE) routers steer customer > traffic > 142 into a P-Tunnel that can be instantiated by a SR-MPLS or SRv6 > P2MP > 143 trees. A SR P2MP tree is defined by a SR P2MP policy > 144 [I-D.ietf-pim-sr-p2mp-policy]. > > GV> does this forget to mention ingress replication? when reading like > this, perception may be that SR P2MP is the only way? > Potentially some extra context. > > > > [RP] Agreed. > > > > > 151 initiated by various methods (BGP, PCEP, others) which are > outside > > GV> initiated or instantiated? > > > > [RP] instantiated. Fixed. > > > > > 150 for the tree. A Replication segment of a SR P2MP tree can be > 151 initiated by various methods (BGP, PCEP, others) which are > outside > 152 the scope of this document. > 153 > 154 PE routers interact with controllers to create, modify and > delete SR > 155 P2MP Policies using various methods (BGP, PCEP, etc.) which are > 156 outside the scope of this document. > > GV> this text seems to say twice that BGP, PCEP etc is out of scope > > > > [RP] This is meant to convey that the Root PE routers create/modify/delete > SR P2MP policies on the controller (PCE) using mechanisms like BPG, PCEP. I > have modified text to clarify this. > > > > > 156 outside the scope of this document. A PE router is a Path > 157 Computation Client (PCC) when PCE is used as a controller. > > GV> if PCEP is out of scope (see prior comment), then why delve into > PCE/PCC terminology? > > > > [RP] Point taken. Removed this sentence. > > > > > 159 The Root of a P2MP tree imposes the Tree-SID to steer the > customer > 160 payload into the P2MP tree. Provider (P) routers replicate > customer > > GV> I am not sure what is exactly intended to be understood as 'customer > payload'. Would this not be just received payload intended to be sent over > the tree. It does not necessary have to be from a customer i suppose? > > > > [RP] Agrees. Removed "customer". > > > > > 165 An Ingress PE can deliver payload to egress PEs of the service > using > 166 Ingress Replication. This payload is encapsulated in SR-MPLS > or SRv6 > 167 and replicated to each egress PE. > > GV> Maybe move this paragraph to earlier in the section to provide context > that p2mp is the other option available. > > > > [RP] Done. > > > > > 171 BGP PMSI Tunnel Attribute (PTA) is defined in [RFC6514] to > identify > 172 the P-Tunnel that is used to instantiate a Provider Multicast > Service > 173 Interface (PMSI). The PTA is carried in Intra-AS I-PMSI, > Inter-AS > 174 I-PMSI, Selective PMSI, and Leaf Auto-Discovery routes. > > GV> is this list complete? On the IANA i can for example find "S-PMSI A-D > route for C-multicast mLDP" > > https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#mcast-vpn-route-types > Maybe add more explicit references and context in the claim for > completeness. > > > > [RP] Route types 1, 2, 3 and 4 in RFC 6514 listed above are the > "auto-discovery" routes and only these route types have the PTA because. > Route types 5,6,7 from RFC 6514 are "overlay signalling" routes and they do > not have the PTA. Similarly, "S-PMSI A-D route for C-multicast mLDP" and > other route types defined in RFC 7441 are meant to signal MLDP FECs in the > overlay and hence do have the PTA. In this sense, the above list is > complete. > > > > > 176 A P2MP tree PTA is constructed as specified below. > > GV> A short overview with field lengths would help. Maybe a reference to > https://www.rfc-editor.org/rfc/rfc6514#section-5 > > > > [RP] Done. > > > > 185 * Flags: See Section 4 for use of "Leaf Info Required bit". > > GV> The keyword "Flags" is plural, but at the same time only a single bit > seems mentioned? > > > > [RP] "Flags" is a field of PTA defined in RFC 6514. Although that RFC > defines only one flag "Leaf Info Required", and this is the only flag of > interest in this document, other drafts/RFCs have specified additional flag > field and I believe there is a document that even extends the "Flags" field > since 8 bits are no longer sufficient :) > > > > > 189 * Tunnel Identifier: The SR P2MP P-Tunnel is identified by > <Tree-ID, > 190 Root> where, > > GV> prior in the document Tree-SID was used, and now Tree-ID. What is the > purpose of the Tunnel-identifier if there is a Tree-ID? is it to make the > id globally unique > > > > [RP] If you refer back to the PIM SR P2MP Policy draft, <Root, Tree-ID> is > an identifier of a SR P2MP policy whereas Tree-SID is a *data plane* > identifier > of one P2MP tree instance of an SR P2MP policy. > > > 195 - Root is an IP address identifying the Root of a P2MP tree. > 196 This can be either an IPv4 or IPv6 address. The address > type > 197 can be inferred from the PTA length. > > GV> Could it be a SRv6 node SID? (for example when flex-algo is used for > topology aware tree roots) > > > > [RP] No, Root address is one of the identifiers of SR P2MP policy (along > with Tree-ID) that is used to instantiate a specific P-tunnel signalled in > I-PMSI or S-PMSI MVPN route. So, it does not have any underlay > significance. For a given SR P2MP policy (and a CP), the P2MP tree instance > can be instantiated by SR-MPLS or SRv6 Tree-SID. > > > 199 When a P-Tunnel is non-segmented, the PTA is created by PE > router at > 200 the Root of a SR P2MP tree. For segmented P-Tunnels, each > segment > 201 can be instantiated by a different technology. If a segment is > 202 instantiated using P2MP tree, the router at the root of a P2MP > tree > 203 creates the PTA. > > GV> Add reference for segmented P-Tunnels. Maybe add context and a > use-case example. > > > > [RP] These are terms from RFC 6513. Added a reference. > > > > > 211 specific MVPN. For EVPN considerations, see SR P2MP Trees for > EVPN > 212 section. > > GV> Add the section number for easier finding the section > > > > [RP] Done > > > 216 When a SR P2MP P-Tunnel is shared across two or more MVPNs in a > SR > 217 MPLS domain [RFC8660], the "MPLS Label" field of a PTA > advertised in > 218 an Auto-Discovery route MUST contain an upstream-assigned MPLS > label > 219 that the advertising PE has bound to the MVPN, or a label > assigned > 220 from a global context such as "Domain-wide Common Block" (DCB) > as > 221 specified in [RFC9573]. > > GV> Add reference on 'upstream-assigned MPLS label' in the context of > multicast and sr-mpls. > (i assumed upstream assigned was a LDP based term) > > > > [RP] It is specified in RFC 6513/6514, but they refer to RFC 5331. I will > add a reference to 5331. > > > 223 When a customer payload is steered into a shared SR P2MP > P-Tunnel, > 224 this MPLS label MUST be imposed before the MPLS label > representing > 225 the Tree-SID. > > GV> In such a case, there are two labels imposed, instead of one label > when tunnel is not shared. Maybe make this more explicit as the trade-off > > > > [RP] Ok. > > > > > 229 When a SR P2MP P-Tunnel is shared across two or more MVPNs in a > SRv6 > 230 domain [RFC8986], the "MPLS Label" field of a PTA advertised in > an > 231 Auto-Discovery route MUST contain an upstream-assigned SRv6 > Multicast > 232 Service SID Section 5.2.1 that the advertising PE has bound to > the > 233 MVPN, or a SRv6 Multicast Service SID assigned from a global > context; > > GV> s/Section 5.2.1/(Section 5.2.1)/ > Also note that the section name is "SRv6 Multicast Endpoint Behaviors" > > [RP] Added brackets. The first sentence of Section 5.2.1 is "The following > behaviors can be associated with SRv6 Multicast Service SID.", so the > behaviors are associated with a Multcast Service SID. > > > 232 Service SID Section 5.2.1 that the advertising PE has bound to > the > 233 MVPN, or a SRv6 Multicast Service SID assigned from a global > context; > > GV> Add references what is a global context in this paragraph > > > > [RP] Subsequence sentence refers to "Domain-wide Common Block" (DCB) RFC > 9573 as an example of "global context". > > > 234 this follows same concept of "Domain-wide Common Block" (DCB) > label > 235 as specified in [RFC9573]. The high order 20 bits of this field > 236 carry the whole or a portion of the Function part of the SRv6 > 237 Multicast Service SID when Transposition Scheme of encoding as > > GV> What is exactly meant with 'this field'? > > > > [RP] The "MPLS Label" field. I will make this explicit. > > > > > 237 Multicast Service SID when Transposition Scheme of encoding as > 238 defined in [RFC9252] is used. When using the Transposition > Scheme, > 239 the Transposition Length of SRv6 SID Structure Sub-Sub-TLV of > SRv6 > > GV> Is there a reason why Transposition Scheme and Length are written with > upper case? > > > > [RP] RFC 9252 uses "Transposition Scheme" and Transposition Length is one > of the fields of the SRv6 SID Structure Sub-SubTLV. > > > 241 less than or equal to the Function Length. When Transposition > scheme > 242 is not used, the label field MUST be set to zero and > Transposition > 243 Length MUST be zero. > > GV> What about error handling? What must a receiver do when it receives a > packet with incorrect label field or Length setting? > > > > [RP] RFC 9252 does not specify any error handling of BGP NLRI updates when > these conditions are not met. But my guess is BGP speaker must validate > these condition and discard the BGP update if these are not met and > potentially log these errors. > > > > > > > 257 set to zero. The locator (LOC) of SRv6 Multicast Service SID > is the > 258 LOC of the advertising ingress PE. The ingress PE MAY user a > non- > > GV> Any restriction for algorithm aware Locators or is algorithm 0 assumed? > > > > [RP] No restrictions, but this section is about sharing SRv6 P2MP trees > across MVPN context, and this SRv6 Multicast Service SID is used to > identify a specific MVPN context at the ingress and egress PEs. i.e. this > SID is not relevant at P routes in SRv6 domain. So, the algo of the Locator > does not really matter. > > > > > 258 LOC of the advertising ingress PE. The ingress PE MAY user a > non- > 259 routable prefix as LOC of the SRv6 Multicast Service SID to > prevent > 260 packets being routed to it based on the SID. The LOC of an SRv6 > > GV> Should this not say s/ingress PE MAY/advertising ingress PE MAY/ ? > > > > [RP] Right. Fixed. > > > > any algorithm awareness or implications? > > [RP] No, as explained above. > > > 264 The ingress PE MUST encapsulate customer payload, steered into a > 265 shared SR P2MP P-Tunnel, in an outer IPv6 header with SRH in > which > > GV> ingress PE or advertising ingress PE? in other sections the > terminology of root node, leaf node and bud node is used. Maybe that could > be used in sectin 3.1.2. also from consistency perspective? > > > > [RP] I have added text stating advertising ingress PE is also the Root > node of the shared SR P2MP tunnel. > > > > > 278 the SRv6 Multicast Service SID. An egress PE MUST NOT install > the > 279 SRv6 Multicast Service SID in it's Forwarding Information Base > (FIB) > 280 i.e. it MUST NOT forward packets based on the Locator portion > of the > 281 SRv6 Multicast Service SID. > > GV> is this correct assumption about installation in the FIB? My > understanding is: > * In the control plane, the SID is associated with a local function. > * In the FIB, the SID is installed with an action that maps to the local > processing behavior. > * The FIB entry does not point to a next-hop but to a local function > handler. > > > > [RP] The only purpose of this SRv6 Multicast Service SID on egress PE is > to identify the MVPN context. So, the SRv6 Tree-SID is installed in the FIB > and the associated local function handler is the End.Replicate behavior > (section 2.2.1 of RFC 9524) and that handler then uses the SRv6 Multicast > Service SID to derive the MVPN contxt (or "Packet Processing Context" as > called in RFC 9524 section 2.2.1). The intention here is the egress PE must > not install this SRv6 Multicast service SID in its *unicast* FIB. This is > to prevent any unintentional forwarding of incoming IPv6 packets based on > the LOC of this SID back to the advertising ingress PE. > > > 288 for SR P2MP tree P-Tunnels. In this section, the term "SR P2MP" > 289 refers to both SR-MPLS and SRv6. > > GV> SR-MPL and SRv6 dataplanes > > > > [RP] Done. > > > > > 381 When a PE originates S-PMSI A-D route with a PTA having SR P2MP > 382 P-Tunnel Type, it MUST set the "Leaf Info Required bit" in the > PTA. > 383 The PE MUST create a Candidate Path of SR P2MP Policy on the > 384 controller. When the controller instantiates an instance of > P2MP > 385 tree on the PE, the Tree-SID MUST be imposed for customer flows > 386 steered into the S-PMSI. > > GV> With sr-mpls the word imposed is used, but for SRv6 there is > encapsulation. Should this be worded differently? > > > > [RP] Actually this imposition is already implied. I will remove this > sentence and similar sentences from other sections aout Intra-AS I-PMSI etc. > > > > > 388 The Leaf nodes of P2MP tree are discovered by Leaf A-D routes > using > 389 procedures described in Section 4.4.2. When a PE originates > S-PMSI > 390 A-D route with a PTA having SR P2MP P-Tunnel Type, it is > possible the > 391 PE might have imported Leaf A-D routes whose route keys match > the > 392 S-PMSI A-D route. The PE MUST re-apply procedures of Section > 4.4.2 > 393 to these Leaf A-D routes. > > GV> What does "these Leaf A-D routes" refer to? Are these the nodes with > matched keys? > should the re-apply be limited to only those specific leaf nodes, and not > to the other leaf nodes of the three? > > > > [RP] "these Leaf A-D routes" refers to the "imported Leaf A-D routes whose > route keys match the S-PMSI A-D route" in the prior sentence. I thought the > context should be clear from these two sentences. > > > > > > > 395 When a PE withdraws a S-PMSI A-D route, advertised with PTA > having > 396 P2MP tree P-Tunnel type, the Tree-SID imposition state MUST be > > GV> What is exactly a "Tree-SID imposition state"? is that yang type of > state? > > > > [RP] It means encapsulation of the payload in SR-MPLS or SRv6 Tree-SID. > But again this is implied and I will remove this paragraph and similar > paragraphs in other sections. > > > 398 Note, the Tree-SID is removed when the controller removes the > P2MP > 399 tree instance. > > GV> s/P2MP/SR P2MP/ > > 401 A PE MAY aggregate two or more S-PMSIs onto the same SR P2MP > 402 P-Tunnel. When a PE withdraws the last S-PMSI A-D route, > advertised > 403 with a PTA identifying a specific SR P2MP P-Tunnel , it MUST > remove > 404 the the Candidate Path of SR P2MP Policy on the controller. > > GV> i am not sure what this exactly means. Does this say that when there > is no longer a need for the sr p2mp tunnels, that the controller must > withdraw them from the network devices (using for example pcep)? that would > mean that at a later moment in time they would be required again, because > there is requirement again that the sr p2mp needs to be re-instantiated > again. Maybe i misunderstood this paragraph > > > > [RP] The ingress PE maps one more more S-PMSI A-D routes onto one SR P2MP > P-tunnel which is instantiated by SR P2MP Policy, or specifically a > Candidate path of an SR P2MP Policy. When this mapping is done (using > S-PMSI Auto-Discovery procedures), the ingress PE signals the controller > (using PCEP, BGP etc.) to create the SR P2MP policy (or specifically a CP > of SR P2MP Policy). The controller then computes the P2MP tree instance of > the Candidate path and instantiates it in the SR domain devices with > Tree-SID as data plane identifier. The ingress PE then steers payload into > the SR P2MP P-tunnel by encapsulating it in the SR-MPLS or SRv6 Tree-SID. > > > > When the mapping is removed i.e. the last S-PMSI A-D route mapped to the > SR P2MP P-tunnel is removed, the ingress PE no longer needs the SR P2MP > tree instance to carry traffic. So it deletes the Candidate path of the SR > P2MP policy on the controller (using PCEP, BGP etc.). The controller then > removes the SR P2MP tree instance from the SR domain and deletes the CP and > SR P2MP Policy. > > > > If at a later time, the S-PMSI A-D route needs a new SR P2MP P-tunnel, the > process above is repeated. > > > > > 416 controller, the PE MUST program Tree-SID for disposition. If > the > 417 P2MP tree is instantiated later, the Tree-SID MUST be > programmed for > 418 disposition at that time. > > GV> What is the intended difference between instantiated and programmed? > > > > [RP] Again, this text is not necessary. Removing it. > > > 424 P-Tunnel. The PE MUST withdraw the Leaf A-D route it had > originated > 425 and remove the Tree-SID disposition state. Note, the Tree-SID > is > 426 removed when the controller removes the P2MP tree instance. > > GV> What does "Tree-SID disposition state" exactly mean? > > > > [RP] It means the necessary data plane state to remove the SR-MPLS or SRv6 > Tree-SID encapsulation and deliver the payload. But, this text has been > removed. > > > 485 which a Leaf A-D is received can be identified by examining the > P2MP > 486 tunnel Identifier in the PTA of A-D route that matches "Route > Key" > 487 field of the Leaf A-D route. When the PE receives the first > Leaf A-D > 488 route from a Leaf PE, identified by the Originating Router's IP > > GV> Is there a specific normative reference/definition of what is included > is the "route key"? > > > > [RP] It is in Section 9.2.3.5 of RFC 6514 which is already referred to at > the beginning of Section 4.4.2, but I will add the reference here again. > > > 492 When a Leaf PE withdraws the last Leaf A-D route for a given SR > P2MP > 493 P-Tunnel, the Root PE MUST remove the Leaf PE from the SR P2MP > Policy > 494 on the controller. Note that Root PE MAY remove the SR P2MP > Policy > 495 on the controller, before the last Leaf A-D is withdrawn. In > this > 496 case, the Root PE MAY not need to remove the Leaf from SR P2MP > 497 Policy.. > > GV> double .. at end of the paragraph > GV> I assumed that the controller instantiate sr p2mp on the routers > (roots/leafs/buds), and not the other way around. > Could it be that "Root PE MAY remove the SR P2MP Policy on the controller" > should say "Root PE MAY remove the SR P2MP Policy ***FROM*** the controller" > > > > [RP] Yes, I will change it to FROM. I have also modified text to clarify > what it mean to "remove Leaf PE from the SR P2MP Policy." > > > 502 Routing. Customer payload is encapsulated in SR-MPLS or IPv6 > (SRv6) > 503 at Ingress PE. The encapsulated payload is replicated and a > unicast > > GV> s/encapsulated in SR-MPLS or IPv6 (SRv6)/encapsulated in SR-MPLS or > SRv6/ > it looks odd to say first sr-mpls and the IPv6 (SRv6), if this is > required, then maybe say MPLS (SR-MPLS) or IPv6 (SRv6) for consistency. or > simply directly say SRv6 instead. > > > > [RP] Ok. > > > 510 Ingress Replication. Egress PEs join as Leaf Nodes using > Intrra-AS > > GV> s/intrra-AS/intra-AS/ > > 522 5.1. SR-MPLS > 523 > 524 Procedures of RFC 7988 are sufficient to create a SR-MPLS > Ingress > 525 Replication for MVPN service. > 526 > 527 If an egress PE colors the Leaf A-D route with Colo Extended > 528 Community, the ingress PE encapsulates the payload packet into > 529 segment list of (Color, egress PE) SR-TE policy along with IR > label > 530 received from the egress PE. Suppose the egress PE, say PE2, > sends > 531 Leaf A-D route with extended color community C1 and IR label > L10. > 532 Assume the segment list of SR-TE policy (C1, PE2) at ingress > PE1 is > 533 <L1, L2, L3>, PE1 will encapsulate MVPN customer payload into > MPLS > 534 label stack <L1, L2, L3, L10> with L10 as BoS label. > > GV> If the procedures in RFC7988 are sufficient from procedure > perspective, then the example provided line 527-534 is maybe not required > for the content of the document? > > > > [RP] The procedures of RFC 7988 are sufficient for MVPN service without an > SLA (clarified in the text). The next paragraph describes how MVPN IR > service with SLA can be realized as new procedures in this document. > > > GV> consider expanding IR on the first usage (line529) > > 538 Procedures of RFC 7988, along with modifications described in > this > 539 Section, are sufficient to create a SRv6 Ingress Replication > for MVPN > 540 service. > > GV> what about something in the style of: > > " > The procedures specified in [RFC7988], with the modifications defined in > this section, MUST be used to construct an SRv6 Ingress Replication tree > for MVPN service. > " > > [RP] Ok. > > > 542 The PTA carried in Intra-AS, Inter-AS, Selective PMSI and Leaf > Auto- > 543 Discovery routes is constructed as specified in RFC 7988 with > 544 modifications as below: > > GV> Can the correct full names of the routes be used for normative > purpose? > for example: Intra-AS -> Intra-AS I-PMSI A-D route > > > > [RP]. Done. > > > > > 561 Replication, these sections apply to SRv6 Multicast Service SID. > > GV> unclear if the term "these sections" refer to the sections following > the paragraph or if it was referring to the sections 6 and 7. > > > > [RP] Section 6 and 7 of RFC 7988. Reworded text to clarify this. > > > 563 To join a SRv6 Ingress Replication P-Tunnel advertised in PTA of > > GV> is it the intention that the use of "IR" vs "Ingress Replication" is > inconsistent? sometimes IR is used and sometimes the expanded term. > > > > [RP] Tried to make it consistent with IR except where "Ingress > Replication" is needed for reference etc. > > > > > 564 Inra-AS, Inter-AS, or Selective S-PMSI A-D routes, an egress PE > > > GV> has typo's and is not using the correct standardized route names > > > > [RP] Fixed. > > > > > 566 7988 with modified PTA above. The egress PE attaches a BGP > Prefix- > 567 SID attribute [RFC8669] in Leaf A-D or Intra-AS I-PMSI route > with > 568 SRv6 L3 Service TLV [RFC9252] to signal SRv6 Multicast Service > SID . > > GV> does it attach the attribute 'in' or 'upon' leaf A-D or Intra-AS > I-PMSI route? > > > > [RP] A better word is "with". Changed it. > > > > > 570 SID in SRv6 SID Value field. The SRv6 Endpoint Behavior of the > SRv6 > 571 SID Information Sub-TLV encodes one of End.DTMC4, End.DTMC6 or > 572 End.DTMC46 code point value. The SRv6 SID Structure Sub-Sub-TLV > > GV> Is there error handling needed when more as one of these code points > values are encoded? > > > > [RP] Did you mean "more than one of these code points are encoded"? If so, > there is only one Endpoint Behavior field in SRv6 SId Information Sub-TLV. > > I have changed the text to say "MUST encode one of ...." > > > 573 encodes the structure of SRv6 Multicast Service SID. If > 574 Transposition scheme is used, the offset and length of SRv6 > Multicast > 575 Endpoint function of SRv6 Multicast Service SID is set in > 576 Transposition Length and Transposition Offset fields of this > sub-sub > 577 TLV. Otherwise, the Transposition Length and Offset fields > MUST be > 578 set to zero. The BGP Prefix SID attribute with SRv6 L3 Service > TLV > 579 in Intra-AS I-PMSI or Leaf A-D route indicates to ingress PE > that > 580 egress PE supports SRv6. > > GV> When going through the text, the explanation about trans positioning > is used in various places and sounds repetitive. Is that needed? can it not > be explained once and then references to reduce repetitive nature? > > > > [RP] This is used for different procedures. Earlier text for Transposition > is for sharing SRv6 P2MP P-tunnels across MVPNs whereas here it is required > for basic SRv6 IR procedure. > > > 582 The SRv6 Multicast Service SID SHOULD be routable within the AS > of > 583 the egress PE. As per RFC 7988, the Ingress PE uses the Tunnel > 584 Identifier of PTA to determine the unicast tunnel to use in > order to > 585 send data to the egress PE. This document requires the ingress > PE to > > GV> I am wondering about something that confuse me. On line 258-259 it is > mentioned that the ingress PE MAY use a non-routable prefix. Is this not > conflicting with the text used in this paragraph "SHOULD be routable"? What > happens if it is not routable? Is this not a MUST instead of a SHOULD? > > > > [RP] Again, the lines 258-259 are in Section where SRv6 Multicast Service > SID is used to derive the MVPN context for shared SRv6 P2MP P-tunnels. As I > have explained in detail in a response above, the SRv6 SID in this case is > significant only on the ingress and egress PEs and therefore the SRv6 > Multicast Service SID does not need to be routable. > > > > For IR, the SRv6 Multicast Service SID needs to be routable since its LOC > carries the encapsulated payload from the ingress to one egress PE. I will > change it to MUST. > > > > > 585 send data to the egress PE. This document requires the ingress > PE to > 586 use the SRv6 Multicast Service SID to determine the unicast > tunnel to > 587 be used. For best-effort MVPN service or SLA based MVPN service > > GV> The 'requires' sounds as if it is normative requirement, and maybe the > BCP14 language should be used instead to make this even more clear? > > > > [RP] Done. > > > > > 587 be used. For best-effort MVPN service or SLA based MVPN service > 588 using IGP Flexible Algorithm, the ingress PE MUST encapsulate > payload > 589 in an outer IPv6 header with the SRv6 Multicast Service SID > provided > 590 by the egress PE as the destination address. If Transposition > scheme > > GV> What about: > > " > For both best-effort MVPN service and SLA-based MVPN service using IGP > Flexible Algorithm, the ingress PE MUST encapsulate the payload in an outer > IPv6 header, with the SRv6 Multicast Service SID provided by the egress PE > used as the destination address. > " > > > > [RP] Ok. > > > > > 594 Multicast Service SID > 595 If an egress PE colors a Leaf A-D route with Color Extended > > GV> there should be section divider (empty line). Something went odd with > rendering the txt field > > > > [RP] Fixed. > > > 596 Community, the ingress PE SHOULD encapsulate the payload packet > into > > GV> if there a reason this is a SHOULD instead of a MUST? a SHOULD allows > implementors to differently and break operator SLA expectations. > > > > [RP] Sometimes an operator may prefer a backup option if the SLA cannot be > met (for example when the ingress PE cannot resolve the unicast SR-TE > policy (Color, Egress PE) to a segment list). In such scenarios encoding > the SRv6 Multicast Service SID directly as the destination address of > encapsulating IPV6 header will get the payload to the egress PE, even > though it might not satisfy the SLA. Of course, this is dependent on > implementation and provisioning based on operator's requirements. Hence, > SHOULD and not MUST. > > > > > 599 route from the egress PE using SRH. Suppose the egress PE, say > PE2, > 600 sends Leaf A-D route with extended color community C1 and SRv6 > 601 Multicast Service SID S10. Assume the segment list of SR-TE > policy > 602 (C1, PE2) at ingress PE1 is <S1, S2, S3>, PE1 will encapsulate > MVPN > 603 customer payload into IPv6 header with SRH (PE1, S1) (S10, S3, > S2; > 604 SL=3) (payload). If SRv6 SID compression is used, the ingress > PE > 605 SHOULD use Compressed SID (C-SID) containers for the policy > segments. > > GV> line605: why is BCP14 language used during an example? Can the > expected procedure be prescribed in anoter place in the text? > > > > [RP] Are you referring to the "SHOULD" in last sentence about C-SID? If > so, I can remove this sentence, as it is not particularly significant for > SRv6 IR in this document. > > > > GV2> Yes, indeed. Using formal BCP14 terminology in examples is frowned > upon when going through IESG ballot. > > > > > GV> What about for the example: > > " > Suppose the egress PE (PE2) advertises a Leaf A-D route with Extended > Color Community C1 and SRv6 Multicast Service SID S10. If the ingress PE > (PE1) selects an SR Policy identified by (C1, PE2) with a segment list <S1, > S2, S3>, then PE1 MUST encapsulate the MVPN customer payload in an outer > IPv6 header with an SRH as follows: > > [IPv6 Header: Src=PE1, Dst=S1] > [SRH: Segments Left=3, Segments=<S10, S3, S2>] > [Payload] > > If SRv6 SID compression is used, the ingress PE SHOULD encode the policy > segments using Compressed SID (C-SID) containers. > > > > [RP] See the previous response. > > > > " > > 615 The "Endpoint with decapsulation and specific IPv4 Multicast > table > 616 lookup" behavior ("End.DTMC4" for short) is similar to End.DT4 > 617 behavior of RFC 8986 except the lookup is in IPv4 multicast > table. > > GV> what about, adding bcp14 language (This avoids "similar to," clarifies > the exception precisely, and uses MUST to make the forwarding behavior > normative.): > > " > The Endpoint with Decapsulation and IPv4 Multicast Table Lookup behavior > (abbreviated End.DTMC4) is functionally identical to the End.DT4 behavior > specified in [RFC8986], except that the forwarding lookup MUST be performed > in the IPv4 multicast routing table rather than the unicast IPv4 routing > table. > " > > 622 The "Endpoint with decapsulation and specific IPv6 Multicast > table > 623 lookup" behavior ("End.DTMC6" for short) is similar to End.DT6 > 624 behavior of RFC 8986 except the lookup is in IPv6 multicast > table. > > GV> what about, adding bcp14 language (This avoids "similar to," clarifies > the exception precisely, and uses MUST to make the forwarding behavior > normative.): > > " > The Endpoint with Decapsulation and IPv6 Multicast Table Lookup behavior > (abbreviated End.DTMC6) is functionally identical to the End.DT6 behavior > specified in [RFC8986], except that the forwarding lookup MUST be performed > in the IPv6 multicast routing table rather than the unicast IPv6 routing > table. > " > > 629 The "Endpoint with decapsulation and specific IP Multicast table > 630 lookup" behavior ("End.DTMC46" for short) is similar to End.DT4 > and > 631 End.DT6 behaviors of RFC 8986 except the lookup is in IP > multicast > 632 table. > > GV> what about, adding bcp14 language (This avoids "similar to," clarifies > the exception precisely, and uses MUST to make the forwarding behavior > normative.): > > " > The Endpoint with Decapsulation and IP Multicast Table Lookup behavior > (abbreviated End.DTMC46) is functionally identical to the End.DT4 and > End.DT6 behaviors specified in [RFC8986], except that the forwarding lookup > MUST be performed in the IP multicast routing table rather than in an IP > unicast routing table. > " > > > > [RP] Done for all three above. > > > > 636 When P2MP trees are used as P-Tunnels for S-PMSI A-D routes, > change > > GV> maybe explicit spell out that S-PMSI A-Droutes are really the Intra-AS > S-PMSI A-D route, Inter-AS S-PMSI A-D route, Leaf A-D route > > > > [RP] No, the text is correct. S-PMSI A-D routes are per (C-S,C-G) or > (C-*,C-G) (i.e. per MVPN customer (*,G) or (S,G) states) and if group > membership changes rapidly, Leaf A-D routes (used to signal participation > of a particular egress PE in the SR P2MP P-tunnel of the S-PMSI A-D route), > can be originated/withdrawn continuously. Each such change can lead the > ingress PE to add or remove egress PEs as Leaf nodes from the SR P2MP > Policy that is used for the SR P2MP P-Tunnel. Hence the next paragraph in > the section recommending dampening of Leaf A-D routes. > > > > Intra-AS and Inter-AS I-PMSI A-D routes are per MVPN and are unaffected by > group membership changes in the MVPN. > > > > > 645 7899 [RFC7899]. PEs MAY also implement procedures for damping > other > 646 Auto-Discovery and BGP C-multicast routes as described in > [RFC7899]. > > GV> should "BGP C-multicast routes" be nailed down to: C-multicast Source > Tree Join, C-multicast Source Tree Prune, C-multicast Shared Tree > Join/Prune, C-multicast Switching (S,G) Join triggered by (S,G,rpt) Prune, > Bidirectional PIM-specific C-multicast signalling > > > > [RP] Yes, but only to C-multicast Source Tree Join and C-multicast Shared > Tree Join routes. Other route types do not exist. PIM and Bidir-PIM > C-multicast signalling is out of scope of this document. > > > > > 657 [RFC9572] updates BUM procedures to support selective P-Tunnels > and > 658 P-Tunnel segmentation in EVPN. That document specifies new > route > 659 types that are advertised with PTA, including Selective PMSI > (S-PMSI) > 660 Auto-Discovery route. > > GV> What about: > > " > [RFC9572] updates the EVPN Broadcast, Unknown unicast, and Multicast (BUM) > procedures to support selective P-tunnels and P-tunnel segmentation. That > document defines new BGP route types that MUST be advertised with a PMSI > Tunnel Attribute (PTA), including the Selective PMSI (S-PMSI) > Auto-Discovery route. > " > > > > [RP] Ok. > > > > > 662 These inclusive/selective P-Tunnels can be realized by SR P2MP > trees. > 663 As with other types of P2MP P-Tunnels, the ESI label used for > split > 664 horizon MUST be either upstream assigned by PE advertising the > IMET > 665 or S-PMSI route, or assigned from a global context such as > "Domain- > 666 wide Common Block" (DCB) as specified in [RFC9573]. > > GV> > > " > Inclusive and Selective P-tunnels MAY be instantiated using SR P2MP trees. > As with all other types of P2MP P-tunnels, the Ethernet Segment Identifier > (ESI) label used for split-horizon MUST either be: > > 1. upstream-assigned by the PE that advertises the corresponding IMET or > S-PMSI route, or > 2. allocated from a global context, such as the Domain-wide Common Block > (DCB), as specified in [RFC9573]. > " > > [RP] Ok. > > > > 668 [RFC9625] specifies procedures to support Inter-Subnet > Multicast. > 669 [I-D.ietf-bess-evpn-mvpn-seamless-interop] specifies how MVPN > SAFI > 670 routes can be used to support Inter-Subnet Multicast. The > P-Tunnels > 671 advertised in PTA of either EVPN and MVPN routes as specified in > 672 these documents respectively can be realized by SR P2MP trees. > > GV> > > " > [RFC9625] specifies the procedures to support Inter-Subnet Multicast. > [I-D.ietf-bess-evpn-mvpn-seamless-interop] specifies how MVPN SAFI routes > are used to support Inter-Subnet Multicast. The P-tunnels carried in the > PTA of EVPN routes and MVPN routes, as specified in these documents, MAY be > instantiated using SR P2MP trees. > > " > > > > [RP] Ok/ > > > 674 SRv6 P2MP trees can serve as an underlay multicast as described > in > 675 RFC 8293 Section 3.4 ( > https://tools.ietf.org/html/rfc8293#section- > 676 3.4). A NVE encapsulates a tenant packet in an SRv6 header and > 677 deliver it over SRv6 P2MP trees to other NVEs. > > GV> > > " > SRv6 P2MP trees MAY be used as an underlay multicast mechanism, as > described in [RFC8293], Section 3.4. In this case, a Network Virtualization > Edge (NVE) MUST encapsulate tenant packets in an SRv6 header and deliver > them over SRv6 P2MP trees to other NVEs. > " > > 679 The same procedures specified for MVPN are used to collect the > leaf > 680 information of corresponding SR P2MP tree (either based on IMET > route > 681 or Leaf A-D routes in response to x-PMSI routes), to pass the > tree > 682 information to the controller controller, and to get back tree > 683 forwarding state used for customer multicast traffic forwarding. > > GV> explain in where x-PMSI is defined, or add terminology section. > > GV> what about spaying some BCP14 language onto the text: > > " > The procedures specified for MVPN MUST be used to collect the leaf > information of the corresponding SR P2MP tree. This leaf information is > obtained either from IMET routes or from Leaf A-D routes in response to > x-PMSI routes. The ingress PE or controller MUST pass the tree information > to the controller, and the controller MUST return the tree forwarding > state, which is then used for customer multicast traffic forwarding. > " > > [RP] Re-worded in a different way. > > > Gunter Van de Velde > RTG Area Director > > > > > > > _______________________________________________ > BESS mailing list -- [email protected] > To unsubscribe send an email to [email protected] > >
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
