Re: [spring] Question about SRv6 Insert function

[Alexandre Petrescu <[e-mail]>]

Le 11/12/2019 à 10:27, [e-mail] a écrit :
> Brian, Pablo
> 
> Please see inline (multiple points)
> 
>> From: Brian E Carpenter [mailto:[e-mail]]
>> Sent: Tuesday, December 10, 2019 8:36 PM
>> To: DECRAENE Bruno TGI/OLN; Fernando Gont
>> Cc: Ron Bonica; [e-mail]; [e-mail]; Suresh Krishnan; draft-voyer-6man-extension-header-insertion; draft-ietf-spring-srv6-network-programming
>> Subject: Re: [spring] Question about SRv6 Insert function
>>
>> Bruno,
>>
>> On 11-Dec-19 06:17, [e-mail] wrote:
>>> Fernando,
>>>
>>>> From: Fernando Gont [mailto:[e-mail]]
>>>> Sent: Monday, December 9, 2019 9:54 PM
>>>>
>>>> On 5/9/19 09:46, [e-mail] wrote:
>>>> [....]
>>>>>>
>>>>>> Since there have been plenty of attempts to do EH insertion or
>>>>>> leave the IPv6 standard ambiguous in this respect, and the IETF has
>>>>>> had consensus that EH insertion is not allowed, I think it would be
>>>>>> bad, wastefull, tricky, and even dangerous to let a document go
>>>>>> through the whole publication process, and just rely on the AD to
>>>>>> keep the "DISCUSS" button pressed.
>>>>>
>>>>> draft-ietf-spring-srv6-network-programming has a normative reference
>>>>> to [I-D.voyer-6man-extension-header-insertion]
>>>>> https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-01#section-13.1
>>>>>
>>>>>   As such, from a process standpoint, it would not going to be
>>>>> published before [I-D.voyer-6man-extension-header-insertion] be
>>>>> itself published as RFC. And from its name, the latter is intended to
>>>>> be discussed and within control of the 6MAN WG. So I don't think that
>>>>> we can say that it "just rely on the AD to keep the "DISCUSS" button
>>>>> pressed."
>>>>
>>>> Yes, it is just relying on that.
>>>
>>> Situation has changed since this email: the network programming draft has now removed text related to SRH insertion.
>>> Please comment on the text if you see text related to SRH insertion.
>>
>> For example:
>> https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05#section-8.2
> 
> Quoting the draft for everyone to read
> " Every  node is expected to advertise via BGP-LS its SRv6 capabilities (e.g.
>     how many SIDs it can insert as part of a T.Encaps behavior)"
 >
>   
> This is related to T.Encaps which is using IPv6 (outer) encapsulation.

The term 'IPv6 encapsulation' has a somehow precise meaning, see below a 
citation from an RFC.

Do you mean that T.Encaps 'encapsulates' just the SRv6 header or the 
entire IPv6 packet that contains the SRv6 header?

RFC2473:
>    IPv6 encapsulation consists of prepending to the original packet an
>    IPv6 header and, optionally, a set of IPv6 extension headers (see
>    Fig.3), which are collectively called tunnel IPv6 headers. 

Alex

> - If you believe that T.Encaps is unclear on that, please comment on its text. [1]
> - If the issue is the use of the term 'insert', which is too close to the 'SRH insertion issue', I'm personally fine with using a different term. E.g. "add". Please propose any term which suits you [1]. That been said, I hope that we are not in a situation where words are being forbidden.
> 
> [1] Preferably in the related thread, in order to help everyone (all WG members, chairs, shepherds, ADs, IESG)  to be able to track all comments. As we'll likely be in a situations where the number of emails may be consequent
> 
>> Why would draft-voyer-6man-extension-header-insertion exists if the SRH proponents do not intend to perform SRH insertion?
> 
> As of today, the question been asked is a WG last call on draft-ietf-spring-srv6-network-programming. If you want to secure that SRH insertion is not used in the document, please comment as part of its last call.
> 
> That been said, thanks to your comment, I've seen an unused reference for [I-D.filsfils-spring-srv6-net-pgm-insertion]  that needs to be removed
> 
> --Bruno
> 
> 
>>
>      > Brian
>>
>>>
>>>> A question of you as a chair: does the wg you chair publish documents
>>>> based on current specs (or at the very least based on  changes that are
>>>> going to happen in the near term as a result of *existing and proven
>>>> consensus*), or does spring ship documents that implicitly betting on
>>>> changes that have no consensus?
>>>
>>> In general, I don't see the benefit of sending a draft which we expect would never progress to RFC. So this would not be my preferred path.
>>> However, I guess that as always, there are exceptions and I'm not a priori aware of a process forbidding this. As of today, I'd rather not spend time on this hypothetical case.
>>>   
>>>> The former is how I expect WGs to operate. The later shows a clear path
>>>> to a huge pile of documents stuck at IESG review, simply because so
>>>> later in the process folks found out that the document turns out to
>>>> violate existing specs. With the risk of an AD pressing "YES", and hence
>>>> IETF has been circumvented.
>>>
>>> While IESG processing is beyond my paycheck (literally ;-) ), I trust the IESG. And I don't see a reason to doubt a priori.
>>> And even in this case, there may be a possibly to fetch back the document from the RFC editor queue.
>>>
>>> In short: very hypothetic case and beyond my hat. As of today, I'd propose that we work on the text of the document.
>>>
>>> Thank you,
>>> --Bruno
>>>   
>>>> Thanks,
>>>> -- 
>>>> Fernando Gont
>>>> e-mail: [e-mail] || [e-mail]
>>>> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
>>>>
>>>>
>>>>
>>>
>>> _________________________________________________________________________________________________________________________
>>>
>>> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
>>> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>>>
>>> This message and its attachments may contain confidential or privileged information that may be protected by law;
>>> they should not be distributed, used or copied without authorisation.
>>> If you have received this email in error, please notify the sender and delete this message and its attachments.
>>> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
>>> Thank you.
>>>
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> [e-mail]
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>>>
> 
> _________________________________________________________________________________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>