Re: END SID Without SRH

[Gyan Mishra <[e-mail]>]

This was discussed on the Spring WG regards to SR and the two major flavors
being "MPLS" & "IPv6" of which MPLS = SR-MPLS -IPv4 & IPv6 Prefix & Adj
segments label stacking with use case being "Core PHP UHP" and IPv6 being
SRv6 "Core PSP & USP" as well as the many SRv6 "non core" permutations for
traffic steering use cases that exist.

So the many permutations of SRv6 makes SRv6 that much more powerful next
gen technology and really a driver for all 6MAN stakeholders towards the
near future IPv6 only as there is alot to gain with SRv6!!

Thank you

 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/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT

On Sat, Jun 15, 2019 at 12:57 PM Gyan Mishra <[e-mail]> wrote:

> Catching up on this thread..hopefully not to late for the wrap up..few
> comments..
>
> With SRv6 since there are many applications of SRV6 that go beyond the
> "core"  use case and that SRv6 can be used for any traffic steering use
> case from SOHO edge to DC to Access layers there are so many use cases that
> come up the discussion regarding End SID ends up with so many permutations.
>
> What I wanted to point out was that for the "core" use case both PHP & UHP
> by the time you get to SR end node you either have PSP or USP function for
> implict-null or explicit null scenario respectively that the SRH header has
> been popped on the P 2nd to last hop node for the PSP function and hop
> egress PE node for the USP function.  So in that scenario when you do a
> ping troublehooting lets say the FEC destination loopback egress PE just as
> with mpls will there be an mpls oam type SRv6 ping that is in the data
> plane versus control plane and that might help answer question also with
> the SRv6 OAM type ping draft which I checked Spring and does not exist yet
> if you have the options to set USP explicit null so the SRH stays intact
> till the egress that can also help with data plane ping processing so you
> don't get the ICMP parameter error.  This is out of scope for 6MAN but I
> think should be brought up to the Spring WG. I think if  you did a ping
> within SR domain the ping is in the data plane forwarding so would have SRH
> by default and would be standard SR domain processing for End SID for
> "core" PSP & USP scenario's respectively.
>
> I think the SRv6 "non core" traffic steering use cases will happen as
> customers move towards IPv6 only and that use case is where the End SID
> scenario comes up where we don't have PSP or USP occuring and then SRH is
> still present.  That is described below after the "core" use case.
>
> For the use case of new green field SRv6 core with BEES BGP enabled
> services etc L3 VPN MVPN EVPN etc below is the SRv6 processing behavior
> which is in Spring SR6 network programming draft sections below which I
> think should be included in the SRH section 4.3.1.1. SRH Processing.
>
> **I took some excerpts from this SRv6 preso**
> http://www.segment-routing.net/tutorials/2017-12-05-srv6-introduction/
>
> SR Segment Endpoints
> • SR Endpoints: SR-capable nodes
> whose address is in the IP DA
> • SR Endpoints inspect the SRH and do:
> – IF Segments Left > 0, THEN
> >Decrement Segments Left ( -1 )
> >Update DA with Segment List [ Segments Left ]
> >Forward according to the new IP DA
>
> SR Segment Endpoints
> • SR Endpoints: SR-capable nodes
> whose address is in the IP DA
> • SR Endpoints inspect the SRH and do:
> – IF Segments Left > 0, THEN
> >Decrement Segments Left ( -1 )
> >Update DA with Segment List [ Segments Left ]
> >Forward according to the new IP DA
> – ELSE (Segments Left = 0)
> *>Remove the IP and SR header*
> >Process the payload:
> • Inner IP: Lookup DA and forward
> • TCP / UDP: Send to socket
> •
>
> https://tools.ietf.org/pdf/draft-ietf-spring-srv6-network-programming-00.pdf
>
>
> 4.21. Flavours . . . . . . . . . . . . . . . . . . . . . . . . 21
> 4.21.1. PSP: Penultimate Segment Pop of the SRH . . . . . . 21
> 4.21.2. USP: Ultimate Segment Pop of the SRH . . . . . . . . 22
> 4.21.3. USD: Ultimate Segment Decapsulation . . . . . . . . 23
>
> *4.21.1. PSP: Penultimate Segment Pop of the SRH*
> After the instruction ’update the IPv6 DA with SRH[SL]’ is executed,
> the following instructions must be added:
> 1. IF updated SL = 0 & PSP is TRUE
> 2. pop the top SRH ;; Ref1
> Ref1: The received SRH had SL=1. When the last SID is written in the
> DA, the End, End.X and End.T functions with the PSP flavour pop the
> first (top-most) SRH. Subsequent stacked SRH’s may be present but
> are not processed as part of the function.
>
> END.PSP – Penultimate Segment Popping
> • Penultimate Segment Popping (PSP) behavior
> – Decrement Segments Left, update DA
> *– If Segments Left = 0, remove SRH*
> – Forward according to new DA
> • Node 5 advertises prefix A5::/64
> • On 5, the Penultimate Segment Popping behavior is associated with ID 1
> • The corresponding SID is A5::1
>
> END.PSP – Penultimate Segment Popping
> • Penultimate Segment Popping (PSP) behavior
> – Decrement Segments Left, update DA
> *– If Segments Left = 0, remove SRH*
> – Forward according to new DA
> • Node 5 advertises prefix A5::/64
> • On 5, the Penultimate Segment Popping behavior is associated with ID 1
> • The corresponding SID is A5::1
>
> 4.21.2. USP: Ultimate Segment Pop of the SRH
> We insert at the beginning of the pseudo-code the following
> instructions:
> 1. IF NH=SRH & SL = 0 & USP=TRUE ;; Ref1
> *2. pop the top SRH*
> 3. restart the function processing on the modified packet ;; Ref2
>
>  END.USP – Ultimate Segment Popping
> • Ultimate Segment Popping (USP) behavior
> – If Segments Left = 0
> *>Pop the top SRH*
> >Restart the END function processing on the modified packet
> • Decrement Segments Left, update DA
> • Forward according to new DA
> • Node 6 advertises prefix A6::/64
> • A6:: is the last segment in the top SRH
>
> *SRv6 traffic steering use case where the SRH is intact and you get the
> parameter error:*
>
> *I think the text in the draft this discussion is about is..*
>
> 4.3.1.2. Upper-layer Header or No Next Header
> When processing the Upper-layer header of a packet matching a FIB
> entry locally instantiated as an SRv6 SID defined in this document.
>
> IF (Upper-layer Header is IPv4 or IPv6) and*==========================>
> SRv6 domain node processing "non core use case" for End SID *
> local configuration permits {
> Perform IPv6 decapsulation
> Resubmit the decapsulated packet to the IPv4 or IPv6 module
> }
> ELSE {*======================================================> Non SRv6
> domain node use the standard IP spec rfc 8200 processing *
> Send an ICMP parameter problem message to the Source Address and
> discard the packet. Error code (TBD by IANA) "SR Upper-layer
> Header Error", pointer set to the offset of the upper-layer
> header.
> }
> A unique error code allows an SR Source node to recognize an error in
> SID processing at an endpoint.
>
> *RFC 8200 - bottom of section 4.4*
> 4.4. Routing Header
> If, while processing a received packet, a node encounters a Routing
> header with an unrecognized Routing Type value, the required behavior
> of the node depends on the value of the Segments Left field, as
> follows:
> If Segments Left is zero, the node must ignore the Routing header
> and proceed to process the next header in the packet, whose type
> is identified by the Next Header field in the Routing header.
>
>
> *If Segments Left is non-zero, the node must discard the packet andsend an
> ICMP Parameter Problem, Code 0, message to the packet’sSource Address,
> pointing to the unrecognized Routing Type.*
> If, after processing a Routing header of a received packet, an
> intermediate node determines that the packet is to be forwarded onto
> a link whose link MTU is less than the size of the packet, the node
> must discard the packet and send an ICMP Packet Too Big message to
> the packet’s Source Address.
> The currently defined IPv6 Routing Headers and their status can be
> found at [IANA-RH]. Allocation guidelines for IPv6 Routing Headers
> can be found in [RFC5871].
>
>
> https://tools.ietf.org/pdf/draft-ietf-spring-srv6-network-programming-00.pdf
>
>
> *I believe this section is referring to the "non core PSP & USP" SRv6
> steering scenario "End SID" decap*
>
> 4.8. End.DX6: Decapsulation and IPv6 cross-connect
>  The "Endpoint with decapsulation and cross-connect to an array of
>  IPv6 adjacencies" function (End.DX6 for short) is a variant of the
>  End.X function.
>  When N receives a packet destined to S and S is a local End.DX6 SID,
>  N does:
>  1. IF NH=SRH and SL > 0
>  2. drop the packet ;; Ref1
>  3. ELSE IF ENH = 41 ;; Ref2
>  4. pop the (outer) IPv6 header and its extension headers
>  5. forward to layer-3 adjacency bound to the SID S ;; Ref3
>  6. ELSE
>
>
>
> * 7. Send an ICMP parameter problem message ;; Ref4====> RFC 8200 standard
> processing non SRv6 domain node 8. drop the packet Ref1: The End.DX6 SID
> must always be the last SID, or it can be the Destination Address of an
> IPv6 packet with no SRH header.*
>
> Ref2: 41 refers to IPv6 encapsulation as defined by IANA allocation
>  for Internet Protocol Numbers
>  Ref3: Selected based on a hash of the packet’s header (at least SA,
>  DA, Flow Label)
>  Ref4: ICMP error is sent to the source address with error code (TBD
>  by IANA) "SR Upper-layer Header Error" and pointer set to the NH.
>  One of the applications of the End.DX6 function is the L3VPNv6 use-
>  case where a FIB lookup in a specific tenant table at the egress PE
>  is not required. This would be equivalent to the per-CE VPN label in
>  MPLS [RFC4364].
>
> 4.9. End.DX4: Decapsulation and IPv4 cross-connect
>  The "Endpoint with decapsulation and cross-connect to an array of
>  IPv4 adjacencies" function (End.DX4 for short) is a variant of the
>  End.X functions.
>  When N receives a packet destined to S and S is a local End.DX4 SID,
>  N does:
>  1. IF NH=SRH and SL > 0
>  2. drop the packet ;; Ref1
>  3. ELSE IF ENH = 4 ;; Ref2
>  4. pop the (outer) IPv6 header and its extension headers
>  5. forward to layer-3 adjacency bound to the SID S ;; Ref3
>  6. ELSE
>  7. *Send an ICMP parameter problem message ;; Ref4* *====> RFC 8200
> standard processing non SRv6 domain nod*
> * 8. drop the packet*
>  Ref1: The End.DX4 SID must always be the last SID, or it can be the
>  Destination Address of an IPv6 packet with no SRH header.
>  Ref2: 4 refers to IPv4 encapsulation as defined by IANA allocation
>  for Internet Protocol Numbers
>  Ref3: Selected based on a hash of the packet’s header (at least SA,
>  DA, Flow Label)
>  Ref4: ICMP error is sent to the source address with error code (TBD
>  by IANA) "SR Upper-layer Header Error" and pointer set to the NH.
>  One of the applications of the End.DX4 function is the L3VPNv4 use-
>  case where a FIB lookup in a specific tenant table at the egress PE
>  is not required. This would be equivalent to the per-CE VPN label in
>  MPLS [RFC4364].
>
>
> The Spring SRv6 network programming draft has all the SR processing
> functions for SID processing so I wonder if we should reference the entire
> section 4 or maybe include that entire section in this draft.
>
>
> https://tools.ietf.org/pdf/draft-ietf-spring-srv6-network-programming-00.pdf
>
>
>  Functions associated with a SID . . . . . . . . . . . . . . . 7
>  4.1. End: Endpoint . . . . . . . . . . . . . . . . . . . . . . 8
>  4.2. End.X: Layer-3 cross-connect . . . . . . . . . . . . . . 8
>  4.3. End.T: Specific IPv6 table lookup . . . . . . . . . . . . 9
>  4.4. End.DX2: Decapsulation and L2 cross-connect . . . . . . . 10
>  4.5. End.DX2V: Decapsulation and VLAN L2 table lookup . . . . 11
>  4.6. End.DT2U: Decapsulation and unicast MAC L2 table lookup . 11
>  4.7. End.DT2M: Decapsulation and L2 table flooding . . . . . . 12
>  4.8. End.DX6: Decapsulation and IPv6 cross-connect . . . . . . 13
>  4.9. End.DX4: Decapsulation and IPv4 cross-connect . . . . . . 14
>  4.10. End.DT6: Decapsulation and specific IPv6 table lookup . . 15
>  4.11. End.DT4: Decapsulation and specific IPv4 table lookup . . 15
>  4.12. End.DT46: Decapsulation and specific IP table lookup . . 16
>  4.13. End.B6.Insert: Endpoint bound to an SRv6 policy . . . . . 17
>  4.14. End.B6.Insert.Red: [...] with reduced SRH insertion . . . 18
>  4.15. End.B6.Encaps: Endpoint bound to an SRv6 policy w/ encaps 18
>  4.16. End.B6.Encaps.Red: [...] with reduced SRH insertion . . . 19
>  4.17. End.BM: Endpoint bound to an SR-MPLS policy . . . . . . . 19
>  4.18. End.S: Endpoint in search of a target in table T . . . . 20
>  4.19. SR-aware application . . . . . . . . . . . . . . . . . . 21
>  4.20. Non SR-aware application . . . . . . . . . . . . . . . . 21
>  4.21. Flavours . . . . . . . . . . . . . . . . . . . . . . . . 21
>  4.21.1. PSP: Penultimate Segment Pop of the SRH . . . . . . 21
>  4.21.2. USP: Ultimate Segment Pop of the SRH . . . . . . . . 22
>  4.21.3. USD: Ultimate Segment Decapsulation . . . . . . . . 23
>
> See attached SRv6 preso's from Cisco Live
>
> In the SRv6 preso"3123 srv6" page 20-22 insertion vs encapsulation its
> mentioned that on Non SR -- this goes into the End SID scenario for "non
> core PSP & USP" use case where SRH is removed prior to delivery to
> destination which is similar to the "core" USP or PSP pop.
>
> Insertion Vs. Encapsulation
> •Header Insertion at the Source:
> –Source originates the packet with the SRH
> –SRH is kept and used along the path
> –Packet is delivered to destination with the SRH (plain IPv6 operations)
>
> *>Optionally, the SRH may be removed prior to deliver the packet to
> destination–Use case: source is SRv6 capable*
>
> Insertion Vs. Encapsulation
> •Header Insertion at Ingress:
> –Source originates the packet without any SRH
> –SRH is inserted at ingress
>
> *–SRH is removed prior to deliver the packet to the destination–Use case:
> source is not SRv6 capable*
>
> Insertion Vs. Encapsulation
> •Encapsulation at Ingress :
> –Source originates the packet without any SRH
> –Ingress encapsulates the incoming packet into a new outer IPv6 header
> followed by the SRH
> –Packet is decapsulated at egress (both outer IPv6 header and SRH are
> removed)
> –Use Case:
>
> Thank you
>
> 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/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT
>
> On Fri, Jun 14, 2019 at 1:41 PM Ole Troan <[e-mail]> wrote:
>
>> Mark,
>>
>> > The ambiguity and I think non-compliance with RFC 8200 is when
>> > dropping isn't occurring, and how to process the packet is singularly
>> > encoded in the DA address. This is instead of following what is
>> > explicitly encoded in the following EHs and transport layer headers.
>> > This is contrary to IPv6 host processing of DA match -> EH processing
>> > -> Transport layer -> Application Layer packet processing.
>> >
>> > (I started down this path a few years ago by thinking about the
>> > scenario of buying a router (device) from a router vendor, and then
>> > running it as a BGP route reflector or server that isn't ever in the
>> > packet forwarding path. Is it still a "router", or is it now a host?
>> > Per RFC 8200, not a router, only a host, even if it still looks like a
>> > router (device) with a router vendor's logo on it).
>>
>> To make another analogy.
>> Let's say I give my BGP application an IPv6 address. Not an interface,
>> not the "host stack", but the application itself.
>>
>> Cheers,
>> Ole
>> --------------------------------------------------------------------
>> 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/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT
>
>

-- 

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/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT