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

"Wang, Weibin (NSB - CN/Shanghai)" <> Wed, 18 December 2019 10:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 89463120025 for <>; Wed, 18 Dec 2019 02:01:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.106
X-Spam-Status: No, score=-1.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zei6bnWP5k0G for <>; Wed, 18 Dec 2019 02:01:30 -0800 (PST)
Received: from (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 74885120071 for <>; Wed, 18 Dec 2019 02:01:29 -0800 (PST)
X-AuditID: ac189297-0e1ff700000012ae-1c-5df9f8d52fee
Received: from (Unknown_Domain []) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id AA.76.04782.5D8F9FD5; Wed, 18 Dec 2019 18:00:53 +0800 (HKT)
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Wed, 18 Dec 2019 18:00:52 +0800
Received: from ([]) by ([]) with mapi id 15.01.1713.007; Wed, 18 Dec 2019 18:00:52 +0800
From: "Wang, Weibin (NSB - CN/Shanghai)" <>
To: "" <>
Thread-Topic: USD/USP question in draft-ietf-spring-srv6-network-programming-06.txt
Thread-Index: AdWy4hb6WRZE2f3ZSWKmDwtbtf5+NACj/4sgAAWyGNA=
Date: Wed, 18 Dec 2019 10:00:52 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_8b9d8f46098c4ae69c355d4f4b64dc59nokiasbellcom_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIIsWRmVeSWpSXmKPExsXS/ts4R/fqj5+xBl0zOC2OX/jN6MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujC+3D7MVvN7JWNHxq5OlgfHcKsYuRg4OCQETiXUNFl2MXBxC AoeYJL4972OHcP4ySjzbsIYJwtnEKNHV9oGli5GTg03ATWLStl1sIN0iAuoSz46Gg4SFBUIk 9r5aywZiiwiEShx7M5MdwraS2DjjG1icRUBVYs7aN0wgNq+AncTB+22MILaQQLHEjguHwGo4 Bewl5p9aD9bLKCAm8f3UGrB6ZgFxiVtP5oPZEgICEkv2nGeGsEUlXj7+xwrxjJJE3wao8lSJ xR9uQa0SlDg58wnLBEaRWUgmzUJSNgtJGURcS2Jew2+oGkWJKd0P2SFsTYkrkw9B2doSyxa+ Zl7AyL6KUTo5rzgjqzg3M8/AWC8vPzszUbc4KTUnRy85P3cTIzCi1khMmr6D8dgB70OMAhyM Sjy8DXd+xgqxJpYVV+YeYpTgYFYS4b3dARTiTUmsrEotyo8vKs1JLT7EKM3BoiTO2zJ5YayQ QHpiSWp2ampBahFMlomDU6qBcVsvy/NNLy1W/fnqzBv9dZJv7o5TRu53v8xft0BXNOuqn6cZ U6D68/fr+19s1sryyj176/3RMKnXb+wrvr2U52+I872sm/PYJ6g7fvOfvR69fv0v/zZ7CYou uG3NLX9sq93ssiv6xy/cnGAwx+51b/E9Y/WDXExiqqJGPAdmus+7d9Z9n7yCmhJLcUaioRZz UXEiAKQyJlqkAgAA
Archived-At: <>
Subject: Re: [spring] USD/USP question in draft-ietf-spring-srv6-network-programming-06.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 18 Dec 2019 10:01:33 -0000

well, I went through again some sections about specific SIDs definition in last draft, I feel that SRH processing module (pseudocode module) include outright all kinds of EHs processing. OK.


Wang Weibin

From: Wang, Weibin (NSB - CN/Shanghai)
Sent: 2019年12月18日 16:08
Subject: RE: USD/USP question in draft-ietf-spring-srv6-network-programming-06.txt

Hi SPRING WG and authors:

I need in further express my opinion about USD SID.
From the content in this last draft, I find lots of SIDs defined in draft, such as END.DX, END.DT, END.DX2 etc., which imply in fact that the next-header immediately following SRH being processed are upper-layer header such NH==41 or 4 (IPv4 or IPv6 or Ethernet frame), which is payload in sense. So if the 2 context assumption mentioned in previous email, “multi extension header may exist and no successive multi SRHs in one packet”, are removed, the behavior of SIDs mentioned above keep no change, because the 2 assumption has not effective for these SIDs. But regarding to END, END.X and END.T with USD, it may be impacted, because it is possible that there are other extension headers residing between SRH and upper-layer header,  as such, in order to decapsulate the outer header to expose inner packet (IPv4/6 or Ethernet), the SR-node has to handle all extension headers existing in this packet until reaching the upper-layer header within its pseudocode module, the function of processing all extension headers has been in normal IPv6 module, so I think it is not necessary for introducing USD, it is better to remove the USD definition.

I hope someone give reply on this question or point out where is my misunderstanding.


Wang Weibin

From: Wang, Weibin (NSB - CN/Shanghai)
Sent: 2019年12月15日 10:09
To: Pablo Camarillo (pcamaril) <<>>
Cc: '' <<>>
Subject: USD/USP question in draft-ietf-spring-srv6-network-programming-06.txt

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:

   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