Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Fri, 7 Feb 2020 10:03:46 +0000

Greg,

We have published an updated revision of the draft that incorporates the change. See more inline PC2.

Many thanks,
Pablo.

From: Greg Mirsky <[email-masked]>
Date: Monday, 27 January 2020 at 06:36
To: "Pablo Camarillo (pcamaril)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: WGLC - draft-ietf-spring-srv6-network-programming

Hi Pablo,
thank you for your thoughtful consideration of my comments. Please find my new notes in-line below tagged GIM>>.

Regards,
Greg

On Tue, Jan 21, 2020 at 11:08 PM Pablo Camarillo (pcamaril) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,

Inline.

Thanks,
Pablo.

From: Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Date: Sunday, 19 January 2020 at 20:28
To: "Pablo Camarillo (pcamaril)" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: WGLC - draft-ietf-spring-srv6-network-programming

Hi Pablo,
thank you for sharing your opinion. I understand that you believe that draft-ietf-6man-spring-srv6-oam will not change and will be published with defining the O-flag as
      O-flag: OAM flag.  When set, it indicates that this packet is an
      operations and management (OAM) packet.
I, on the other hand, am much less certain that that draft and SRv6 OAM, in general, require the special flag in SRH. I believe that progressing the draft-ietf-spring-srv6-network-programming with the current text and the informative reference increases the likelihood that an Errata must be filed one the SRv6 OAM draft is published.

PC:
I believe that we can trim the text in section 6.3 to avoid mentioning the O-bit without reducing the overall quality of the document.
<old>
   [I-D.ietf-6man-spring-srv6-oam] defines OAM behaviors for SRv6.  This
   includes the definition of the SRH Flag 'O-bit', as well as
   additional SR Endpoint behaviors for OAM purposes.
</old>
<new>
   [I-D.ietf-6man-spring-srv6-oam] defines OAM behaviors for SRv6.  This
   includes the definition of additional SR Endpoint behaviors for OAM purposes.
</new>
Do you agree with this change?
GIM>> I agree that the new text is more clear and less dependent on the discussion of I-D.ietf-6man-spring-srv6-oam. Though the "OAM behaviors for SRv6" that are introduced in the draft, i.e., "punt the packet" and "punt the packet with a timestamp", are being discussed and may change as the result of the discussion by 6man WG. Hence I think that it be better to not to reference   I-D.ietf-6man-spring-srv6-oam altogether.

PC2: I have updated the draft to remove the reference to O-bit as you agreed.
Regarding removing the full reference to the OAM draft: I believe that the new text is generic enough as to be good regardless of the changes during the WG LC of the OAM draft. I believe that the reference is useful for someone implementing it.

And as we're discussing a sub-section in the Operation section, I've got few questions on counters, hope you don't mind:
•         As this is part of the operational considerations, should there be any recommendation on the length of the counters?
PC: Counter length is implementation dependent. The capabilities of different platforms have significant hairpin as to make any recommendation irrelevant.
•         Also, the usual drawback of detailed statistics to characterize a flow is scaling. Any consideration and recommendation on that?
PC: There is no per-flow statistics. It is a counter per SRv6 SID. An SRv6 SID is shared among different flows. No per-flow scaling is required.
•         And last. I didn't find any of these counters being discussed in draft-ietf-6man-spring-srv6-oam. Perhaps you can help me with a reference to the SRv6 document that uses them.
PC: The counters are required by the controller. Its usage is out of the scope of this document.
GIM>> I think that if SRv6 OAM was part of the network programming draft, then defining these counters, that are, in my understanding, an integral part of SRv6 OAM, logical, in the right place. But since SRv6 OAM is discussed in the draft of its own, I suggest considering moving Section 6.1 Counters to I-D.ietf-6man-spring-srv6-oam.

PC2: The counters are part of the architecture and in my opinion do not belong to the OAM draft. The usage of the counters are beyond the OAM draft.
Regards,
Greg

On Mon, Jan 13, 2020 at 10:23 AM Pablo Camarillo (pcamaril) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,

Inline.

Thank you,
Pablo.

From: Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Date: Sunday, 12 January 2020 at 04:01
To: “Pablo Camarillo (pcamaril)” <[email-masked]<mailto:[email-masked]>>
Cc: “[email-masked]<mailto:[email-masked]>” <[email-masked]<mailto:[email-masked]>>
Subject: Re: WGLC – draft-ietf-spring-srv6-network-programming

Hi Pablo,
thank you for your expedient response. Please find my new notes under GIM>> tag below in-line.

Regards,
Greg

On Fri, Jan 10, 2020 at 1:09 PM Pablo Camarillo (pcamaril) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,

Inline.

Thanks,
Pablo.

From: Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, 7 January 2020 at 21:01
To: Bruno Decraene <[email-masked]<mailto:[email-masked]>>
Cc: SPRING WG List <[email-masked]<mailto:[email-masked]>>, “[email-masked]<mailto:[email-masked]>” <[email-masked]<mailto:[email-masked]>>, draft-ietf-spring-srv6-network-programming <[email-masked]<mailto:[email-masked]>>
Subject: Re: WGLC – draft-ietf-spring-srv6-network-programming
Resent from: <[email-masked]<mailto:[email-masked]>>
Resent to: <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>
Resent date: Tuesday, 7 January 2020 at 21:01

