Subject: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-06.txt

From: [email-masked]
Date: Wed, 11 Dec 2019 11:54:45 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Source Packet Routing in Networking WG of the IETF.

        Title           : SRv6 Network Programming
        Authors         : Clarence Filsfils
                          Pablo Camarillo Garvia
                          John Leddy
                          Daniel Voyer
                          Satoru Matsushima
                          Zhenbin Li
	Filename        : draft-ietf-spring-srv6-network-programming-06.txt
	Pages           : 39
	Date            : 2019-12-11

Abstract:
   The SRv6 Network Programming framework enables a network operator or
   an application to specify a packet packet processing program by
   encoding a sequence of instructions in the IPv6 packet header.

   Each instruction is implemented on one or several nodes in the
   network and identified by an SRv6 Segment Identifier in the packet.

   This document defines the SRv6 Network Programming concept and
   specifies the base set of SRv6 behaviors that enables the creation of
   interoperable overlays with underlay optimization (Service Level
   Agreements).

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-network-programming/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-06
https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-network-programming-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-srv6-network-programming-06

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Wed, 11 Dec 2019 19:57:40 +0000

Hi all,
 
We have published a new revision of draft-ietf-spring-srv6-network-programming. It addresses the comments received. I will be replying individually on each thread.
Many thanks to all of those who have contributed with such comments.
 
Please have a look and let me know any comment.
 
I will be replying in the upcoming days to the pending comments at the mailer.
 
Thanks,
Pablo (on behalf of the co-authors).
 
Diff:
===
-New abstract
-Use of normative language throughout the entire document
-Updated terminology section
-Moved Requirements Language section to 2.1
-Rewrote first paragraph in 3.1 to improve readability
-Removed some redundant pseudocodes
-Added explicit pseudocode on the “Pop the SRH” operation (applicable in both PSP and USP)
-Rewrote Security Considerations section
-IANA: Editorial changes to align the text with RFC8126
-IANA: Changed “SRv6 Endpoint Behaviors” registry to be a child of “Segment Routing Parameters” instead of “Segment-Routing with IPv6 dataplane parameters”
-IANA: changed “SRv6 Endpoint behaviors” registry to a)Remove private use block; b)Limit the huge Experimental block to only 15 values; c)Create a new Reserved subblock for future use; d)Change the -allocation policy to FCFS
-New normative reference to Ethernet
-Moved RFC2473, RFC8200 and RFC8402 from informational to normative
-Removed unused references (draft-filsfils-spring-srv6-net-pgm-insertion, draft-ietf-spring-sr-service-programming, draft-raza-spring-srv6-yang)
-New informative references to RFC7432, TILFA
-Last but not least, I have removed the word Insert or any of its variants from the draft. It was being used in different contexts NOT related to SRH insertion. However, more than one person has being confused about this. Hence better to remove it.

-----Original Message-----
From: spring <[email-masked]> on behalf of "[email-masked]" <[email-masked]>
Reply to: "[email-masked]" <[email-masked]>
Date: Wednesday, 11 December 2019 at 20:55
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-06.txt

    
    Abstract:

    

    
    
    _______________________________________________
    spring mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/spring

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 12 Dec 2019 11:06:17 +1300

So, I've tried to look at this with fresh eyes, and thanks for the
various updates and clarifications.

