Re: [spring] Question about SRv6 Insert function

["Pablo Camarillo (pcamaril)" <[e-mail]>]

Hi Alex.

Please see inline.

Many thanks,
Pablo.

________________________________
From: Alexandre Petrescu <[e-mail]>
Sent: Monday, December 16, 2019 3:31 PM
To: Pablo Camarillo (pcamaril) <[e-mail]>; [e-mail] <[e-mail]>
Subject: Re: [spring] Question about SRv6 Insert function

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?

PC: Same format as in other documents (e.g. SRH).

-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.

PC: I have added a paragraph in the latest version of the draft to capture your point. See rev07. Many thanks.

-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.

PC: This is explained in the terminology section of the draft (with a detailed example).

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
> --------------------------------------------------------------------
>
>