Re: [spring] We don't seem to be following our processes (Re: Network Programming - Penultimate Segment Popping)

[Robert Raszuk <[e-mail]>]

Exactly - That is why I thought  it does make sense to make this crystal
clear to everyone here.

>From some comments it seemed that either folks do not understand or want on
purpose to make false assertions only to mud the waters :)

All - have a great weekend,
Robert.



On Sat, Dec 7, 2019 at 4:57 PM Darren Dukes (ddukes) <[e-mail]>
wrote:

> Hi Robert, thank you for injecting clarity to this thread.
>
> draft-ietf-spring-network-programming defines PSP, and the only relevant
> portion of this thread to that draft is Discussion #3.
>
> As I stated in another post, I consider #3 closed as this is clearly
> complying with RFC8200.
> https://mailarchive.ietf.org/arch/msg/ipv6/6Uy_JuMm7W66kTql_o7FYisxkg0
>
> The remainder of the discussion in this thread is unrelated to
> draft-ietf-spring-network-programming.
>
> Thanks
>   Darren
>
> On Dec 7, 2019, at 6:47 AM, Robert Raszuk <[e-mail]> wrote:
>
> Hey Fernando,
>
> (pop when you are the destination but SL!=0 is essentially 'in the
>> network removal')
>
>
> I was trying to stay out of this but I have one fundamental question or
> observation this entire debate seems to be about.
>
> In the context of SRv6 there are two parallel discussions
>
> *Discussion #1* - It is about inserting, modifying or deleting SRH by
> nodes which are not in the outer IPv6 header of the packet
>
> *Discussion #2* - It is about RFC8200 compliance when the node doing
> insertion of SRH is *the* destination of the packet as read verbatim from
> the outer IPv6 header.
>
> *Discussion #3* - It is about RFC8200 compliance when the node doing
> modification or removal of SRH is *the* destination of the packet as read
> verbatim from the outer IPv6 header.
>
> First let's observe that RFC8200 is only defining the behaviour regarding
> EH processing in the context of destination address of the IPv6 outer
> header: "identified in the Destination Address field of the IPv6
> header.identified in the Destination Address field of the IPv6 header. "
>
> Therefore stating that SL value before local decrement matters in this in
> respect to being compliant to the IPv6 RFC is at best just an individual
> interpretation. Besides the pseudocode says it black and white "S14.1.   If
> (updated SL == 0) {". We do all sort of processing decision after
> decrementing the values ... think TTL :)
>
> So back to reality ...
>
> *Discussion #1* - I think we all agree that to accomplish that RFC8200
> would need to be updated.
>
> *Discussion #2* - I think we also all agree here that to accomplish this
> RFC8200 would need to be updated as it does says clearly that "Each
> extension header should occur at most once, ..."
>
> *Discussion #3* - It seems clearly that there is no issue with compliance
> with RFC8200 and that if penultimate segment midpoint decides or is
> instructed to pop SRH it sure can and still be 100% compliant with current
> wording of RFC8200.
>
> So other then so much foam what is this debate all about ?
>
> Cheers,
> Robert.
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
>
>