RFC 7473 SAC stands for Selective Advertisement Capability. Thanks
Gyan On Wed, Jan 4, 2023 at 2:36 AM Gyan Mishra <hayabusa...@gmail.com> wrote: > > +1 > > Segment Routing has been built for unicast routing for both SR-MPLS and > SRv6 flavors - “Unicast SR”. > > All legacy existing technologies as Jeffrey described MVPN PTAs that exist > today can all be used with SR and are fully supported with “Unicast SR”. > > So there is no rule that legacy MVPN PTA technologies cannot be used with > SR and are used today widespread worldwide. > > As well MPLS, SR-MPLS and SRv6 can done as dual or multi plane deployments > multiple ships in the night where SRv6 network can be used for all Unicast > traffic snd LDP can still be leveraged for just multicast only traffic. > > MVPN legacy stateful PTA’s RFC 6514 all fully supported by SR > > + 0 - No tunnel information present > + 1 - RSVP-TE P2MP LSP > + 2 - mLDP P2MP LSP > + 3 - PIM-SSM Tree > + 4 - PIM-SM Tree > + 5 - BIDIR-PIM Tree > + 6 - Ingress Replication > + 7 - mLDP MP2MP LSP > > > BIER is along the lines of stateless > > Also BGP Multicast and Multicast Controller are as well stateless and > along the lines of SR > > https://datatracker.ietf.org/doc/html/draft-ietf-bess-bgp-multicast-00 > > > https://datatracker.ietf.org/doc/html/draft-ietf-bess-bgp-multicast-controller/ > > > RFC 7473 Controlling State Advertisements of Non Negotiated LDP > applications code name (SAC knob) > > So with this SAC knob disabled LDP label exchange label mapping message > for unicast prefixes. > > So this eliminates the footprint of LDP in the stack of protocols > eliminates LDP unicast without having to completely remove LDP and allows > mLDP extension to continue to be used for multicast applications only. > > Replication SID used as a building block for Tree SID is the first SR > based “IR style” attempt for a P2MP SR based policy for operators that want > to completely eliminate LDP from the network. > > This is highly valuable and desirable for operators wanting to completely > eliminate LDP. > > https://datatracker.ietf.org/doc/html/draft-ietf-pim-sr-p2mp-policy > > SR eliminates forwarding state provided by LDP label mapping message LFIB > by placing all the forwarding stare into the packet by leveraging the SR > IGP extensions to eliminate the same LDP mapping message label distribution > which is now being done via SR IGP extension. As well RSVP-TE elimination > and putting the steering forwarding state into the packet with SR policy > BSID binding candidate path for SID list or label stack to forwarding > plane pushed onto the packet. > > So that is what makes SR “stateless”. > > SRs goal is for simplicity and elimination of as many protocols as > possible using the KISS principle. > > However there is still plenty of state with IGP which is something that > you cannot eliminate as well as BGP state. > > However, when we talk about stateless in the context of SR it’s data > plane forwarding plane state (LDP and RSVP-TE) elimination that we are > talking about and not control plane state elimination (IGP / EGP). > > Hope this explanation helps! > > Kind Regards > > Gyan > > On Mon, Dec 12, 2022 at 9:08 AM Jeffrey (Zhaohui) Zhang <zzhang= > 40juniper....@dmarc.ietf.org> wrote: > >> Hi, >> >> >> >> Replication trees built with replication segments do have per-tree state. >> However please consider the following: >> >> >> >> While an SR network does not need per-path state for unicast, it does not >> mean that multicast must strictly follow the same. Any of the following >> could be used, depending on an operator’s choice. >> >> >> >> 1. Ingress Replication or BIER >> 2. Traditional PIM or mLDP/RSVP P2MP solutions that maintain per-tree >> state for efficient replication >> 3. Replication tree based on replication segments but signaled from >> controllers via PCEP/BGP/NETCONF/whatever >> 4. Other options that are in the discussion in PIM/BIER WGs (e.g., >> BIER-RBS, encoding sub-tree in SRH) >> >> >> >> #1 is actually independent of SR, yet it sticks to SR principle (of no >> per-tree state in network) perfectly. However, we also need non-IR/BIER >> solutions for SR networks. >> >> >> >> Nobody can reject #2 as a valid option. For the same reason, #3 is also >> valid and it is what this WGLC is about. #3 allows an SR operator to use >> controller-based calculation & signaling and move away from PIM/mLDP/RSVP – >> to me that goes very well with SR even though it still has per-tree state. >> >> >> >> #3 with MPLS data plane is identical to #2 in the data plane, though >> we’re introducing this new “replication segment” term to go with the big SR >> framework. It is also the only non-BIER, non-legacy solution for SR-MPLS >> data plane (so far). >> >> >> >> For #3 with SRv6 data plane, while in concept it is similar to #3 with >> MPLS (the FUNCT bits of an SRv6 SID are the equivalent of P2MP label), we >> do need the replication segment concept and corresponding endpoint behavior >> defined for SRv6. >> >> >> >> In short, this document introduces the replication segment concept and >> defines the corresponding SRv6 endpoint behavior. It provides the building >> block for replication trees in SR network that are not necessarily set up >> via traditional means, and it does not exclude other solutions. >> >> >> >> Thanks. >> >> Jeffrey >> >> >> >> >> >> >> >> Juniper Business Use Only >> >> *From:* spring <spring-boun...@ietf.org> *On Behalf Of *Aijun Wang >> *Sent:* Saturday, December 10, 2022 8:35 PM >> *To:* Robert Raszuk <rob...@raszuk.net> >> *Cc:* SPRING WG <spring@ietf.org>; spring-cha...@ietf.org; Huaimo Chen < >> huaimo.c...@futurewei.com> >> *Subject:* Re: [spring] WGLC for draft-ietf-spring-sr-replication-segment >> >> >> >> *[External Email. Be cautious of content]* >> >> >> >> Hi, Joel and Robert: >> >> >> >> I think we should clarify what’s kind of state is that we are talking >> first before making any assertions. >> >> >> >> What we should avoid in Segments Routing panoramic view is that we >> shouldn’t introduce the per-flow state within the network. >> >> >> >> Consider the different multicast services require different multicast >> trees, you need to store different “Replications Segments” for different >> multicast services. >> >> Isn’t this per-flow state? >> >> >> >> Based on the same principle, the Binding-SID introduces also some kind of >> per-flow state in the network——if every different flow needs to take >> different paths at the advertising node——In such case, you need to keep >> many or per-flow Binding-SID at the advertising node. It violates certainly >> the dogmas of segment routing. >> >> >> >> The other SIDs(or that defined in RFC8986)that you mentioned are the >> states about the action of the related segment value and they are not >> Path-related, we can omit them. >> >> >> >> In summary, the “Replication Segment SID” that introduced in this draft >> has the similar effects that the MPLS label derived from the various >> distribution protocol of multicast VPN solutions. Will you also call these >> MPLS states within the transit nodes as segment routing based? >> >> >> >> Aijun Wang >> >> China Telecom >> >> >> >> On Dec 11, 2022, at 08:02, Robert Raszuk <rob...@raszuk.net> wrote: >> >> >> >> Joel, >> >> >> >> Yes IMO your understanding is correct. >> >> >> >> That does also mean that anyone who is making assertions that the subject >> document is introducing per flow "state" is just wrong or simply does not >> understand SR dogmas. >> >> >> >> Cheers, >> Robert. >> >> >> >> >> >> >> >> On Sun, Dec 11, 2022 at 12:42 AM Joel Halpern <j...@joelhalpern.com> >> wrote: >> >> Speaking personally, my understanding of the "stateless" aspect of SR >> does not match what this email seems to describe. >> >> SR is path stateless. There is no state related to specific paths across >> the network. Any SID may be used, if it has relevant meaning, in any path. >> >> Advertising routers have internal state about what they mean when the >> advertise SIDs. >> >> Transit rotuers have state about where to forward packets based on the >> current SID in the packet. >> >> Binding SIDs have stored state about what stack of labels replace the >> binding SID at the advertising router. >> >> All these forms of state are considered by the community, as far as I can >> tell, as acceptable and reasonable forms of state with SR. >> >> >> >> Personally, it seems to me that replication SIDs have much the same kinds >> of state, and therefore fit well in the SR architecture. >> >> Yours, >> >> Joel >> >> >> >> On 12/9/2022 11:53 AM, Huaimo Chen wrote: >> >> Hi Everyone, >> >> >> >> It seems that the core value of segment routing is stateless (in the >> core of a network). The document defines a new type of segment for >> Segment Routing [RFC8402], called Replication segment. Using Replication >> segment is not stateless. This is not consistent with the core value of >> segment routing. I oppose the progress of the document. >> >> >> >> Best Regards, >> >> Huaimo >> ------------------------------ >> >> *From:* spring <spring-boun...@ietf.org> <spring-boun...@ietf.org> on >> behalf of James Guichard <james.n.guich...@futurewei.com> >> <james.n.guich...@futurewei.com> >> *Sent:* Monday, November 28, 2022 10:10 AM >> *To:* SPRING WG <spring@ietf.org> <spring@ietf.org> >> *Cc:* spring-cha...@ietf.org <spring-cha...@ietf.org> >> <spring-cha...@ietf.org> >> *Subject:* [spring] WGLC for draft-ietf-spring-sr-replication-segment >> >> >> >> Dear WG: >> >> >> >> This email starts a 2-week Working Group Last Call for >> https://datatracker.ietf.org/doc/draft-ietf-spring-sr-replication-segment/ >> <https://urldefense.com/v3/__https:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fdraft-ietf-spring-sr-replication-segment*2F&data=05*7C01*7Chuaimo.chen*40futurewei.com*7C385b4881095c41b2c27008dad152b258*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C1*7C638052450396258660*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C2000*7C*7C*7C&sdata=Xc85avPl8dZMqGuCSXAA6f89OTvRfQfQ6MGa9NCQnBE*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!Aap0ylLmZYJ1m1MjpemXu4Fz7a4wq8hOk2RxE7cl_MTy9LmWoS0sxaf9JZve052OYvuoksWxsH1wBIomHPupKiGX$> >> >> >> >> Please read the updated document if you haven’t already and send your >> comments to the SPRING WG list no later than December 12th 2022. >> >> >> >> If you are raising a point which you expect will be specifically debated >> on the mailing list, consider using a specific email/thread for this point. >> >> >> >> Lastly, if you are an author or contributor please respond to indicate >> whether you know of any undisclosed IPR related to this document. >> >> >> >> Thanks! >> >> >> >> Jim, Joel & Bruno >> >> >> >> >> >> >> >> _______________________________________________ >> >> spring mailing list >> >> spring@ietf.org >> >> https://www.ietf.org/mailman/listinfo/spring >> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!Aap0ylLmZYJ1m1MjpemXu4Fz7a4wq8hOk2RxE7cl_MTy9LmWoS0sxaf9JZve052OYvuoksWxsH1wBIomHJ7SA_l8$> >> >> _______________________________________________ >> spring mailing list >> spring@ietf.org >> https://www.ietf.org/mailman/listinfo/spring >> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!Aap0ylLmZYJ1m1MjpemXu4Fz7a4wq8hOk2RxE7cl_MTy9LmWoS0sxaf9JZve052OYvuoksWxsH1wBIomHJ7SA_l8$> >> >> _______________________________________________ >> spring mailing list >> spring@ietf.org >> https://www.ietf.org/mailman/listinfo/spring >> >> _______________________________________________ >> spring mailing list >> spring@ietf.org >> https://www.ietf.org/mailman/listinfo/spring >> > -- > > <http://www.verizon.com/> > > *Gyan Mishra* > > *Network Solutions A**rchitect * > > *Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>* > > > > *M 301 502-1347* > > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>* *M 301 502-1347*
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
