SRv6 OAM

[Robert Raszuk <[e-mail]>]

Hi Zafar,

I think I am also missing something here. Let me ask few questions

Q1 -  I am talking describing the case of in-situ Node A to Node B
unidirection telemetry stream where assume nodes A & B are within given
administrative domain. How would B know that SRH was removed somewhere in
the middle ? Note - node A is never part of any reception of the probe
packets.

Q2 - Basic ping - Let's assume that src A is a host outside of SP and that
it wants to run ping or traceroute through the domain or even further. As
ingress node encapsulates the packets (hopefully this will be configured
such ICMP gets the same encap as TCP or UDP) how nodes within SR path till
the very end of the path will be able to send responses back A ?

Do you count on ingress node (encapsulation src address) doing the proxy
NAT function in the slow path ? Or is the assumption here that SRv6 does
not propagate TTL and what happens within the domain is invisible for the
external party ?

Thx,
R.

On Sun, Mar 1, 2020 at 3:34 PM Zafar Ali (zali) <zali=
[e-mail]> wrote:

> 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
>