Hi Xiejingrong,
Many thanks for your comments. Greatly appreciated.
First off, let’s take the example in section 4.2.2.2 of the draft.
Let’s also modify the example using END.DT4 SID in your example.
I.e., user user wants to traceroute to a remote SID function B:5:DT4, via
<B:2:C31, B:4:C52> from node N1 using O-bit.
In this case,
Node N1 initiates a traceroute probe with SRH as follows (A:1::,
B:2:C31)(B:5:DT4, B:4:C52, B:2:C31; HC=64, SL=2, Flags.O=1;
NH=UDP)(Traceroute Probe).
When O-bit is processed at node 2, we the existing pseudo code works fine.
When O-bit is processed at node 4, we the existing pseudo code works fine.
The pseudo code for O-bit processing at node 5 needs a fix – please see [ZA]
in-line for the suggested change to address your comment.
We can make the change to address your comment during the IETF week.
Thanks
Regards … Zafar
From: ipv6 <[email protected]> on behalf of Xiejingrong
<[email protected]>
Date: Tuesday, July 9, 2019 at 10:34 PM
To: "[email protected]" <[email protected]>
Subject: Comments on <draft-ali-6man-spring-srv6-oam-02>
Hi,
I have a few comments on <draft-ali-6man-spring-srv6-oam-02>:
3.1.1. O-flag Processing
Implementation of the O-flag is OPTIONAL. A node MAY ignore
SRH.Flags.O-flag. It is also possible that a node is capable of
supporting the O-bit but based on a local decision it MAY ignore it
during processing on some local SIDs. If a node does not support the
O-flag, then upon reception it simply ignores it. If a node supports
the O-flag, it can optionally advertise its potential via node
capability advertisement in IGP [I-D.ietf-isis-srv6- extensions] and
BGP-LS [I-D.ietf-idr-bgpls-srv6-ext].
The SRH.Flags.O-flag implements the "punt a timestamped copy and
forward" behavior.
When N receives a packet whose IPv6 DA is S and S is a local SID, N
executes the following pseudo-code, before the execution of the local
SID S.
1. IF SRH.Flags.O-flag is one and local configuration permits THEN
a. Make a copy of the packet.
b. Send the copied packet, along with an accurate timestamp
to the OAM process. ;; Ref1,
[ZA] Add Ref2
Ref1: An implementation SHOULD copy and record the timestamp as soon as
possible during packet processing. Timestamp is not carried in the packet
forwarded to the next hop.
[ZA] Ref2: An implementation should not generate further ICMP error during
local SID S processing. If local SID S processing requires generation of an
ICMP error, the error is generated by the local OAM process.
[XJR] O-flag is OPTIONAL while the process is the first, I don’t think it is
optimized.
I don't even believe the process is clear until the whole process is put
together. I try this for the End.DT4 function (1a to 3a is added as above):
1a. IF NH=SRH AND SRH.Flags.O-flag is one and local configuration permits THEN
2a. a. Make a copy of the packet.
3a. b. Send the copied packet, along with an accurate timestamp to the OAM
process. ;; Ref1
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. lookup the exposed inner IPv4 DA in IPv4 table T
6. forward via the matched table entry
7. ELSE
8. Send an ICMP parameter problem message ;; Ref3
9. drop the packet
Then a packet (NH=SRH<with O flag>, SL=0, ENH=ICMPv6) will go to 2a/3a and 8/9,
means that two ICMP will be send to CPU. Right ?
Besides, the Step 1 to 9 should be more optimized, other than deep check of
SRH.Flags.O-flag at the beginning.
[ZA] The pseudo code does not restrict an implementation to optimize O-bit
processing, as necessary, to get the same behavior.
4.1.2. Pinging a SID Function
The classic ping described in the previous section cannot be used to
ping a remote SID function, as explained using an example in the
following.
Consider the case where the user wants to ping the remote SID
function B:4:C52, via B:2:C31, from node N1. Node N1 constructs the
ping packet (A:1::, B:2:C31)(B:4:C52, B:2:C31, SL=1;
NH=ICMPv6)(ICMPv6 Echo Request).. The ping fails because the node N4
receives the ICMPv6 echo request with DA set to B:4:C52 but the next
header is ICMPv6, instead of SRH. To solve this problem, the
initiator needs to mark the ICMPv6 echo request as an OAM packet.
[XJR] Who produce the problem then ? Seems like it is the SID itself drop the
ICMPv6 packet.
I guess it is easy for an SID to support sending the ICMPv6 packet to CPU, and
support pinging this SID just the same as pinging a classic IPv6 address. Is it
?
I try this for the End.DT4 function (add 7A and 8A):
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. lookup the exposed inner IPv4 DA in IPv4 table T
6. forward via the matched table entry
7A. ELSE IF ENH = 58
8A. Send the packet to CPU
7. ELSE
8. Send an ICMP parameter problem message ;; Ref3
9. drop the packet
Isn’t this simpler than adding a new End.OTP SID ?
The normal use of End.DT4 doesn’t require an SRH header, while the pinging of
the End.DT4 need to add an SRH with an End.OTP and the End.DT4. That looks
strange to me.
[ZA] The issue is that an implementation may not send ICMP error.
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
