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

Reply via email to