Re: [bess] WG adoption and IPR poll for draft-dawra-bess-srv6-services-02

[Robert Raszuk <[e-mail]>]

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 <[e-mail]>
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)" <[e-mail]>
> *Date: *Friday, September 27, 2019 at 4:00 AM
> *To: *"[e-mail]" <
> [e-mail]>, "[e-mail]" <[e-mail]>
> *Subject: *WG adoption and IPR poll for draft-dawra-bess-srv6-services-02
> *Resent-From: *<[e-mail]>
> *Resent-To: *<[e-mail]>, <[e-mail]>, <
> [e-mail]>, Swadesh Agrawal <[e-mail]>, <
> [e-mail]>, <[e-mail]>, <[e-mail]>, <
> [e-mail]>, <[e-mail]>, <
> [e-mail]>, <[e-mail]>, <
> [e-mail]>
> *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%7C9d0ccb0f99ab43a2dfa208d74773b695%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637056434649952897&sdata=zrZ%2FfeJpHztL0j7urfz0irAsIinAtZadKXYZ6lDhnig%3D&reserved=0>
>
>
>
>
>