Re: IPv6 header insertion in a controlled domain

[Gyan Mishra <[e-mail]>]

This draft is really the missing link that really helps give some clarity
to SRv6 and EH insertion issue.

This is from the BESS WG

https://tools.ietf.org/html/draft-dawra-bess-srv6-services-02

Imagine an overlay and network with underlay being MPLS LDP with overlay
BGP services IPv4 IPv6 VPNv4 VPNv6.

Now swap the MPLS underlay with the SRv6 keeping the BGP overlay intact.

That is what is described in this draft and is what is deployed by a number
of operators worldwide.

The key point to note is at the PE-CE junction where typically in an MPLS
domain label imposition happens on the PE towards the P core.

Now instead of label imposition we have 6in6 encapsulation occurring.

Note that this is like the bottom services label L3 vpn label not the
topmost label which is now IPv6 forwarding plane with SRv6.

So we had asked in the voyer eh draft for encapsulation to be complaint
with 8200 instead of doing in flight EH insertion.  That encapsulation I
believe is already occurring with the BGP overlay L2 or L3 services.

So with the overlay which is the tunneled payload customer traffic over
SRv6 that is encapsulated per the BESS overlay draft above.

Below describes BE L3 VPN but I believe even for all SRv6 scenarios, BGP
services overlay, an 6in6 encapsulation occurs which is what we want for
8200 compliance.

1 <https://tools.ietf.org/html/draft-dawra-bess-srv6-services-02#section-1>.
Introduction

   SRv6 refers to Segment Routing instantiated on the IPv6 dataplane [I-
   D.ietf-spring-srv6-network-programming][I-D.ietf-6man-segment-routing
   -header].

   SRv6 based BGP services refers to the L3 and L2 overlay services with
   BGP as control plane and SRv6 as dataplane.

   SRv6 SID refers to a SRv6 Segment Identifier as defined in
   [I-D.ietf-spring-srv6-network-programming
<https://tools.ietf.org/html/draft-dawra-bess-srv6-services-02#ref-I-D.ietf-spring-srv6-network-programming>].

   SRv6 Service SID refers to an SRv6 SID associated with one of the
   service specific behavior on the advertising Provider Edge(PE)
   router, such as (but not limited to), END.DT (Table lookup in a VRF)
   or END.DX (cross-connect to a nexthop) behaviors in the case of L3VPN
   service as defined in [I-D.ietf-spring-srv6-network-programming
<https://tools.ietf.org/html/draft-dawra-bess-srv6-services-02#ref-I-D.ietf-spring-srv6-network-programming>].

   To provide SRv6 service with best-effort connectivity, the egress PE
   signals an SRv6 Service SID with the BGP overlay service route.  The
   ingress PE encapsulates the payload in an outer IPv6 header where the
   destination address is the SRv6 Service SID provided by the egress
   PE.  The underlay between the PEs only need to support plain IPv6
   forwarding [RFC8200 <https://tools.ietf.org/html/rfc8200>
].

   To provide SRv6 service in conjunction with an underlay SLA from the
   ingress PE to the egress PE, the egress PE colors the overlay serviceSo



Gyan


On Mon, Dec 9, 2019 at 1:40 AM Sander Steffann <[e-mail]> wrote:

> Hi Ron,
>
> > See Section 7.5 of
> https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26
>
> Not choosing to use AH to protect the SRH is one thing, but not supporting
> an AH in the existing packet when doing header insertion is quite another.
> I want to be sure the second doesn't apply.
>
> Cheers
> Sander
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
-- 

Gyan S. Mishra

IT Network Engineering & Technology

Verizon Communications Inc. (VZ)

13101 Columbia Pike FDC1 3rd Floor

Silver Spring, MD 20904

United States

Phone: [phone]

Email: [e-mail]

www.linkedin.com/in/networking-technologies-consultant