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 <[email protected]> Sent: Thursday, October 03, 2019 3:50 AM To: Linda Dunbar <[email protected]> Cc: [email protected]; [email protected] 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 <[email protected]<mailto:[email protected]>> 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)" <[email protected]<mailto:[email protected]>> Date: Friday, September 27, 2019 at 4:00 AM To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: WG adoption and IPR poll for draft-dawra-bess-srv6-services-02 Resent-From: <[email protected]<mailto:[email protected]>> Resent-To: <[email protected]<mailto:[email protected]>>, <[email protected]<mailto:[email protected]>>, <[email protected]<mailto:[email protected]>>, Swadesh Agrawal <[email protected]<mailto:[email protected]>>, <[email protected]<mailto:[email protected]>>, <[email protected]<mailto:[email protected]>>, <[email protected]<mailto:[email protected]>>, <[email protected]<mailto:[email protected]>>, <[email protected]<mailto:[email protected]>>, <[email protected]<mailto:[email protected]>>, <[email protected]<mailto:[email protected]>>, <[email protected]<mailto:[email protected]>> 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 [email protected] https://www.ietf.org/mailman/listinfo/bess
