Hello Gyan, I have read your comment few times. but can't parse it.
Is this a question ? A concern ? Just comment ? You say: "Is that true and if so that is a major design concern for migration of customers to a SRv6 core." But what is that ? I am very happy to answer any questions you may have in honest way, but just need to understand what the question really is. Thx, R. On Fri, Oct 4, 2019 at 1:03 AM Gyan Mishra <hayabusa...@gmail.com> wrote: > > Hi Robert > > In-line question > > Sent from my iPhone > > On Oct 3, 2019, at 11:01 AM, Robert Raszuk <rob...@raszuk.net> wrote: > > Hi Linda, > > Nope. Nodes except egress have any reason to look at VPN label. That label > has only local significance on egress. > > Thx, > R. > > > Robert > > From an operator perspective ease of implementation and migration is > critical to deployment. > > So just as with SR-MPLS where you can prefer SR over mpls and it’s a swap > of the “topmost label” in the label stack and all VPN services label at the > bottom of the stack remain unchanged. Drawing an analogy to SRv6 scenario > that would it be exactly the same it sounds like that L3 VPN vpn label > remains intact for vpnv4 vpnv6 scenario and IP native native IPv4 / IPv6 > encapsulation IP/MPLS remains the same no change and it’s just the > “topmost” label gets swapped out from either legacy mpls LDP/TE to either > SR-MPLS or now SRv6 topmost label. The services bottom label are only > imposed by ingress PE as with legacy mpls and per SRv6 End SID programming > is either PSP or USP popped similar to legacy mpls PHP UHP and VPN label is > then processed by the egress PE identical to how it’s done with SR-MPLS or > legacy mpls. > > So from an operator perspective such as Verizon that does make it > attractive and an easy swap out migration or new green field implementation > to migrate to SRv6 as all the customer Edge PE-CE protocols and > encapsulation VPN related services L3 VPN. MVPN EVPN PBB VPWS e-tree e-lan > e-line does not change for any services bottom labels. > > Is that true and if so that is a major design concern for migration of > customers to a SRv6 core. > > With SR-TE now we would have native TE capabilities with SRv6 over SR-MPLS > so that we can individually color each per vpn flow to an SR-TE tunnel > over SRv6 core. I am stating that correctly that is the major benefit of > SRv6 over SR-MPLS. > > Gyan > Verizon Communications > Cell phone 301 502-1347 > > > On Thu, Oct 3, 2019 at 4:45 PM Linda Dunbar <linda.dun...@futurewei.com> > wrote: > >> Robert, >> >> >> >> Thank you very much for the explanation. >> >> With the L3VPN case, there are nodes between Egress and Ingress PEs that >> do look into the VPN label carried by the packets for VRF & IP lookup, >> correct? >> >> I was just confused of the statement about “all nodes between Egress & >> Ingress PE are SR unaware plain IP forwarding nodes”. >> >> >> >> Thanks, >> >> >> >> Linda >> >> >> >> *From:* Robert Raszuk <rob...@raszuk.net> >> *Sent:* Thursday, October 03, 2019 3:50 AM >> *To:* Linda Dunbar <linda.dun...@futurewei.com> >> *Cc:* draft-dawra-bess-srv6-servi...@ietf.org; bess@ietf.org >> *Subject:* Re: [bess] WG adoption and IPR poll for >> draft-dawra-bess-srv6-services-02 >> >> >> >> Linda, >> >> >> >> SRv6 services is just a general term used here. Imagine one of such >> service is L3VPN. VPN label (or pointer to it) is needed to be carried >> somewhere in the packet as address space may be overlapping between VPN >> customers and simple IP lookup will not be sufficient to determine VRF or >> exit interface. >> >> >> >> One option which has been done and deployed is to encode it natively in >> the packet and on ingress simply apply prodecures of IPv4 or IPv6 >> encapsulation - RFC4797 and RFC7510 >> >> >> >> The other new option is to take the VPN label or VPN demux value and >> encode it in SRH or in DO. >> >> >> >> Now which option to choose is left for the operator to decide likely >> depending on a lot of other factors involved. >> >> >> >> Thx, >> >> R. >> >> >> >> On Thu, Oct 3, 2019 at 5:52 AM Linda Dunbar <linda.dun...@futurewei.com> >> wrote: >> >> I support WG adoption of the draft, with the following questions. Hope >> authors can help to explain: >> >> >> >> Section 1 Introduction states that the underlay between the Ingress and >> Egress only needs to support plain IPv6 >> >> Forwarding. Those plain IPv6 routers don't need to understand the SR >> policies encoded in the payload, correct? >> >> Why need Ingress PE to encapsulate the policy sent by egress PE if all >> the nodes between them are plain IPv6 routers? >> >> >> >> Which PE is to enforce the SR policy? >> >> If the policies are for the egress to enforce, why can't the egress PE >> simply enforce the policy instead of asking ingress node to encapsulate the >> policy in the packet header? Which has the drawback of extra header bits in >> packets. >> >> >> >> Linda Dunbar >> >> >> >> >> >> *From: *"Bocci, Matthew (Nokia - GB)" <matthew.bo...@nokia.com> >> *Date: *Friday, September 27, 2019 at 4:00 AM >> *To: *"draft-dawra-bess-srv6-servi...@ietf.org" < >> draft-dawra-bess-srv6-servi...@ietf.org>, "bess@ietf.org" <bess@ietf.org> >> *Subject: *WG adoption and IPR poll for >> draft-dawra-bess-srv6-services-02 >> *Resent-From: *<alias-boun...@ietf.org> >> *Resent-To: *<gdawra.i...@gmail.com>, <cfils...@cisco.com>, < >> pbris...@cisco.com>, Swadesh Agrawal <swaag...@cisco.com>, < >> daniel.vo...@bell.ca>, <daniel.bern...@bell.ca <daniel..bern...@bell.ca>>, >> <d...@steinberg.net>, <rob...@raszuk.net>, <bruno.decra...@orange.com>, < >> satoru.matsush...@g.softbank.co.jp>, <zhuangshun...@huawei.com>, < >> jorge.raba...@nokia.com> >> *Resent-Date: *Friday, September 27, 2019 at 4:00 AM >> >> >> >> Hello, >> >> >> >> This email begins a two-weeks WG adoption poll for >> draft-dawra-bess-srv6-services-02 [1] . >> >> >> >> Please review the draft and post any comments to the BESS working group >> list. >> >> >> >> We are also polling for knowledge of any undisclosed IPR that applies to >> this Document, to ensure that IPR has been disclosed in compliance with >> IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). >> >> >> >> If you are listed as an author or a contributor of this document, please >> respond to this email and indicate whether or not you are aware of any >> relevant undisclosed IPR, copying the BESS mailing list. The document won't >> progress without answers from all the authors and contributors. >> >> Currently, there are no IPR disclosures against this document. >> >> >> >> If you are not listed as an author or a contributor, then please >> explicitly respond only if you are aware of any IPR that has not yet been >> disclosed in conformance with IETF rules. >> >> >> >> This poll for adoption closes on Friday 11th October 2019. >> >> >> >> Regards, >> >> Matthew and Stephane >> >> >> >> [1] https://datatracker.ietf.org/doc/draft-dawra-bess-srv6-services/ >> <https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-dawra-bess-srv6-services%2F&data=02%7C01%7Clinda.dunbar%40futurewei.com%7Ccda46858450b47cddd2908d747deab0f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637056893990134792&sdata=KplKMUlBMxL1hSt2ZMbYHpChddEsDhTRrUOLH7e7gaQ%3D&reserved=0> >> >> >> >> >> >> _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess > >
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