(I'm still not on the SPRING list so please leave me in CC.)

I remain a bit puzzled. First, a quote from the SRH specification
(draft-ietf-6man-segment-routing-header-26):

> 4.2.  Transit Node
> 
>    As specified in [RFC8200], the only node allowed to inspect the
>    Routing Extension Header (and therefore the SRH), is the node
>    corresponding to the DA of the packet.  Any other transit node MUST
>    NOT inspect the underneath routing header and MUST forward the packet
>    toward the DA according to its IPv6 routing table.

Next, a quote from the current draft:

>    SRH[n]: A shorter representation of Segment List[n], as defined in
>    [I-D.ietf-6man-segment-routing-header].
> 
>    When a packet is intercepted on a wire, it is possible that SRH[SL]
>    is different from the DA.

Huh? That would be extremely unusual in the normal interpretation
of a routing header, where is RH[SL] is by definition the next
destination where the RH will be processed. Any other node is a transit
node, and I don't see anything in draft-ietf-6man-segment-routing-header-26
that allows for anything else. So it seems to me that the quoted statement
needs an explanation of why it isn't a violation of
draft-ietf-6man-segment-routing-header-26, not to mention why it's useful.

That leads us back to:

> 4.16.1.  PSP: Penultimate Segment Pop of the SRH
> 
>    The SRH processing of the End, End.X and End.T behaviors are
>    modified: after the instruction "S14.  Update IPv6 DA with Segment
>    List[Segments Left]" is executed, the following instructions must be
>    executed as well:
> 
>  S14.1.   If (Segments Left == 0) {
>  S14.2.      Update the Next Header field in the preceding header to the
>                 Next Header value of the SRH
>  S14.3.      Decrease the IPv6 header Payload Length by the Hdr Ext Len
>                 value of the SRH
>  S14.4.      Remove the SRH from the IPv6 extension header chain
>  S14.5.   }

This is clearly a breach of RFC8200, but it can never be reached if
DA == SRH[SL]. 

The operation "4.16.2.  USP: Ultimate Segment Pop of the SRH" seems like
a pointless variant on "4.16.3.  USD: Ultimate Segment Decapsulation", 
since the packet has reached its destination anyway and will presumably
be decapsulated anyway. 

Regards
   Brian Carpenter

On 12-Dec-19 08:54, [email-masked] wrote:
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Sat, 14 Dec 2019 09:34:25 +0000

Brian,

Many thanks for having another look to the draft. Please see inline [PC].

Thank you,
Pablo.

-----Original Message-----
From: spring <[email-masked]> on behalf of Brian E Carpenter <[email-masked]>
Date: Wednesday, 11 December 2019 at 23:06
To: "[email-masked]" <[email-masked]>
Subject: Re: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-06.txt

    

    

PC: This occurs when we use the reduced SRH as described in: https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26#section-4.1.1
If you think this sentence does not reflect that, I can edit it for the next revision of the draft. 

    >  S14.4.      Remove the SRH from the IPv6 extension header chain
    
    This is clearly a breach of RFC8200, but it can never be reached if DA == SRH[SL]. 
PC: PSP executes at the segment that is the Destination Address. 

PC: This has already been discussed in the past in the SPRING mailer. https://mailarchive.ietf.org/arch/msg/spring/Q3MYlGDQs5MO-dOFOZJUx2hHni4
    
    Regards
       Brian Carpenter

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 15 Dec 2019 09:04:28 +1300

Hi Pablo,

See in line:

> PC: This occurs when we use the reduced SRH as described in: https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26#section-4.1.1

OK, well that definitely needs to be added to the draft, since it is very far from
obvious to a newcomer.

> PC: PSP executes at the segment that is the Destination Address.

I am probably being stupid, but I don't understand what is "penultimate" about
a condition where SL == 0 and the packet has reached the node that owns DA.
Where will the packet be sent next, since it's already at the final DA?

(The example at
https://tools.ietf.org/html/draft-filsfils-spring-srv6-net-pgm-illustration-01#section-2.8.1
doesn't help me in the least. Is there a conceptual discussion of the purpose
of PSP?)

If the packet is to be forwarded again, "Remove the SRH from the IPv6
extension header chain" violates RFC 8200, as does "Decrease the IPv6 header
Payload Length by the Hdr Ext Len value of the SRH".

This objection doesn't seem to arise for USP, since presumably at that point
the packet has reached the final DA and any mangling is internal to the host.
  
> PC: This has already been discussed in the past in the SPRING mailer. https://mailarchive.ietf.org/arch/msg/spring/Q3MYlGDQs5MO-dOFOZJUx2hHni4

Yes, OK, the offload NIC as a use case is reasonable. As far as the network
is concerned, that is internal to the host. But some hint about the purpose
and value of these features is needed in the draft, IMHO.

Regards
    Brian

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Thu, 19 Dec 2019 11:53:30 +0000

Brian,

Inline.

Thank you,
Pablo.

-----Original Message-----
From: Brian E Carpenter <[email-masked]>
Date: Saturday, 14 December 2019 at 21:04
To: "Pablo Camarillo (pcamaril)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-06.txt

    Hi Pablo,
    
    See in line:

PC: I have removed this sentence from the latest revision of the draft. Unneeded, misleading and covered in the SRH. See rev07. Thank you for your comment.

    

PC: You are reading line 14 of a pseudocode. In the previous lines we have received a packet with Segments Left = 1, and we have decremented by one such value.
    
    (The example at

PC: The node that executes the PSP behavior is identified in the IPv6 Destination Address of the packet. This does not violate RFC8200.

    
    
    Regards
        Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 20 Dec 2019 10:39:39 +1300

Sorry, I am still confused, see in line:

> PC: I have removed this sentence from the latest revision of the draft. Unneeded, misleading and covered in the SRH. See rev07. Thank you for your comment.

Thanks.

> PC: You are reading line 14 of a pseudocode. In the previous lines we have received a packet with Segments Left = 1, and we have decremented by one such value.

If I have this right, the PSP case is inserted in this pseudocode:

  S14.   Update IPv6 DA with Segment List[Segments Left]
  S15.   Submit the packet to the egress IPv6 FIB lookup and
            transmission to the new destination

which produces:

  S14.   Update IPv6 DA with Segment List[Segments Left]
  S14.1.   If (Segments Left == 0) {
  S14.2.      Update the Next Header field in the preceding header to the
                 Next Header value of the SRH
  S14.3.      Decrease the IPv6 header Payload Length by the Hdr Ext Len
                 value of the SRH
  S14.4.      Remove the SRH from the IPv6 extension header chain
  S14.5.   }
  S15.   Submit the packet to the egress IPv6 FIB lookup and
            transmission to the new destination

That's explicitly removing the header before forwarding the packet. How
can that not be a violation of RFC 8200? And where is it forwarded to, since
we are already at the DA?

    Brian

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 20 Dec 2019 00:01:57 +0100

>   And where is it forwarded to, since we are already at the DA?

PSP operates at the n-1 segment end of the SR path so naturally after
swapping DA it is forwarded to the segment end. Note that we are all along
operating on the encapsulated header ... original packet including its
original IPv6 header is sitting as passenger here.

So last segment here will received encapsulated IPv6 packet will
decapsulate it and fwd based on the original DA.

Seems very simple :)

Cheers,
R.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 19 Dec 2019 18:06:40 -0500

Robert, you say we are operating on the encapsulating header.
Do things still work right for the case that the authors felt was 
important in the SRH document where the source and destination hosts are 
inside the SR Domain, and therefore there is only one IPv6 header?  (I 
would not be surprised if they do still work.  But your assertion in the 
email below, and the repeated mention that the encapsulated case was the 
only case during the header insertion discussion in Singapore leaves me 
needing to clarify.)

Yours,
Joel

On 12/19/2019 6:01 PM, Robert Raszuk wrote:
> swapping DA it is forwarded to the segment end. Note that we are all 
> along operating on the encapsulated header ... original packet including 
> its original IPv6 header is sitting as passenger here.
>

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 20 Dec 2019 00:10:58 +0100

Hi Joel,

Yes I do not see why things would not work if original SRC would insert SRH
and PSP would happen leaving original DA to forward.  Case of no encap.

I was more responding to Brian's question "Where are we forwarding if we
are at DA" ... that very DA was the encapsulated one I presume.

But your observation is correct.

Many thx,
R.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 20 Dec 2019 14:44:45 +1300

On 20-Dec-19 12:01, Robert Raszuk wrote:
> PSP operates at the n-1 segment end of the SR path so naturally after swapping DA it is forwarded to the segment end. Note that we are all along operating on the encapsulated header ... original packet including its original IPv6 header is sitting as passenger here. 
> 
> So last segment here will received encapsulated IPv6 packet will decapsulate it and fwd based on the original DA. 
> 
> Seems very simple :) 

