RE: Comments on <draft-ali-6man-spring-srv6-oam-02>

[Xiejingrong <[e-mail]>]

Hi,
Please see my comments inline below:

________________________________
From: Zafar Ali (zali) [[e-mail]]
Sent: Wednesday, July 17, 2019 8:48
To: Xiejingrong; [e-mail]
Cc: Zafar Ali (zali); [e-mail]
Subject: Re: Comments on <draft-ali-6man-spring-srv6-oam-02>

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.

[XJR] This example works for me after the following change about repeated ICMP messages.
[XJR] But still there is a problem not solved, see below marked with [XJR0719]:

Thanks

Regards … Zafar

From: ipv6 <[e-mail]> on behalf of Xiejingrong <[e-mail]>
Date: Tuesday, July 9, 2019 at 10:34 PM
To: "[e-mail]" <[e-mail]>
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.

[XJR0719]
There is hint in the draft <draft-ietf-spring-srv6-network-programming> that an SID may receive ICMP error:

7.2.  SEC-2
   An SRv6 router MUST support an ACL with the following behavior:
   1.   IF (DA == LocalSID) && (SA != internal address or SID space)
   2.      drop

This clearly shows that, an SID may be used as IPv6 SA.
Once that happens, an ICMPv6 error may be send to this SID.

Imagine the scenario:
A PE1 and a PE2 both configure SRv6-VPN using End.DT4 through an IPv6 network without any other SRv6 nodes in between.
The Normal VPNv4 service runs perfectly without using SRH.

Isn't it more beautiful to allow pinging the End.DT4 of PE2 from PE1 without using SRH (and the O-bit in it)?
And more beautiful to allow pinging the End.DT4 of PE1 from PE2 the same way?

It can reduce the unnecessary IPv6 address consumption and configuration as well.
In the above case, there is only one IPv6 address (the End.DT4) on PE1/PE2 required:
(1) When PE1 send Customer packet to PE2, it uses PE1's End.DT4 as SA and uses PE2's End.DT4 as DA.
(2) When PE2 send Customer packet to PE1, it uses PE2's End.DT4 as SA and uses PE1's End.DT4 as DA.

Thanks
Jingrong