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

From: Gyan Mishra <[email-masked]>
Date: Sun, 1 Mar 2020 13:52:39 -0500

6MAN only

Brian

I believe your assessment is correct.  The verbiage is very confusing in
the draft.  Probably need to make a Visio diagram of this would be helpful.

Z is the PSP node -one hop before final destination C

Z receives SL=1

When the packet leaves Y, segments-left = 1, list = [C,Z,Y,X], and the
next IPv6 destination is Z. => Ref1 - Z has received SRH has SL=1

Z updates SRH and sends SL=0

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

So now on PSP node Z - will get the updated SL and process PSP set below:

1.   IF updated SL = 0 & PSP is TRUE
2.      pop the top SRH

On node C PSP processing:

   When the last SID is written in the
   DA, the End, End.X and End.T functions with the PSP flavour pop the
   first (top-most) SRH.  Subsequent stacked SRH's may be present but

   are not processed as part of the function.

This verbiage is even more confusing and I still don’t understand.  So
this PSP flavor knob can be used on any

end, end.X and end.T function.  I understand the end but not the use
on the end.X or end.T.  So this is a loophole

Spring is creating to be able to do the PSP removal

of the SRH on any P node and not just the 2nd to last

hop PSP node as long as the pseudocode conditions are satisfied with
the SL received and updated value.

https://tools.ietf.org/html/draft-filsfils-spring-srv6-network-programming-07#section-4.21

4.21.1 <https://tools.ietf.org/html/draft-filsfils-spring-srv6-network-programming-07#section-4.21.1>.
PSP: Penultimate Segment Pop of the SRH

   After the instruction 'update the IPv6 DA with SRH[SL]' is executed,
   the following instructions must be added:

 1.   IF updated SL = 0 & PSP is TRUE
 2.      pop the top SRH                                         ;; Ref1

Ref1: The received SRH had SL=1.  When the last SID is written in the
   DA, the End, End.X and End.T functions with the PSP flavour pop the
   first (top-most) SRH.  Subsequent stacked SRH's may be present but
   are not processed as part of the function.

As far as RFC 8200 since node Z being the PSP node, it is removing the SRH
so that would be in violation of the spec.

I think the reasons given for PSP still does not make sense to me and I
believe are not valid.  Using my SP technical expertise in MPLS and
applying to SR below.

The doh and AH reason given for PSP function does not make sense since the
encapsulated customer payload would have AH and doh and not the outer v6
header.

As far as legacy hardware not supporting SRH processing does not
technically make sense at all. Since every PE in an SR domain both SRv6 or
SR-MPLS identical to MPLS would be both a SR source node and final
destination node of an LSP.  I am using the MPLS term LSP with SR as the
concept of FEC destination which now is a prefix SID still exists that all
traffic to egress final destination  PE is forwarded to.  Since LSPs to FEC
destination are uni directional and that would be the case as well for SR
paths - the idea that the final destination PE would lack hardware
capability for SRH processing does not make sense as the source and final
destination node are one and the same.

Gyan
---------- Forwarded message ---------
From: Brian E Carpenter <[email-masked]>
Date: Fri, Feb 28, 2020 at 5:52 PM
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming
To: <[email-masked]>, draft-ietf-spring-srv6-network-programming
<[email-masked]>, Pablo Camarillo
(pcamaril) <[email-masked]>
CC: SPRING WG List <[email-masked]>

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:
> 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
> [1]
https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-10#section-4.16.1
>
>
>
>
>
> *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,
>
>
>
> 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.
_________________________________________________________________________________________________________________________
>
> 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.

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

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

Email: [email-masked]

---

From: <[email-masked]>
Date: Mon, 2 Mar 2020 13:32:47 +0000

Sander,

> From: Sander Steffann [mailto:[email-masked]] 
> Sent: Friday, February 28, 2020 8:51 PM
> To: DECRAENE Bruno TGI/OLN
> Cc: SPRING WG List; draft-ietf-spring-srv6-network-programming; 6man WG
> > ===============
> > 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.
> 
> Wait, what?!  There is no "we needed to advance this document" in the IETF or any other consensus based forum... 

By advance this document, I meant start the WG LC. Which is about collecting comments on the document.

The situation is that there was and is a single chair. I'm personally ok to not proceed with any adoption call or last call while there is no other co-chair. Note that my AD never asked for this.

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

This is you right to appeal to the IESG.
Note that appealing to the IESG is exactly what I'm proposing to do with regards to the reading of RFC 8200.

--Bruno
>
> I also find the behaviour of the WG chairs does not befit their responsibilities.
> 
> Appalling.
> Sander
>

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.

---

From: Martin Vigoureux <[email-masked]>
Date: Mon, 2 Mar 2020 19:53:20 +0100

WG,

as I had indicated in a previous message I am the one evaluating 
consensus for this WG LC.

I have carefully read the discussions on the list. I acknowledge that 
disagreements were expressed regarding what a particular piece of text 
of RFC 8200 says, and on which this document builds to propose an 
optional capability. Since RFC 8200 is not a product of the SPRING WG, I 
have paid specific attention to the messages ([1], [2], and [3]) sent by 
the responsible AD of 6MAN and of RFC8200.

My overall conclusion is that there is support and rough consensus to 
move this document to the next stage.

Bruno will handle the immediate next steps.

Martin

[1] 
https://mailarchive.ietf.org/arch/msg/spring/67ZG76XRezPXilsP3x339rGpcso/
[2] 
https://mailarchive.ietf.org/arch/msg/spring/plidxjZFBnd4_mEzGsLC76FZmQ0/
[3] 
https://mailarchive.ietf.org/arch/msg/spring/uBYpxPyyBY6bb86Y2iCh3jSIKBc/

Le 2019-12-05 à 18:15, [email-masked] a écrit :
> duplicating emails on the 6MAN mailing list for the comments which are 
> only spring specifics.
>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 3 Mar 2020 08:37:38 +1300

Martin,

> move this document to the next stage.

I am amazed by this statement, coming before we have had time to digest the changes
in draft-ietf-spring-srv6-network-programming-11. I think it's highly premature.

   Brian

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Andrew Alston <[email-masked]>
Date: Mon, 2 Mar 2020 19:56:10 +0000

I am completely stunned by this.

The question regarding RFC8200 is still unaddressed.
The promises to deliver an assessment of IP Space burn as per what is on video from the montreal meeting – was not delivered on or addressed
The issues around the potentially problems in relation to rfc7112 – have never been addressed or commented on.

And – there are other issues which will be raised within the appeal(s) that are now coming – that’s just what comes to mind.

Further to this – how consensus can be declared on a document that was changed 2 hours before the declaration – with the changes directly relating to the issue at question – before anyone had had a chance to digest or comment on those changes?  How can there be consensus on something that half the world has not had a chance to read because time zones alone declare that they are asleep!

Absolutely amazing

Andrew

From: spring <[email-masked]> on behalf of Martin Vigoureux <[email-masked]>
Date: Monday, 2 March 2020 at 21:53
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, draft-ietf-spring-srv6-network-programming <[email-masked]>
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

WG,

Martin

[1]
https://mailarchive.ietf.org/arch/msg/spring/67ZG76XRezPXilsP3x339rGpcso/<https://mailarchive.ietf.org/arch/msg/spring/67ZG76XRezPXilsP3x339rGpcso>
[2]
https://mailarchive.ietf.org/arch/msg/spring/plidxjZFBnd4_mEzGsLC76FZmQ0/<https://mailarchive.ietf.org/arch/msg/spring/plidxjZFBnd4_mEzGsLC76FZmQ0>
[3]
https://mailarchive.ietf.org/arch/msg/spring/uBYpxPyyBY6bb86Y2iCh3jSIKBc/<https://mailarchive.ietf.org/arch/msg/spring/uBYpxPyyBY6bb86Y2iCh3jSIKBc>

Le 2019-12-05 à 18:15, [email-masked] a écrit :
> https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05<https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05>
>
> https://www.ietf.org/mailman/listinfo/spring<https://www.ietf.org/mailman/listinfo/spring>
>

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

---

From: Sander Steffann <[email-masked]>
Date: Mon, 2 Mar 2020 21:02:48 +0100

Hi Bruno,

> By advance this document, I meant start the WG LC. Which is about collecting comments on the document.

I think you are confused. This document has been in WG LC since December… I think many of us read "advance this document" as "declare consensus on WG LC".

> The situation is that there was and is a single chair. I'm personally ok to not proceed with any adoption call or last call while there is no other co-chair. Note that my AD never asked for this.

I'm glad you confirm that no consensus has been declared. That seems the appropriate state at the moment.

> This is you right to appeal to the IESG.

Now that we know that consensus hasn't been declared and the document is still in LC I think appealing would be premature :)

> Note that appealing to the IESG is exactly what I'm proposing to do with regards to the reading of RFC 8200.

Getting that feedback would indeed be helpful.

Cheers!
Sander

---

From: Sander Steffann <[email-masked]>
Date: Mon, 2 Mar 2020 21:12:24 +0100

Hi,

> My overall conclusion is that there is support and rough consensus to move this document to the next stage.

Declare consensus immediately after a new version is published and people haven't even had the change to read it?

NO, just NO

Sander

---

From: Fernando Gont <[email-masked]>
Date: Mon, 2 Mar 2020 17:15:33 -0300

Martin,

> consensus for this WG LC.

This is more and more confusing, seriously.

Bruno did the WGLC, and also communicated the outcome of the WGLC in 
first person, and now you state that it's you evaluating WGLC??

For instance.. what's this note in: 
https://mailarchive.ietf.org/arch/msg/spring/or8086G4iYfee5_Icw4PnhkPLBo/
"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."

..posted by Bruno?

> move this document to the next stage.

Then you have explicitly dismissed lots of comments made on this 
document that remained unaddressed. I assume you also implicitly support 
Bruno's claim that this wg is enable to evaluate the need for PSP.

