Hi Fernando, Answer inline. > On Dec 7, 2019, at 9:31 AM, Fernando Gont <fg...@si6networks.com> wrote: > > On 7/12/19 04:19, Suresh Krishnan wrote: >> (responding on spring mailing list) >> >> Hi Fernando, >> >>> On Dec 7, 2019, at 11:07 AM, Fernando Gont <fg...@si6networks.com >>> <mailto:fg...@si6networks.com>> wrote: >>> >>> On 6/12/19 23:47, Brian E Carpenter wrote: >>>> Again, comment at the end... >>>> On 07-Dec-19 14:37, Fernando Gont wrote: >>>>> On 6/12/19 22:15, Brian E Carpenter wrote: >>>>> [...] >>>>>> >>>>>>> and if such a thing is required, an update to RFC8200 should be done. >>>>>> >>>>>> Why does that follow? Alternatively, >>>>>> draft-ietf-spring-srv6-network-programming could acknowledge that >>>>>> it deviates from RFC8200. >>>>> >>>>> You can deviate from s "should", not from a "must". This is an outright >>>>> violation of a spec, rather than a mere "deviation". >>>>> >>>>> >>>>>> Whether that's acceptable would be a question for the IETF Last >>>>>> Call rather than any single WG. >>>>> >>>>> I would expect that a WG cannot ship a document that is violating an >>>>> existing spec, where the wg shipping the document is not in a position >>>>> of making decisions regarding the spec being violated. >>>>> >>>>> That would be like a waste of energy and time for all. >>>>> >>>>> >>>>> >>>>>> At the moment, the draft only mentions RFC8200 in a context that >>>>>> discusses neither insertion nor removal of extension headers, which >>>>>> is beside the point. Like draft-voyer, if it describes a violation >>>>>> of RFC8200, shouldn't that be explicit in the text? >>>>>> >>>>>> There's a lot of jargon in >>>>>> draft-ietf-spring-srv6-network-programming. I can't tell from the >>>>>> jargon whether "insert" means "insert on the fly" and whether "Pop >>>>>> the SRH" means "delete on the fly". Should those terms be clarified >>>>>> before the draft advances? >>>>> >>>>> Well, if it's not clear to you, it would seem to me that the simple >>>>> answer would be "yes". >>>> >>>> But if "insert" refers to the encapsulating node at the SR domain >>>> ingress, it's no problem, and if "pop" simply means doing normal >>>> routing header processing, it's no problem. It simply isn't clear in >>>> the text, at least not clear to me. >>> >>> The fact that a folk that has been deeply involved with IPv6 cannot >>> unequivocally tell what they talking about should be an indication with >>> respect to how ready the document is to be shipped. >>> >>> (pop when you are the destination but SL!=0 is essentially 'in the >>> network removal’) >> >> It is not obvious to me why you think this is a violation of RFC8200 >> though it is possible that I misread your comment. The relevant text I >> am looking at is >> >> " Extension headers (except for the Hop-by-Hop Options header) are not >> processed, inserted, or deleted by any node along a packet's delivery >> path, until the packet reaches the node (or each of the set of nodes, >> in the case of multicast) identified in the Destination Address field >> of the IPv6 header.” >> >> which seems to permit it. Can you please clarify where there is a >> violation? > > In the context of RFC8200, where the text you have quoted is present, > can you tell me which address other than that of the final destination > can be in the Destination Address of the packet?
RFC8200 *clearly* speaks about the possibility of the destination address not being the ultimate recipient in the presence of a Routing Header. This is from Section 3 defining the Destination Address as "128-bit address of the intended recipient of the packet (possibly not the ultimate recipient, if a Routing header is present).” Thanks Suresh _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
