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

[Fernando Gont <[e-mail]>]

Hello, Gyan,

Is it me, or somehow when asked a simple question this results in
complexity explosion -- not unusually diverting the attention elsewhere
(where intentionally or unintentionally)?

Let's make things simple:

1) The SRH draft draft-ietf-6man-segment-routing-header talks about
encapsulating an incoming packet into a new header, that incorporates a
SRH. Of course, this is encapsulation/tunneling, so this does not result
in header insertion.

2) Things like TI-LFA have been implemented by inserting a new SRH n
flight, leasing to the situation described by Brian (and  going against
the recommendation in RFC8200)

3) Penultimate Segment Popping results in the SRH being removed
in-flight, violating RFC8200.


Going back to #2, the scenario raised by Brian: from a semantical point
of view, a packet containing two SRH does not make any sense.

Thanks,
Fernando




On 10/12/19 00:28, Gyan Mishra 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] <mailto:[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]
>     <mailto:[e-mail]>> *On Behalf Of *Ron Bonica
>     >> *Sent:* 09 December 2019 03:04
>     >> *To:* 6man <[e-mail] <mailto:[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] <mailto:[e-mail]>
>     >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>     >> --------------------------------------------------------------------
>     >>
>     >
> 
>     --------------------------------------------------------------------
>     IETF IPv6 working group mailing list
>     [e-mail] <mailto:[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] <mailto:[e-mail]>
> 
> www.linkedin.com/in/networking-technologies-consultant
> <http://www.linkedin.com/in/networking-technologies-consultant>
> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 


-- 
Fernando Gont
e-mail: [e-mail] || [e-mail]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1