Seriously, and with all due respect, I've never seen a wg or area 
proceed like this.

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

---

From: Fernando Gont <[email-masked]>
Date: Mon, 2 Mar 2020 17:22:55 -0300

Martin,

As an Area Director, what are your thoughts regarding Bruno's claim that 
this working group (Spring) doesn't have the necessary skills for 
evaluating the need of a functionality (PSP) that this wg is including 
in draft-ietf-spring-srv6-network-programming?

Specifically, Bruno has noted (in 
https://mailarchive.ietf.org/arch/msg/spring/or8086G4iYfee5_Icw4PnhkPLBo/):

---- cut here ----
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).
---- cut here ----

Doesn't this sound a bit like a group is shipping something that it 
cannot really understand?

Thanks,
Fernando

On 2/3/20 15:53, Martin Vigoureux wrote:
>> 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] 
>> a l'expediteur et le detruire ainsi que les pieces jointes. Les 
>> messages electroniques etant susceptibles d'alteration,
>> This message and its attachments may contain confidential or 
>> privileged information that may be protected by law;
> .

---

From: Mark Smith <[email-masked]>
Date: Tue, 3 Mar 2020 08:39:44 +1100

This -11 draft was posted at 3:53 am Melbourne, Australia time, and this
declaration of consensus was at 5:35 am Melbourne, Australia time.

Sometimes I'm awake at those hours, but not last night. I did not have an
opportunity to review the changes.

Regards,
Mark.

---

From: Mark Smith <[email-masked]>
Date: Tue, 3 Mar 2020 08:47:45 +1100

On Tue, 3 Mar 2020 at 08:39, Mark Smith <[email-masked]> wrote:
>
> This -11 draft was posted at 3:53 am Melbourne, Australia time, and this declaration of consensus was at 5:35 am Melbourne, Australia time.
>
> Sometimes I'm awake at those hours, but not last night. I did not have an opportunity to review the changes.
>

Reviewing what was changed, my comment section 3.1, "SID Format", and
offer to provide some text as been completely ignored.

"[spring] draft-ietf-spring-srv6-network-programming-10 - "3.1. SID
Format" should be more prescriptive"

https://mailarchive.ietf.org/arch/msg/spring/2ApHpreqPTS689pAEyhiZEdTf7k/

Regards,
Mark.

>
> Regards,
> Mark.
>
>
>
>
> On Tue, 3 Mar 2020, 05:53 Martin Vigoureux, <[email-masked]> wrote:
>>
>> WG,
>>

---

From: S Moonesamy <[email-masked]>
Date: Mon, 02 Mar 2020 16:09:58 -0800

Hi Fernando,

[Discussion moved to 6man)

At 10:01 AM 02-03-2020, Fernando Gont wrote:
>That's a comment on a future decision,  not a decision that can be acted upon.
>
>Simple: what would have happened if Suresh had changed his mind, and 
>"verified" the erratum? -- You'd have a spring document that you 
>claimed to have wg consensus based on an incorrect assumption.
>
>i.e., the consensus outcome was sent based on an *assumption*, not 
>on a decision.

I was reminded of the following on reading the SPRING discussions: 
https://mailarchive.ietf.org/arch/msg/spfbis/VbT1OuHTouS9GrVR934EwOnzp64/

The points which you raised (please see quoted text) can be go both 
ways, i.e. favorably or unfavorably if it has to be considered 
formally.  I would rate the erratum as "minor" within the context of 
the dispute.  The rationale for that is that:

   (a) The decisions are distinct from each other.  A decision in 6MAN does,
       from a procedural perspective, cannot be used in a SPRING process
       discussion.

   (b) An erratum in an "approved" state does not reflect IETF 
Consensus.  There
       is a message [1] from Mr Klensin about that.

Please see the message at 
https://mailarchive.ietf.org/arch/msg/ipv6/_gG2foiugk5B7w3TpnPvBbjHDzs/ 
I would argue, from a process perspective, that the intent of the 
text under dispute should be read in that light.

Regards,
S. Moonesamy

1. https://mailarchive.ietf.org/arch/msg/ietf/r1WnAemu12WcdT7VoFpPUI3j6pk/

---

From: Fernando Gont <[email-masked]>
Date: Mon, 2 Mar 2020 21:49:18 -0300

On 2/3/20 21:09, S Moonesamy wrote:
>> i.e., the consensus outcome was sent based on an *assumption*, not on 
>> a decision.
> 

This email misses the number of employees from the same company -- 
similar to the "+1" effect we have seen in spring recently.

> formally.  I would rate the erratum as "minor" within the context of the 
> dispute.  

At the time of rfc2460bis, folks were claiming that en-route 
eh-insertion/removal was not forbiden. Then the discussion was about 
whether to clarify it, or not.

Once the wg shipped the document, and during IETF LC, there was 
consensus that the clarification be added.

-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: <[email-masked]>
Date: Tue, 3 Mar 2020 15:49:17 +0000

Fernando 

> From: spring [mailto:[email-masked]] On Behalf Of Fernando Gont
> Sent: Monday, March 2, 2020 9:23 PM
> To: Martin Vigoureux; [email-masked]
> Cc: [email-masked]; [email-masked]'; draft-ietf-spring-srv6-network-programming

There have been replied and statement from the WG. E.g. From Dan (network operator) & Jingrong (vendor).
https://mailarchive.ietf.org/arch/msg/spring/ErcErN39RIlzkL5SKNVAeEWpnAI/

My comment is that a statement such as "(1) reduce the load of final destination.", while true in general, is difficult to evaluate, e.g. in term of packet processing gain, or NPU processing resource gain.
One can say "not on my hardware", but nobody can say "not in your hardware".

And I think that this is along Joel reply (although I would not want to speak for Joel)
"Do you have any comments on what appears to be the significant increase 
in complexity on the device performing PSP?  The question I am trying to 
get at is about the tradeoff, which needs one to evaluate both sides."
https://mailarchive.ietf.org/arch/msg/spring/CMSX7ijacRdG8qHlla61ylJNggo/

So in the end, what we have is the statement "(1) reduce the load of final destination.".

Thanks,
--Bruno

---

From: <[email-masked]>
Date: Tue, 3 Mar 2020 16:07:04 +0000

Sander, 
 
> -----Original Message-----
> Sent: Monday, March 2, 2020 9:03 PM

Re-reading my sentence, I agree that it may be misinterpreted. Let me try to rephrase:
In December, I have started the WGLC because this has been asked by the authors of this WG document. And because this is usually a good way to trigger a review of the whole document by many persons, and hence improve the document.
(And I do think that the document has improved as a result of starting the WGLC)

> Getting that feedback would indeed be helpful.

Good.
How do you propose that we get an evaluation and formal answer from the IESG on this point?
My proposal is to ask while asking the IESG review on draft-ietf-spring-srv6-network-programming.

--Bruno

---

From: Sander Steffann <[email-masked]>
Date: Tue, 3 Mar 2020 19:41:17 +0100

Hi Bruno,

> My proposal is to ask while asking the IESG review on draft-ietf-spring-srv6-network-programming.

I think it's important that the answer can be used to improve the draft, so whatever works for that. That should be done before we can discuss consensus. 

Cheers,
Sander

---

From: Fernando Gont <[email-masked]>
Date: Tue, 3 Mar 2020 19:58:52 -0300

> https://mailarchive.ietf.org/arch/msg/spring/ErcErN39RIlzkL5SKNVAeEWpnAI/

The motivation should be in the draft, not in the mail archive. And you 
declared consensus on a document that does not include such motivation.

> https://mailarchive.ietf.org/arch/msg/spring/CMSX7ijacRdG8qHlla61ylJNggo/

You have to justify the included behavior, not the other way around:

Thanks,

---

From: Warren Kumari <[email-masked]>
Date: Tue, 3 Mar 2020 19:28:56 -0500

> My proposal is to ask while asking the IESG review on draft-ietf-spring-srv6-network-programming.

<no-hats>
Ok, I'm confused -- the process goes that (for WG documents) the WG
chairs evaluate and declare consensus, and then send the document to
the responsible AD. The responsible AD reviews the document and the
process, and if they deem it appropriate, sends to to the IESG for
evaluation.
"ask while asking the IESG review on
draft-ietf-spring-srv6-network-programming" implies that the chairs
would have declared consensus and believe it is ready to publish, and
that the responsible AD agrees it is ready to progress - is this what
you are proposing / saying?

Or were you meaning that you would just ask the IESG to review? Or
that you would state that you cannot declare consensus, and are
gridlocked, and ask the IESG to help? Or something else?

I'm genuinely confused what you mean by the above, and am just trying
to figure out what you are proposing.

W

</no-hats>

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: S Moonesamy <[email-masked]>
Date: Tue, 03 Mar 2020 22:10:18 -0800

Hi Fernando,
>similar to the "+1" effect we have seen in spring recently.

I'll skip the above unless you would like me to comment about it.

>consensus that the clarification be added.

RFC 8200 is an Internet Standard.  If there was a clarification on 
in-flight header insertion/removal, I would say that the 
clarification is not clear.  On reading the recently discussions, it 
looks like there is a technical defect in that Internet Standard.

Regards,
S. Moonesamy

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Wed, 4 Mar 2020 10:53:53 +0000

Hi Mark,

Thank you for your comment.

As you have pointed out, currently in Section 3.1 we have the following text:

A locator may be represented as B:N where B is the SRv6 SID block

(IPv6 subnet allocated for SRv6 SIDs by the operator) and N is the

      identifier of the parent node instantiating the SID.

This is exactly like any IPv6 address allocation to a router as part of a subnet of a domain.

Thanks,

Pablo.

-----Original Message-----

From: Mark Smith <[email-masked]>

Date: Monday, 2 March 2020 at 22:48

