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

[Gyan Mishra <[e-mail]>]

Confirming below that SRv6 TI-LFA does not require Remote LFA or DLFA so
their is no additional 6in6 encapsulation done as with MPLS ldp remote LFA
where a MPLS label is added to tunnel the flow to the PQ node.

https://tools.ietf.org/pdf/draft-ietf-rtgwg-segment-routing-ti-lfa-01.pdf

So with SRv6 TI-LFA we would definitely have in flight SRH EH insertion
anywhere in the network where their is a failure and fast reroute pre
programmed backup SRH path exists.

IPv6 header
  * SRH -SRv6 source node
  * SRH -TI-LFA PLR node
IPv6 header -L3 services TLV
  * Upper-layer header

Gyan

On Tue, Dec 10, 2019 at 12:28 AM Gyan Mishra <[e-mail]> wrote:

>
> 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
>
> --

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