Re: [spring] Question about SRv6 Insert function

[Alexandre Petrescu <[e-mail]>]

sorry, worng manipluation

Le 16/12/2019 à 15:31, Alexandre Petrescu a écrit :
> Hi, SPRINGers,
> 
> This is my first post to this list.
> 
> This is about draft-ietf-spring-srv6-network-programming-06
> more precisely the T.Encaps section 5.2.
> 
> Le 11/12/2019 à 21:05, Pablo Camarillo (pcamaril) a écrit :
>> Alex,
>>
>> The precise definition T.Encaps is done in section 5.1 [5.2 now] of
>> draft-ietf-spring-srv6-network-programming-06. If you have any
>> comment on such definition please let me know -on a separate thread
>> and directed to SPRING mailer-.
> 
> Thank you for the reply.
> 
> Please make the T.Encaps part of the draft easier for me to read, e.g.:
> -expand what it means 'S01'; is it 'Step 01', like in BASIC programming
>   language?
> -clarify that the original packet in transit is not modified upon
>   transition (modulo the Hop Limit field and the Segments Left field if
>   present); new packet is created to carry the original packet - yes.
> -clarify what it means 'a packet (A, S2)(S3, S2, S1; SL=1)'; because it
>   is confusing in several ways; (A,S2) invites to think it is src and dst
>   addresses, but their place is switched (the normal order is Source,
>   Destination).  S in 'S2' might mean a Source Address but also might
>   mean a Segment ID, or a Destination address.  Confusion should be
>   avoided, at least in my mind.
> 
> Alex
> 
>>
>> Many thanks, Pablo.
>>
>> -----Original Message----- From: ipv6 <[e-mail]> on
>> behalf of Alexandre Petrescu <[e-mail]> Date:
>> Wednesday, 11 December 2019 at 10:46 To: "[e-mail]"
>> <[e-mail]> Subject: Re: [spring] Question about SRv6 Insert
>> function
>>
>>
>>
>> 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 
>>> --------------------------------------------------------------------
>>
>>>
>>
>>
>> -------------------------------------------------------------------- 
>> IETF IPv6 working group mailing list [e-mail] Administrative
>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 
>> --------------------------------------------------------------------
>>
>>
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------