To: Martin Vigoureux <[email-masked]>

Cc: SPRING WG <[email-masked]>, 6MAN <[email-masked]>, draft-ietf-spring-srv6-network-programming <[email-masked]>

Resent from: <[email-masked]>

Resent to: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>

Resent date: Monday, 2 March 2020 at 22:48

    On Tue, 3 Mar 2020 at 08:39, Mark Smith <[email-masked]> wrote:

    Regards,

    Mark.

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Wed, 4 Mar 2020 12:17:06 +0000

Andrew,

Inline. PC1.

Regards,
Pablo.

From: Andrew Alston <[email-masked]>
Date: Monday, 2 March 2020 at 20:56
To: Martin Vigoureux <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, draft-ietf-spring-srv6-network-programming <[email-masked]>
Subject: Re: [spring] 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: Monday, 2 March 2020 at 20:56

The question regarding RFC8200 is still unaddressed.
PC1: PSP complies with RFC8200.
https://mailarchive.ietf.org/arch/msg/spring/6ZNyPMuZaaP9amVRXQdX9uRMbVk/
https://mailarchive.ietf.org/arch/msg/spring/pGS5O53VTDSt2tpc7mm3FVVd0Xk/
https://mailarchive.ietf.org/arch/msg/spring/i0faTfqB-NduzI2VyMyQ6R60dQw/
https://mailarchive.ietf.org/arch/msg/spring/kV6By4pnvbURdU1O7khwPbk_saM/
https://mailarchive.ietf.org/arch/msg/spring/plidxjZFBnd4_mEzGsLC76FZmQ0/
https://mailarchive.ietf.org/arch/msg/spring/67ZG76XRezPXilsP3x339rGpcso/
https://mailarchive.ietf.org/arch/msg/spring/C20J-h835TJYHH2Q4KCHaS_lmek/
https://mailarchive.ietf.org/arch/msg/spring/65GgH7fY3_TDEbE7dNXwSz64l58/

The promises to deliver an assessment of IP Space burn as per what is on video from the montreal meeting – was not delivered on or addressed
PC1: Authors do not recall such a promise. Can you please point me at either a) an email URL; b) SPRING WG meeting minutes; c) SPRING WG meeting recording (with precise minute and seconds) where such promise happened?

PC1: Also, I do not understand the issue or what “IP Space burn” you talk about.
Please see this: https://mailarchive.ietf.org/arch/msg/spring/34s0MNMsXe7lTYJr1jw-xBpoRp0/
Was this your question?

The issues around the potentially problems in relation to rfc7112 – have never been addressed or commented on.
PC1: RFC7112 considerations apply to all extension headers including SRH. I do not understand the relevance of it with Network Programming draft.

Absolutely amazing

Andrew

---

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Wed, 4 Mar 2020 13:03:19 +0000

Hi WG,
What I can see is that the version 11 diffs are just borrowed from the initial text I proposed on the mailing list days before.
https://mailarchive.ietf.org/arch/msg/spring/nZwDUSpsVxTN_3UO0VLE9_2Eo5s/

These changes were editorial in nature and did not change anything of the behavior.

Even the proposed text by myself were all summarized from the long discussion that already there months before.

Going back further, my knowledge about the benefits of the PSP also came from the long discussion, as I said admittedly "benefits that people have already said seems notable to me".
https://mailarchive.ietf.org/arch/msg/spring/wTLJQkzC6xwSNPbhB84VH0mLXx0/
It was almost 3 months before!

I don’t see how the editorial changes, based on the long discussion 3 months before, can affect at all the decision on whether to move forward the I-D.

BTW: I see rev-12 was just posted, and I am happy to see more of my proposed text are taken, though these text are just words in the list for 3 months. Maybe 1 minute is enough to get through the diff link.
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-srv6-network-programming-12

Thanks,
Jingrong

From: spring [mailto:[email-masked]] On Behalf Of Mark Smith
Sent: Tuesday, March 3, 2020 5:40 AM
To: Martin Vigoureux <[email-masked]>
Cc: SPRING WG <[email-masked]>; 6MAN <[email-masked]>; draft-ietf-spring-srv6-network-programming <[email-masked]>
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

Regards,
Mark.

On Tue, 3 Mar 2020, 05:53 Martin Vigoureux, <[email-masked]<mailto:[email-masked]>> wrote:
WG,

Martin

[1]

Le 2019-12-05 à 18:15, [email-masked]<mailto:[email-masked]> a écrit :
> [email-masked]<mailto:[email-masked]>

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

---

From: Fernando Gont <[email-masked]>
Date: Wed, 4 Mar 2020 09:36:17 -0300

On 3/3/20 13:07, [email-masked] wrote:
[....]
> My proposal is to ask while asking the IESG review on draft-ietf-spring-srv6-network-programming.

THat seems to late in the process.

May I ask what's the status of this I-D?  -

On one hand, both you and Martin declared consensus to move it forward. 
On another hand, the authors keep making changes to address comments 
(good) so what the wg will ship will be different from what the document 
on which you claimed consensus. Besides, the datatrackers lists the 
document as "in WGLC".

Thanks,

---

From: Andrew Alston <[email-masked]>
Date: Fri, 6 Mar 2020 05:36:16 +0000

From: Pablo Camarillo (pcamaril) <[email-masked]>
Sent: Wednesday, 4 March 2020 15:17
To: Andrew Alston <[email-masked]>; Martin Vigoureux <[email-masked]>; [email-masked]
Cc: [email-masked]; draft-ietf-spring-srv6-network-programming <[email-masked]>
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

Andrew,

Inline. PC1.

Regards,
Pablo.

From: Andrew Alston <[email-masked]<mailto:[email-masked]>>
Date: Monday, 2 March 2020 at 20:56
To: Martin Vigoureux <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, draft-ietf-spring-srv6-network-programming <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] 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: Monday, 2 March 2020 at 20:56

The question regarding RFC8200 is still unaddressed.
PC1: PSP complies with RFC8200.
https://mailarchive.ietf.org/arch/msg/spring/6ZNyPMuZaaP9amVRXQdX9uRMbVk/<https://mailarchive.ietf.org/arch/msg/spring/6ZNyPMuZaaP9amVRXQdX9uRMbVk>
https://mailarchive.ietf.org/arch/msg/spring/pGS5O53VTDSt2tpc7mm3FVVd0Xk/<https://mailarchive.ietf.org/arch/msg/spring/pGS5O53VTDSt2tpc7mm3FVVd0Xk>
https://mailarchive.ietf.org/arch/msg/spring/i0faTfqB-NduzI2VyMyQ6R60dQw/<https://mailarchive.ietf.org/arch/msg/spring/i0faTfqB-NduzI2VyMyQ6R60dQw>
https://mailarchive.ietf.org/arch/msg/spring/kV6By4pnvbURdU1O7khwPbk_saM/<https://mailarchive.ietf.org/arch/msg/spring/kV6By4pnvbURdU1O7khwPbk_saM>
https://mailarchive.ietf.org/arch/msg/spring/plidxjZFBnd4_mEzGsLC76FZmQ0/<https://mailarchive.ietf.org/arch/msg/spring/plidxjZFBnd4_mEzGsLC76FZmQ0>
https://mailarchive.ietf.org/arch/msg/spring/67ZG76XRezPXilsP3x339rGpcso/<https://mailarchive.ietf.org/arch/msg/spring/67ZG76XRezPXilsP3x339rGpcso>
https://mailarchive.ietf.org/arch/msg/spring/C20J-h835TJYHH2Q4KCHaS_lmek/<https://mailarchive.ietf.org/arch/msg/spring/C20J-h835TJYHH2Q4KCHaS_lmek>
https://mailarchive.ietf.org/arch/msg/spring/65GgH7fY3_TDEbE7dNXwSz64l58/<https://mailarchive.ietf.org/arch/msg/spring/65GgH7fY3_TDEbE7dNXwSz64l58>

This is highly – highly disputed still – by multiple parties – and repeatedly claiming something that is wrong does not make it somehow right.   In fact to claim that it doesn’t flies in the face of the last call write up which says that this needs to be adjudicated by the IESG.

PC1: Also, I do not understand the issue or what “IP Space burn” you talk about.
Please see this: https://mailarchive.ietf.org/arch/msg/spring/34s0MNMsXe7lTYJr1jw-xBpoRp0/<https://mailarchive.ietf.org/arch/msg/spring/34s0MNMsXe7lTYJr1jw-xBpoRp0>
Was this your question?

Please see around minute 22 for the next couple of minutes in https://www.youtube.com/watch?v=WuoJWecyATQ which specifically calls for a credible discussion around IP space usage and agreement to have such a credible discussion, which has not occurred.

The concern here is around the SID size and deep SID stacks in the face of 128bit SID’s.

Andrew

---

From: Mark Smith <[email-masked]>
Date: Fri, 6 Mar 2020 17:31:47 +1100

On Thu, 12 Dec 2019 at 05:37, <[email-masked]> wrote:
> Fernando,
<snip>
>
> - Read the mailing list and you will see that everyone do not share your opinion. So at least one person is wrong. I think that it would help if everyone, including you, could consider that they/you _may_ be wrong, at least to better understand the comments been made by others.  And possibly the text from RFC 8200 is not clear, but this is what we have. And this is the text to use to support the claim that this text is violated.

The final interpretation and intent of text in RFC8200 should be up to
6man, not SPRING, when there is ambiguity and dispute, as 6man is the
ultimate design authority for IPv6.

RFC5704, "Uncoordinated Protocol Development Considered Harmful":

" In particular, the
   IAB considers it an essential principle of the protocol development
   process that only one SDO maintains design authority for a given
   protocol, with that SDO having ultimate authority over the allocation
   of protocol parameter code-points and over defining the intended
   semantics, interpretation, and actions associated with those code-
   points."

IETF WGs would qualify as standards development organisations.

