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.
Cheers!
Wang Weibin
From: Wang, Weibin (NSB - CN/Shanghai)
Sent: 2019年12月15日 10:09
To: Pablo Camarillo (pcamaril) <pcama...@cisco.com>
Cc: 'spring@ietf.org' <spring@ietf.org>
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:
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
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
