Hi Alex. Please see inline.
Many thanks, Pablo. ________________________________ From: Alexandre Petrescu <[email protected]> Sent: Monday, December 16, 2019 3:31 PM To: Pablo Camarillo (pcamaril) <[email protected]>; [email protected] <[email protected]> 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 <[email protected]> on > behalf of Alexandre Petrescu <[email protected]> Date: > Wednesday, 11 December 2019 at 10:46 To: "[email protected]" > <[email protected]> Subject: Re: [spring] Question about SRv6 Insert > function > > > > Le 11/12/2019 à 10:27, [email protected] a écrit : >> Brian, Pablo >> >> Please see inline (multiple points) >> >>> From: Brian E Carpenter [mailto:[email protected]] >>> Sent: Tuesday, December 10, 2019 8:36 PM To: DECRAENE Bruno >>> TGI/OLN; Fernando Gont Cc: Ron Bonica; [email protected]; >>> [email protected]; 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, [email protected] wrote: >>>> Fernando, >>>> >>>>> From: Fernando Gont [mailto:[email protected]] Sent: >>>>> Monday, December 9, 2019 9:54 PM >>>>> >>>>> On 5/9/19 09:46, [email protected] 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: [email protected] || >>>>> [email protected] 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 >>>> [email protected] 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 >> [email protected] Administrative Requests: >> https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > >> > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list [email protected] Administrative > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > >
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