Those of us in 6man during the clarifications in this area of RFC8200
know the intent. It was specifically about modification of the EH
chain, and was in response to the
'draft-voyer-6man-extension-header-insertion' Internet Draft.

> - Why have _you_ filled an errata against RFC 8200, in order to change the technical content of this section, if you don't agree that one may red " Destination Address field of the IPv6 header" as the IPv6 address present in the Destination Address field of the IPv6 header been received by the End node (or even sent by the source node)
> https://www.rfc-editor.org/errata/eid5933
>
> > > At minimum, I think that we can agree that there is another reading, as expressed by other WG participants, and hence I disagree with "of course".
> >
> > No, I argue that there is not.IN fact, I argue that folks have been
> > following that strategy for way too long, and that's quite frustrating.
> >
> >
> >
> > > Personally, I understand "Destination Address" as "Destination Address field of the IPv6 header." as indicated explicitly in the text quoted.
> >
> > The quoted text is from RFC8200. In the context of RFC8200 the
> > Destination Address can only contain the ultimate destination of the
> > packet. Where's the ambiguity?
> >
> > And let me ask you, as chair, another question, that will lead you to
> > the same place: is IPv6 and end to end protocol?
>
> That's not a question for a spring chair to answer.
> I'm reading the sentence in RFC8200. If we can't agree on the meaning of this explicit sentence, I don't think that discussing philosophical r religious question is going to help.
>
> > The fact that I may claim that RFC8200 contains a receipe for BBQ does
> > not actually mean that that's the case.
>
> You do realize that your above sentence also applies to yourself? So how is this helping to progress?
> Can we please focus on the RFC8200 sentence?  I'm really trying to understand your point.
> Let's stick to the texts of documents.
>
>
> >
> > > I'm fine with having this clarified with 6MAND chairs and AD. That been said, the Internet AD would have an opportunity to DISCUSS this.
> >
> > For the record, I think this is a major issue that should be cleared
> > before it can be claimed that there is consensus to request publication
> > of this document.
>
> OK, this is recorded.
> >
> >
> > >
> > >> does not specify any routing header type, and hence the meaning is
> > >> unambiguous (there's no destination other than the final destination of
> > >> the packet).
> > >>
> > >> This is of course in line with IPv6 being and end-to-end protocol, and
> > >> crucial for other related mechanisms to work as expected (such as IPsec
> > >> AH). Please also check: draft-smith-6man-in-flight-eh-insertion-harmful.
> > >>
> > >> So, in order to proceed with the document, there are multiple options
> > >> forward:
> > >>
> > >> 1) Just remove the corresponding text/behavior
> > >
> > > That is indeed one option. But as of today, this is not my assumption.
> > >
> > >> 2) Implement a similar mechanism in an RFC8200-compliant manner (e.g.,
> > >> re-encap)
> > >
> > > SRH insert is out of scope of this specification. So yes, IPv6 encaps is used.
> > > We are talking SRH removal. I'm assuming that you are referring to PSP. My understanding is that this function (PSP) is to distribute the (forwarding plane) load between the PSP and the USP. In a way similar to MPLS PHP. But in all cases, this is not about SRH insertion.
> >
> > It's about SRH removal, which is also forbiden by RFC8200.
> >
> >
> >
> >
> > >> 3) Do the necessary standards work to update RFC8200, such that it
> > >> allows this sort of behavior, and only ship the network-programming
> > >> draft for publication when at least 6man has consensus to proceed on
> > >> that path.
> > >
> > > Not the preferred path as of today.
> >
> > Yes, it should be evident that it seems the preferred path has been
> > (starting with EH insertion at the time) to circumvent existing
> > specifications.
> >
> >
> >
> > >
> > >> P.S.: I will go through the document once again... but the same
> > >> reasoning should be applied to any EH-insertion/removal at a place other
> > >> than the source of the packet or its final destination.
> > >
> > > It looks to me that SRH insertion and SRH removal are to be treated differently.
> >
> > I don't see how or why.
>
> SRH insertion is done by a node, on the path, which is not the destination of the IPv6 addresses.
> SRH removal is done by a node which is receiving the packet because it's IPv6 address is in the destination of the IPv6 packet.
>
> > Both violate the same requirement in RFC8200.
>
> We are not having a conversation, so let's not repeats the same point again and again.
>
> Your opinion has been noted. So does opinions on this same point expressed by other wg participants.
>
> >
> >
> >
> > Thanks,
> > --
> > Fernando Gont
> > SI6 Networks

---

From: [email-masked]
Date: Fri, 6 Mar 2020 14:24:11 +0100

[spring cross posting deleted]

> 'draft-voyer-6man-extension-header-insertion' Internet Draft.

No, it is the IETF that is the SDO and has that authority through IETF consensus.
Not the working group.

Let me summarize my take on this from a 6man perspective:

1) PSP violates RFC8200.
I also object to any statement in SR PGM that it is in "compliance with 8200". It specifies it's own unique EH handling.
As I state below that's perfectly fine.

2) A premise for the work on tightening extension header processing rules leading up to 8200, was that new specifications can specify different behaviour than what's defined in 8200.
That is what the SR PGM document does. Any specification that changes EH processing must specify how that processing is done, and must be technically sound, in that it is shown not to break anything (interoperability, PMTUD, end to end security etc).
The SR PGM document has been terse in it's description and how it deals with identified technical issues. But it is also clear, that it is specified to only work within a limited domain, where the source, destination and in-path nodes are all within the same domain of control.
I see no outstanding technical issues with that mechanism.

3) It is also clear that what is specified in SR PGM does not work across administrative domain or on the general Internet.
For that reason I would object to any modification to 8200. Be it erratum, updated by pointer or bis document.

Is is possible to come to some agreement and consensus on the above points?

Ole

---

From: James Guichard <[email-masked]>
Date: Fri, 6 Mar 2020 14:31:53 +0000

Hi Mark,

With all due respect, from what I have read, I do not see how SPRING, or the authors of the network programming draft are interpreting the "intent" of the text in RFC8200. The text as written is very clear; there is no interpretation needed other than reading the plain English which clearly says the node identified in the Destination Address field of the IPv6 header may process, insert, or delete Extension headers (other than Hop-by-Hop Options header). It seems to me to set a very bad precedence if we now expect non-authors of an original Internet standard to have to interpret the intent of the original authors rather than simply read the text as published, especially in the case of an Internet standard.

Respectfully,

Jim
-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Mark Smith
Sent: Friday, March 06, 2020 1:32 AM
To: bruno.decraene <[email-masked]>
Cc: Fernando Gont <[email-masked]>; SPRING WG List <[email-masked]>; [email-masked]; draft-ietf-spring-srv6-network-programming <[email-masked]>
Subject: Who is the design ultimate authority over IPv6? (Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming)

<snip>
> - Read the mailing list and you will see that everyone do not share your opinion. So at least one person is wrong. I think that it would help if everyone, including you, could consider that they/yo…

The final interpretation and intent of text in RFC8200 should be up to 6man, not SPRING, when there is ambiguity and dispute, as 6man is the ultimate design authority for IPv6.

" In particular, the

Those of us in 6man during the clarifications in this area of RFC8200 know the intent. It was specifically about modification of the EH chain, and was in response to the 'draft-voyer-6man-extension-header-insertion' Internet Draft.

> - Why have _you_ filled an errata against RFC 8200, in order to change 
> the technical content of this section, if you don't agree that one may 
> red " Destination Address field of the IPv6 header" as the IPv6 
> address present in the Destination Address field of the IPv6 header 
> been received by the End node (or even sent by the source node)
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> rfc-editor.org%2Ferrata%2Feid5933&amp;data=02%7C01%7Cjames.n.guichard%
> 40futurewei.com%7C3a9e583a99324ab04a0708d7c19825be%7C0fee8ff2a3b240189
> c753a1d5591fedc%7C1%7C0%7C637190731541021508&amp;sdata=bybICm4YFIPalNf
> qYea%2FEGXVl5sYj6cRSd0VXZsnpww%3D&amp;reserved=0
>
> > And let me ask you, as chair, another question, that will lead you 
> > to the same place: is IPv6 and end to end protocol?
>
> > The fact that I may claim that RFC8200 contains a receipe for BBQ 
> > does not actually mean that that's the case.
>
> > before it can be claimed that there is consensus to request 
> > publication of this document.
>
> OK, this is recorded.
> >
> >
> > >
> > >> does not specify any routing header type, and hence the meaning 
> > >> is unambiguous (there's no destination other than the final 
> > >> destination of the packet).
> > >>
> > >> This is of course in line with IPv6 being and end-to-end 
> > >> protocol, and crucial for other related mechanisms to work as 
> > >> expected (such as IPsec AH). Please also check: draft-smith-6man-in-flight-eh-insertion-harmful.
> > >>
> > >> 3) Do the necessary standards work to update RFC8200, such that 
> > >> it allows this sort of behavior, and only ship the 
> > >> network-programming draft for publication when at least 6man has 
> > >> consensus to proceed on that path.
> > >
> > >> reasoning should be applied to any EH-insertion/removal at a 
> > >> place other than the source of the packet or its final destination.
> > >
> ______________________________________________________________________
> ___________________________________________________
>
> 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.
>
> privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Fspring&amp;data=02%7C01%7Cjames.n.guic
> hard%40futurewei.com%7C3a9e583a99324ab04a0708d7c19825be%7C0fee8ff2a3b2
> 40189c753a1d5591fedc%7C1%7C0%7C637190731541021508&amp;sdata=scW9s5WS7z
> 1ndZyX3iYNT4ktjv9HcmXOQzuS47rQCWY%3D&amp;reserved=0

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fipv6&amp;data=02%7C01%7Cjames.n.guichard%40futurewei.com%7C3a9e583a99324ab04a0708d7c19825be%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637190731541021508&amp;sdata=YfIWJd%2FvZpVd1c%2BNukB4O5YmBVZrx2oAmW1wv7JE9PE%3D&amp;reserved=0
--------------------------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 7 Mar 2020 09:17:09 +1300

