Re: [spring] Question about SRv6 Insert function

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

Alex,

The precise definition T.Encaps is done in section 5.1 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-.

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