Dear Authors, WG Chairs, et al.,
I hope I’m not too late with my comments and questions on the document. Please kindly consider them as WG LC comments:
•         I have a question regarding the following pseudo-code:
  S08.   Max_LE = (Hdr Ext Len / 2) – 1
  S09.   If ((Last Entry > max_LE) or (Segments Left > (Last Entry+1)) {
  S10.      Send an ICMP Parameter Problem to the Source Address,
               Code 0 (Erroneous header field encountered),
               Pointer set to the Segments Left field.
               Interrupt packet processing and discard the packet.
  S11.   }

According to RFC 8200, Hdr Ext Len is the length of the extension header in 8-octet units, not including the first 8 octets. Thus, as I understand, max_LE is the length in 8-octet units of half of the extension header less one. On the other hand, Last Entry and Segments Left are indices. Hence my question, What is being compared in line S09 ( Last Entry > max_LE)? Length and index? If the goal is to use Hdr Ext Len to calculate the number of entries in the header, then what assumption is used in S08? Is it that the entry’s length is always and only 128 bits, i.e. 16 octets? I believe that using such an assumption is too narrowing and limiting to SRH.

PC: This has already been discussed with Adrian. Please check this thread: https://mailarchive.ietf.org/arch/msg/spring/IOA_4nlNPacD2v7Jue2dkGeOABk
GIM>> Thank you for the reference. In some aspects, part of my statement is repeating your answer to Adrain. The only length on an element in SRH considered is 128 bits, the length of IPv6 address. I think that your explanation of how you have arrived at th following formula
    S08.   Max_LE = (Hdr Ext Len / 2) – 1
 will benefit the document.
My question to you and SPRING WG goes beyond this scenario. Considering presented in Singapore Unified Identifier proposals (draft-mirsky-6man-unified-id-sr<https://datatracker.ietf.org/doc/draft-mirsky-6man-unified-id-sr/> and draft-wmsaxw-6man-usid-id-use<https://datatracker.ietf.org/doc/draft-gmsm-bess-evpn-bfd/?include_text=1>), I believe other scenarios of using SRH, with elements of length other than 128 bits should be accommodated, e.g., 32 bits-long elements.
i.

PC: It is up to the draft-mirsky authors to standardize in their draft the changes to the SRH processing. As per today the draft-mirsky proposal is still an individual document.

•         Another question is to Section 6.3. What value do you see in this section? I've noticed that draft-ietf-6man-spring-srv6-oam is in the Informational References section. I agree with that for the first sentence in the section. But I believe that the second sentence that refers to the new O-bit and OAM behaviors defined in  draft-ietf-6man-spring-srv6-oam requires it to be moved into the Normative References section. Unless you'll decide to remove the section altogether.
PC: The O-bit and OAM behaviors described in draft-ietf-6man-spring-srv6-oam are not required to understand or implement the technology described in draft-ietf-spring-srv6-network-programming. However, they are relevant as to provide additional information to the reader. Why would it be a normative reference?
GIM>> Ali and I are discussing several aspects of draft-ietf-6man-spring-srv6-oam. For example, the O-bit is applicable to any OAM operation or to some part of them. Note that OAM apparatus usually considered to include Fault Management and Performance Monitoring protocols. Both may operate as proactive or on-demand. Is the O-bit applicable to all OAM methods? Then, Fault Management OAM supports Continuity Check, Connectivity Verification and, for some networks, Automatic Protection Coordination. How O-bit is used in these methods? Now, to the Performance Monitoring OAM. I think that the O-bit can be only used in dual-ended one-way PM OAM. How O-bit may be used in single-ended two-way PM OAM? Can the O-bit support the Loss Measurement? As you may see, there are many questions to discuss and clarify in the document. I can imagine that the result of our work on draft-ietf-6man-spring-srv6-oam may be somewhat different from its current form. How to ensure synchronization between SRv6 programming and OAM specifications?

PC: The current reference in draft-ietf-spring-srv6-network-programming does not explain particular mechanisms of draft-ietf-6man-spring-srv6-oam. It only says that draft-ietf-6man-spring-srv6-oam defines OAM mechanisms for SRv6 as well as the O-bit. This is flexible enough as to be correct regardless of the changes that you make during the WGLC to draft-ietf-6man-spring-srv6-oam.

Regards,
Greg

On Thu, Dec 5, 2019 at 9:15 AM <[email-masked]<mailto:[email-masked]>> wrote:

Hello SPRING,

This email starts a two weeks Working Group Last Call on draft-ietf-spring-srv6-network-programming [1].

Please read this document if you haven't read the most recent version, and send your comments to the SPRING WG list, no later than December 20.

You may copy the 6MAN WG for IPv6 related comment, but consider not duplicating emails on the 6MAN mailing list for the comments which are only spring specifics.

If you are raising a point which you expect will be specifically debated on the mailing list, consider using a specific email/thread for this point.

This may help avoiding that the thread become specific to this point and that other points get forgotten (or that the thread get converted into parallel independent discussions)

Thank you,

Bruno

[1] https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05

_________________________________________________________________________________________________________________________

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-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 11 Feb 2020 08:38:23 -0800

Hi Pablo,
thank you for considering my comments and making the update. I think that
it is up to others interested, in particular in OAM of SRv6, to share their
opinions regarding the relationship between this draft and SRv6 OAM document
<https://tools.ietf.org/html/draft-ietf-6man-spring-srv6-oam-03> that is in
6man WG. Maybe Chairs of SPRING WG will reach out to 6man WG to consider
the relationship between the documents.
Regarding the counters being defined in the document. I think that the
primary use of counters is by OAM. Thus, I think it would be appropriate to
define and demonstrate the use of these counters in SRv6 OAM specification.

Regards,
Greg

On Fri, Feb 7, 2020 at 2:03 AM Pablo Camarillo (pcamaril) <
[email-masked]> wrote:

> *From: *Greg Mirsky <[email-masked]>
> *Date: *Monday, 27 January 2020 at 06:36
> *To: *"Pablo Camarillo (pcamaril)" <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *Subject: *Re: WGLC - draft-ietf-spring-srv6-network-programming
>
>
>
> Hi Pablo,
>
> On Tue, Jan 21, 2020 at 11:08 PM Pablo Camarillo (pcamaril) <
> [email-masked]> wrote:
>
> Hi Greg,
>
>
>
> Inline.
>
>
>
> Thanks,
>
> Pablo.
>
>
>
> *From: *Greg Mirsky <[email-masked]>
> *Date: *Sunday, 19 January 2020 at 20:28
> *To: *"Pablo Camarillo (pcamaril)" <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *Subject: *Re: WGLC - draft-ietf-spring-srv6-network-programming
>
>
>
> Hi Pablo,
>
> thank you for sharing your opinion. I understand that you believe that
> draft-ietf-6man-spring-srv6-oam will not change and will be published with
> defining the O-flag as
>
> I, on the other hand, am much less certain that that draft and SRv6 OAM,
> in general, require the special flag in SRH. I believe that progressing
> the draft-ietf-spring-srv6-network-programming with the current text and
> the informative reference increases the likelihood that an Errata must be
> filed one the SRv6 OAM draft is published.
>
>
>
> PC:
>
> I believe that we can trim the text in section 6.3 to avoid mentioning the
> O-bit without reducing the overall quality of the document.
>
> <old>
>
> GIM>> I agree that the new text is more clear and less dependent on the
> discussion of I-D.ietf-6man-spring-srv6-oam. Though the "OAM behaviors for
> SRv6" that are introduced in the draft, i.e., "punt the packet" and "punt
> the packet with a timestamp", are being discussed and may change as the
> result of the discussion by 6man WG. Hence I think that it be better to not
> to reference   I-D.ietf-6man-spring-srv6-oam altogether.
>
>
>
> Regarding removing the full reference to the OAM draft: I believe that the
> new text is generic enough as to be good regardless of the changes during
> the WG LC of the OAM draft. I believe that the reference is useful for
> someone implementing it.
>
>
>
> And as we're discussing a sub-section in the Operation section, I've got
> few questions on counters, hope you don't mind:
>
> ·         As this is part of the operational considerations, should there
> be any recommendation on the length of the counters?
>
> PC: Counter length is implementation dependent. The capabilities of
> different platforms have significant hairpin as to make any recommendation
> irrelevant.
>
> ·         Also, the usual drawback of detailed statistics to characterize
> a flow is scaling. Any consideration and recommendation on that?
>
> PC: There is no per-flow statistics. It is a counter per SRv6 SID. An SRv6
> SID is shared among different flows. No per-flow scaling is required.
>
> ·         And last. I didn't find any of these counters being discussed
> in draft-ietf-6man-spring-srv6-oam. Perhaps you can help me with a
> reference to the SRv6 document that uses them.
>
> GIM>> I think that if SRv6 OAM was part of the network programming draft,
> then defining these counters, that are, in my understanding, an integral
> part of SRv6 OAM, logical, in the right place. But since SRv6 OAM is
> discussed in the draft of its own, I suggest considering moving Section 6.1
> Counters to I-D.ietf-6man-spring-srv6-oam.
>
>
>
> PC2: The counters are part of the architecture and in my opinion do not
> belong to the OAM draft. The usage of the counters are beyond the OAM draft.
>
> Regards,
>
> Greg
>
>
>
>
>
> On Mon, Jan 13, 2020 at 10:23 AM Pablo Camarillo (pcamaril) <
> [email-masked]> wrote:
>
> Hi Greg,
>
>
>
> Inline.
>
>
>
> Thank you,
>
> Pablo.
>
>
>
> *From: *Greg Mirsky <[email-masked]>
> *Date: *Sunday, 12 January 2020 at 04:01
> *To: *“Pablo Camarillo (pcamaril)” <[email-masked]>
> *Cc: *“[email-masked]” <[email-masked]>
> *Subject: *Re: WGLC – draft-ietf-spring-srv6-network-programming
>
>
>
> Hi Pablo,
>
> On Fri, Jan 10, 2020 at 1:09 PM Pablo Camarillo (pcamaril) <
> [email-masked]> wrote:
>
> Hi Greg,
>
>
>
> Inline.
>
>
>
> Thanks,
>
> Pablo.
>
>
>
> *From: *Greg Mirsky <[email-masked]>
> *Date: *Tuesday, 7 January 2020 at 21:01
> *To: *Bruno Decraene <[email-masked]>
> *Cc: *SPRING WG List <[email-masked]>, “[email-masked]” <[email-masked]>,
> draft-ietf-spring-srv6-network-programming <
> [email-masked]>
> *Subject: *Re: WGLC – draft-ietf-spring-srv6-network-programming
> *Resent from: *<[email-masked]>
> *Resent to: *<[email-masked]>, <[email-masked]>, <[email-masked]>, <
> [email-masked]>, <[email-masked]>, <
> [email-masked]>
> *Resent date: *Tuesday, 7 January 2020 at 21:01
>
>
>
> I hope I’m not too late with my comments and questions on the document.
> Please kindly consider them as WG LC comments:
>
> ·         I have a question regarding the following pseudo-code:
>
> According to RFC 8200, Hdr Ext Len is the length of the extension header
> in 8-octet units, not including the first 8 octets. Thus, as I understand,
> max_LE is the length in 8-octet units of half of the extension header less
> one. On the other hand, Last Entry and Segments Left are indices. Hence my
> question, What is being compared in line S09 ( Last Entry > max_LE)? Length
> and index? If the goal is to use Hdr Ext Len to calculate the number of
> entries in the header, then what assumption is used in S08? Is it that the
> entry’s length is always and only 128 bits, i.e. 16 octets? I believe that
> using such an assumption is too narrowing and limiting to SRH.
>
>
>
> PC: This has already been discussed with Adrian. Please check this thread:
> https://mailarchive.ietf.org/arch/msg/spring/IOA_4nlNPacD2v7Jue2dkGeOABk
>
> GIM>> Thank you for the reference. In some aspects, part of my statement
> is repeating your answer to Adrain. The only length on an element in SRH
> considered is 128 bits, the length of IPv6 address. I think that your
> explanation of how you have arrived at th following formula
>
> My question to you and SPRING WG goes beyond this scenario. Considering
> presented in Singapore Unified Identifier proposals (
> draft-mirsky-6man-unified-id-sr
> <https://datatracker.ietf.org/doc/draft-mirsky-6man-unified-id-sr/> and
> draft-wmsaxw-6man-usid-id-use
> <https://datatracker.ietf.org/doc/draft-gmsm-bess-evpn-bfd/?include_text=1>),
> I believe other scenarios of using SRH, with elements of length other than
> 128 bits should be accommodated, e.g., 32 bits-long elements.
>
> i.
>
>
>
> PC: It is up to the draft-mirsky authors to standardize in their draft the
> changes to the SRH processing. As per today the draft-mirsky proposal is
> still an individual document.
>
>
>
> ·         Another question is to Section 6.3. What value do you see in
> this section? I've noticed that draft-ietf-6man-spring-srv6-oam is in the
> Informational References section. I agree with that for the first sentence
> in the section. But I believe that the second sentence that refers to the
> new O-bit and OAM behaviors defined in  draft-ietf-6man-spring-srv6-oam
> requires it to be moved into the Normative References section. Unless
> you'll decide to remove the section altogether.
>
> PC: The O-bit and OAM behaviors described in
> draft-ietf-6man-spring-srv6-oam are not required to understand or implement
> the technology described in draft-ietf-spring-srv6-network-programming.
> However, they are relevant as to provide additional information to the
> reader. Why would it be a normative reference?
>
> GIM>> Ali and I are discussing several aspects of
> draft-ietf-6man-spring-srv6-oam. For example, the O-bit is applicable to
> any OAM operation or to some part of them. Note that OAM apparatus usually
> considered to include Fault Management and Performance Monitoring
> protocols. Both may operate as proactive or on-demand. Is the O-bit
> applicable to all OAM methods? Then, Fault Management OAM supports
> Continuity Check, Connectivity Verification and, for some networks,
> Automatic Protection Coordination. How O-bit is used in these methods? Now,
> to the Performance Monitoring OAM. I think that the O-bit can be only used
> in dual-ended one-way PM OAM. How O-bit may be used in single-ended two-way
> PM OAM? Can the O-bit support the Loss Measurement? As you may see, there
> are many questions to discuss and clarify in the document. I can imagine
> that the result of our work on draft-ietf-6man-spring-srv6-oam may be
> somewhat different from its current form. How to ensure synchronization
> between SRv6 programming and OAM specifications?
>
>
>
> PC: The current reference in draft-ietf-spring-srv6-network-programming
> does not explain particular mechanisms of draft-ietf-6man-spring-srv6-oam.
> It only says that draft-ietf-6man-spring-srv6-oam defines OAM mechanisms
> for SRv6 as well as the O-bit. This is flexible enough as to be correct
> regardless of the changes that you make during the WGLC to
> draft-ietf-6man-spring-srv6-oam.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Thu, Dec 5, 2019 at 9:15 AM <[email-masked]> wrote:
>
> Hello SPRING,
>
>
>
> [email-masked]

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Sun, 23 Feb 2020 20:11:48 +0000

Hi Greg,

As per your feedback we’ve removed the reference to the OAM draft from the document.
We’ve also removed the counters 2 and 3, keeping in this document the only counter specific to this document.

These changes have already been incorporated into revision 10. Many thanks for the review.

Cheers,
Pablo.

Date: Tuesday, 11 February 2020 at 17:38

Hi Pablo,
thank you for considering my comments and making the update. I think that it is up to others interested, in particular in OAM of SRv6, to share their opinions regarding the relationship between this draft and SRv6 OAM document<https://tools.ietf.org/html/draft-ietf-6man-spring-srv6-oam-03> that is in 6man WG. Maybe Chairs of SPRING WG will reach out to 6man WG to consider the relationship between the documents.
Regarding the counters being defined in the document. I think that the primary use of counters is by OAM. Thus, I think it would be appropriate to define and demonstrate the use of these counters in SRv6 OAM specification.

Regards,
Greg

On Fri, Feb 7, 2020 at 2:03 AM Pablo Camarillo (pcamaril) <[email-masked]<mailto:[email-masked]>> wrote:
Greg,

Many thanks,
Pablo.

Hi Pablo,

Regards,
Greg

Inline.

Thanks,
Pablo.

Hi Pablo,

PC:

Inline.

Thank you,
Pablo.

Hi Pablo,

Regards,
Greg

Inline.

Thanks,
Pablo.

Regards,
Greg

Hello SPRING,

Thank you,

Bruno

Thank you.

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 27 Feb 2020 17:30:27 -0800

Hi Pablo,
thank you and al lthe authors for kind consideration of my comments, much
appreciated.
I've found all my comments being address in the latest version of the draft.
I'll now discuss with Zafar OAM-specific aspects of using some of behaviors
defined in the SRv6 network programming. Would be the most helpful if you
share your views. I hope you will agree if I keep you in the loop.

Regards,
Greg

On Sun, Feb 23, 2020 at 12:12 PM Pablo Camarillo (pcamaril) <
[email-masked]> wrote:

> *Date: *Tuesday, 11 February 2020 at 17:38
> opinions regarding the relationship between this draft and SRv6 OAM
> document <https://tools.ietf.org/html/draft-ietf-6man-spring-srv6-oam-03>
> that is in 6man WG. Maybe Chairs of SPRING WG will reach out to 6man WG to
> consider the relationship between the documents.
>

---

From: <[email-masked]>
Date: Fri, 28 Feb 2020 16:53:07 +0000

Hello SPRING WG,

Please find below some status on the main points of this WG LC.

===============
A) PSP [1] & RFC 8200 [2]
===============

This point is whether SRH removal by the penultimate SR end point (aka PSP) is allowed by RFC 8200.

More specifically
" S14.4.      Remove the SRH from the IPv6 extension header chain"
Vs
 "   Extension headers (except for the Hop-by-Hop Options header) are not
   processed, inserted, or deleted by any node along a packet's delivery
   path, until the packet reaches the node (or each of the set of nodes,
   in the case of multicast) identified in the Destination Address field
   of the IPv6 header."

On this text, what is been discussed is "the node (or each of the set of nodes,
   in the case of multicast) identified in the Destination Address field
   of the IPv6 header."
More specifically whether "Destination Address field of the IPv6 header" means the "final Destination Address" or the "Destination Address" as seen in the packet that the node received.

[1] https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-10#section-4.16.1
[2] https://tools.ietf.org/html/rfc8200#section-4

It's clear that two different opinions have been expressed, sometimes strongly, sometimes repeatedly.
The literal reading of RFC 8200 wording ("the Destination Address field of the IPv6 header."), seem to allow PSP. At the very least, I don't find a basis to block this PSP behavior.
Finally, the responsible AD has not accepted the related errata. https://mailarchive.ietf.org/arch/msg/ipv6/yVKxBF3VnJQkIRuM8lgWN4_G3-o/

Based on this, the plan is to flag this point of debate in the shepherd report, and leave this for the IESG to decide on how to read RFC 8200 (which represented 6MAN consensus and which the IESG approved). The threat to appeal will also be explicitly indicated (shepherd write up, point 10).

Independently of RFC 8200, the question has been raised with regards to the benefit of PSP.
My take is that PSP is an optional data plane optimization. Judging its level of usefulness is very hardware and implementation dependent. It may range anywhere from "not needed" to "required for my platform" (deployed if you are network operator, or been sold if you are a vendor), with possible intermediate points along "n% packet processing gain", or "required when combined with a specific other feature". I don't think that the SPRING WG can really evaluate this point (lack of hardware knowledge, lack of detailed information on the hardwares). The fact that this has been implemented by some platforms and deployed by some operators, is, to me, an indication that it is useful for those cases. (I believe that an English proverb is "the proof of the pudding is in the eating". Although I'm certainly missing part of its meaning and culture, in it's literal reading, it seems to apply).

===============
B) confirmed WG interest and WG support to move forward
===============