Ole,

> No, it is the IETF that is the SDO and has that authority through IETF consensus.

Absolutely. And that means: IETF consensus as judged by the IESG, subject to the RFC 2026 appeal process. 
> I also object to any statement in SR PGM that it is in "compliance with 8200". It specifies it's own unique EH handling.

It doesn't use the word "compliance" which is rather loaded in standards-speak. It now says:

  "This behavior does not contravene Section 4 of [RFC8200] because the
   current destination address of the incoming packet is the address of
   the node executing the PSP behavior."

Like it or not, that's what we published. Whether it's what we meant is another question.

> I see no outstanding technical issues with that mechanism.

After a lot of thought, I agree with that. It's known not to work with AH, but AH is optional. It cannot break PMTUD because it only makes the packet smaller. And I am told it doesn't break OAM.

> 3) It is also clear that what is specified in SR PGM does not work across administrative domain or on the general Internet.

In fact, the whole of SRH is intra-domain, as specified by RFC8402.

> For that reason I would object to any modification to 8200. Be it erratum, updated by pointer or bis document.

I think there's an established weakness in RFC 8200. We could decide to live with it, as we live with weaknesses in RFC 791. 
 
> Is is possible to come to some agreement and consensus on the above points?

That beats me ;-)

    Brian

---

From: Tom Herbert <[email-masked]>
Date: Fri, 6 Mar 2020 13:00:25 -0800

> After a lot of thought, I agree with that. It's known not to work with AH, but AH is optional. It cannot break PMTUD because it only makes the packet smaller. And I am told it doesn't break OAM.

Brian,

I don't understand what you mean by "AH is optional" in this context.
AH is certainly optional to send by source nodes, however if it is in
a packet then I don't see how intermediate nodes have the option to
knowingly break AH. This is precisely why declaring what data in
header fields is mutable in flight is so important. This isn't just to
make AH work, but enforcing that the network doesn't arbitrarily
modify packets in random ways is one of the reasons why AH is needed.

(If you were to say that AH isn't a problem because it will never be
in the same packet as and SRH, then I will have to point that SRH does
not preclude that possibility. IMO, until the combination is expressly
prohibited, intermediate nodes are subject to "be liberal in what you
receive" in this regard)

Tom

> > 3) It is also clear that what is specified in SR PGM does not work across administrative domain or on the general Internet.
That's the limited domain argument which as pointed out several times
is not a normatively defined construct in IETF. Without such a
definition I don't see how requirements pertaining to IPv6 can take
this into account (i.e. we can't update RFC8200 with requirements that
would only be applicable in a limited domain without defining limited
domain).

---

From: [email-masked]
Date: Fri, 6 Mar 2020 22:17:36 +0100

Hi Brian,

>   the node executing the PSP behavior."

I _think_ I would be happier if that paragraph was deleted.
And replaced or pointing to text describing the behaviour.
(The reason for that is that I don't want that particular reading of the 8200 paragraph to set precedence.)

> Like it or not, that's what we published. Whether it's what we meant is another question.

And we also say (cut and pasted): "are not processed, inserted, or deleted by any node along a packet's delivery path".
But regardless of that, my suggestion was that it shouldnt' matter if it contravened or not. As long as the proposed solution was technically sound standing on it's own feet.

> After a lot of thought, I agree with that. It's known not to work with AH, but AH is optional. It cannot break PMTUD because it only makes the packet smaller. And I am told it doesn't break OAM.

As long as it states that, and there are no other technical objections I think that is fine.

> I think there's an established weakness in RFC 8200. We could decide to live with it, as we live with weaknesses in RFC 791. 

You might be right. Although I think that we cannot modify our documents on every occasion someone wants to do something.
In that case they must go off and write a document. And if there is consensus on that, well so be it.
(Even if that is MPLS labels in the flow label field, or semantic addressing. :-))

>> Is is possible to come to some agreement and consensus on the above points?

Well, you didn't sound like you disagreed too much. That's a start. ;-)

Have a nice weekend!
Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 7 Mar 2020 15:04:09 +1300

Tom,

> I don't understand what you mean by "AH is optional" in this context.

AH is optional in *every* context. So it's completely legitimate for
the SRH architecture to state that AH is not used in SRH domains. It
might be used in packets that are encapsulated for transit across an
SRH domain, but that's fine.

I thought this was clear when we persuaded the SRH community to drop
insertion and specify encapsulation.

    Brian

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 6 Mar 2020 21:11:26 -0500

I think there is a difference between
AH Is optional in all IPv6 implementations and deployments
     and
A standard may be incompatible with AH.

Having said ath, we approved SRH knowing it was incompatible with AH. 
So whether I think that makes sense or not, we live with it.  (In this 
context, we is both 6man and the IETF as a whole.)

Yours,
Joel

---

From: Mark Smith <[email-masked]>
Date: Sat, 7 Mar 2020 13:12:18 +1100

Hi Ole,

On Sat, 7 Mar 2020, 00:24 , <[email-masked]> wrote:

> >> - Read the mailing list and you will see that everyone do not share
> your opinion. So at least one person is wrong. I think that it would help
> if everyone, including you, could consider that they/you _may_ be wrong, at
> least to better understand the comments been made by others.  And possibly
> the text from RFC 8200 is not clear, but this is what we have. And this is
> the text to use to support the claim that this text is violated.
> >
RFC5704 doesn't formally define what it considers an SDO to be. Yes it uses
ITU and IETF as examples, however the word "organisation" doesn't mean an
officially registered organisation, because the word organisation means:

"a group of people who work together in an organized way for a shared
purpose"

https://dictionary.cambridge.org/dictionary/english/organization

I would say that within the IETF, WGs are SDOs.

6man are clearly the "group of people who work together" to define (well,
actually now maintain) IPv6. SPRING are not, so when there is disagreement
about RFC 8200 content and intent, 6man should be deferred to.

> I also object to any statement in SR PGM that it is in "compliance with
> 8200". It specifies it's own unique EH handling.
>

I agree.

> As I state below that's perfectly fine.

I disagree.

>
> 2) A premise for the work on tightening extension header processing rules
> leading up to 8200, was that new specifications can specify different
> behaviour than what's defined in 8200.
>

I don't ever remember that being the premise. I would have objected to it
if it was.

If alternative EH handling was now allowed to be specified outside of RFC
8200, then the EH processing restriction text that was updated for more
clarity in RFC 8200 should have instead been deleted.

If alternative EH handling was now allowed by the base specification of
IPv6, that should be explicitly stated, and there should have been text in
RFC 8200 describing considerations and constraints when doing so, including
that processing other than in RFC 8200 may cause AH to fail if immutable
fields such as payload length and next header fields were changed.

> That is what the SR PGM document does. Any specification that changes EH
> processing must specify how that processing is done, and must be
> technically sound, in that it is shown not to break anything
> (interoperability, PMTUD, end to end security etc).
> The SR PGM document has been terse in it's description and how it deals
> with identified technical issues. But it is also clear, that it is
> specified to only work within a limited domain, where the source,
> destination and in-path nodes are all within the same domain of control.
>

I think "limited domain" is and will be used as excuse to call something
"IPv6" when it really isn't IPv6. Currently "IPv6" means RFC 8200 and its
ancestors' IPv6, nothing else.

If I decide the word "cat" means "wash" in my house (a limited domain), and
now say "I cat my dishes", is that still English? The word "cat" is an
valid English word, but I'm not using it per it's normal English meaning. I
can't be claiming to using common English if I redefine word meanings and
grammar. Somebody who talks and expects common English won't understand
what I'm saying.

I can say I'm talking "Mark's version of English" or "Mark's English"
("American English",
https://en.wikipedia.org/wiki/List_of_English-based_pidgins ).

A controlled domain by itself doesn't indicate variation and enforce
variation compliance by its existence. I think it is necessary to indicate
that using version or sub-version numbers. In network protocols version or
sub-version numbers are also used to indicate and enforce inoperability, as
well as interoperability.

>
> 3) It is also clear that what is specified in SR PGM does not work across
> administrative domain or on the general Internet.

The more I've thought about NAT (since it first failed on me in 1996 when I
first tried to use it), and subsequently thinking about in-flight EH
modification, the more I'm convinced that the ideal operation during packet
forwarding is read-only. I think read-write operations are more prone to
error, and their effects can last beyond the device that is suffering from
the fault.

