Re: [bess] Questions to draft-dawra-bess-srv6-services-02

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 <hayabusagsm@gmail.com> wrote:

>
> Hi Robert
>
> In-line question
>
> Sent from my iPhone
>
> On Oct 3, 2019, at 11:01 AM, Robert Raszuk <robert@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.dunbar@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 <robert@raszuk.net>
>> *Sent:* Thursday, October 03, 2019 3:50 AM
>> *To:* Linda Dunbar <linda.dunbar@futurewei.com>
>> *Cc:* draft-dawra-bess-srv6-services@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.dunbar@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.bocci@nokia.com>
>> *Date: *Friday, September 27, 2019 at 4:00 AM
>> *To: *"draft-dawra-bess-srv6-services@ietf.org" <
>> draft-dawra-bess-srv6-services@ietf.org>, "bess@ietf.org" <bess@ietf.org>
>> *Subject: *WG adoption and IPR poll for
>> draft-dawra-bess-srv6-services-02
>> *Resent-From: *<alias-bounces@ietf.org>
>> *Resent-To: *<gdawra.ietf@gmail.com>, <cfilsfil@cisco.com>, <
>> pbrisset@cisco.com>, Swadesh Agrawal <swaagraw@cisco.com>, <
>> daniel.voyer@bell.ca>, <daniel.bernier@bell.ca <daniel..bernier@bell.ca>>,
>> <dws@steinberg.net>, <robert@raszuk.net>, <bruno.decraene@orange.com>, <
>> satoru.matsushima@g.softbank.co.jp>, <zhuangshunwan@huawei.com>, <
>> jorge.rabadan@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
>
>