Re: [spring] USD/USP question in draft-ietf-spring-srv6-network-programming-06.txt

["Wang, Weibin (NSB - CN/Shanghai)" <[e-mail]>]

Hi Gyan:
Pls see more inline;

Cheers!

Wang Weibin

From: Gyan Mishra <[e-mail]>
Sent: 2019年12月15日 15:07
To: Wang, Weibin (NSB - CN/Shanghai) <[e-mail]>
Cc: Pablo Camarillo (pcamaril) <[e-mail]>; [e-mail]
Subject: Re: [spring] USD/USP question in draft-ietf-spring-srv6-network-programming-06.txt

Hi Wang

I have a question regarding the PSP, USP and USD sections I pasted below.

I just sent an email to Spring WG related to PSP and technically why that is necessary as that is a legacy concept that has parity to MPLS but is not used today due to QOS issues.  Please see that email related to that topic.

<WWB> : I am NOT against PSP/USP/UDP concepts, or SID with combination of them, as long as they are useful meaning in network. You may check mails whose subject is “Is srv6 PSP a good idea” in this mailing list, you may get something.

In the PSP section can If we have to keep PSP can we add verbiage that states that PSP removal of the SRH header occurs on the Penultimate egress P node.
<WWB>: PSP is option function, just a building block in network programming, as Pablo said, its usage or not is up to the Ingress border PE of SRv6 domain to encode it in SRH, I don’t care for.

In the USP section can we also add that all remaining SRH present in the packet are popped on the egress PE ultimate node.
<WWB> : at current draft version, multiple successive SRH instances in one packet is NOT allowed.

In looking at these 3 SID functions the PSP and USP pop the EH and the USP removes the 6in6 encapsulation so that the other end.x dt4 dt6 etc can pop the services L3vpn headers.

Why can’t the USD 6in6 encapsulation removal be done on with the USP SID?

<WWB>: I think, you May have a misunderstanding on USP, keeping in mind, IMHO, SID is only instruction, how to deal with packet with destination field value of Packet being SID is decided by the SID, not following the normal rule. In your case, the 6in6 tunnel decapsulation is decided by END.DT4/6 SID, not END with USD flavor.

Why does the USP and USD SID have to be separate?
<WWB>: I am NOT against the SID with combination of USD/USP, even combination of PSP/USP/USD, as long as the mixed function SID is logically reasonable in practice. By the way, the following text you cited isn’t last version.

4.16.1<https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05#section-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 (updated SL == 0) {

   S14.2.      Pop the SRH

   S14.3.   }



4.16.2<https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05#section-4.16.2>.  USP: Ultimate Segment Pop of the SRH





   The SRH processing of the End, End.X and End.T behaviors are

   modified: the instructions S02-S04 are substituted by the following

   ones:



   S02.   If (Segments Left == 0) {

   S03.       Pop the SRH

   S04.   }



4.16.3<https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05#section-4.16.3>.  USD: Ultimate Segment Decapsulation





   The SRH processing of the End, End.X and End.T behaviors are

   modified: the instructions S02-S04 are substituted by the following

   ones:



   S02.   If (Segments Left == 0) {

   S03.      Skip the SRH processing and proceed to the next header

   S04.   }





   Further on, the Upper-layer header processing of the End, End.X and

   End.T behaviors are modified as follows:





Kind regards,



Gyan

On Sat, Dec 14, 2019 at 9:08 PM Wang, Weibin (NSB - CN/Shanghai) <[e-mail]<mailto:[e-mail]>> wrote:
Hi Pablo:

After the 2 context assumption in previous version of this draft,  “we assume that there is no other extension header than the SRH.”  and  “We assume
   that the SRH may be present multiple times inside each packet”, are removed in this last draft, I feel a bit confusion on USD SID, as well as combination of USD & USP.

First, within the content of this last draft, the word “Further on” marked red in the following pseudocode in section “4.16.3” is hard to understand if the packet being processed has other EH embed between SRH and Upper-layer header, such as AH or other EH, then the processing control of this packet will be passed to normal IPv6 module from current SRH processing module in SR-Node, so my question is : Can its control after completing AH processing (for example)  be back to SRH module (or call it pseudocode module) to proceed the next header like “upper-lay header type ==41 or 4”.
Or, if not, Did you created a new EH processing protocol stack instance in parallel to normal IPv6 module within the scope of SRH processing in SR-node.

4.16.3.  USD: Ultimate Segment Decapsulation

S02.   If (Segments Left == 0) {
   S03.      Skip the SRH processing and proceed to the next header
   S04.   }

Further on, the Upper-layer header processing of the End, End.X and
   End.T behaviors are modified as follows:

   End:
   S01. If (Upper-layer Header type == 41 || 4) {
   S02.    Remove the outer IPv6 Header with all its extension headers
   S03.    Submit the packet to the egress IP FIB lookup and
              transmission to the new destination
   S04. } Else {
   S05.    Send an ICMP Parameter Problem message to the Source Address
              Code 4 (SR Upper-layer Header Error),
              Pointer set to the offset of the upper-layer header.
              Interrupt packet processing and discard the packet.

   S06. }

From my understanding, the all processing action about specific SID must be completed successively. That is to say, upon USD, the upper-layer header (type 41 or 4) must be followed the SRH header being processed currently, or second SRH following the same rule (of course, the draft not considering 2 or more successive SRHs).

Second, the mixed SIDs function with combination of USD and USP (even PSP&USD&USP), I think, it is easy to understand when the two assumption above exist, but now I think it isn’t clear if you only provide the following sentence in this draft, i.e.  “if … else…” statement:
“An implementation that supports the USD flavor in conjunction with
   the USP flavor MAY optimize the packet processing by first looking
   whether the conditions for the USD flavor are met, in which case it
   can proceed with USD processing else do USP processing.”
This confusion is also described in my another mail. Of course, if the first question is addressed then this confusion does not exist.

By the way, is it really no different in text description before and after the two context assumption above removed?


Cheers !

WANG Weibin
_______________________________________________
spring mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/spring
--
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>