That ship has sailed (courtesy of TTL in the first instance - cerf74 TCP
(IP) didn't have it, and it took until 1978 for a TTL field to appear),
however I think read-only is the ideal to aim for. Proposals for in-flight
modifications to packets should be minimised and resisted.

Regards,
Mark.

---

From: Mark Smith <[email-masked]>
Date: Sat, 7 Mar 2020 13:17:55 +1100

Hi Joel,

> Having said ath, we approved SRH knowing it was incompatible with AH.

I don't think 6man or the IETF have "approved" it. It's still a 6man
WG Internet Draft.

https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26

6man could abandon it just like "IPv6 Router Advertisement IPv6-Only
Flag" was, due to lack of consensus during WG last call.

Regards,
Mark.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 6 Mar 2020 21:30:04 -0500

Mark, it has been approved by the IESG for publication.  We had a WG 
last call.  An IETF last call.  An IESG review.  It is in the RFC EDitor 
queue for publication.  While we could theoretically call it back, there 
would have to be an overwhelming reason.

Yours,
Joel

---

From: Tom Herbert <[email-masked]>
Date: Fri, 6 Mar 2020 18:34:55 -0800

> I don't think 6man or the IETF have "approved" it. It's still a 6man

Joel,

The 6man WG did not agree that SRH is incompatible with AH nor that it
is acceptable for SRH to indiscriminately break AH. What was consensus
and is clearly articulated in
draft-ietf-6man-segment-routing-header-26 is that that draft does not
define use of SRH with AH, however it may be defined later.
Specifically, from the draft:

"The use of SRH with AH by an SR source node, and processing at a SR
segment endpoint node is not defined in this document. Future
documents may define use of SRH with AH and its processing."

So that is the text that 6man WG agreed upon. I don't see how that
could possibly be misinterpreted as requiring that SHR and AH MUST NOT
be used in the same packet, and without such a normative requirement,
blindly deleting routing header will break AH when it's present.

Tom

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 6 Mar 2020 21:46:06 -0500

It seems clear to me that the wording you quote means that we do not 
know how to use AH with SRH.  If someone wants to define it, they can do 
so.  But it is not currently defined in a compatible fashion.

We approved it.  The IETF approved it.   The IESG surprised me by 
approving it.  So it goes.

Yours,
Joel

---

From: Mark Smith <[email-masked]>
Date: Sat, 7 Mar 2020 14:04:32 +1100

Hi Joel,

On Sat, 7 Mar 2020 at 13:30, Joel M. Halpern <[email-masked]> wrote:
> queue for publication.

Ok, I've missed that.

 While we could theoretically call it back, there
> would have to be an overwhelming reason.

It only occurred to me yesterday that SRH/SRv6 might also be violating
RFC 4291, as it seems that when SIDs are transformed into IPv6
addresses, those IPv6 addresses aren't assigned to interfaces but
rather nodes:

RFC 4291:

"2.1.  Addressing Model

 IPv6 addresses of all types are assigned to interfaces, not nodes.
   An IPv6 unicast address refers to a single interface.  Since each
   interface belongs to a single node, any of that node's interfaces'
   unicast addresses may be used as an identifier for the node."

draft-ietf-6man-segment-routing-header-26:

"4.3.  SR Segment Endpoint Node

 When an SRv6-capable node receives an IPv6 packet, it performs a
   longest-prefix-match lookup on the packets destination address.  This
   lookup can return any of the following:

       * A FIB entry that represents a locally instantiated SRv6 SID
       * A FIB entry that represents a local interface, not locally
                                       instantiated as an SRv6 SID
       * A FIB entry that represents a non-local route
       * No Match"

It would seem to me that the first match bullet point is effectively a
node IPv6 address match.

Regards,
Mark.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 7 Mar 2020 16:55:08 +1300

>        * A FIB entry that represents a locally instantiated SRv6 SID

I'll bet you a beer next time I'm in Melbourne that the implemenations
all assign such SIDs to the loopback interface. What else can "locally
instantiated" mean in any vaguely Unix-like O/S?

What makes me feel upset is using an IPv6-address-shaped object to
convey semantics rather than location, but as Joel said this went right
through the process and for reasons that I don't know has been in
AUTH48 for 134 days.

    Brian

---

From: Fernando Gont <[email-masked]>
Date: Sat, 7 Mar 2020 03:13:53 -0300

On 7/3/20 00:55, Brian E Carpenter wrote:
[....]
> convey semantics rather than location, 

Is it segment-routing-header doing tihs, or other subsequent documetns 
such as network-programming?

> but as Joel said this went right
> through the process 

That ship has sailed, but, if you ask me, I don't think many 6man'ers 
reviewed the document to the extent we review others.

> and for reasons that I don't know has been in
> AUTH48 for 134 days.

I guess the... AD should know?

Thanks,

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 8 Mar 2020 15:41:56 +1300

RFC 8402 gives these definitions:

>>>    SID: a segment identifier.  Note that the term SID is commonly used
>>>    in place of the term "Segment", though this is technically imprecise
>>>    as it overlooks any necessary translation.
>>> 
>>>    SR-MPLS SID: an MPLS label or an index value into an MPLS label space
>>>    explicitly associated with the segment.
>>> 
>>>    SRv6 SID: an IPv6 address explicitly associated with the segment.

and it is used for routing. But elsewhere in RFC 8402 we find this:

>>>    A segment is often referred to by its Segment Identifier (SID).
>>> 
>>>    A segment may be associated with a topological instruction.  A
>>>    topological local segment may instruct a node to forward the packet
>>>    via a specific outgoing interface.  A topological global segment may
>>>    instruct an SR domain to forward the packet via a specific path to a
>>>    destination.  Different segments may exist for the same destination,
>>>    each with different path objectives (e.g., which metric is minimized,
>>>    what constraints are specified).
>>> 
>>>    A segment may be associated with a service instruction (e.g., the
>>>    packet should be processed by a container or Virtual Machine (VM)
>>>    associated with the segment).  A segment may be associated with a QoS
>>>    treatment (e.g., shape the packets received with this segment at x
>>>    Mbps).
>>> 
>>>    The SR architecture supports any type of instruction associated with
>>>    a segment.

So the reader can decide whether it's a locator, an identifier, or the
label for an open-ended instruction. (I suppose that if an SRV6 node
is capable of supporting many different instructions, it will have
many different SIDs assigned, which IPv6 addressing certainly allows.)

Now I'm not saying that any of this is *bad*. It's innovative, and it isn't
what we traditionally think of as an IP address.

    Brian

---

From: Andrew Alston <[email-masked]>
Date: Sun, 8 Mar 2020 06:28:53 +0000

Sorry realized I had hit direct reply so adding relevant

Andrew

Get Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: Andrew Alston <[email-masked]>
Sent: Sunday, March 8, 2020 09:07
To: Brian E Carpenter
Subject: Re: Who is the design ultimate authority over IPv6? (Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming)

Hi Mark, Brian

> * A FIB entry that represents a locally instantiated SRv6 SID

The above issue with the fact that srv6 as a whole - and to a wider degree - mangles the ipv6 address semantics has been raised several times in spring by myself and others - and very studiously ignored - it’s been amazing how emails on these questions seem to magically disappear into spam filters.

> instantiated" mean in any vaguely Unix-like O/S?

Do I get to claim the beer if we are ever in the same place? :). I ask because I tested across a few platforms - and while most of the testing I did was on XR/eXR/XRv here is what I can say in the code I tested

A.) The SIDs arent assigned to a loopback - and from what I could see the Loopback couldn’t come from the same range as the “locator”

B.) There are some very strange length limitations on the length of the locator - specifically, the documentation explicitly states that the SID block portion of the address cannot be less than 40 bits in length, and the node section can not exceed 24 bits.  It also states explicitly that only a single locator is supported and that is the block used by default for SID allocation.

C.) Use of this means that every device you add a SID to now has 2 entries in your FIB with the IGP domain - which is you are running lower end edge devices creates a problem - particularly if you are already segmenting with areas so specific design criteria in order to keep that IGP entry count down so as to allow for the use of lower cost edge

D.) If you look closely post implementing this - you find that there is a new route type on the devices referred to as SRv6-Local - and each function instantiates a new “Local” IGP route - as in they show up in a look at for example the ISIS routes but never propagate beyond the end point node itself (in a test we instantiated 2000 VRFs and found 2000 local routes appeared - none of which were associated with any “Interface” as such.

I will also say - I’ve been configuring and troubleshooting networks for a long long long time - and my only thought as I went through the testing I’ve been playing with up till now - for so many reasons - was “God help the NOC that has to troubleshoot this the day it goes wrong” :)

Can I say if this is all implementations out there - no - not at all - but this is what I found on the ones that I have tested so far.  Then again - the implementations I have tested so far also never use the SRH and seem to have no facility to enable anything that would mandate it - and every request for packet dumps from these platforms or for configurations that would cause an SRH to be applied have again mysteriously disappeared into the ether (I’ve asked for such both on spring and directly).  Happy to share packet captures of what is actually happening.

Does make me wonder though what all the people in the deployment draft have deployed though - because in my book - if you haven’t got an SRH - you aren’t doing SRv6 - you are doing something that is probably more appropriately placed in BLESS

Andrew

---

From: S Moonesamy <[email-masked]>
Date: Sat, 07 Mar 2020 23:27:19 -0800

Hi Mark,

[Cc trimmed]

>IETF WGs would qualify as standards development organisations.

The Standards Development Organization is the IETF.  The working 
group is the equivalent of a committee within the IETF.  The design 
authority, internally, is IPv6 Maintenance Working Group.

Sometimes, the work within the Area in which I was active would 
overlap with another Area.  My preference was to identify the 
relevant working group and ask for advice.  The question of which 
working group is the design authority did not arise.

Regards,
S. Moonesamy

---

From: Suresh Krishnan <[email-masked]>
Date: Sun, 8 Mar 2020 12:14:14 -0400

Hi Brian,

> On Mar 6, 2020, at 10:55 PM, Brian E Carpenter <[email-masked]> wrote:
> 

It has not :-). You are reading the total time it has been in the queue since approval by the IESG.
It has been in AUTH48 for all of 4 days (since March 4).

https://www.rfc-editor.org/auth48/rfc8754 <https://www.rfc-editor.org/auth48/rfc8754>

Thanks
Suresh

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 9 Mar 2020 11:06:48 +1300

On 09-Mar-20 05:14, Suresh Krishnan wrote:
> Hi Brian,
> 
>> On Mar 6, 2020, at 10:55 PM, Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>> On Sat, 7 Mar 2020 at 13:30, Joel M. Halpern <[email-masked] <mailto:[email-masked]>> wrote:
>>>>

Ack. My eyes connected directly to the keyboard, bypassing brain ;-).
 
   Brian
> 
> https://www.rfc-editor.org/auth48/rfc8754
> 
> Thanks
> Suresh
>

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Tue, 10 Mar 2020 18:11:23 +0000

Andrew,

Please see inline the answers with PC2.

Also, I guess that by mistake, your inline emails remove this text from your original email and my reply to it. Let me copy paste it in here to make sure it is not lost.

