Re: What if? [was Re: Extension Header Insertion]

[Gyan Mishra <[e-mail]>]

Brian


I would like to put this into proper context for SRv6 and how it would be
deployed in a real world scenario so we can fully connect all the dots of
this puzzle.

So with SRv6 the 1st SRH eh insertion would never be in flight eh insertion
in the middle of the network.

Providing some context below.

The topology is identical to a typical service provider MPLS core where you
have a PE-CE link to customers.  So in the MPLS scenario the Ingress PE
would add L3 VPN MBGP bottom of stack label for the customer VRF PE-CE
attachment circuit.

With SRv6 the L3 VPN MBGP is encapsulated in IPv6 and sits in the overlay
as the inner header payload since now with SRv6 we have an IPv6 data plane
as our underlay 6in6 outer header instead of MPLS ldp topmost label.
Essentially we are swapping MPLS ldp topmost label for SRv6 IPv6 data plane
underlay with all BGP services overlay remaining as-is intact AFI/SAFI
riding on top of SRv6 sitting in the 6in6 payload.

The SRv6 source node ingress PE of the SR domain would now encapsulate the
SRv6 L3 services TLV and at the same time inserts SRH header routing type 4
for the hop by hop traffic engineering of the flow through the controlled
SRv6 operators domain.

So from the big picture standpoint the 1st SRH eh insertion is most
definitely not in the middle of the network and not in flight eh insertion
since the BGP services TLV originating from the external CE edge is
tunneled over the SRv6 IPv6 data plane controlled operator domain.

BESS WG draft depicts the L3 vpn services TLV that is 6in6 tunneled sits in
the overlay.

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