Multiple/many "support" and "+1" have been expressed.
There is clearly an interest from the WG on this document, and to have it progressed.

Note that there is no need for one to express his support multiple times. e.g., by sending another "+1" when one has already expressed his support.

===============
C) clarifying/correcting the text in order to have common understanding and interoperable implementations.
===============

WG is working on clarifying/correcting the text in order to have common understanding and interoperable implementations. We should finalize this.
This is taking a bit more time than unusual (although it really depends compared to which document, e.g., SRH draft).
I'd like everyone to consider the specifics of the SRv6 work and this document:  there may be cultural differences between people from the spring/routing context and the 6man/Internet context. As such, someone coming from one context may believe that point "A" is obvious and hence doesn't understand why someone from another context seem to not understand it. I'd like everyone to make an effort on this.
Let's remember that this point is about writing a technical specification which is well understood by everyone, and minimizing interoperability risks.

--> Let's please focus on this aspect.

===============
D) formal decision to advance this document
===============
I'm listed as a contributor on this document (among 23 contributors).
Even though I have zero specific write/modification privilege on the text in this document, and I'm not part of the authors email alias, this would not be ideal for me to take the decision to forward this document to the IESG. I've discussed this with our AD (Martin) and he agreed to make the formal decision to send the document to the next level. Thank you Martin.
As an element of context, I handled this WG LC not for the fun of it or because I believed it would easy, but because we needed to advance this document and that Rob was not available to take that role.