From Andrew on March 2nd:
The promises to deliver an assessment of IP Space burn as per what is on video from the montreal meeting – was not delivered on or addressed
Pablo on March 4th:
PC1: Authors do not recall such a promise. Can you please point me at either a) an email URL; b) SPRING WG meeting minutes; c) SPRING WG meeting recording (with precise minute and seconds) where such promise happened?

Technical points inline below.

Regards,
Pablo.

From: Andrew Alston <[email-masked]>
Date: Friday, 6 March 2020 at 06:36
To: "Pablo Camarillo (pcamaril)" <[email-masked]>, Martin Vigoureux <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, draft-ietf-spring-srv6-network-programming <[email-masked]>
Subject: RE: [spring] WGLC - draft-ietf-spring-srv6-network-programming

Andrew,

Inline. PC1.

Regards,
Pablo.

PC2: Text in RFC8200 is crystal clear.

PC2: The comment started because in the draft we had an example that was assigning A:1::/32 as loopback interface for a router. This is wrong (prefix length, documentation prefix,).
This was fixed in revision 2 of the WG draft, published in September 19th 2019. The closure of this comment was presented by me personally in IETF Singapore. Please refer to the slides. In Singapore you were present (signed blue sheet) and did not had any comment about such closure.

PC2: Still, if you want to discuss technically: please let me know what is unanswered after reading this email https://mailarchive.ietf.org/arch/msg/spring/34s0MNMsXe7lTYJr1jw-xBpoRp0/

PC2: Neither this document, nor this working group, is defining the Segment Routing Header. That was done at 6man. If you think there are considerations from RFC7112 that should apply particularly for the SRH, please raise it there.
That said personally I don’t believe that there’s any consideration from RFC7112 that should apply particularly to the SRH.

Andrew

---

From: Andrew Alston <[email-masked]>
Date: Wed, 11 Mar 2020 07:48:26 +0000

Pablo

This is interesting – so firstly – let me state that because I was present in a meeting and signed a blue sheet to say I was there – in no way indicates that I forgo the right to object after the meeting – and last I checked, signatures on a blue sheet are there to track attendance, not to track consensus.

Now, on to the issue at hand – I am curious as to how this closure was presented to you because I just went and checked the spring WG site on trac.ietf.org.  I found it rather curious that there is not a *single* ticket on that site – nor is there any closures listed on that site, despite all the work that has gone in.  I also point out that I was in that room in Montreal, and the issue related beyond just as a /32 – and the agreement from my reading of it was not to change to an arbitrary number, and declare the issue closed – the agreement was to do an analysis of the address space potentially utilized and present it to the working group – this has not happened.  So – can you provide a clear reference to this closure either in a tracker or an email list somewhere?

I also point you to  https://mailarchive.ietf.org/arch/msg/spring/_SYsvWXQo9t4o2KbJuEiVS-75B4/ Which expressly refers to the lack of discussion that has occurred on this – which appeared way after Singapore.

Thanks

Andrew

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Wed, 11 Mar 2020 10:03:58 +0000

Andrew,

Inline with PC3.

Regards,
Pablo.

From: Andrew Alston <[email-masked]>
Date: Wednesday, 11 March 2020 at 08:48
To: "Pablo Camarillo (pcamaril)" <[email-masked]>
Cc: 6man WG <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [spring] WGLC - draft-ietf-spring-srv6-network-programming

Pablo

PC3: In IETF105 Montreal you went to the microphone and made a comment about addressing space. (IETF105 SPRING recording 25:07)
The presenter did not understand the details of your question and asked you to send it by email to the mailer. (IETF105 SPRING recording 25:53). You didn’t send such email.
You remain silent since then, and now you are accusing the authors of not doing a promise that you think was made.
                “The promises to deliver an assessment of IP Space burn as per what is on video from the montreal meeting – was not delivered on or addressed”
First I fail to see in the recording where such promise happened. I asked you for the precise timing but you did not send it.
It seems to me that you are putting words in someone else’s mouth, because the presenter asked you politely to send your comment to the mailer and you didn’t.
Then you are using this fake promise to attack the authors, chair and AD.
Am I missing anything?

PC3: On the closure of the /32 wrong addressing examples:  IETF106 SPRING recording 26:13. And in the IETF106 NET-PGM slides, slide 7.

PC3: As I pointed out yesterday, that email you are referring to has already been replied: https://mailarchive.ietf.org/arch/msg/spring/34s0MNMsXe7lTYJr1jw-xBpoRp0/ So, going back to making technical progress: is there any technical point that remains to be addresses after reading the email I just referred to?

Thanks

Andrew

---

From: Andrew Alston <[email-masked]>
Date: Wed, 11 Mar 2020 10:52:07 +0000

Actually – I did send you the timing – please see my email which included a youtube url and a timing.  There is nothing fake about what was stated at the microphone.  Furthermore – the reply to Nick – refers to a /20 – that – is no way indicative of what is contained within RIR policy – not everyone can just lay their hands on a /20.  I also point out – that right now – despite my questions about these deployments – I have asked, multiple times, for information about this.  Those emails – have been met with deafening silence.  Now, normally I would say that what people deploy and what is running code – isn’t that material – but – the day a document is published that makes clear claims to such, those claims become subject to scrutiny and questioning – questions – that are not being answered.

And Pablo,  the issue around RFC8200 – is still very much open – to the point where the WG Chair indicated in his writeup that this was being referred back to the IESG to adjudication – despite your claims that the wording is crystal clear – that is a technical issue.  The issues around the IPv6 addressing semantics – which I raised – time and again – are still very much open – and the issues around address space – where a discussion was promised – in the youtube URL that I sent to the list – has never happened.

Andrew

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Wed, 11 Mar 2020 14:42:25 +0000

Andrew,

The threads you initiated describing technical questions on the mailing list have been replied by the authors.
You still have not initiated any discussion or clarify your concerns on the topic of “IP Space Burn” on the mailing list. At this point I don’t see any technical discussion points outstanding on this topic.

Regards,
Pablo.

Date: Wednesday, 11 March 2020 at 11:52

Andrew

---

From: <[email-masked]>
Date: Wed, 11 Mar 2020 18:23:25 +0000

Andrew,

>  I just went and checked the spring WG site on trac.ietf.org.  I found it rather curious that there is not a *single* ticket on that site – nor is there any closures listed on that site, despite all the work that has gone in.

Some WGs use the ticket tracking system [1] , some don’t. SPRING WG has not, so far, since its creation. For the WGs that I follow in the routing area, it’s not used a lot. 6MAN WG has used it for the SRH document.

--Bruno

[1] I’m assuming that you are referring to https://trac.ietf.org/trac/spring/report/6

From: ipv6 [mailto:[email-masked]] On Behalf Of Andrew Alston
Sent: Wednesday, March 11, 2020 8:48 AM
To: Pablo Camarillo (pcamaril)
Cc: [email-masked]; 6man WG
Subject: RE: [spring] WGLC - draft-ietf-spring-srv6-network-programming

Pablo

Thanks

Andrew

---

From: Andrew Alston <[email-masked]>
Date: Thu, 12 Mar 2020 11:04:31 +0000

Pablo,

I’ve clarified these questions many times – and I’m not going to keep repeating myself – we can leave that to the appeal.  So – for now I’ll leave this alone – but I did just want to drop a note and say thank you for indirectly confirming what I thought on the deployment stuff, and nicely side stepped.

Andrew

From: Pablo Camarillo (pcamaril) <[email-masked]>
Sent: Wednesday, 11 March 2020 17:42
To: Andrew Alston <[email-masked]>
Cc: 6man WG <[email-masked]>; [email-masked]
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

Andrew,

Regards,
Pablo.

From: Andrew Alston <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, 11 March 2020 at 11:52
To: "Pablo Camarillo (pcamaril)" <[email-masked]<mailto:[email-masked]>>
Cc: 6man WG <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [spring] WGLC - draft-ietf-spring-srv6-network-programming

Andrew

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Thu, 12 Mar 2020 11:33:12 +0000

Hi Andrew,

I believe the /20 example was what Softbank seems to be using for their (very large?) network and use-cases. It’s an example of how much IPv6 space they’ve got from ARIN. A millionth of that for SRv6 indicates a /40 (if I’ve got my maths right). Now, I don’t claim to be aware of Softbank’s current and future use-cases. I don’t think it is a topic for discussion on an IETF mailing list. Perhaps any operator that is genuinely interested in understanding their use of that /40 should approach Softbank (or other operators deploying SRv6). Perhaps some of them will (or may be have) presented at one of the NOGs. I don’t see any side-stepping here.

There is nothing in the net-pgm draft that prescribes an allocation policy. Honestly, I doubt if such a prescription is possible given that it would be up to the operator depending on the size and design of their network as also the use-cases they have in mind for SRv6.

Regarding your concern of “IP Space burn”, I don’t find any email on the mailing list in which you have actually described the issues and problems that you perceive. I am not sure how the WG is supposed understand your concerns or discuss something that is not clearly written down?

Would it be too much to ask you to explain your concerns to the WG in the spirit of engaging in constructive technical discussions? Especially if it is related to the net-pgm draft.

I see rather long emails from you quite frequently on the list … and for this technical point you don’t want to explain?

Thanks,
Ketan

From: spring <[email-masked]> On Behalf Of Andrew Alston
Sent: 12 March 2020 16:35
To: Pablo Camarillo (pcamaril) <[email-masked]>
Cc: [email-masked]; 6man WG <[email-masked]>
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

Pablo,

Andrew

From: Pablo Camarillo (pcamaril) <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, 11 March 2020 17:42
To: Andrew Alston <[email-masked]<mailto:[email-masked]>>
Cc: 6man WG <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

Andrew,

Regards,
Pablo.

Andrew

---