Right, but the language in the PSP sub-section does not talk about decapsulation. I think the root problem may be using the word "pop", which is relevant in the MPLS label stack context but not here, without additional definition.

    Brian

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 20 Dec 2019 01:22:15 -0500

On Thu, Dec 19, 2019 at 8:45 PM Brian E Carpenter <
[email-masked]> wrote:

> Right, but the language in the PSP sub-section does not talk about
> decapsulation. I think the root problem may be using the word "pop", which
> is relevant in the MPLS label stack context but not here, without
> additional definition.
>

  [Gyan] I agree with what Brian is saying that pop in MPLS PHP or UHP you
are popping an MPLS label 4 byte shim, where here you are removing the SRH
header.  Not a really a pop.  The MPLS shim is an encapsulation since it’s
sits between the L2 and L3 header.  I think if we fix the verbiage and
change from pop to remove we may want to come up with some other name like
PSR & USR if “remove” was used.

-- 

Gyan S. Mishra

IT Network Engineering & Technology

Verizon Communications Inc. (VZ)

13101 Columbia Pike FDC1 3rd Floor

Silver Spring, MD 20904

United States

Phone: 301 502-1347

Email: [email-masked]

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

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 20 Dec 2019 02:21:35 -0500

> PSR & USR if “remove” was used.
      With both SRv6 and MPLS within their respective domains when the
