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) <ddu...@cisco.com> 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 <rob...@raszuk.net> 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 > i...@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