From: Sander Steffann <[email-masked]>
Date: Thu, 12 Mar 2020 12:53:22 +0100

Hi,

> I believe the /20 example was what Softbank seems to be using for their (very large?) network and use-cases. It’s an example of how much IPv6 space they’ve got from ARIN. A millionth of that for SRv6 indicates a /40 (if I’ve got my maths right). Now, I don’t claim to be aware of Softbank’s current and future use-cases. I don’t think it is a topic for discussion on an IETF mailing list.

I disagree. I think the RFCs that the IETF produces should be deployable in the real world, and where that requires changes at other organisations in the internet ecosystem like the RIRs and their communities that requires cooperation, communication and consideration. The IETF does not exist in a vacuum.

To help start the discussion and awareness, I just made a list of all the IPv6 current assignment and allocation sizes in the RIPE NCC service region:

/19:     3
/20:     2
/21:     2
/22:     2
/23:     5
/24:     5
/25:     5
/26:     8
/27:    11
/28:     7
/29: 11614
/30:   107
/31:    54
/32:  6346
/40:     1
/42:     1
/43:     1
/44:     2
/45:     7
/46:    17
/47:    39
/48:  2998

This is the operational context that these standards exist in. If anything needs to be changed that will need cooperation with the RIR communities at the least.

Cheers,
Sander

Source:
wget ftp://ftp.ripe.net/pub/stats/ripencc/delegated-ripencc-extended-latest
grep ipv6 delegated-ripencc-extended-latest | grep -E 'allocated|assigned' | cut -d '|' -f 5 | sort -n | uniq -c

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Thu, 12 Mar 2020 12:03:55 +0000

Hi Sander,

So what is it that you and Andrew see in the net-pgm draft or the SRv6 proposal that lead you to believe such a change in the IPv6 assignment or allocation sizes are required by RIRs?

I am assuming this is the same "IP Space burn" topic that Andrew alludes to ...

Thanks,
Ketan

-----Original Message-----
From: Sander Steffann <[email-masked]> 
Sent: 12 March 2020 17:23
To: Ketan Talaulikar (ketant) <[email-masked]>
Cc: Andrew Alston <[email-masked]>; Pablo Camarillo (pcamaril) <[email-masked]>; [email-masked]; 6man WG <[email-masked]>
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

Hi,

/19:     3
/20:     2
/21:     2
/22:     2
/23:     5
/24:     5
/25:     5
/26:     8
/27:    11
/28:     7
/29: 11614
/30:   107
/31:    54
/32:  6346
/40:     1
/42:     1
/43:     1
/44:     2
/45:     7
/46:    17
/47:    39
/48:  2998

Cheers,
Sander

Source:

---

From: Sander Steffann <[email-masked]>
Date: Thu, 12 Mar 2020 13:55:46 +0100

Hi,

> So what is it that you and Andrew see in the net-pgm draft or the SRv6 proposal that lead you to believe such a change in the IPv6 assignment or allocation sizes are required by RIRs?

Well, your example mentions that a /40 is used for SRv6 in a very large setup. A regular business entity has a /48 and a regular ISP will have a /29 available. I think it is necessary to look at what an expected address space requirements for SRv6 will be for such entities, and whether that fits and leaves enough remaining address space for the rest of the network.

What is also necessary is to see if the way SRv6 uses addresses is compatible with the RIR policies. In the RIPE NCC region we have https://www.ripe.net/publications/docs/ripe-707#assignment_infra, which basically allows for a separate /48 per PoP and a single /48 for in-house operation of the operator. If changes are required in RIR policies their communities need to be told so, and mutual expectations of what will and will not be considered acceptable address space use will have to be discussed.

> I am assuming this is the same "IP Space burn" topic that Andrew alludes to …

Yes
Sander

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Thu, 12 Mar 2020 13:17:37 +0000

Hi Sander,

In this context, we are talking about allocations for the provider's infrastructure.

This is what is there on the link that you provided

To qualify for an initial allocation of IPv6 address space, an LIR must have a plan for making sub-allocations to other organisations and/or End Site assignments within two years.

LIRs that meet the initial allocation criteria are eligible to receive an initial allocation of /32 up to /29 without needing to supply any additional information.

LIRs may qualify for an initial allocation greater than /29 by submitting documentation that reasonably justifies the request. If so, the allocation size will be based on the number of users, the extent of the LIR infrastructure, the hierarchical and geographical structuring of the LIR, the segmentation of infrastructure for security and the planned longevity of the allocation.

Please check further inline below.

-----Original Message-----
From: Sander Steffann <[email-masked]>
Sent: 12 March 2020 18:26
To: Ketan Talaulikar (ketant) <[email-masked]>
Cc: Andrew Alston <[email-masked]>; Pablo Camarillo (pcamaril) <[email-masked]>; [email-masked]; 6man WG <[email-masked]>
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

Hi,

> So what is it that you and Andrew see in the net-pgm draft or the SRv6 proposal that lead you to believe such a change in the IPv6 assignment or allocation sizes are required by RIRs?

Well, your example mentions that a /40 is used for SRv6 in a very large setup. A regular business entity has a /48 and a regular ISP will have a /29 available.

[KT] The example of /40 is for a large SP across their network infrastructure – not a single POP.

I think it is necessary to look at what an expected address space requirements for SRv6 will be for such entities, and whether that fits and leaves enough remaining address space for the rest of the network.

[KT] Sure and I would expect such discussions to happen at NOGs or in other operational forums including within the IETF.

[KT] I believe so and we should get the feedback and inputs of operators that have deployed or deploying it. AFAIK none of them have raised such a concern or any issue with the RIR policies.

Yes

[KT] Thanks for confirming. So this is then a discussion on how providers want to manage their address space and allocations within it for SRv6. Nothing prevents such a discussion from continuing. I just don’t see how this as being related to the progression of the net-pgm draft towards publication.

Thanks,

Ketan

Sander

---

From: Sander Steffann <[email-masked]>
Date: Thu, 12 Mar 2020 14:43:50 +0100

Hi,

> In this context, we are talking about allocations for the provider's infrastructure.

No, we’re not. Allocations are the superblocks that RIRs delegate to an LIR. Before being allowed to use address space an LIR has to make assignments from that allocation. It is that assignment policy that seems incompatible with the way that net-pgm seems to use addresses.
 
> [KT] The example of /40 is for a large SP across their network infrastructure – not a single POP.

I understand. At least one RIR has a policy that doesn’t allow for assignments to network-side infrastructure, only assignments per PoP. I’m not saying this shouldn’t be fixed (I think this is an oversight), but this working group should be aware of that.

> What is also necessary is to see if the way SRv6 uses addresses is compatible with the RIR policies. In the RIPE NCC region we havehttps://www.ripe.net/publications/docs/ripe-707#assignment_infra, which basically allows for a separate /48 per PoP and a single /48 for in-house operation of the operator. If changes are required in RIR policies their communities need to be told so, and mutual expectations of what will and will not be considered acceptable address space use will have to be discussed.

That’s nice. I’m just making you and the rest of the working group aware of the incompatibilities that I have noticed. Apparently so far you have been lucky that you haven’t hit the limits of RIR policies yet, or that the operators have violated the RIR policy without realising it. This is why I am informing the WG of this potential issue that might need some work.

> [KT] Thanks for confirming. So this is then a discussion on how providers want to manage their address space and allocations within it for SRv6. Nothing prevents such a discussion from continuing.…

The draft introduces an new IPv6 address format, so I think it has to at least give guidelines on the expected use and the expected sizes of LOC (L), FUNCT (F) and ARG (A). Although 3.1 says "F and A may be any value as long as L+F+A <= 128” I noticed that 9.2 says "The range of the registry is 0-65535 (0x0000 - 0xFFFF)”. That places at least a minimum size limit on the length of F that should be reflected in 3.1. What I am missing completely are guidelines on the size of A that can be reasonably expected.

Concretely: 
- Section 3.1 needs guidelines on the expected sizes of F and A, which will give operators guidance on the L they should assign to network programming
- Explicit guidance on the size of L would be greatly appreciated
- The guideline on the size of F should state that at least 16 bits are required (considering section 9.1). Whether the authors want to specify F==16 or F>=16 is up to them.

Cheers,
Sander

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Thu, 12 Mar 2020 15:28:17 +0000

Hi Sander,

Please check inline below.

-----Original Message-----
From: Sander Steffann <[email-masked]>
Sent: 12 March 2020 19:14
To: Ketan Talaulikar (ketant) <[email-masked]>
Cc: Andrew Alston <[email-masked]>; Pablo Camarillo (pcamaril) <[email-masked]>; [email-masked]; 6man WG <[email-masked]>
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

Hi,

[KT] I was talking about the allocation for use for SRv6 – that is for the provider’s infrastructure.

[KT] I think it is unfair to say that operators deploying SRv6 are not aware of their RIR’s policies and cannot be expected to perform their allocations appropriately. Coming to the net-pgm document itself, there are no incompatibilities – let me clarify in further comments what might be the source of this misconception.

[KT] Seems like you might have the same misconception as few others had between “behavior code points” (in 9.2) and the “function bits” in the SIDs. Please check

https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-13#section-9.2

   This
   sub-registry maintains 16-bit identifiers for the SRv6 Endpoint
   behaviors.  This registry is established to provide consistency for
   control plane protocols which need to refer to these behaviors.
   These values are not encoded in the function bits within a SID.

Concretely:

[KT] I think you are suggesting for the specification to be prescriptive when clearly it needs to be flexible as reflected in the draft text to allow operators the flexibility in managing allocations and assignments based on their use-cases and requirements (one of these factors would be what they have/get from their RIR). We can obviously continue discussions on this topic in the Spring WG (and possibly others related) and get feedback from operators and their deployments – that would lead to more meaningful guidance. I don’t think this standards track document is the right place for such a discussion.

Thanks,

Ketan

Cheers,

Sander