packet comes in from external to the domain on the PE-CE attachment circuit
with MPLS the label  4 byte shim imposition or encapsulation happens on the
PE upon forwarding on any MPLS enabled “core”  interface PE-P link.  With
SRv6 the 6in6 encapsulation occurs when a packet from the PE-CE attachment
circuit originating from outside the SRv6 domain hits the SRv6 source node
ingress PE which 6in6 encapsulates the packet from the CE and then adds the
SRH header to source route the packet through the SRv6 domain.  With mpls
the label disposition happens with PHP on egress P penultimate node.  So
that de-encapsulation with SRv6 ends up mapping to USD end.x SID function
where the original 6in6 encapsulation done on the SRv6 source node is now
removed.  So big difference here in nomenclature with PSP and USP removing
SRH and not performing any de-encapsulation which is decoupled to a
separate USD function.

Gyan S. Mishra

Silver Spring, MD 20904

United States

Phone: 301 502-1347

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 20 Dec 2019 10:18:50 +0100

Hi Brian,

> decapsulation.

Sure as in a way there is no decapsulation there. This is Segment N-1 node
not Final Segment End node.

Of course the other way to look at this would be to conceptually describe
this as decapsulation at *each* segment end point and on most just copy the
SRH to a new IPv6 header and on PSP happening on Segment N-1 to not copy
it.

I think the root problem may be using the word "pop", which is relevant in
> the MPLS label stack context but not here, without additional definition.

Well I agree. "POP" does not sound like the best terminology choice here
for SRH removal or deletion :). Now all what is needed for WG to convince
Pablo for massive editing ....

Happy Holidays,
R.

---

From: Fernando Gont <[email-masked]>
Date: Fri, 20 Dec 2019 00:22:00 -0500

On 19/12/19 20:44, Brian E Carpenter wrote:
> Right, but the language in the PSP sub-section does not talk about decapsulation. 

Because it's not. :-) They are deleting an EH.

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

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Fri, 20 Dec 2019 17:30:35 +0000

Inline.

Thanks.

-----Original Message-----
From: Brian E Carpenter <[email-masked]>
Date: Thursday, 19 December 2019 at 22:39
To: "Pablo Camarillo (pcamaril)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-06.txt

    
    Thanks.

    
    
    which produces:

PC:
I receive a packet at the node identified in the Destination Address field of the IPv6 header.
I process the extension header and delete it (in that same node).
The packet, with the updated Destination Address, is forwarded towards the node identified in the Destination Address field of the IPv6 header.
    
        Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 22 Dec 2019 08:22:28 +1300

On 20-Dec-19 22:18, Robert Raszuk wrote:
> Sure as in a way there is no decapsulation there. This is Segment N-1 node not Final Segment End node.

If there is no decapsulation and the words mean what they say, then there is certainly a violation of RFC 8200. That needs to be said *explicitly* in the text so that the community can decide what to do about it.