2 <https://tools.ietf.org/html/draft-dawra-bess-srv6-services-02#section-2>.
SRv6 Services TLVs

   This document extends the BGP Prefix-SID attribute
   [I-D.ietf-idr-bgp-prefix-sid
<https://tools.ietf.org/html/draft-dawra-bess-srv6-services-02#ref-I-D.ietf-idr-bgp-prefix-sid>]
to carry SRv6 SIDs and associated
   information.

   The SRv6 Service TLVs are defined as two new TLVs of the BGP Prefix-
   SID Attribute to achieve signaling of SRv6 SIDs for L3 and L2
   services.

   o  SRv6 L3 Service TLV: This TLV encodes Service SID information for
      SRv6 based L3 services.  It corresponds to the equivalent
      functionality provided by an MPLS Label when received with a Layer
      3 service route.  Some behaviors which MAY be encoded, but not
      limited to, are End.DX4, End.DT4, End.DX6, End.DT6, etc.

   o  SRv6 L2 Service TLV: This TLV encodes Service SID information for
      SRv6 based L2 services.  It corresponds to the equivalent
      functionality provided by an MPLS Label1 for EVPN Route-Types as
      defined in[RFC7432].  Some behaviors which MAY be encoded, but not
      limited to, are End.DX2, End.DX2V, End.DT2U, End.DT2M etc.

   When an egress PE is enabled for BGP Services over SRv6 data-plane,
   it MUST signal one or more SRv6 Service SIDs enclosed in SRv6 Service
   TLV(s) within the BGP Prefix-SID Attribute attached to MP-BGP NLRIs
   defined in [RFC4760
<https://tools.ietf.org/html/rfc4760>][RFC4659][RFC5549
<https://tools.ietf.org/html/rfc5549>][RFC7432][RFC4364
<https://tools.ietf.org/html/rfc4364>] where
   applicable as described in section 3
<https://tools.ietf.org/html/draft-dawra-bess-srv6-services-02#section-3>
and 4.

   The 2nd SRH EH insertion with TI-LFA occurs at the PLR point of local

Repair node to the loop free PQ node.


So this addition SRH header is only inserted and   removed during a
failure fast reroute.  I believe  but not sure if TI-LFA behaves the
same as MPLS ldp

Remote LFA where a MPLS label is added at the PLR

Node and tunneled to the PQ node.  I am still      researching that one.


With SRv6 the use cases are for wherever you use mpls public internet or
private or enterprise scenario so you would always have the same SR source
PE encapsulation of the edge CE L3 services TLV and so in any of those use
cases would not be a middle of the network in flight EH insertion which is
a violation of RFC 8200.

Gyan

On Mon, Dec 9, 2019 at 8:21 PM Brian E Carpenter <
[e-mail]> wrote:

> So, let's assume that two consecutive SRH headers are allowed in the same
> packet.
>
> So the first one (an example from
> draft-ietf-6man-segment-routing-header-26) is:
>
>        Segments Left=2
>        Last Entry=2
>        Flags=0
>        Tag=0
>        Segment List[0]=S3
>        Segment List[1]=S2
>        Segment List[2]=S1
>
> and the second one is
>
>        Segments Left=1
>        Last Entry=1
>        Flags=0
>        Tag=0
>        Segment List[0]=S4
>        Segment List[1]=S5
>
> I made that up and it's obviously nonsense, but if this is allowed why
> aren't the rules for processing conflicting SRHs described in
> draft-ietf-6man-segment-routing-header-26? Do we need to recall it from the
> RFC Editor queue to be fixed?
>
> Regards
>    Brian Carpenter
>
> On 10-Dec-19 14:02, Brian E Carpenter wrote:
> > On 09-Dec-19 22:33, Adrian Farrel wrote:
> >> Hi Ron,
> >>
> >> I think we can jump to a quick answer on this because
> draft-ietf-spring-srv6-network-programming-05 says:
> >>
> >>    We assume that the SRH may
> >>    be present multiple times inside each packet.
> >>
> >> Thus we may assume that the proponents of Extension Header insertion do
> think that it is acceptable to insert a second routing header into a packet
> that already has one.
> >>
> >> And 8200 is clear when it says:
> >>    Each extension header should occur at most once, except for the
> >>    Destination Options header, which should occur at most twice (once
> >>    before a Routing header and once before the upper-layer header).
> >
> > That's "should", which in a non-RFC2119 document like RFC 8200, means
> "should".
> > It's not "must". So while I would prefer that the relevant SRH document
> justifies
> > the exception, there isn't a breach of a mandatory requirement.
> >
> >> So draft-ietf-spring-srv6-network-programming-05 includes a false
> assumption which need to be either removed or secured through an update to
> 8200.
> >>
> >> Ideally, I suppose, draft-ietf-6man-segment-routing-header would have
> contained the clarification that the SRH could be present multiple times
> >
> > Yes
> >
> >> (updating 8200 as it went).
> >
> > Unnecessary, IMHO.
> >
> >     Brian
> >
> >>
> >>
> >>
> >> Cheers,
> >>
> >> Adrian
> >>
> >>
> >>
> >> *From:*ipv6 <[e-mail]> *On Behalf Of *Ron Bonica
> >> *Sent:* 09 December 2019 03:04
> >> *To:* 6man <[e-mail]>
> >> *Subject:* Extension Header Insertion
> >>
> >>
> >>
> >> Folks,
> >>
> >>
> >>
> >> This question is posed primarily to the proponents of Extension Header
> insertion.
> >>
> >>
> >>
> >> Do you think that it is acceptable to insert a second routing header
> into a packet that already has one, so the resulting packet looks like the
> following:
> >>
> >>
> >>
> >>   * IPv6 header
> >>   * SRH
> >>   * SRH
> >>   * Upper-layer header
> >>
> >>
> >>
> >> Would this be common in TI-LFA?
> >>
> >>
> >>
> >>
> Ron
> >>
> >>
> >>
> >>
> >>
> >> Juniper Business Use Only
> >>
> >>
> >> --------------------------------------------------------------------
> >> IETF IPv6 working group mailing list
> >> [e-mail]
> >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >> --------------------------------------------------------------------
> >>
> >
>
> --------------------------------------------------------------------
> 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