On 11/12/19 19:04, Suresh Krishnan wrote: > 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).”
Section 4.4 says: The Routing header is used by an IPv6 source to list one or more intermediate nodes to be "visited" on the way to a packet's destination. (contrasts this to the statement with eh insertion/removal/processing) While there could have been better use of terms, do you really think that RFC8200 is allowing EH insertion/removal at waypoints? Or do you think that, at best, the wording in RFC8200 could have been better? How would eh insertion at waypoints work with AH, Path-MTU Discovery, etc., etc.,etc? Thanks, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring