Hello Ron, I believe this is the fifth time you have raised this comment in 6man and/or spring. The comment has been addressed in earlier iterations.
Let me recap. With the PSP behavior, the SRH is only removed by the node identified in the destination address field of the IPv6 header. That destination address was placed in the SRH by the SR Source node, fully expecting the behavior. Thanks Darren Iterations: [2019-09-06] https://mailarchive.ietf.org/arch/msg/spring/7zMgIwEY9AipZCCGO9KnT2CGH3o [2019-09-27] https://mailarchive.ietf.org/arch/msg/spring/4_Slu3kkHwduZZPFJJmRUkmoTVo [2019-10-14] https://mailarchive.ietf.org/arch/msg/spring/u536YH4tv7kKRq_b9_x9gBYpO9c [2019-10-21] https://mailarchive.ietf.org/arch/msg/spring/4pikRli_HSECun9AbwfpmOF5KLI [2019-12-04] https://mailarchive.ietf.org/arch/msg/spring/oDWLbRDqKCaF5Xa-QvKY6mk_D5E On Dec 4, 2019, at 11:37 AM, Ron Bonica <rbonica=40juniper....@dmarc.ietf.org> wrote: Pablo, It seems to me that the following are equally controversial: * A transit node inserting a Routing header * A transit node removing a Routing header We have agreed to move discussion of RH insertion out of the Network Programming draft and into another draft. Shouldn’t discussion of RH removal be treated similarly. This comment applies to Penultimate Segment Popping (PHP) in the Network Programming draft. Ron Juniper Business Use Only -------------------------------------------------------------------- IETF IPv6 working group mailing list i...@ietf.org<mailto: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