> 
> Of course the other way to look at this would be to conceptually describe this as decapsulation at *each* segment end point and on most just copy the SRH to a new IPv6 header and on PSP happening on Segment N-1 to not copy it.

No, we're not talking about "conceptual" decapsulation. If a packet addressed to address A contains a packet addressed to address B, it isn't going to get to B unless A physically decapsulates it. (Since we're in a state where Segments Left == 0, we're already at the end
of the segment list in the RH, so I don't see where Segment N-1 comes in.)

Where are the diagrams showing example packets to illustrate exactly what happens during PSP?

> 
>     I think the root problem may be using the word "pop", which is relevant in the MPLS label stack context but not here, without additional definition.
> 
> 
> Well I agree. "POP" does not sound like the best terminology choice here for SRH removal or deletion :). Now all what is needed for WG to convince Pablo for massive editing .... 

Yes, but that is precisely because MPLS is designed to support a label stack with pushing and popping, and IPv6 is not designed that way. So "pop" really is completely false terminology when referring to an IPv6 header.

If the explanation was that the original packet is fully decapsulated at the PSP node, so that the SRH disappears along with the rest of the encapsulating header, we wouldn't be having this conversation.

> Happy Holidays,

Indeed!
   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 22 Dec 2019 08:33:26 +1300

Comment at the end:

> The packet, with the updated Destination Address, is forwarded towards the node identified in the Destination Address field of the IPv6 header.

Thanks, I understand that. I think that after the holidays we need to take that explanation back to 6MAN, where I suspect we will find strong objections. This means that two strange things are happening to the packet: in-flight deletion of a header and NAT.

As I just said to Robert, MPLS was designed in a way that makes this natural, but IPv6 wasn't. The natural solution for IPv6 is Penultimate Segment Decapsulation, not PSP, I think.

Regards
    Brian

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 22 Dec 2019 00:38:00 +0100

> No, we're not talking about "conceptual" decapsulation.

Well if you want to take what has been said here to 6man after holidays no
one will stop you there.

But let's keep in mind that a lot of forwarding engines takes input from
various sources and generate a complete outbound rewrite of the packet
header from given offset.

No one I know at data plane is playing with atomic bits or octets overrides
in the packets. Leave alone that data plane does not even do full
processing on entire packets normally. All it does is to copy packet header
leaving the payload in fast local DRAM and just saving pointer to it.

So literally if we agree that IPv6 packet can be encapsulated before it
reaches final destination - what really happens at each segment endpoint if
you zoom in is a decapsulation and encapsulation operation. Hence full
compliance with all IPv6 specs.

IETF drafts usually never go to that level of detail as they do not have
to. Besides even what I just described above significantly differes in
pipeline processing vs run-to-completion NPUs.

So sure after Santa arrives we can argue about all of that for a long time.
But IMHO it would be best if first we really all well understand what are
we really after ...

Cheers,
Robert

On Sat, Dec 21, 2019 at 8:22 PM Brian E Carpenter <
[email-masked]> wrote:

> If there is no decapsulation and the words mean what they say, then there
> is certainly a violation of RFC 8200. That needs to be said *explicitly* in
> the text so that the community can decide what to do about it.
>
> >
> > Of course the other way to look at this would be to conceptually
> describe this as decapsulation at *each* segment end point and on most just
> copy the SRH to a new IPv6 header and on PSP happening on Segment N-1 to
> not copy it.
>
> No, we're not talking about "conceptual" decapsulation. If a packet
> addressed to address A contains a packet addressed to address B, it isn't
> going to get to B unless A physically decapsulates it. (Since we're in a
> state where Segments Left == 0, we're already at the end
> >     I think the root problem may be using the word "pop", which is
> relevant in the MPLS label stack context but not here, without additional
> definition.
> >
> >
> Yes, but that is precisely because MPLS is designed to support a label
> stack with pushing and popping, and IPv6 is not designed that way. So "pop"
> really is completely false terminology when referring to an IPv6 header.
>
> If the explanation was that the original packet is fully decapsulated at
> the PSP node, so that the SRH disappears along with the rest of the
> encapsulating header, we wouldn't be having this conversation.
>
> > Happy Holidays,
>
> Indeed!
>    Brian
>
>