--Bruno

From: ipv6 [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, December 5, 2019 6:15 PM
To: 'SPRING WG List'
Cc: [email-masked]; draft-ietf-spring-srv6-network-programming
Subject: WGLC - draft-ietf-spring-srv6-network-programming

Hello SPRING,

Thank you,

Bruno

Thank you.

---

From: <[email-masked]>
Date: Fri, 28 Feb 2020 17:19:10 +0000

Pablo, authors, WG,

Section 4.16.1 [1] is the subject of multiple comments and clarification questions. Most notably some comments from Brian.

Its current text is very focused on the technical specification. Technical specification is good and this is the primary objective to achieve interoperability. But some would say that it is a bit terse, especially given the amount of context behind it. So I think that it could benefit from some introduction text.

Could you work on some text to better introduce PSP and put it in context? Possibly working with Brian who is kind enough to work on improving the clarity of this section for everyone.
Quoting Brian "simply need more explanation in elementary terms".

I personally have a few points in mind:

-          Clarifying what "Penultimate" refers to. This is required as there are multiple reading such "penultimate IPv6/SRv6 transit node" (which we all agree is not allowed by RFC 8200, so let's make things clear that the document is not talking or suggesting or allowing this) or "penultimate SR Segment Endpoint Node indicated in the IPv6 destination address of the received IPv6 header".

-          Clarify what you mean by "Pop". (as this terminology is heavily borrowed from MPLS and may not be crystal clear for everyone, especially since the MPLS RFC is not a normative reference (and it should not be))

-          Clarify that given the nodes A-B-C,  the PSP flavor is done by penultimate Segment Endpoint "B" at the request of the IPv6 source node "A" as an outsourced service from the ultimate SR End Point "C". "A", "B" and "C" been within the same control domain.

Agreed that this is not changing anything in the spec, and may be obvious to you, and hopefully clear for people having read the relevant document, however from the comments it seems clear that some additional context may help to clarify. Also it's plausible that some persons may only read this specific PSP section and react on it.

Thank you,
--Bruno

Hello SPRING,

Thank you,

Bruno

Thank you.

---

From: Fernando Gont <[email-masked]>
Date: Fri, 28 Feb 2020 16:27:44 -0300

Bruno,

On 28/2/20 13:53, [email-masked] wrote:
> " S14.4.Remove the SRH from the IPv6 extension header chain"
> 
> Vs
> 
> "Extension headers (except for the Hop-by-Hop Options header) are not
> More specifically whether "Destination Address field of the IPv6 header" 
> means the "final Destination Address" or the "Destination Address" as 
> seen in the packet that the node received.

If it meant "Destination Address", that would mean multicast addresses, 
would be allowed in routing headers. Do you think htat's the case?

[...]
> Finally, the responsible AD has not accepted the related errata. 
> https://mailarchive.ietf.org/arch/msg/ipv6/yVKxBF3VnJQkIRuM8lgWN4_G3-o/

The status of this erratum is found here: 
https://www.rfc-editor.org/errata/eid5933   -- not on the mailing-list 
archive. And the erratum is marked as "reported", not as "rejected".

Suresh may well go ahead and reject it. BUt so far the status has not 
changed since I've reported it.

> Based on this, the plan is to flag this point of debate in the shepherd 
> report, and leave this for the IESG to decide on how to read RFC 8200 
> (which represented 6MAN consensus and which the IESG approved). The 
> threat to appeal will also be explicitly indicated (shepherd write up, 
> point 10).

I have *noted* a number of times that I would appeal (so *please* do 
note that a number of people felt that the specs were being violated 
*and* that our processes were being circumvented).

But I've never *threatened* to appeal.

A quick lookup in a dictionary says:
"threat"

noun
1.
a statement of an intention to inflict pain, injury, damage, or other 
hostile action on someone in retribution for something done or not done.
2.
a person or thing likely to cause damage or danger.

Clearly, there was no "threat". I did indicate that one of our specs was 
being violated, and that our processes were being circumvented (in the 
same way that I'm quite curious how you can claim consensus on this 
document, but.. ).  That says, appeals are part of our processes.

I have no idea whatsoever how, sticking to our processes could be 
considered a threat.

Quite the contrary, the intention is for our existing specs and 
procedures to be respected. If *that* is considered a threat, that's a 
different question.

> My take is that PSP is an optional data plane optimization. Judging its 
> level of usefulness is very hardware and implementation dependent. It 
> may range anywhere from "not needed" to "required for my platform" 
> (deployed if you are network operator, or been sold if you are a 
> vendor), with possible intermediate points along "n% packet processing 
> gain", or "required when combined with a specific other feature". I 
> don't think that the SPRING WG can really evaluate this point (lack of 
> hardware knowledge, lack of detailed information on the hardwares). 

Am I reading correctly? Are you kind of stating that the same working 
group that is shipoing this document doesn't have enough of a clue to 
analyze the benefits (or lack thereof) of PSP?

And, because of that, you make the assessment yourself?

> Even though I have zero specific write/modification privilege on the 
> text in this document, and I'm not part of the authors email alias, this 
> would not be ideal for me to take the decision to forward this document 
> to the IESG. I've discussed this with our AD (Martin) and he agreed to 
> make the formal decision to send the document to the next level. Thank 
> you Martin.

Indeed, this could be seen as a possible conflict of interests.

Thanks,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Sander Steffann <[email-masked]>
Date: Fri, 28 Feb 2020 20:51:05 +0100

Wait, what?!  There is no "we needed to advance this document" in the IETF or any other consensus based forum... Based on the discussions on the mailing list (including questions on why PSP is so important that we can't take it out for now which have never been clearly answered by the authors) I can't see you can possibly declare consensus.

If there is going to be an appeal I will certainly put my signature on it.

I also find the behaviour of the WG chairs does not befit their responsibilities.

Appalling.
Sander

---

From: Fernando Gont <[email-masked]>
Date: Fri, 28 Feb 2020 17:13:07 -0300

On 28/2/20 16:51, Sander Steffann wrote:
[...]

Thank you.

FWIW, I have already started drafting the appeal, and going through the 
list archive to find both the technical and procedural objections to be 
raised.

I'll be contacting many of you during the next few days to get the text 
together.

> I also find the behaviour of the WG chairs does not befit their responsibilities.

I agree.

Thanks,

---

From: S Moonesamy <[email-masked]>
Date: Fri, 28 Feb 2020 14:02:38 -0800

Dear Mr Vigoureux,

I am contacting you as you are listed as the Responsible Area 
Director for the SPRING Working Group [1].  I would like to thank the 
Working Group for providing some information [2] about the status of 
the Working Group Last Call.

I was a bit surprised to see that one of the Working Group Chairs is 
listed as a contributor in 
draft-ietf-spring-srv6-network-programming-10.  It is quite unusual 
to have the contributor of a Working Group document handle the 
Working Group process for the document.  Would there be a potential 
conflict of interest?

The summary provides by the Working Group Chair states that the 
Responsible Area Director "has not accepted the related errata".  I 
took a quick look at erratum eid5933; it is listed as "Reported".  As 
the erratum has not been classified as per the relevant IESG 
Statement, describing it as "not accepted" is inaccurate.

Regards,
S. Moonesamy

1. https://datatracker.ietf.org/wg/spring/about/
2. https://mailarchive.ietf.org/arch/msg/spring/or8086G4iYfee5_Icw4PnhkPLBo/
3. https://www.rfc-editor.org/errata/eid5933

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 28 Feb 2020 23:36:55 +0100

Dear Mr Moonesamy,

Let me state that your accusations of Bruno's conflict of interest are
simply absurd.

You can count on one hand such chairs like Bruno who not only know very
well technology in the WG they are chairing, but also take a very neutral
position in accepting or progressing any work by the WG. I know Bruno for
over 20 years and never would even think for a second to send such nonsense
blast.

Last time I checked IETF does not prohibit chairs to be part of WG
documents.

His information about 6man AD not accepting the Errata: 5933 is correct.
Errata must be first accepted by an AD then processed further. Since it was
posted on 11th Dec 2019 it was still not accepted at first stage. You are
mixing AD acceptance / validation with IESG decision. Those are completely
different errata processing phases.

I understand when someone is not able to make any further technical
arguments, personal attacks start. Awesome !

Have a nice weekend,
RR.

On Fri, Feb 28, 2020 at 11:04 PM S Moonesamy <[email-masked]> wrote:

> https://mailarchive.ietf.org/arch/msg/spring/or8086G4iYfee5_Icw4PnhkPLBo/
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 29 Feb 2020 11:37:54 +1300

Bruno,

Thanks for this. Please view what follows with a non-proportional font.
Here's my understanding of the scenario we are talking about:

  A -------->B---------->C
  |                      ^
  |                      |
  \                     /
   X-------->Y-------->Z

The normal path is from A to B to C and the packet would be a plain
IPv6 packet with no routing header.

Now assume that node A detects a "link down" condition on the link to B.
Until routing has converged, A (with pre-existing knowledge of the topology)
sends packets to C with a routing header via X, Y and Z.

So what does the routing header look like when the packet leaves A?
Presumably, segments-left = 3, and the list of destinations is [C,Z,Y,X],
and the initial IPv6 destination is X.

When the packet leaves X, segments-left = 2, list = [C,Z,Y,X], and the
next IPv6 destination is Y.

When the packet leaves Y, segments-left = 1, list = [C,Z,Y,X], and the
next IPv6 destination is Z.

When the packet leaves Z, segments-left = 0, list = [C,Z,Y,X], and the
next IPv6 destination is C.

To me this seems to be what is described by RFC8200 and by the approved
draft-ietf-6man-segment-routing-header-26. Is this correct?

In what way is the PSP flavor different (Z being the penultimate hop)?

I have just realised what may be the misunderstanding here. The wording in
RFC8200 may be a bit loose, as Fernando has observed, but the logic of
draft-ietf-spring-srv6-network-programming-10 PSP also depends on looking
at the value of segments-left and only deleting the routing header
if segments-left == 0. The problem is that this test is applied *after*
the node (Z in my example) has already decremented the value of segments-left.
The text in RFC8200 clearly refers to the incoming value, which is 1
in node Z. The routing header is not exhausted until it reaches a node
whose address is the last one in the list, i.e. C in my example, and
the incoming segments-left == 0.

So, the PSP mechanism is depending on a reading of RFC8200 that ignores
the statement of intent in Appendix B, *and* on testing against the already
decremented value of segments-left, not the incoming value of segments-left.

Now, it may be that there will be IETF rough consensus to allow this but
I think the text needs to be much more explicit about these two points.

(BTW, I am not denying that PSP works, subject to the usual comments
about AH and PMTUD.)

Regards
   Brian Carpenter

On 29-Feb-20 06:19, [email-masked] wrote:
> Quoting Brian “simply need more explanation in elementary terms”.
> 
>  
> 
> -          Clarifying what “Penultimate” refers to. This is required as there are multiple reading such “penultimate IPv6/SRv6 transit node” (which we all agree is not allowed by RFC 8200, so let’s make things clear that the document is not talking or suggesting or allowing this) or “penultimate SR Segment Endpoint Node indicated in the IPv6 destination address of the received IPv6 header”.
> 
> -          Clarify what you mean by “Pop”. (as this terminology is heavily borrowed from MPLS and may not be crystal clear for everyone, especially since the MPLS RFC is not a normative reference (and it should not be))
> 
> -          Clarify that given the nodes A—B—C,  the PSP flavor is done by penultimate Segment Endpoint “B” at the request of the IPv6 source node “A” as an outsourced service from the ultimate SR End Point “C”. “A”, “B” and “C” been within the same control domain.
> 
>  
> 
> Agreed that this is not changing anything in the spec, and may be obvious to you, and hopefully clear for people having read the relevant document, however from the comments it seems clear that some additional context may help to clarify. Also it’s plausible that some persons may only read this specific PSP section and react on it.
> 
>  
> 
> Thank you,
> 
> --Bruno
> 
>  
> 
> *From:*ipv6 [mailto:[email-masked]] *On Behalf Of [email-masked]
> *Sent:* Thursday, December 5, 2019 6:15 PM
> *To:* 'SPRING WG List'
> *Cc:* [email-masked]; draft-ietf-spring-srv6-network-programming
> *Subject:* WGLC - draft-ietf-spring-srv6-network-programming
> 
>  
> 
> Hello SPRING,
> 
>  
>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sat, 29 Feb 2020 01:14:54 +0000

Robert,

I did not read any “accusation” or “attack” in SM’s note, nor anything specifically directed at Bruno, the person, his decision-making, or his character — just a set of question to the AD on potential based on roles and processes.

Thanks,

— Carlos.
PS: There are documents that codify some cases (like RFC 4858, IESG statement on shepherds, RFC 2418, etc.)

2020/02/28 午後5:36、Robert Raszuk <[email-masked]<mailto:[email-masked]>>のメール:

Dear Mr Moonesamy,

Let me state that your accusations of Bruno's conflict of interest are simply absurd.

You can count on one hand such chairs like Bruno who not only know very well technology in the WG they are chairing, but also take a very neutral position in accepting or progressing any work by the WG. I know Bruno for over 20 years and never would even think for a second to send such nonsense blast.

Last time I checked IETF does not prohibit chairs to be part of WG documents.

His information about 6man AD not accepting the Errata: 5933 is correct. Errata must be first accepted by an AD then processed further. Since it was posted on 11th Dec 2019 it was still not accepted at first stage. You are mixing AD acceptance / validation with IESG decision. Those are completely different errata processing phases.

I understand when someone is not able to make any further technical arguments, personal attacks start. Awesome !

Have a nice weekend,
RR.

On Fri, Feb 28, 2020 at 11:04 PM S Moonesamy <[email-masked]<mailto:[email-masked]>> wrote:
Dear Mr Vigoureux,

Regards,
S. Moonesamy

1. https://datatracker.ietf.org/wg/spring/about/
2. https://mailarchive.ietf..org/arch/msg/spring/or8086G4iYfee5_Icw4PnhkPLBo/<https://mailarchive.ietf.org/arch/msg/spring/or8086G4iYfee5_Icw4PnhkPLBo/>
3. https://www.rfc-editor.org/errata/eid5933

_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring

---

From: Jeff Tantsura <[email-masked]>
Date: Fri, 28 Feb 2020 17:48:25 -0800

I second Carlos. Besides, Bruno's integrity is well known!
It is a common practice however, when one of the chairs is a co-author of a document that is progressing in the working group chaired, for the second chair to manage the document in question.

Cheers,
Jeff
On Feb 28, 2020, 5:15 PM -0800, Carlos Pignataro (cpignata) <cpignata=[email-masked]>, wrote:
> > 2020/02/28 午後5:36、Robert Raszuk <[email-masked]>のメール:
> >
> > Dear Mr Moonesamy,
> >
> > > > 2. https://mailarchive.ietf..org/arch/msg/spring/or8086G4iYfee5_Icw4PnhkPLBo/

---

From: S Moonesamy <[email-masked]>
Date: Fri, 28 Feb 2020 20:28:17 -0800

Hi Carlos, Jeff,

Thanks for the comments.

Regards,
S. Moonesamy

---

From: Martin Vigoureux <[email-masked]>
Date: Sat, 29 Feb 2020 21:03:31 +0100

Dear Mr Moonesamy,

I am convinced there is no conflict of interest.
Since he has been WG Chair Bruno has demonstrated exemplary behaviour, 
on top of being a recognized expert in his field.

Regarding the errata, "not processed" would have been more accurate than 
"not accepted" but I am sure this is what Bruno meant.

Best regards,
Martin Vigoureux

Le 2020-02-28 à 23:02, S Moonesamy a écrit :
> Dear Mr Vigoureux,
> 
> I am contacting you as you are listed as the Responsible Area Director 
> for the SPRING Working Group [1].  I would like to thank the Working 
> Group for providing some information [2] about the status of the Working 
> Group Last Call.
> 
> draft-ietf-spring-srv6-network-programming-10.  It is quite unusual to 
> have the contributor of a Working Group document handle the Working 
> Group process for the document.  Would there be a potential conflict of 
> interest?
> 
> Responsible Area Director "has not accepted the related errata".  I took 
> a quick look at erratum eid5933; it is listed as "Reported".  As the 
> erratum has not been classified as per the relevant IESG Statement, 
> describing it as "not accepted" is inaccurate.
> 
> Regards,
> S. Moonesamy
>

---

From: "Voyer, Daniel" <[email-masked]>
Date: Sun, 1 Mar 2020 01:16:13 +0000

Hi,

Please note that Bruno has already clarified that “Rob was not available to take that role”. 
As “Bruno's integrity is well known”, this email should be considered as a moot point.

Thanks
Dan

On 2020-02-28, 5:04 PM, "spring on behalf of S Moonesamy" <[email-masked] on behalf of [email-masked]> wrote:

    Dear Mr Vigoureux,

    
    
    Regards,
    S. Moonesamy

    _______________________________________________
    spring mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/spring
    ------------------------------------------------------------------------------
    External Email: Please use caution when opening links and attachments / Courriel externe: Soyez prudent avec les liens et documents joints

---

From: Fernando Gont <[email-masked]>
Date: Sat, 29 Feb 2020 22:54:00 -0300

> I am convinced there is no conflict of interest.

"conflict of interest" 
(https://www.lexico.com/definition/conflict_of_interest)
noun

a situation in which the concerns or aims of two different parties are 
incompatible.

a situation in which a person is in a position to derive personal 
benefit from actions or decisions made in their official capacity.

There is, indeed, a conflict of interest when the same person that has 
to judge consensus on a document is an author/contributor of that document.

Note: flagging a "conflict of interest" is not an accusation of actually 
behaving dishotestly in the presence of such conflict of interest.

> "not accepted" but I am sure this is what Bruno meant.

The concerns of this document violating RFC8200 were dismissed by 
stating that the AD had not accepted the erratum I had submitted.

Clearly, if Bruno had meant "not processed", he couldn't have dismissed 
the erratum like that.

Thanks,

---

From: S Moonesamy <[email-masked]>
Date: Sat, 29 Feb 2020 23:26:45 -0800

Dear Mr Vigoureux,
>I am convinced there is no conflict of interest.

I would like to thank you for the timely response to my question.

Mr Decraene, who is listed as a SPRING Working Group Chair stated [1] 
the following: "Even though I have zero specific write/modification 
privilege on the text in this document, and I'm not part of the 
authors email alias, this would not be ideal for me to take the 
decision to forward this document to the IESG."  I assume that it 
would be fair to say that the Working Group Chair was straightforward 
in informing the SPRING Working Group that the situation is less than ideal.

The difference between "conflict of interest" and "potential conflict 
of interest" is sometimes lost, especially when there is an 
ill-disposed discussion.  Those discussions can be unpleasant when 
there is a perception of bias or other interests at stake.

One of the principles of natural justice is that one cannot be judge 
and party in a case.  In the matter under discussion, Mr Decraene is 
the Working Group Chair taking the decision(s) on 
draft-ietf-spring-srv6-network-programming and listed as a 
Contributor of  draft-ietf-spring-srv6-network-programming.  Based on 
that, I unfortunately have to disagree with your assessment on 
whether there would be a potential conflict of interest.

Regards,
S. Moonesamy

1. https://mailarchive.ietf.org/arch/msg/spring/or8086G4iYfee5_Icw4PnhkPLBo/