Re: [spring] Suggest some text //RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

["Zafar Ali (zali)" <[e-mail]>]

Hi Joel,

_All_ the existing IPv6 OAM tools will send OAM probes encoding the “actual PSP SID” in the packet (just mimicking data packets).
The penultimate node does not and cannot differentiate between the data packets and OAM probes and executes the exact same PSP SID.
None of the existing IPv6 OAM tools has any dependency on the SRH presence.
Like I mention, we can add clarification in the OAM draft.

Thanks

Regards … Zafar

From: "Joel M. Halpern" <[e-mail]>
Date: Sunday, March 1, 2020 at 9:09 AM
To: "Zafar Ali (zali)" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, spring <[e-mail]>
Subject: Re: [spring] Suggest some text //RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

Zafar, I seem to have missed something.  I understand how the SRv6 OAM
works with a SID that happens to be a PSP SID, up until we get to the
step from the penultimate hop to the ultimate hop.  At the penultiamte
hop, everything works.  But before getting to the ultimate hop, the SRH
is stripped.  Therefore, at the ultimate hop no OAM can take place for
the path with PSP.
If you define the O bit to over-ride the PSP processing, that in and of
itself means that the packets on that final leg are different, again
modifying the intended behavior of OAM.

I will be happy if you can explain how you found a way out of this
conundrum.

Yours,
Joel

On 3/1/2020 8:57 AM, Zafar Ali (zali) wrote:
Greg, Joel,
_All_ the existing IPv6 OAM tools (e.g., ICMP, traceroute, TWAMP, BFD,
etc.) works “as-is” for the PSP SID.
They shall exercise the FIB entry for the PSP SIDs, follow the same path
as PSP SIDs, etc.
We can add clarification in the OAM draft.
Thanks
Regards … Zafar
*From: *spring <[e-mail]<mailto:[e-mail]>> on behalf of Greg Mirsky
<[e-mail]<mailto:[e-mail]>>
*Date: *Sunday, March 1, 2020 at 8:32 AM
*To: *Robert Raszuk <[e-mail]<mailto:[e-mail]>>
*Cc: *"[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, spring <[e-mail]<mailto:[e-mail]>>, "Joel
M. Halpern" <[e-mail]<mailto:[e-mail]>>, 神明達哉<[e-mail]<mailto:[e-mail]>>
*Subject: *Re: [spring] Suggest some text //RE: Request to close the LC
and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming
Hi Robert,
yes, the path probably will be the same regardless whether PSP was
applied or not. But performance metrics, e.g. packet delay, may be
different for OAM and "regular" packets.
Regards,
Greg
On Sun, Mar 1, 2020, 14:08 Robert Raszuk <[e-mail]<mailto:[e-mail]>
<mailto:[e-mail]><mailto:[e-mail]%3e>> wrote:
     Nope.
     Node can advertise two SIDs or PSP in a given network may be a well
     know function (to limit IGP burden) Example: odd SID includes PSP
     and even SID does not.
     O*A*M  packets can use on the exact same path but the penultimate
     hop traversal is directed by even SID and is not subject to PSP..
     Done.
     Thx,
     R.
     On Sun, Mar 1, 2020 at 5:50 AM Joel M. Halpern <[e-mail]<mailto:[e-mail]>
     <mailto:[e-mail]><mailto:[e-mail]%3e>> wrote:
         Presuming that by "OEM" you mean "OAM", then no, this does not work.
         If the OAM is intended to monitor a path that has a last SID whose
         flavor is PSP, then something will break.  The monitoring will
         monitor
         something else, or it won't monitor the last hop, or...
         Given the point that was made that ignoring a source route (SRH or
         otherwise) with segments-left = 0 is a mandatory behavior of
         8200, I am
         really left puzzled as to what use case justifies the contortion
         of PSP.
         Yours,
         Joel
     --------------------------------------------------------------------
     IETF IPv6 working group mailing list
     [e-mail]<mailto:[e-mail]> <mailto:[e-mail]>
     Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
     --------------------------------------------------------------------