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

From: Andrew Alston <[email-masked]>
Date: Sun, 1 Mar 2020 09:17:21 +0000

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

While some on this list have made references to Bruno's integrity - let me start by saying - I make no comment on anyone's integrity - because I don't know Mr. Decraene well enough to comment on that, and because I find an individual's integrity in a discussion about if a potential conflict exists to be irrelevant. When people recuse for conflict in any normal environment, it is not because they will act on the conflict necessarily, it is because of perception, because it can taint the issue under discussion, and it leaves the process open to both attack and appeal.

Now, with that said - I completely fail to understand how there can be a claim that there is no potential conflict here.  Let us look at the facts -

Not only is Mr. Decraene a contributor to this document - but - he is also a direct co-author on multiple open drafts that have normative references to the document in question - and which will be held up should this document not proceed.  Indeed one of those drafts goes as far as to say:

   The network programming paradigm
   [I-D.ietf-spring-srv6-network-programming<https://tools.ietf.org/html/draft-ietf-idr-bgpls-srv6-ext-02#ref-I-D.ietf-spring-srv6-network-programming>] is central to SRv6.  It
   describes how different behaviors can be bound to SIDs and how a
   network program can be expressed as a combination of SIDs.

On the basis of what is in the following drafts and how it relates to this last call - I fail to see how ANYONE could claim there is no potential conflict with this document having been taken through LC and last call closure by Mr Decraene.

https://tools.ietf.org/html/draft-ietf-spring-sr-service-programming-01
https://tools.ietf.org/html/draft-ietf-bess-srv6-services-02
https://tools.ietf.org/html/draft-ietf-lsr-isis-srv6-extensions-05
https://tools.ietf.org/html/draft-decraene-spring-srv6-vlsid-02
https://tools.ietf.org/html/draft-ietf-idr-bgpls-srv6-ext-02
https://tools.ietf.org/html/draft-dawra-idr-bgp-ls-sr-service-segments-03

Thanks

Andrew

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 1 Mar 2020 13:51:52 +0100

> a situation in which a person is in a position to derive personal
benefit

Just so we are clear here ... what are those personal benefits ?

Does anyone think that by writing IETF drafts and progressing them anyone
here gets paid or perhaps get's some sort of recognition or maybe a medal ?

If so great for you - but based on my own experience in IETF involvement
this was/is never the case. A lot of people just work in IETF based on
their personal beliefs and do commit personal free time for such work. That
is so true especially for non vendor participants. And that is a fact for
Bruno too.

Now go fire all chairs who co-authored or contributed a draft in their
respective WG as clearly they may have influence on the process itself
either directly or indirectly (via other chair or AD).

Kind regards,
R.

---

From: S Moonesamy <[email-masked]>
Date: Sun, 01 Mar 2020 12:36:20 -0800

Hi Andrew,

[Cc to ietf@]

I'll disclose that I am also affiliated with a 
RIR.  I am copying this message to the 
Responsible Area Director [1] for the SPRING Working Group.

At 01:17 AM 01-03-2020, Andrew Alston wrote:
>While some on this list have made references to 
>Bruno’s integrity – let me start by saying – I 
>make no comment on anyone’s integrity – because 
>I don’t know Mr. Decraene well enough to comment 
>on that, and because I find an individual’s 
>integrity in a discussion about if a potential 
>conflict exists to be irrelevant. When people 
>recuse for conflict in any normal environment, 
>it is not because they will act on the conflict 
>necessarily, it is because of perception, 
>because it can taint the issue under discussion, 
>and it leaves the process open to both attack and appeal.

My question was about the process and the role 
with respect to 
draft-ietf-spring-srv6-network-programming.  I am 
not personally acquainted with Mr. Decraene to 
comment about his integrity.  It has been pointed 
out to me that the person is well-known.  I don't 
see what that has to do with the question which I asked.

There is a message at 
https://mailarchive.ietf.org/arch/msg/spring/3zbi71sjcJ8KaFgVIrF2Ymx4GC8/ 
which lists the Responsible Area Director as a 
Contributor.  In my opinion, the procedural 
aspects are problematic.  I commented about a 
somewhat similar topic previously [2].  From what 
I understand, RFC 2026 is applicable for all 
documents coming out of the IETF 
Stream.  According to that RFC, the "procedures 
are explicitly aimed at recognizing and adopting 
generally-accepted practices".  One of the 
definitions in RFC 7776 is: "A conflict of 
interest may arise if someone involved in the 
process of handling a harassment report is in the 
role of Reporter, Respondent, or 
Subject.  Furthermore, a conflict of interest 
arises if the person involved in the process of 
handling a harassment report is closely 
associated personally or through affiliation with 
any of the Reporter, Respondent, or 
Subject".  The general practice, in such a 
situation, is recusal.  I'll invite the 
Responsible Area Director to comment about 
whether there should be an exception to that practice and the rationale for it.

Regards,
S. Moonesamy

1. https://datatracker.ietf.org/wg/spring/about/
2. https://mailarchive.ietf.org/arch/msg/ietf/xBjDAIM4hdnSTyxL7QHlbiFX3eE/

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 2 Mar 2020 00:02:13 +0100

Exception ? As far as I see it this is rather a norm in multiple WGs across
IETF for chair to co-author or contribute to his area of focus. And there
is absolutely nothing wrong with it. In fact it is expected for chair to
read the draft  and comment othen resulting in becoming a contributor or at
least being added to the Ack section.

If this saga continues any further I recommend we start first by obsoleting
RFC8200 too. After all it's main author Bob Hinden was also a 6man chair
who requested publication of 2460bis:

2016-12-02
2016-12-02 17:06:39 -0800
08 Bob Hinden IETF WG state changed to Submitted to IESG for Publication from
WG Consensus: Waiting for Write-Up

2016-12-02
08 Bob Hinden IESG state changed to Publication Requested

2016-12-02
08 Bob Hinden IESG process started in state Publication Requested

2016-11-30
08 Bob Hinden Changed document writeup

2016-11-15
08 Bob Hinden New version available: draft-ietf-6man-rfc2460bis-08.txt

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 1 Mar 2020 18:17:26 -0500

The usual practice when a hair o-authors a document is for the co-chair 
to manage all aspects of the document life cycle.  In this case, due to 
the co-chair being unavailable, we have a bit of a problem.  For 
non-contentious documents, we can easily manage anyway.  In this case, 
the document is quite contentious.  Which makes things complicated.

Yours,
Joel

On 3/1/2020 6:02 PM, Robert Raszuk wrote:
> 
> Exception ? As far as I see it this is rather a norm in multiple WGs 
> across IETF for chair to co-author or contribute to his area of focus. 
> And there is absolutely nothing wrong with it. In fact it is 
> expected for chair to read the draft  and comment othen resulting in 
> becoming a contributor or at least being added to the Ack section.
> 
> If this saga continues any further I recommend we start first by 
> obsoleting RFC8200 too. After all it's main author Bob Hinden was also a 
> 6man chair who requested publication of 2460bis:
> 
> 2016-12-02
> 	08	Bob Hinden	IETF WG state changed to Submitted to IESG for 
> Publication from WG Consensus: Waiting for Write-Up
> 2016-12-02
> On Sun, Mar 1, 2020 at 9:38 PM S Moonesamy <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Hi Andrew,
> 
>     [Cc to ietf@]
> 
>     2.
>     https://mailarchive.ietf.org/arch/msg/ietf/xBjDAIM4hdnSTyxL7QHlbiFX3eE/
> 
> 
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>

---

From: Jeff Tantsura <[email-masked]>
Date: Sun, 1 Mar 2020 15:30:24 -0800

As Robert mentioned, it is quite often the case for a chair to participate in the development of a draft.
Taking RTGWG as an example, when we got (as result of a merge) a draft that both Chris and myself have co-authored, we had RTGWG secretary taking care of the life cycle of the draft.
I’m more than convinced that Bruno is entirely capable of driving the process unbiased and fair to all involved,  pointing out that there are formal possibilities to address this.

Cheers,
Jeff

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Mon, 2 Mar 2020 06:01:26 +0000

All,

In addition, there is a misunderstanding here.

The draft-ietf-spring-srv6-network-programming LC is being handled by Martin Vigoureux, as stated by Martin in the following:
https://mailarchive.ietf.org/arch/msg/spring/w6VJzDYTVRFWOtvHuMso-kkiBXk/

Martin is neither a co-author nor a contributor to the draft.

Furthermore, since IETF106, Spring WG has only one active chair, as stated by Martin in the above email.

A copy of Martin’s email is cut-and-pasted for quicker reference:

----
Date: Wed, 26 Feb 2020 12:55:24 -0000
WG,

Bruno has been managing SPRING alone since after IETF 106, because Rob
has been unable to act as chair. I have made several attempts to find a
solution and I now have serious hopes for the situation to return back
to normal soon.

Bruno being involved in the draft currently in WG LC, I will handle
closing it.

Martin

---

Thanks

Regards … Zafar

From: spring <[email-masked]> on behalf of Robert Raszuk <[email-masked]>
Date: Sunday, March 1, 2020 at 6:03 PM
To: S Moonesamy <[email-masked]>
Cc: SPRING WG <[email-masked]>, IETF <[email-masked]>, Andrew Alston <[email-masked]>
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming (off-topic)

Exception ? As far as I see it this is rather a norm in multiple WGs across IETF for chair to co-author or contribute to his area of focus. And there is absolutely nothing wrong with it. In fact it is expected for chair to read the draft  and comment othen resulting in becoming a contributor or at least being added to the Ack section.

If this saga continues any further I recommend we start first by obsoleting RFC8200 too. After all it's main author Bob Hinden was also a 6man chair who requested publication of 2460bis:

2016-12-02
2016-12-02 17:06:39 -0800
08
Bob Hinden
IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2016-12-02
08
Bob Hinden
IESG state changed to Publication Requested
2016-12-02
08
Bob Hinden
IESG process started in state Publication Requested
2016-11-30
08
Bob Hinden
Changed document writeup
2016-11-15
08
Bob Hinden
New version available: draft-ietf-6man-rfc2460bis-08.txt

On Sun, Mar 1, 2020 at 9:38 PM S Moonesamy <[email-masked]<mailto:[email-masked]>> wrote:
Hi Andrew,

[Cc to ietf@]

There is a message at

Regards,
S. Moonesamy

---

From: Andrew Alston <[email-masked]>
Date: Mon, 2 Mar 2020 07:06:30 +0000

Yours,
Joel

In any normal circumstance, I would agree there would be far less of a problem – and we could find an simple way to manage this.  This however, is not a normal situation.

You have a write up of the LC – that states “We had to move this document forward” – there is absolutely nothing in the IETF process that states any document has to move forward in the absence of consensus.  The IETF says – we move forward based on consensus, not based on majority will of the working group to move something forward in the face of sustained unaddressed objections.
You have a write up of the LC – which not once – other than in the context of RFC8200 and consensus achieved on that – mentions the word consensus in the context of this RFC – and last I checked, rough consensus was the basis for moving documents forward.
You have multiple issues that have not been addressed – you have a deep point of contention about RFC8200 – you have promises made at the microphone in Montreal (with the chair’s blessing) about providing an analysis of address space used, you have a concern that has been raised about RFC7112, and more and more individuals coming out and saying – we don’t agree with this – for technical reasons.

Now, in light of this – there are going to be questions – particularly in light of the fact that both the chair in question, and the AD in question, have their names on drafts either as contributors or authors which are either the draft in question, or have direct normative references to the draft on question.  Intentional and gaming the process – that I cannot say – it is up to each individual to decide on their own action and I do not know these individuals well enough to judge myself, however, I think it is naïve of anyone to believe that there will not be serious questions raised as to the impartiality of participants in the closure  of last call when we are facing such contentious issues, a very clear lack of consensus, and a series of unaddressed issues.

Thanks

Andrew

---

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

Fernando,

> -----Original Message-----
> From: Fernando Gont [mailto:[email-masked]] 
> Sent: Friday, February 28, 2020 8:28 PM
> To: DECRAENE Bruno TGI/OLN; 'SPRING WG List'
> Cc: draft-ietf-spring-srv6-network-programming; rtg-ads
> Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming
> 
> Bruno,
> 
> On 28/2/20 13:53, [email-masked] wrote:
> > Hello SPRING WG,
> > 
> > Please find below some status on the main points of this WG LC.
> > 
> > ===============
> > 
> > A) PSP [1] & RFC 8200 [2]
> > 
> > ===============
> > 
> > This point is whether SRH removal by the penultimate SR end point (aka 
> > PSP) is allowed by RFC 8200.
> > 
> > More specifically
> > 
> > " S14.4.Remove the SRH from the IPv6 extension header chain"
> > 
> > Vs
> > 
> > "Extension headers (except for the Hop-by-Hop Options header) are not
> > processed, inserted, or deleted by any node along a packet's delivery
> > path, until the packet reaches the node (or each of the set of nodes,
> > in the case of multicast) identified in the Destination Address field
> > of the IPv6 header."
> > 
> > On this text, what is been discussed is "the node (or each of the set of 
> > nodes,
> > 
> > in the case of multicast) identified in the Destination Address field
> > 
> > of the IPv6 header."
> > 
> > More specifically whether "Destination Address field of the IPv6 header" 
> > means the "final Destination Address" or the "Destination Address" as 
> > seen in the packet that the node received.
> 
> If it meant "Destination Address", that would mean multicast addresses, 
> would be allowed in routing headers.

I don't think so. 
I'll try to reorganize the sentence to try to highlight the point:

until the packet reaches the node identified in the Destination Address field of the IPv6 header.
(or each of the set of nodes [identified by that Destination Address] ,in the case of multicast)

In the case that we are discussing, there is one single node, identified by the Destination Address. This is not multicast.

> Do you think htat's the case?
>
> 
> 
> [...]
> > Finally, the responsible AD has not accepted the related errata. 
> > https://mailarchive.ietf.org/arch/msg/ipv6/yVKxBF3VnJQkIRuM8lgWN4_G3-o/
> 
> The status of this erratum is found here: 
> https://www.rfc-editor.org/errata/eid5933   -- not on the mailing-list 
> archive. And the erratum is marked as "reported", not as "rejected".
> 
> Suresh may well go ahead and reject it. BUt so far the status has not 
> changed since I've reported it.

The email from Suresh seems crystal clear, including to you given your reaction. Even after you said you would appeal, Suresh said that he were standing by his decision. 
" > As such, I will formally Appeal your decision.
Please do go ahead. I stand by my assessment that this is a misuse of the Errata process and it is not a simple clarification as you claim."

Also, I have never sent that the errata was rejected. Please don't put words in my mouth. I said "not accepted".

Finally, the errata status has now change. So what's you point, now?

> 
> 
> > Based on this, the plan is to flag this point of debate in the shepherd 
> > report, and leave this for the IESG to decide on how to read RFC 8200 
> > (which represented 6MAN consensus and which the IESG approved). The 
> > threat to appeal will also be explicitly indicated (shepherd write up, 
> > point 10).
> 
> I have *noted* a number of times that I would appeal (so *please* do 
> note that a number of people felt that the specs were being violated 
> *and* that our processes were being circumvented).
> 
> But I've never *threatened* to appeal.
> 
> A quick lookup in a dictionary says:
> "threat"
> 
> noun
> 1.
> a statement of an intention to inflict pain, injury, damage, or other 
> hostile action on someone in retribution for something done or not done.
> 2.
> a person or thing likely to cause damage or danger.
> 
> 
> Clearly, there was no "threat". I did indicate that one of our specs was 
> being violated, and that our processes were being circumvented (in the 
> same way that I'm quite curious how you can claim consensus on this 
> document, but.. ).  That says, appeals are part of our processes.
> 
> I have no idea whatsoever how, sticking to our processes could be 
> considered a threat.

I used the wording from the official shepherd write up.
" (10) Has anyone threatened an appeal"
https://www.ietf.org/chairs/document-writeups/document-writeup-working-group-documents/

I you have an issue with this term, please raise it to the IESG.

I fully agree that appeal is part of the process (so does errata). I would go further that IMHO this is definitely a required part of the process.
Making an appeal is your right. I don't want discourage or encourage you do use it in any way.

> Quite the contrary, the intention is for our existing specs and 
> procedures to be respected. If *that* is considered a threat, that's a 
> different question.
> 
> 
> > 
> > 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). 
> 
> Am I reading correctly? Are you kind of stating that the same working 
> group that is shipoing this document doesn't have enough of a clue to 
> analyze the benefits (or lack thereof) of PSP?
> 
> And, because of that, you make the assessment yourself?
 
On the mailing list, multiple persons stated that it was implemented in their implementation or useful for their deployment.
I'm saying that the performance gain cannot be evaluated by the working group.
>From a logical standpoint, to prove that this is useful, it's enough to have one implementation/deployment case to benefit from it. This has been stated on the mailing list.
To prove that this is not useful, one need to prove that this is not useful some any one/any case. This is much harder. No one has even tried to make that demonstration.

> 
> 
> > ===============
> > 
> > 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.
> 
> Indeed, this could be seen as a possible conflict of interests.

That's why both myself and Martin have stated that the decision would be taken my Martin.

That been said, "conflict of interest" is about "interest". I'm not working for a vendor who may have an interest to push, or delay or stop a work based on it's hardware and software capability. I'm not working for an operator who is deploying it.
My only interest would be to be listed as an contributor on a document. Really? I'm fine with been removed from the list of contributors. I have not proposed that because doing so would be borderline with regards to IPR declaration, and could be seen an trying to hide this. Trying very hard to see a remote conflict of interest, it would be to slow down SRv6 to avoid the competitors of my employer to use it. So quite the opposite direction.

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

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 2 Mar 2020 08:37:22 -0500

As far as I can tell, most of your email below is fair and well taken. 
I appreciate your efforts Bruno.

However, I have to disagree with your description of what it takes to 
decide to keep in or remove a "feature".  You assert that an 
implementation having been done and a claimed use is enough to have 
something in this document.  If it were an authors draft, that would be 
true.  As a working group document, aiming at becoming an RFC, the bar 
is higher.  We do not put every optional feature in our documents.
In particular, in this case several people have pointed out that the 
claimed utility is marginal.  For example, the primary argument seems to 
be a device in the SR domain that can not ignored the SR header.  Excpet 
that RFC 8200 actually already requires that devices be able to ignore 
source routing headers with SL = 0.

I would sincerely hope that we do not put features into a document for 
the purpose of supporting devices that do not comply with existing RFCs.

Yours,
Joel

---

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

Dear Mr  S. Moonesamy,

> From: spring [mailto:[email-masked]] On Behalf Of S Moonesamy
> Sent: Friday, February 28, 2020 11:03 PM
> To: Martin Vigoureux
> Cc: [email-masked]
> Dear Mr Vigoureux,
> I am contacting you as you are listed as the Responsible Area 
> Director for the SPRING Working Group [1].  I would like to thank the 
> Working Group for providing some information [2] about the status of 
> the Working Group Last Call.
> 
> I was a bit surprised to see that one of the Working Group Chairs is 
> listed as a contributor in 
> draft-ietf-spring-srv6-network-programming-10.  It is quite unusual 
> to have the contributor of a Working Group document handle the 
> Working Group process for the document.  Would there be a potential 
> conflict of interest?

And as stated in Martin's and mine email, that's the reason for which the decision will be called by Martin (AD).
 
> The summary provides by the Working Group Chair states that the 
> Responsible Area Director "has not accepted the related errata".  I 
> took a quick look at erratum eid5933; it is listed as "Reported".  As 
> the erratum has not been classified as per the relevant IESG 
> Statement, describing it as "not accepted" is inaccurate.

To me, the email from Suresh was crystal clear.
That been said, Suresh has now updated the errata status. So what's your point exactly?

[under Suresh's control that I'm explicitly adding in copy]

Regards,
--Bruno
 
> 2. https://mailarchive.ietf.org/arch/msg/spring/or8086G4iYfee5_Icw4PnhkPLBo/
> 3. https://www.rfc-editor.org/errata/eid5933
>

---

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

> [under Suresh's control that I'm explicitly adding in copy]

Sorry Suresh, I meant :s/that/who

My primary excuse is that English is not my first language. Still, my mistake.

--Bruno

-----Original Message-----
From: spring [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, March 2, 2020 2:40 PM
To: S Moonesamy; Martin Vigoureux; Suresh Krishnan
Cc: [email-masked]
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

Dear Mr  S. Moonesamy,

 

Regards,
--Bruno

---

From: <[email-masked]>
Date: Mon, 2 Mar 2020 14:00:00 +0000

S. Moonesamy,

Please see inline
 
> Sent: Sunday, March 1, 2020 9:36 PM
> To: Andrew Alston; [email-masked]
> Cc: [email-masked]; Martin Vigoureux
> >Bruno's integrity - let me start by saying - I 
> >make no comment on anyone's integrity - because 
> >I don't know Mr. Decraene well enough to comment 
> >on that, and because I find an individual's 

As stated twice on the list, by both by Martin and myself, the decision will be taken by Martin, not me:

> From: Martin Vigoureux
> Bruno being involved in the draft currently in WG LC, I will handle closing it.

> From: [email-masked]
> 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.
https://mailarchive.ietf.org/arch/msg/spring/or8086G4iYfee5_Icw4PnhkPLBo/

--Bruno

---

From: <[email-masked]>
Date: Mon, 2 Mar 2020 14:16:18 +0000

Dear S. Moonesamy,

Please see and read inline  

> Statement, describing it as "not accepted" is inaccurate.

The email from Suresh that I had cited in support of my statement, seemed and still seems clear to me.

What was not clear to you in Suresh's email?

>  I will process this and move it to the "Hold for Document Update" state
https://mailarchive.ietf.org/arch/msg/ipv6/tRn94-NlupHLcWdzo7O9BfHpiik/

> > Just to be clear, I believe that your stated decision of processing this errata as "Hold for document update" is not only incorrect, but also doesn't represent the consensus this working group got during the rfc2460bis effort -- now RFC8200.
[...]
>  > As such, I will formally Appeal your decision.
>

Please take another look now. Suresh has updated the status of the errata. I guess that your point is now moot.

[+ Suresh]

Regards,
--Bruno

---

From: <[email-masked]>
Date: Mon, 2 Mar 2020 14:25:27 +0000

Andrew,

From: spring [mailto:[email-masked]] On Behalf Of Andrew Alston
Sent: Monday, March 2, 2020 8:07 AM
To: Joel M. Halpern; Robert Raszuk
Cc: SPRING WG
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming (off-topic)

Yours,
Joel

[Bruno] “Move this document forward” was related to starting the WG LC.
Also the whole point of the text was to say that the decision for the WGLC would be taken by Martin, not me.
https://mailarchive.ietf.org/arch/msg/spring/or8086G4iYfee5_Icw4PnhkPLBo/

Now, in light of this – there are going to be questions – particularly in light of the fact that both the chair in question, and the AD in question, have their names on drafts either as contributors or authors which are either the draft in question, or have direct normative references to the draft on question.

Intentional and gaming the process – that I cannot say –

[Bruno] So don’t say.

--Bruno

it is up to each individual to decide on their own action and I do not know these individuals well enough to judge myself, however, I think it is naïve of anyone to believe that there will not be serious questions raised as to the impartiality of participants in the closure  of last call when we are facing such contentious issues, a very clear lack of consensus, and a series of unaddressed issues.

Thanks

Andrew

---

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

> From: Joel M. Halpern [mailto:[email-masked]] 
> 

Thank you Joel.
 
> something in this document.

Sorry if I did not made myself clear, but my intention was not to say that.
The point was related to the usefulness of the optional feature, which has been challenged.
I was trying to say the required argumentation to declare usefulness or usefulness is asymmetric, from a logical discussion stand point.

a) It only requires one person to find it useful, in order to make the feature useful (for that person).
b) In order to state that this is un-useful,  requires to prove that this is never useful.

Multiple persons have stated "a". Noone has even tried to prove "b" (which would require to know the specifics of all hardware, which is not the type of information that vendors disclose publically)

>  If it were an authors draft, that would be 

I agree with you. Please feel free to start a thread on this, with which ever argument you want.
My statement was expected to only cover the "usefulness" argument, which has been brought on the list multiple times.

> claimed utility is marginal.

Yes, but others have said that it was important for them. Cf first point above.

>  For example, the primary argument seems to 

"Ignore" is one thing.
"Ignore at line rate" is another thing.
"Ignore at line rate with additional features enabled" is another thing.
 
If you want to discuss the level of hardware support which is required for a vendor to claims compliancy with RFC 8200, I think that this belong to the 6MAN WG. (and AFAIK this does not belong to the IETF, but anyone please feel free to do whatever you want)

> the purpose of supporting devices that do not comply with existing RFCs.

That would not change their level of support of RFC 8200.

Thank you for your clear and factual email.
Yours,
Bruno

---

From: Fernando Gont <[email-masked]>
Date: Mon, 2 Mar 2020 13:32:41 -0300

Hello, Bruno,

On 2/3/20 10:19, [email-masked] wrote:
[....]
>>> This point is whether SRH removal by the penultimate SR end point
>>> (aka PSP) is allowed by RFC 8200.
>>> 
>>> More specifically
>>> 
>>> "Extension headers (except for the Hop-by-Hop Options header) are
>>> not processed, inserted, or deleted by any node along a packet's
>>> delivery path, until the packet reaches the node (or each of the
>>> set of nodes, in the case of multicast) identified in the
>>> Destination Address field of the IPv6 header."
>>> 
>>> On this text, what is been discussed is "the node (or each of the
>>> set of nodes,
>>> 
>>> More specifically whether "Destination Address field of the IPv6
>>> header" means the "final Destination Address" or the "Destination
>>> Address" as seen in the packet that the node received.
>> 
>> If it meant "Destination Address", that would mean multicast
>> addresses, would be allowed in routing headers.
> 
> I don't think so. I'll try to reorganize the sentence to try to
> highlight the point:
> 
> until the packet reaches the node identified in the Destination
> Address field of the IPv6 header. (or each of the set of nodes
> [identified by that Destination Address] ,in the case of multicast)
> 
> In the case that we are discussing, there is one single node,
> identified by the Destination Address. This is not multicast.
> 

The PSP has two non-compliant behaviors:

1) EH removal:

In order to claim that IPv6 supports en-route EH insertion/removal, it
should address the issues that would introduce with:
* pmtud
* ipsec ah
* error reporting

And it doesn't. i.e., not only it was never the intent for ipv6 to
support eh insertion/removal, but also clearly couldn't do it without
addressing these three issues.

The status of this erratum is found here:
>> https://www.rfc-editor.org/errata/eid5933   -- not on the
>> mailing-list archive. And the erratum is marked as "reported", not
>> as "rejected".
>> 
>> Suresh may well go ahead and reject it. BUt so far the status has
>> not changed since I've reported it.
> 
> The email from Suresh seems crystal clear, including to you given
> your reaction. Even after you said you would appeal, Suresh said that
> he were standing by his decision. " > As such, I will formally Appeal
> your decision. Please do go ahead. I stand by my assessment that this
> is a misuse of the Errata process and it is not a simple
> clarification as you claim."
> 
> 
> Also, I have never sent that the errata was rejected. Please don't
> put words in my mouth. I said "not accepted".
> 

My point is that, as part of declaring consensus on the network
programming draft, you based such decision (dismissing the non-compliant
behavior of PSP) on a fact that had not taken place. That doesn't seem
correct.

[...]
>> 
>> Clearly, there was no "threat". I did indicate that one of our
>> specs was being violated, and that our processes were being
>> circumvented (in the same way that I'm quite curious how you can
>> claim consensus on this document, but.. ).  That says, appeals are
>> part of our processes.
>> 
> I used the wording from the official shepherd write up. " (10) Has
> anyone threatened an appeal" 

My bad -- I didn't remember the sheperd's write-up had such question.

> 
> I fully agree that appeal is part of the process (so does errata). I
> would go further that IMHO this is definitely a required part of the
> process. Making an appeal is your right. I don't want discourage or
> encourage you do use it in any way.

Agreed.

[...]
>>> 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 
>> Am I reading correctly? Are you kind of stating that the same
>> working group that is shipoing this document doesn't have enough of
>> a clue to analyze the benefits (or lack thereof) of PSP?
>> 
> On the mailing list, multiple persons stated that it was implemented
> in their implementation or useful for their deployment. I'm saying
> that the performance gain cannot be evaluated by the working group.

How can a working group ship a document it cannot evaluate?

If you're saying that the wg doesn't have the skills to evaluate a
document it is shipping, what's the value in your statement that this
document has wg consensus?

Seriously.... it is the wg shipping the document, not a vendor (at least
formally speaking).

>> From a logical standpoint, to prove that this is useful, it's
>> enough to have one implementation/deployment case to benefit from
>> it. This has been stated on the mailing list.
> To prove that this is not useful, one need to prove that this is not
> useful some any one/any case. This is much harder. No one has even
> tried to make that demonstration.

This is *terrible* reasoning. Really. To an extent that I'm even 
surprised that you're saying it.

Several folks have raised questions on the need for PSP, which the 
authors *failed* to respond or address.

If you want to ship a document, you should at least be able to make a 
case for it.

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

Weren't you the one declaring consensus on this document? Weren't you 
the one preparing the shepherd's write up?

> That been said, "conflict of interest" is about "interest". I'm not
> working for a vendor who may have an interest to push, or delay or
> stop a work based on it's hardware and software capability. I'm not
> working for an operator who is deploying it. My only interest would
> be to be listed as an contributor on a document. Really? I'm fine
> with been removed from the list of contributors. I have not proposed
> that because doing so would be borderline with regards to IPR
> declaration, and could be seen an trying to hide this. Trying very
> hard to see a remote conflict of interest, it would be to slow down
> SRv6 to avoid the competitors of my employer to use it. So quite the
> opposite direction.

I'll repeat: conflict of interest refers to a situation where you're 
"judge" and "part" at the same time. It doesn't argue that you have or 
will be intentionally benefiting from such position.

Normally, such situations are avoided, because probing one thing or 
another is, unfortunately, materially impossible,

So that's what my clarification was about. I would have made the same 
comment if someone had flagged the same situation for any other 
document, and a co-author/contributor was shepherding the document or 
calling consensus.

As noted, I disagree with your declaring of consensus to move this 
document forward. But I provided a rationale for my disagreement, and 
never linked the outcome of the consensus call to the aforementioned 
conflict of interest.

Thanks,

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Mon, 2 Mar 2020 16:52:38 +0000

Hi all,

Based on the email below and the received feedback we have published a new revision of draft-ietf-spring-srv6-network-programming.
This new version only introduces changes in the PSP section. Those changes are editorial changes destined to simplify the reading of the aforementioned section.
The diff does not change the specification of the behavior.

Please read and comment.
https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-11#section-4.16.1

Thanks,
Pablo.

From: "[email-masked]" <[email-masked]>
Date: Friday, 28 February 2020 at 18:19
To: draft-ietf-spring-srv6-network-programming <[email-masked]>, "Pablo Camarillo (pcamaril)" <[email-masked]>
Cc: Brian E Carpenter <[email-masked]>, 'SPRING WG List' <[email-masked]>
Subject: RE: WGLC - draft-ietf-spring-srv6-network-programming
Resent from: <[email-masked]>
Resent to: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Resent date: Friday, 28 February 2020 at 18:19

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

Thank you.

Thank you.

---

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

On 2/3/20 11:16, [email-masked] wrote:
[...]
> Please take another look now. Suresh has updated the status of the errata. I guess that your point is now moot.

It's not moot that you based your decision on wg consensus on something 
that had not yet happened. The fact that the errata was marked as "held 
for document update" days *after* you made your decision should be a 
datapoint.

Thanks,

---

From: <[email-masked]>
Date: Mon, 2 Mar 2020 17:28:46 +0000

Fernando,

> Sent: Monday, March 2, 2020 6:14 PM
> To: DECRAENE Bruno TGI/OLN; S Moonesamy; Martin Vigoureux; Suresh Krishnan
> Cc: [email-masked]

That's indeed one data point.
Another data point is that Suresh had stated his decision on the 6MAN mailing list before. That's _this_ decision that I explicitly referred to by providing the URL to this email.

Thanks,
--Bruno

---

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

> Another data point is that Suresh had stated his decision on the 6MAN mailing list before. That's _this_ decision that I explicitly referred to by providing the URL to this email.

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.

Thanks,

---

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

---

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,

---

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

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

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

> > 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: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: <[email-masked]>
Date: Tue, 3 Mar 2020 13:45:08 +0000

Hi Pablo,

It’s not clear to me whether this version -11 aims at addressing all received comments, or only the one related to section 4.16.1.

Could you please clarify to avoid misunderstanding? And avoiding unnecessary waiting or deadlock.

If -11 does not address all received comments (which is my personal assumption), could you please indicate the remaining ones that you are working on? And what’s the progress on this?

Finally, note that, although ultimately this is the text in the draft which matters, it’s also ok to first discuss the proposed resolution with the author, and then update the draft. This may also allow for more timey respond and avoid mixing all points

Thank you,
--Bruno

From: Pablo Camarillo (pcamaril) [mailto:[email-masked]]
Sent: Monday, March 2, 2020 5:53 PM
To: [email-masked]
Cc: Brian E Carpenter; DECRAENE Bruno TGI/OLN
Subject: Re: WGLC - draft-ietf-spring-srv6-network-programming

Hi all,

Please read and comment.

Thanks,
Pablo.

Pablo, authors, WG,

Thank you,
--Bruno

Hello SPRING,

Thank you,

Bruno

Thank you.

Thank you.

---

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, 
 
> 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: "Joel M. Halpern" <[email-masked]>
Date: Tue, 3 Mar 2020 11:23:55 -0500

I'm sorry, but "in my gear I want an option to move some work around, so 
I need a protocol behavior for that" is not usually, in and of itself, 
enough reason to add an optional feature to a protocol.

At one point there was an argument that PSP was needed for compliant 
devices that would not be able to process the packet.  It has been 
pointed out since that such devices would not comply to 8200 (not 
because of PSP, but because being able to ignore an exhausted routing 
header is required in 8200).  Having an optional feature to take care of 
devices which violate a standard again requires some strong evidence to 
justify it.

So no, from where I sit I have not seen a clear explanation of the value 
for PSP.

I also do not understand why the authors have resisted the usual 
solution to this sort of disagreement, namely moving the feature to a 
separate document.  Given the structure of the network programming 
draft, and that it is not exhaustive in either flavors or programming 
behaviors, there is no violence done to the draft by removing this flavor.

Yours,
Joel

---

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

> Sent: Tuesday, March 3, 2020 5:24 PM
> To: DECRAENE Bruno TGI/OLN; Martin Vigoureux; [email-masked]

I can't speak on 'usually', but it certainly happened before. Cf the "Penultimate Hop Popping" section in RFC3031 (MPLS):

"   However, some hardware switching engines may not be able to pop the
   label stack, so this cannot be universally required."
https://tools.ietf.org/html/rfc3031#section-3.16

Yours,
--Bruno

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 3 Mar 2020 12:29:00 -0500

Note, I said "is not usually, in and of itself".  Recognizing that there 
are exceptions.  There appears to be significant disagreement as to 
whether the MPLS case was a good one. )There are lots of other aspects 
for that case which do not apply here.)

Yours,
Joel

---

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: Ron Bonica <[email-masked]>
Date: Tue, 3 Mar 2020 19:30:24 +0000

Folks,

I don't think that you can compare MPLS PHP with SRv6 PSP. MPLS PHP is a clear case of de-encapsulation. We do that all the time. In SRv6 PSP, we are removing something from the middle of a packet. That is quite a different story.

                                                                                                                                      Ron

Juniper Business Use Only

-----Original Message-----
From: spring <[email-masked]> On Behalf Of Joel M. Halpern
Sent: Tuesday, March 3, 2020 12:29 PM
To: [email-masked]; Martin Vigoureux <[email-masked]>; [email-masked]
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

Note, I said "is not usually, in and of itself".  Recognizing that there are exceptions.  There appears to be significant disagreement as to whether the MPLS case was a good one. )There are lots of other aspects for that case which do not apply here.)

Yours,
Joel

On 3/3/2020 12:17 PM, [email-masked] wrote:
>> Subject: Re: [spring] WGLC - 
>> draft-ietf-spring-srv6-network-programming
>>
>> I'm sorry, but "in my gear I want an option to move some work around, 
>> so I need a protocol behavior for that" is not usually, in and of 
>> itself, enough reason to add an optional feature to a protocol.
> 
> https://urldefense.com/v3/__https://tools.ietf.org/html/rfc3031*sectio
> n-3.16__;Iw!!NEt6yMaO-gk!R8IpdFJzyoCo7yckOzOPMieJAOSnyq5AODMxwdW0b6iuY
> Atn0aGSZEOQCiyxWF1i$
> 
> Yours,
> --Bruno
> 
>> header is required in 8200).  Having an optional feature to take care 
>> of devices which violate a standard again requires some strong 
>> evidence to justify it.
>>
>> So no, from where I sit I have not seen a clear explanation of the 
>> value for PSP.
>>
>>>> Cc: [email-masked]; [email-masked]'; 
>>>> draft-ietf-spring-srv6-network-programming
>>>> Subject: Re: [spring] WGLC - 
>>>> draft-ietf-spring-srv6-network-programming
>>>>
>>>> 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?
>>>>
>>>> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spring/or8086G4iYfee5_Icw4PnhkPLBo/__;!!NEt6yMaO-gk!R8IpdFJzyoCo7yckOzOPMieJAOSnyq5AODMxwdW0b6iuYAtn0aGSZEOQCsdZKzc2$ ):
>>>>
>>>> ---- cut here ----
>>>> 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"
>>>> 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 ----
>>>>
>>>>
>>> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/sp
>>> ring/ErcErN39RIlzkL5SKNVAeEWpnAI/__;!!NEt6yMaO-gk!R8IpdFJzyoCo7yckOz
>>> OPMieJAOSnyq5AODMxwdW0b6iuYAtn0aGSZEOQCqGhzAlS$
>>>
>>> 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://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/sp
>>> ring/CMSX7ijacRdG8qHlla61ylJNggo/__;!!NEt6yMaO-gk!R8IpdFJzyoCo7yckOz
>>> OPMieJAOSnyq5AODMxwdW0b6iuYAtn0aGSZEOQCsnVf_mA$
>>>
>>>
>>>>> 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.
>>>>>
>>>>> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/
>>>>> spring/67ZG76XRezPXilsP3x339rGpcso/__;!!NEt6yMaO-gk!R8IpdFJzyoCo7y
>>>>> ckOzOPMieJAOSnyq5AODMxwdW0b6iuYAtn0aGSZEOQCqR0ymms$
>>>>> [2]
>>>>> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/
>>>>> spring/plidxjZFBnd4_mEzGsLC76FZmQ0/__;!!NEt6yMaO-gk!R8IpdFJzyoCo7y
>>>>> ckOzOPMieJAOSnyq5AODMxwdW0b6iuYAtn0aGSZEOQCkr-7fYe$
>>>>> [3]
>>>>> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/
>>>>> spring/uBYpxPyyBY6bb86Y2iCh3jSIKBc/__;!!NEt6yMaO-gk!R8IpdFJzyoCo7y
>>>>> ckOzOPMieJAOSnyq5AODMxwdW0b6iuYAtn0aGSZEOQCizDGW--$
>>>>>
>>>>>> 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.
>>>>>>
>>>>>> 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://urldefense.com/v3/__https://tools.ietf.org/html/draft-iet
>>>>>> f-spring-srv6-network-programming-05__;!!NEt6yMaO-gk!R8IpdFJzyoCo
>>>>>> 7yckOzOPMieJAOSnyq5AODMxwdW0b6iuYAtn0aGSZEOQCvuKcbMU$
>>>>>>
>>>>>> _________________________________________________________________
>>>>>> ________________________________________________________
>>>>>>
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>>
>>>>>>
>>>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo
>>>>>> /spring__;!!NEt6yMaO-gk!R8IpdFJzyoCo7yckOzOPMieJAOSnyq5AODMxwdW0b
>>>>>> 6iuYAtn0aGSZEOQCie_a0dh$
>>>>>>
>>>>>
>>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/
>>>>> spring__;!!NEt6yMaO-gk!R8IpdFJzyoCo7yckOzOPMieJAOSnyq5AODMxwdW0b6i
>>>>> uYAtn0aGSZEOQCie_a0dh$
>>>>> .
>>>>>
>>>>
>>>>
>>>> --
>>>> Fernando Gont
>>>> e-mail: [email-masked] || [email-masked] PGP 
>>>> Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
>>>>
>>>>
>>>>
>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/s
>>>> pring__;!!NEt6yMaO-gk!R8IpdFJzyoCo7yckOzOPMieJAOSnyq5AODMxwdW0b6iuY
>>>> Atn0aGSZEOQCie_a0dh$
>>>
>>> ____________________________________________________________________
>>> _____________________________________________________
>>>
>>> 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.
> ______________________________________________________________________
> ___________________________________________________
> 
> 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://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spri
> ng__;!!NEt6yMaO-gk!R8IpdFJzyoCo7yckOzOPMieJAOSnyq5AODMxwdW0b6iuYAtn0aG
> SZEOQCie_a0dh$
> 

_______________________________________________
spring mailing list
[email-masked]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!R8IpdFJzyoCo7yckOzOPMieJAOSnyq5AODMxwdW0b6iuYAtn0aGSZEOQCie_a0dh$

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 3 Mar 2020 21:10:44 +0100

Hi Ron,

>   MPLS PHP is a clear case of de-encapsulation.

Purely looking at technical aspect that is not true at all.

MPLS PHP does not remove label stack. MPLS PHP is just used to pop last
label. After MPLS PHP packets continue with remaining label stack to the
egress LSR (example L3VPN PE).

>  I don't think that you can compare MPLS PHP with SRv6 PSP

But I agree with that. Both operations have very little in common from
packet's standpoint or forwarding apect. Well maybe except "penultimate"
word :)

Kind regards,
R.

On Tue, Mar 3, 2020 at 8:30 PM Ron Bonica <rbonica=
[email-masked]> wrote:

> Folks,
>
> I don't think that you can compare MPLS PHP with SRv6 PSP. MPLS PHP is a
> clear case of de-encapsulation. We do that all the time. In SRv6 PSP, we
> are removing something from the middle of a packet. That is quite a
> different story.
>
>
>                                                             Ron
>

---

From: Mark Smith <[email-masked]>
Date: Wed, 4 Mar 2020 08:42:01 +1100

Hi Robert,

> Purely looking at technical aspect that is not true at all.

Ron is correct.

> egress LSR (example L3VPN PE).

When an MPLS packet is forwarded through an LSR, with any operation at all
performed on the label stack (including none), is the link layer header
(literally) preserved during that operation?

If the ingress and egress LSR links are both Ethernet, does the LSR ingress
frame's SA and DA match the post LSR processing Ethernet frame's SA and DA?

If you believe they do, how can MPLS work going from an Ethernet link on
one side of an LSR to a PPP (or Frame Relay, etc.) on the other side?
Clearly an Ethernet frame can't travel over a PPP etc. link.

At every MPLS LSR along the LSP the link layer frame is replaced, with new
SA and DA, even if the link layer encapsulation is the same.

The label stack is carried from ingress to egress, possibility modified by
an operation such as pop. However the link layer encapsulation is never
carried "through" the LSR.

PSP as described in SR NP is not the same as PHP in MPLS.

Modelling this operation in RFC 8200 compliant IPv6, there would be
discrete and distinct IPv6 in IPv6 tunnels between each SR router in the SR
domain, and there would not be an Routing Headers in the outer tunnel IPv6
packet. The EH chain ("stack") would be carried been discrete ingress and
egress IPv6 in IPv6 tunnels, possibly modified, however the ingress tunnel
outer header would be replaced at each SR router.

These distinct tunnels between SR routers wouldn't necessarily have to be
preconfigured. If the SR routers are directly link layer attached, then the
outer tunnel header IPv6 addressing could be the mandatory interface Link
Local addresses - which IGPs are already using to identify and track
neighbours.

For SR, there would have to be an EH that carries the SIDs list, however it
would be a Destination Options EH, not a routing header. It would be a
Destination Option because it is processed at the destination addesss of
the outer tunnel header.

Regards,
Mark.

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 3 Mar 2020 22:50:47 +0100

MPLS is not link layer. It is Layer 2.5 if you really want to squeeze it to
OSI.

Regardless of IPv4, IPv6 or MPLS MACs are replaced at each L3 hop - but
that has nothing to do with MPLS PHP. MPLS PHP is the result of LDP
signalling implicit null label from adjacent LSR.

And perhaps it may avoid unnecessary statements if you would read my entire
note :)

Best,
R.

On Tue, Mar 3, 2020 at 10:42 PM Mark Smith <[email-masked]> wrote:

> If the ingress and egress LSR links are both Ethernet, does the LSR
> ingress frame's SA and DA match the post LSR processing Ethernet frame's SA
> and DA?
>
> For SR, there would have to be an EH that carries the SIDs list, however
> it would be a Destination Options EH, not a routing header. It would be a

---

From: Mark Smith <[email-masked]>
Date: Wed, 4 Mar 2020 09:43:19 +1100

On Wed, 4 Mar 2020, 08:50 Robert Raszuk, <[email-masked]> wrote:

> MPLS is not link layer.

I did not say that. I described how MPLS uses link-layers.

It is Layer 2.5 if you really want to squeeze it to OSI.

> Regardless of IPv4, IPv6 or MPLS MACs are replaced at each L3 hop
>

IPv6 is your virtual MAC layer in SR. Then there is a MAC layer below that
IPv6 virtual MAC layer.

You're not thinking about tunnels being virtual links and performing
link-layer operations on them in the context of the upper protocol - MPLS
or SR.

- but that has nothing to do with MPLS PHP. MPLS PHP is the result of LDP
> And perhaps it may avoid unnecessary statements if you would read my
> entire note :)
>

I did.

You don't seem to fully understand the idea of IPv6 being used as a virtual
link layer, and then how an upper IPv6 layer should treat and consider the
lower IPv6 layers.

Clue: the upper IPv6 layer should not be aware that there is an IPv6 "link
layer" below it. There is another link layer below the virtual lower IPv6
link layer, and that is another clue - there isn't always just one one link
layer instance - tunnelling introduces more link-layers, stacked on top of
each other, and that isn't limited to two - you can tunnel inside a tunnel
inside a tunnel. That gets confusing and complicated however once you learn
how to think within a layer, ignoring the others momentarily, it then can
be coped with.

You need to read and consider this Internet Draft. I wish it had existed 20
years ago.

IP Tunnels in the Internet Architecture

https://tools.ietf.org/html/draft-ietf-intarea-tunnels-10

Regards,
Mark.

>> When an MPLS packet is forwarded through an LSR, with any operation at
>> all performed on the label stack (including none), is the link layer header
>> At every MPLS LSR along the LSP the link layer frame is replaced, with
>> new SA and DA, even if the link layer encapsulation is the same.
>>
>> The label stack is carried from ingress to egress, possibility modified
>> by an operation such as pop. However the link layer encapsulation is never
>>>> I don't think that you can compare MPLS PHP with SRv6 PSP. MPLS PHP is
>>>> a clear case of de-encapsulation. We do that all the time. In SRv6 PSP, we

---

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,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 3 Mar 2020 23:59:31 +0100

You are right Mark ... I fully admit I have no clue what so ever about
"IPv6 being a virtual MAC layer in SR" nor " IPv6 being used as a virtual
link layer".

I was only talking about MPLS on which topic I think I still have a little
bit of remaining knowledge.

Thx a lot,
Robert

On Tue, Mar 3, 2020 at 11:43 PM Mark Smith <[email-masked]> wrote:

> You don't seem to fully understand the idea of IPv6 being used as a
> virtual link layer, and then how an upper IPv6 layer should treat and
> consider the lower IPv6 layers.
>
> You need to read and consider this Internet Draft. I wish it had existed
> 20 years ago.
>
>>> These distinct tunnels between SR routers wouldn't necessarily have to
>>> be preconfigured. If the SR routers are directly link layer attached, then
>>> the outer tunnel header IPv6 addressing could be the mandatory interface
>>> Link Local addresses - which IGPs are already using to identify and track
>>> neighbours.
>>>

---

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 3 Mar 2020 18:27:54 -0500

MPLS PHP was invented to solve a particular issue with some forwarding
engines at the time - they couldn't do a final pop followed by an IP lookup
and forward operation in a single forwarding cycle (it would impact
forwarding speed by 50% best case). 20 years later, is this still an issue
at the hardware/firmware level? If so, affected implementers should speak
up, otherwise there's really no need for PSP.

Cheers,
Andy (who was there at the time)

---

From: Mark Smith <[email-masked]>
Date: Wed, 4 Mar 2020 11:10:00 +1100

> "IPv6 being a virtual MAC layer in SR" nor " IPv6 being used as a virtual

I didn't say you had no clue.

Saying things like "MPLS is not link layer." suggests you think I have no
clue, and that makes this conversation a waste of time.

>> IPv6 is your virtual MAC layer in SR. Then there is a MAC layer below
>> that IPv6 virtual MAC layer.
>>
>> Clue: the upper IPv6 layer should not be aware that there is an IPv6
>> "link layer" below it. There is another link layer below the virtual lower
>> IPv6 link layer, and that is another clue - there isn't always just one one
>> link layer instance - tunnelling introduces more link-layers, stacked on
>> top of each other, and that isn't limited to two - you can tunnel inside a
>> tunnel inside a tunnel. That gets confusing and complicated however once
>> you learn how to think within a layer, ignoring the others momentarily, it
>> then can be coped with.
>>
>>>>> MPLS PHP does not remove label stack. MPLS PHP is just used to pop
>>>>> last label. After MPLS PHP packets continue with remaining label stack to
>>>>> the egress LSR (example L3VPN PE).
>>>>>
>>>>
>>>> If you believe they do, how can MPLS work going from an Ethernet link
>>>> on one side of an LSR to a PPP (or Frame Relay, etc.) on the other side?
>>>> For SR, there would have to be an EH that carries the SIDs list,
>>>> however it would be a Destination Options EH, not a routing header. It
>>>> would be a Destination Option because it is processed at the destination
>>>> addesss of the outer tunnel header.
>>>>
>>>>
>>>> Regards,
>>>> Mark.
>>>>
>>>>
>>>>
>>>>>> I don't think that you can compare MPLS PHP with SRv6 PSP. MPLS PHP
>>>>>> is a clear case of de-encapsulation. We do that all the time. In SRv6 PSP,
>>>>>> we are removing something from the middle of a packet. That is quite a
>>>>>> different story.
>>>>>>
>>>>>>
>>>>>>                                                                 Ron
>>>>>>

---

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: "Joel M. Halpern" <[email-masked]>
Date: Wed, 4 Mar 2020 02:09:27 -0500

In this case, it is even less relevant.  The PSP for SRv6 does not 
remove the double-processing.  It merely removes the need to ignore the 
SRH at the ultimate node.

Yours,
Joel

On 3/3/2020 6:27 PM, Andrew G. Malis wrote:
> engines at the time - they couldn't do a final pop followed by an IP 
> lookup and forward operation in a single forwarding cycle (it would 
> impact forwarding speed by 50% best case). 20 years later, is this still 
> an issue at the hardware/firmware level? If so, affected implementers 
> should speak up, otherwise there's really no need for PSP.
> 
> Cheers,
> On Tue, Mar 3, 2020 at 3:11 PM Robert Raszuk <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Hi Ron,
> 
>     last label. After MPLS PHP packets continue with remaining label
>     stack to the egress LSR (example L3VPN PE).
> 
>     But I agree with that. Both operations have very little in common
>     from packet's standpoint or forwarding apect. Well maybe except
>     "penultimate" word :)
> 
>     Kind regards,
>     R.
> 
> 
>     On Tue, Mar 3, 2020 at 8:30 PM Ron Bonica
>     <rbonica=[email-masked]
>     <mailto:[email-masked]>> wrote:
> 
>         Folks,
> 
>         I don't think that you can compare MPLS PHP with SRv6 PSP. MPLS
>         PHP is a clear case of de-encapsulation. We do that all the
>         time. In SRv6 PSP, we are removing something from the middle of
>         a packet. That is quite a different story.
> 
>                                                                         
>                                                                         
>                Ron
> 
>     [email-masked] <mailto:[email-masked]>

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Wed, 4 Mar 2020 07:43:22 +0000

Hi Joel,

I would like to echo the arguments that Bruno has made (and quote part of it) in his summary and then previously on this thread.

QOUTE

UNQOUTE

It’s pure logic!

Please check inline below.

-----Original Message-----
From: spring <[email-masked]> On Behalf Of Joel M. Halpern
Sent: 03 March 2020 21:54
To: [email-masked]; Martin Vigoureux <[email-masked]>; [email-masked]
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

I'm sorry, but "in my gear I want an option to move some work around, so I need a protocol behavior for that" is not usually, in and of itself, enough reason to add an optional feature to a protocol.

[KT] To start with, there are other/more use-cases for PSP as have been discussed on the list over the course of the WGLC and before then. I think you are referring to the use-case that Dan Voyer brought up with legacy hardware - I don't see an issue of being practical and sensitive to real world problems and scenarios. This is what results in actual adoption and deployment success. We have options everywhere - the EH themselves are optional … IIRC HBH options were not so recently made optional out of pure consideration of the actual metal out there in the Internet! 😊

At one point there was an argument that PSP was needed for compliant devices that would not be able to process the packet.  It has been pointed out since that such devices would not comply to 8200 (not because of PSP, but because being able to ignore an exhausted routing header is required in 8200).  Having an optional feature to take care of devices which violate a standard again requires some strong evidence to justify it.

[KT] A device can be conformant with RFC8200 even if were punting the packets for local s/w processing in the presence of an EH (or RH in this case). In that case, it would not be doing line-rate forwarding which is the requirement here. This is again a very practical consideration that is rooted in real world problems and deployments.

So no, from where I sit I have not seen a clear explanation of the value for PSP.

[KT] There have been many use-cases and values expressed for PSP by those that have implemented and deployed it. I can understand if you do not appreciate them. But they are optional and it is unfair to deny it to those who need it.

I also do not understand why the authors have resisted the usual solution to this sort of disagreement, namely moving the feature to a separate document.  Given the structure of the network programming draft, and that it is not exhaustive in either flavors or programming behaviors, there is no violence done to the draft by removing this flavor.

[KT] I think we can go by the track record through the progression of this draft. The contentious topics related to SRH insertion were removed by the authors based on WG feedback and technical arguments – note this was done after it was a WG document. This WGLC has gone beyond the usual timeframe and resulted in unusually large amount of technical discussions. We do see that the document has undergone through multiple changes to improve the text as well as fix certain issues.

So by no stretch of imagination can we say that the authors have been resistant to change when such a change was technically warranted. I do not believe the removal of PSP makes practical and technical sense for those who have implemented and deployed it with real world scenarios in mind.

Thanks,

Ketan

Yours,

Joel

>> From: spring [mailto:[email-masked]] On Behalf Of Fernando

>> Gont

>> To: Martin Vigoureux; [email-masked]<mailto:[email-masked]>

>> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]';

>> Independently of RFC 8200, the question has been raised with regards

>> to the benefit of PSP.

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

> AI/

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

> go/

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

>>> https://mailarchive.ietf.org/arch/msg/spring/67ZG76XRezPXilsP3x339rG

>>> pcso/

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

>>> ZmQ0/

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

>>> IKBc/

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

>>>> duplicating emails on the 6MAN mailing list for the comments which

>>>> are only spring specifics.

>>>> https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programm

>>>> ing-05

>>>> ___________________________________________________________________

>>>> ______________________________________________________

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

>>>> If you have received this email in error, please notify the sender

>>>> and delete this message and its attachments.

>>>> [email-masked]<mailto:[email-masked]>

>>> [email-masked]<mailto:[email-masked]>

>> e-mail: [email-masked]<mailto:[email-masked]> || [email-masked]<mailto:[email-masked]> PGP

>> [email-masked]<mailto:[email-masked]>

spring mailing list

[email-masked]<mailto:[email-masked]>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 4 Mar 2020 02:45:55 -0500

If we really want to say that it takes only one person asking for 
something to put it in a planned RFC, then I guess we have to publish 
all of the competing versions of route headers for v6, since we clealry 
have more than 1 party asking for each variant?
Put differently, no, putting something in because one person asked for 
it (even with the caeat that it appears not to break) is not how the 
IETF generally works.  I do not know where Bruno got that premise, but 
it does not match the history or written policies of the IETF.

Yours,
Joel

On 3/4/2020 2:43 AM, Ketan Talaulikar (ketant) wrote:
> Hi Joel,
> 
> I would like to echo the arguments that Bruno has made (and quote part 
> of it) in his summary and then previously on this thread.
> 
> /QOUTE/
> 
> /The point was related to the usefulness of the optional feature, which 
> has been challenged./
> 
> /I was trying to say the required argumentation to declare usefulness or 
> usefulness is asymmetric, from a logical discussion stand point./
> 
> //
> 
> /a) It only requires one person to find it useful, in order to make the 
> feature useful (for that person)./
> 
> /b) In order to state that this is un-useful,  requires to prove that 
> this is never useful./
> 
> /UNQOUTE/
> 
> It’s pure logic!
> 
> To: [email-masked]; Martin Vigoureux 
> <[email-masked]>; [email-masked]
> */[KT] To start with, there are other/more use-cases for PSP as have 
> been discussed on the list over the course of the WGLC and before then. 
> I think you are referring to the use-case that Dan Voyer brought up with 
> legacy hardware - I don't see an issue of being practical and sensitive 
> to real world problems and scenarios. This is what results in actual 
> adoption and deployment success. We have options everywhere - the EH 
> themselves are optional … IIRC HBH options were not so recently made 
> optional out of pure consideration of the actual metal out there in the 
> Internet! /**/😊/*
> 
> */[KT] A device can be conformant with RFC8200 even if were punting the 
> packets for local s/w processing in the presence of an EH (or RH in this 
> case). In that case, it would not be doing line-rate forwarding which is 
> the requirement here. This is again a very practical consideration that 
> is rooted in real world problems and deployments. /*
> 
> */[KT] There have been many use-cases and values expressed for PSP by 
> those that have implemented and deployed it. I can understand if you do 
> not appreciate them. But they are optional and it is unfair to deny it 
> to those who need it./*
> 
> */[KT] I think we can go by the track record through the progression of 
> this draft. The contentious topics related to SRH insertion were removed 
> by the authors based on WG feedback and technical arguments – note this 
> was done after it was a WG document. This WGLC has gone beyond the usual 
> timeframe and resulted in unusually large amount of technical 
> discussions. We do see that the document has undergone through multiple 
> changes to improve the text as well as fix certain issues. /*
> 
> *//*
> 
> */So by no stretch of imagination can we say that the authors have been 
> resistant to change when such a change was technically warranted. I do 
> not believe the removal of PSP makes practical and technical sense for 
> those who have implemented and deployed it with real world scenarios in 
> mind./*
> 
> *//*
> 
> */Thanks,/*
> 
> */Ketan/*
> 
> Yours,
> 
> Joel
> 
> On 3/3/2020 10:49 AM, [email-masked] 
> <mailto:[email-masked]> wrote:
> 
>  > Fernando
> 
>  >
> 
>  >> To: Martin Vigoureux; [email-masked] <mailto:[email-masked]>
> 
>  >> Cc: [email-masked] <mailto:[email-masked]>; [email-masked]';
> 
>  > 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.
> 
>  >>> Le 2019-12-05 à 18:15, [email-masked] 
> <mailto:[email-masked]> a écrit :
> 
>  >>>> Hello SPRING,
> 
>  >>>>
> 
>  >> e-mail: [email-masked] <mailto:[email-masked]> || 
> [email-masked] <mailto:[email-masked]> PGP
> 
>  > 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.
>

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Wed, 4 Mar 2020 07:49:56 +0000

Hi Joel,

Surely you are exaggerating when you say "one person" asked for something in the context of PSP? 😊

Would you like to clarify? 

And also respond on the real life and practical deployment scenarios and considerations that I've pointed out below? I doubt you meant to just dismissing them without sharing your views?

Thanks,
Ketan

-----Original Message-----
From: Joel M. Halpern <[email-masked]> 
Sent: 04 March 2020 13:16
To: Ketan Talaulikar (ketant) <[email-masked]>; [email-masked]; Martin Vigoureux <[email-masked]>; [email-masked]
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

If we really want to say that it takes only one person asking for something to put it in a planned RFC, then I guess we have to publish all of the competing versions of route headers for v6, since we clealry have more than 1 party asking for each variant?
Put differently, no, putting something in because one person asked for it (even with the caeat that it appears not to break) is not how the IETF generally works.  I do not know where Bruno got that premise, but it does not match the history or written policies of the IETF.

Yours,
Joel

On 3/4/2020 2:43 AM, Ketan Talaulikar (ketant) wrote:
> /The point was related to the usefulness of the optional feature, 
> which has been challenged./
> 
> /I was trying to say the required argumentation to declare usefulness 
> or usefulness is asymmetric, from a logical discussion stand point./
> 
> //
> 
> /a) It only requires one person to find it useful, in order to make 
> the feature useful (for that person)./
> 
> I think you are referring to the use-case that Dan Voyer brought up 
> with legacy hardware - I don't see an issue of being practical and 
> sensitive to real world problems and scenarios. This is what results 
> in actual adoption and deployment success. We have options everywhere 
> - the EH themselves are optional … IIRC HBH options were not so 
> recently made optional out of pure consideration of the actual metal 
> out there in the Internet! /**/😊/*
> 
> */[KT] A device can be conformant with RFC8200 even if were punting 
> the packets for local s/w processing in the presence of an EH (or RH 
> in this case). In that case, it would not be doing line-rate 
> forwarding which is the requirement here. This is again a very 
> practical consideration that is rooted in real world problems and 
> deployments. /*
> 
> those that have implemented and deployed it. I can understand if you 
> do not appreciate them. But they are optional and it is unfair to deny 
> it to those who need it./*
> 
> */[KT] I think we can go by the track record through the progression 
> of this draft. The contentious topics related to SRH insertion were 
> removed by the authors based on WG feedback and technical arguments – 
> note this was done after it was a WG document. This WGLC has gone 
> beyond the usual timeframe and resulted in unusually large amount of 
> technical discussions. We do see that the document has undergone 
> through multiple changes to improve the text as well as fix certain 
> issues. /*
> 
> *//*
> 
> */So by no stretch of imagination can we say that the authors have 
> been resistant to change when such a change was technically warranted. 
> I do not believe the removal of PSP makes practical and technical 
> sense for those who have implemented and deployed it with real world 
> scenarios in
> mind./*
> 
> *//*
> 
> */Thanks,/*
> 
> */Ketan/*
> 
> Yours,
> 
> Joel
> 
> regards
> Judging
>  > 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.
> 
> the
> piece
> not
> email/thread
> informations
> sender
> diffuses,
>  > 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.
> 
>  >
>

---

From: Joel Halpern Direct <[email-masked]>
Date: Wed, 4 Mar 2020 02:55:49 -0500

Bruno's statement, which you chose to quote, was that all it takes is 
for one person to find something useful.  I was responding to what the 
chair said.  It is not true as stated.

Having said that, I agree that more than one person has asked for this. 
But the actual requirement is that there be a coherent and 
understandable explanation of why the feature adds value.  From where I 
sit, I have not seen such an explanation.  It is generally the unbiased 
chair's job to judge whether sufficient explanation has been given.  But 
what Bruno said was not "explanation ... seems sufficient" but rather 
the text you quoted.  Which is not an accurate statement of IETF policy 
or practice.

If there is a claim that there is significant problems on the ultimate 
node for processing the SRH, I would like to see an explanation of how 
an 8200 compliant node would have such problems.  In particular, unlike 
the MPLS case, the presence or absence of an SRH with SL=0 has no effect 
on the number of forwarding lookups that need to be performed.  And 8200 
requires the ability to ignore a routing header with SL=0.

Yours,
Joel

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Wed, 4 Mar 2020 08:27:06 +0000

Hi Joel,

I would not like to misquote Bruno, but his conclusion on this topic was very logical, practical and nuanced (again most likely comes from working with a network operator).

QOUTE

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

UNQOUTE

I don’t believe we need to get into the details of the 18 [1] publicly disclosed (I understand there are more) hardware implementations from multiple vendors to debate the gains from PSP. I don’t believe that is appropriate for an IETF mailing list or pursuant to IETF policy or practice (as you say)?

Again, I like to make the point of how/why HBH processing was made optional based on real world considerations when moving from RFC2460 to RFC8200. So options are good and necessary!

That said, let us turn the tables around.  There is no technical reason for not allowing PSP with SRH – all the ones that have been brought up have been answered and clarified in the text as well as on the mailer. So I fail to understand the resistance of “the other side (including yourself)”.

Therefore, I would suggest we go ahead with the declared Spring WG consensus.

Thanks,

Ketan

[1] https://tools.ietf.org/html/draft-matsushima-spring-srv6-deployment-status-05#section-4.2

-----Original Message-----
From: Joel Halpern Direct <[email-masked]>
Sent: 04 March 2020 13:26
To: Ketan Talaulikar (ketant) <[email-masked]>; [email-masked]; Martin Vigoureux <[email-masked]>; [email-masked]
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

Bruno's statement, which you chose to quote, was that all it takes is for one person to find something useful.  I was responding to what the chair said.  It is not true as stated.

But the actual requirement is that there be a coherent and understandable explanation of why the feature adds value.  From where I sit, I have not seen such an explanation.  It is generally the unbiased chair's job to judge whether sufficient explanation has been given.  But what Bruno said was not "explanation ... seems sufficient" but rather the text you quoted.  Which is not an accurate statement of IETF policy or practice.

If there is a claim that there is significant problems on the ultimate node for processing the SRH, I would like to see an explanation of how an 8200 compliant node would have such problems.  In particular, unlike the MPLS case, the presence or absence of an SRH with SL=0 has no effect on the number of forwarding lookups that need to be performed.  And 8200 requires the ability to ignore a routing header with SL=0.

Yours,

Joel

> Surely you are exaggerating when you say "one person" asked for

> something in the context of PSP? 😊

> From: Joel M. Halpern <[email-masked]<mailto:[email-masked]>>

> To: Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>>;

> [email-masked]<mailto:[email-masked]>; Martin Vigoureux

> <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

>> I would like to echo the arguments that Bruno has made (and quote

>> part of it) in his summary and then previously on this thread.

>> From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of Joel M. Halpern

>> To: [email-masked]<mailto:[email-masked]>; Martin Vigoureux

>> <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

>> do not appreciate them. But they are optional and it is unfair to

>> deny it to those who need it./*

>> On 3/3/2020 10:49 AM, [email-masked]<mailto:[email-masked]>

>>   >> From: spring [mailto:[email-masked]] On Behalf Of

>>   >> To: Martin Vigoureux; [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>

>>   >> Cc: [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>; [email-masked]';

>>   >> As an Area Director, what are your thoughts regarding Bruno's

>> claim

>>   >> that this working group (Spring) doesn't have the necessary

>> skills

>>   >> dependent. It may range anywhere from "not needed" to "required

>> for my platform"

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

>>   >> Doesn't this sound a bit like a group is shipping something that

>> it

>>   > There have been replied and statement from the WG. E.g. From Dan

>> (network operator) & Jingrong (vendor).

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

>> n

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

>> g

>>   > So in the end, what we have is the statement "(1) reduce the load

>> of final destination.".

>>   >>> as I had indicated in a previous message I am the one

>> evaluating

>>   >>> I have carefully read the discussions on the list. I

>> acknowledge

>>   >>> propose an optional capability. Since RFC 8200 is not a product

>> of

>>   >>> the SPRING WG, I have paid specific attention to the messages

>> ([1],

>>   >>> My overall conclusion is that there is support and rough

>> consensus

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

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

>>   >>>> If you are raising a point which you expect will be

>> specifically

>>   >>>> point and that other points get forgotten (or that the thread

>> get

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

>>   >>>> privileged information that may be protected by law; they

>> should

>>   >>>> As emails may be altered, Orange is not liable for messages

>> that

>>   >>>> [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>

>>   >>> [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>

>>   >> e-mail: [email-masked]<mailto:[email-masked]> <mailto:[email-masked]> ||

>> [email-masked]<mailto:[email-masked]> <mailto:[email-masked]> PGP

>>   >> [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>

>> _____________________________________________________________________

>> _

>>   > exploites ou copies sans autorisation. Si vous avez recu ce

>> message

>> [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 4 Mar 2020 03:33:52 -0500

Given that we are talking about the ultimate node, all that it is being 
asked to do is ignore the SRH.  Whether it ignores it because it uses 
the option 8200 permits to ignore things which are understood, or 
ignores it because SL=0, it is required to be able to ignore it.
In either the encapsulated case or the native termination case, the 
result of ignoring it is that the proper things will happen.  The IP 
header will be removed, and what is enclosed will be processed.  (In the 
native case, the upper layer header.  In the encapsulated case, the 
inner header.)

So I am still confused as to what the advantage to any node is of doing 
more work in the preceding node, work that is much more than the act of 
ignoring the header in the final node.  The SRH removal does not remove 
the expensive part of the work, namely the need to decapsulate and 
process the inner header.

Yours,
Joel

On 3/4/2020 3:27 AM, Ketan Talaulikar (ketant) wrote:
> Hi Joel,
> 
> I would not like to misquote Bruno, but his conclusion on this topic was 
> very logical, practical and nuanced (again most likely comes from 
> working with a network operator).
> 
> /QOUTE/
> 
> /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" 
> vendor), with possible intermediate points along _"n% packet processing 
> gain", or "required when combined with a specific other feature"_. I 
> hardware knowledge, lack of detailed information on the hardwares). The 
> fact that this has been implemented by some platforms and deployed by 
> some operators, is, to me, an indication that it is useful for those 
> cases. (I believe that an English proverb is *"the proof of the pudding 
> is in the eating"*. Although I'm certainly missing part of its meaning 
> and culture, in it's literal reading, it seems to apply)./
> 
> /UNQOUTE/
> 
> I don’t believe we need to get into the details of the 18 [1] publicly 
> disclosed (I understand there are more) hardware implementations from 
> multiple vendors to debate the gains from PSP. I don’t believe that is 
> appropriate for an IETF mailing list or pursuant to IETF policy or 
> practice (as you say)?
> 
> Again, I like to make the point of how/why HBH processing was made 
> optional based on real world considerations when moving from RFC2460 to 
> RFC8200. So options are good and necessary!
> 
> That said, let us turn the tables around.  There is no technical reason 
> for not allowing PSP with SRH – all the ones that have been brought up 
> have been answered and clarified in the text as well as on the mailer. 
> So I fail to understand the resistance of “the other side (including 
> yourself)”.
> 
> https://tools.ietf.org/html/draft-matsushima-spring-srv6-deployment-status-05#section-4.2
> 
> To: Ketan Talaulikar (ketant) <[email-masked]>; 
> [email-masked]; Martin Vigoureux 
>  > And also respond on the real life and practical deployment scenarios 
> and considerations that I've pointed out below? I doubt you meant to 
> just dismissing them without sharing your views?
> 
>  >
> 
>  > Thanks,
> 
>  > Ketan
> 
>  >
> 
>  > From: Joel M. Halpern <[email-masked] <mailto:[email-masked]>>
> 
>  > [email-masked] <mailto:[email-masked]>; Martin 
> Vigoureux
> 
>  > <[email-masked] <mailto:[email-masked]>>; 
>  > Put differently, no, putting something in because one person asked 
> for it (even with the caeat that it appears not to break) is not how the 
>  >> From: spring <[email-masked] 
> <mailto:[email-masked]>> On Behalf Of Joel M. Halpern
> 
>  >> To: [email-masked] <mailto:[email-masked]>; 
> Martin Vigoureux
> 
>  >> <[email-masked] <mailto:[email-masked]>>; 
> <mailto:[email-masked]>
> 
>  >>   > Fernando
>  >>   >
>  >>   >> From: spring [mailto:[email-masked]] On Behalf Of
> 
>  >> Fernando
> 
>  >>
> 
>  >>   >> Gont
> 
>  >>
> 
>  >>   >> Sent: Monday, March 2, 2020 9:23 PM
> 
>  >>
> 
>  >>   >> To: Martin Vigoureux; [email-masked] <mailto:[email-masked]> 
> <mailto:[email-masked]>
> 
>  >>
> 
>  >>   >> Cc: [email-masked] <mailto:[email-masked]> 
> <mailto:[email-masked]>; [email-masked]';
> 
>  >>
> 
>  >>   >> draft-ietf-spring-srv6-network-programming
> 
>  >>
> 
>  >>   >> Subject: Re: [spring] WGLC -
> 
>  >>
> 
>  >>   >> draft-ietf-spring-srv6-network-programming
> 
>  >>
> 
>  >>   >>
> 
>  >>
> 
>  >>   >> 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
> 
>  >>
> 
>  >>   >>
> 
>  >> 
>  >>   >>
>  >>   >> ---- 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?
> 
>  >>
> 
>  >>   >
> 
>  >>
> 
>  >>   >
> 
>  >>
> 
>  >>   > There have been replied and statement from the WG. E.g. From Dan
> 
>  >>   >
>  >>   > AI/
>  >>   >
>  >>   > My comment is that a statement such as "(1) reduce the load of
> 
>  >>   > 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
> 
>  >>   >
>  >>   > go/
>  >>   >
>  >>   >
>  >>   > So in the end, what we have is the statement "(1) reduce the load
> 
>  >> of final destination.".
> 
>  >>
> 
>  >>   >
> 
>  >>
> 
>  >>   > Thanks,
> 
>  >>
> 
>  >>   > --Bruno
> 
>  >>
> 
>  >>   >
> 
>  >>
> 
>  >>   >> Thanks,
> 
>  >>
> 
>  >>   >> Fernando
> 
>  >>
> 
>  >>   >>
> 
>  >>
> 
>  >>   >>
> 
>  >>
> 
>  >>   >>
> 
>  >>
> 
>  >>   >>
> 
>  >>
> 
>  >>   >> On 2/3/20 15:53, Martin Vigoureux wrote:
> 
>  >>
> 
>  >>   >>> 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]
> 
>  >>
> 
>  >>   >>>
> 
>  >>   >>> pcso/
>  >>   >>> [2]
>  >>   >>>
>  >>   >>> ZmQ0/
>  >>   >>> [3]
>  >>   >>>
>  >>   >>> IKBc/
>  >>   >>>
>  >>   >>> Le 2019-12-05 à 18:15, [email-masked] 
> <mailto:[email-masked]>
> 
>  >>   >>>> 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]
> 
>  >>
> 
>  >>   >>>>
> 
>  >>   >>>> ing-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.
> 
>  >>
> 
>  >>   >>>>
> 
>  >>
> 
>  >>   >>>>
> 
>  >>
> 
>  >>   >>>>
> 
>  >>
> 
>  >>   >>>> _______________________________________________
> 
>  >>
> 
>  >>   >>>> spring mailing list
> 
>  >>
> 
>  >>   >>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
> 
>  >>
> 
>  >>   >>>> https://www.ietf.org/mailman/listinfo/spring
> 
>  >>
> 
>  >>   >>>>
> 
>  >>
> 
>  >>   >>>
> 
>  >>
> 
>  >>   >>> _______________________________________________
> 
>  >>
> 
>  >>   >>> spring mailing list
> 
>  >>
> 
>  >>   >>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
> 
>  >>
> 
>  >>   >>> https://www.ietf.org/mailman/listinfo/spring
> 
>  >>
> 
>  >>   >>> .
> 
>  >>
> 
>  >>   >>>
> 
>  >>
> 
>  >>   >>
> 
>  >>
> 
>  >>   >>
> 
>  >>
> 
>  >>   >> --
> 
>  >>
> 
>  >>   >> Fernando Gont
> 
>  >>
> 
>  >>   >> e-mail: [email-masked] <mailto:[email-masked]> 
> <mailto:[email-masked]> ||
> 
>  >> [email-masked] <mailto:[email-masked]> 
> <mailto:[email-masked]> PGP
> 
>  >>
> 
>  >>   >> Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
> 
>  >>
> 
>  >>   >>
> 
>  >>
> 
>  >>   >>
> 
>  >>
> 
>  >>   >>
> 
>  >>
> 
>  >>   >> _______________________________________________
> 
>  >>
> 
>  >>   >> spring mailing list
> 
>  >>
> 
>  >>   >> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
> 
>  >>
> 
>  >>   >> https://www.ietf.org/mailman/listinfo/spring
> 
>  >>
> 
>  >>   >
> 
>  >>
> 
>  >>   >
> 
>  >>   > ___________________________________________________
> 
>  >>
> 
>  >>   >
> 
>  >>
> 
>  >>   > 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
> 
>  >>   >
>  >>   > This message and its attachments may contain confidential or
> 
>  >>
> 
>  >>   > privileged information that may be protected by law; they should
> 
>  >>   > If you have received this email in error, please notify the
> 
>  >>   > As emails may be altered, Orange is not liable for messages that
> 
>  >>   > Thank you.
>  >>   >
>  >> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
> 
>  >>
>

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Wed, 4 Mar 2020 09:01:03 +0000

Hi Joel,

Both PSP and the non-PSP flavours are resulting in "proper things".

At this point, it seems to me that we are going in circles. You are repeating your arguments for "Why" while not responding to "Why not". I believe the latter is more important. We could just agree to disagree.

Thanks,
Ketan

-----Original Message-----
From: Joel M. Halpern <[email-masked]> 
Sent: 04 March 2020 14:04
To: Ketan Talaulikar (ketant) <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

Given that we are talking about the ultimate node, all that it is being asked to do is ignore the SRH.  Whether it ignores it because it uses the option 8200 permits to ignore things which are understood, or ignores it because SL=0, it is required to be able to ignore it.
In either the encapsulated case or the native termination case, the result of ignoring it is that the proper things will happen.  The IP header will be removed, and what is enclosed will be processed.  (In the native case, the upper layer header.  In the encapsulated case, the inner header.)

So I am still confused as to what the advantage to any node is of doing more work in the preceding node, work that is much more than the act of ignoring the header in the final node.  The SRH removal does not remove the expensive part of the work, namely the need to decapsulate and process the inner header.

Yours,
Joel

On 3/4/2020 3:27 AM, Ketan Talaulikar (ketant) wrote:
> Hi Joel,
> 
> I would not like to misquote Bruno, but his conclusion on this topic 
> was very logical, practical and nuanced (again most likely comes from 
> vendor), with possible intermediate points along _"n% packet 
> feature"_. I don't think that the SPRING WG can really evaluate this 
> point (lack of hardware knowledge, lack of detailed information on the 
> hardwares). The fact that this has been implemented by some platforms 
> and deployed by some operators, is, to me, an indication that it is 
> useful for those cases. (I believe that an English proverb is *"the 
> proof of the pudding is in the eating"*. Although I'm certainly 
> missing part of its meaning and culture, in it's literal reading, it 
> seems to apply)./
> 
> /UNQOUTE/
> 
> optional based on real world considerations when moving from RFC2460 
> to RFC8200. So options are good and necessary!
> 
> That said, let us turn the tables around.  There is no technical 
> reason for not allowing PSP with SRH – all the ones that have been 
> brought up have been answered and clarified in the text as well as on the mailer.
> understandable explanation of why the feature adds value.  From where 
> I sit, I have not seen such an explanation.  It is generally the 
> unbiased chair's job to judge whether sufficient explanation has been 
> given.  But what Bruno said was not "explanation ... seems sufficient" 
> but rather the text you quoted.  Which is not an accurate statement of 
> IETF policy or practice.
> 
> an 8200 compliant node would have such problems.  In particular, 
> unlike the MPLS case, the presence or absence of an SRH with SL=0 has 
> no effect on the number of forwarding lookups that need to be 
> performed.  And 8200 requires the ability to ignore a routing header with SL=0.
> 
> Yours,
> 
> Joel
> 
>  > And also respond on the real life and practical deployment 
> scenarios and considerations that I've pointed out below? I doubt you 
> meant to just dismissing them without sharing your views?
> 
>  >
> 
>  > Thanks,
> 
>  > Ketan
> 
>  >
> 
>  > [email-masked] <mailto:[email-masked]>; 
> Martin Vigoureux
> 
> all of the competing versions of route headers for v6, since we 
> clealry have more than 1 party asking for each variant?
> 
> for it (even with the caeat that it appears not to break) is not how 
> the IETF generally works.  I do not know where Bruno got that premise, 
> but it does not match the history or written policies of the IETF.
> 
>  >
> 
>  > Yours,
> 
>  > Joel
> 
>  >
> 
>  >>   >> To: Martin Vigoureux; [email-masked] 
> <mailto:[email-masked]> <mailto:[email-masked]>
> 
>  >>
>

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 4 Mar 2020 09:39:08 +0000

Joel, Andy and all,
FWIW I concur with your positions regarding comparison between PHP in MPLS and PSP in SRv6.

I would also like to stress that, to the best of my understanding,  in MPLS PHP is a local behavior between the penultimate and ultimate nodes with the ultimate node explicitly requesting it and the penultimate one giving the option to agree (i.e.to pop the top label when forwarding the packet) or disagree (and to swap the top label to Explicit NULL). The head-end node (and the rest of the nodes on the path) remain completely ignorant of this behavior. I.e., PHP has been introduced - and remains - truly optional.

I have not seen any specifications that would allow the tail-end node of an SRv6 path that wants to benefit from PSP to explicitly request this behavior from the penultimate one, nor do I see would the penultimate node that cannot support PSP do if requested to perform it.  The suggestions I have seen that it would be up to the head-end node (that inserts the SRH) to indicate that PSP is requested - on behalf of the tail-end node? -  look problematic to me as well.

My 2c,
Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   [email-masked]

-----Original Message-----
From: spring <[email-masked]> On Behalf Of Joel M. Halpern
Sent: Wednesday, March 4, 2020 9:09 AM
To: Andrew G. Malis <[email-masked]>
Cc: [email-masked]; Martin Vigoureux <[email-masked]>
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

In this case, it is even less relevant.  The PSP for SRv6 does not remove the double-processing.  It merely removes the need to ignore the SRH at the ultimate node.

Yours,
Joel

On 3/3/2020 6:27 PM, Andrew G. Malis wrote:
> impact forwarding speed by 50% best case). 20 years later, is this 
> still an issue at the hardware/firmware level? If so, affected 
> implementers should speak up, otherwise there's really no need for PSP.
> 
> Cheers,
> https://clicktime.symantec.com/3HYxrbBRUMaCG5VTr1FEMZ96H2?u=https%3A%2
> F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
> 

_______________________________________________
spring mailing list
[email-masked]
https://clicktime.symantec.com/3HYxrbBRUMaCG5VTr1FEMZ96H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring

___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is 
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this 
transmission in error, please inform us by e-mail, phone or fax, and then delete the original 
and all copies thereof.
___________________________________________________________________________

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Wed, 4 Mar 2020 09:48:33 +0000

Hi Sasha,

There is the signalling from the "tail-end node" in SRv6 as well. Perhaps you missed https://tools.ietf.org/html/draft-ietf-lsr-isis-srv6-extensions-06#section-4.4 ?

Thanks,
Ketan

-----Original Message-----
From: spring <[email-masked]> On Behalf Of Alexander Vainshtein
Sent: 04 March 2020 15:09
To: Joel M. Halpern <[email-masked]>; Andrew G. Malis <[email-masked]>
Cc: [email-masked]; Martin Vigoureux <[email-masked]>
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

Joel, Andy and all,

My 2c,
Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

-----Original Message-----
From: spring <[email-masked]> On Behalf Of Joel M. Halpern
Sent: Wednesday, March 4, 2020 9:09 AM
To: Andrew G. Malis <[email-masked]>
Cc: [email-masked]; Martin Vigoureux <[email-masked]>
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

Yours,
Joel

This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.
___________________________________________________________________________
_______________________________________________
spring mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/spring

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 4 Mar 2020 10:10:30 +0000

Ketan,

Lots of thanks for the pointer.

Here is the text I have found at this reference:

4.4<https://tools.ietf.org/html/draft-ietf-lsr-isis-srv6-extensions-06#section-4.4>.  Maximum End D MSD Type

   The Maximum End D MSD Type specifies the maximum number of SIDs in an

   SRH when performing decapsulation associated with "End.Dx" behaviors

   (e.g., "End.DX6" and "End.DT6") as defined in

   [I-D.ietf-spring-srv6-network-programming<https://tools.ietf.org/html/draft-ietf-lsr-isis-srv6-extensions-06#ref-I-D.ietf-spring-srv6-network-programming>].

   SRH Max End D Type: 45 (Suggested value - to be assigned by IANA)

   If the advertised value is zero or no value is advertised

   then it is assumed that the router cannot apply

   "End.DX6" or "End.DT6" behaviors if the outer IPv6 header contains an SRH.

I assume that you have actually referred to the highlighted text in this section – is this correct?

If this is correct then, to the best of my understanding:

1.       The request for PSP (expressed as inability to process the SRH and to perform certain lookup by the originator of an SID) is global and not local between the originator and the penultimate node

2.       It is not clear what the penultimate router that has received such a request but cannot implement it is supposed to do.

My 2c,

Sasha

Office: +972-39266302

Cell:      +972-549266302

-----Original Message-----
From: Ketan Talaulikar (ketant) <[email-masked]>
Sent: Wednesday, March 4, 2020 11:49 AM
To: Alexander Vainshtein <[email-masked]>; Joel M. Halpern <[email-masked]>; Andrew G. Malis <[email-masked]>
Cc: [email-masked]; Martin Vigoureux <[email-masked]>
Subject: RE: [spring] WGLC - draft-ietf-spring-srv6-network-programming

Hi Sasha,

There is the signalling from the "tail-end node" in SRv6 as well. Perhaps you missed https://clicktime.symantec.com/3Fjd1GocprnmRnQ68mT2Nv46H2?u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-lsr-isis-srv6-extensions-06%23section-4.4 ?

Thanks,

Ketan

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

From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of Alexander Vainshtein

To: Joel M. Halpern <[email-masked]<mailto:[email-masked]>>; Andrew G. Malis <[email-masked]<mailto:[email-masked]>>

Cc: [email-masked]<mailto:[email-masked]>; Martin Vigoureux <[email-masked]<mailto:[email-masked]>>

Joel, Andy and all,

My 2c,

Regards,

Sasha

Office: +972-39266302

Cell:      +972-549266302

Email:   [email-masked]<mailto:[email-masked]>

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

To: Andrew G. Malis <[email-masked]<mailto:[email-masked]>>

Cc: [email-masked]<mailto:[email-masked]>; Martin Vigoureux <[email-masked]<mailto:[email-masked]>>

Yours,

Joel

> https://clicktime.symantec.com/3HYxrbBRUMaCG5VTr1FEMZ96H2?u=https%3A%2<https://clicktime.symantec.com/3HYxrbBRUMaCG5VTr1FEMZ96H2?u=https%3A%252>

spring mailing list

spring mailing list

https://clicktime.symantec.com/3GkRJLpXrP2pY9W9t8khQDB6H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Wed, 4 Mar 2020 10:17:45 +0000

Hi Sasha,

From: Alexander Vainshtein <[email-masked]>
Sent: 04 March 2020 15:41
To: Ketan Talaulikar (ketant) <[email-masked]>
Cc: [email-masked]; Martin Vigoureux <[email-masked]>; Joel M. Halpern <[email-masked]>; Andrew G. Malis <[email-masked]>
Subject: RE: [spring] WGLC - draft-ietf-spring-srv6-network-programming

Ketan,

[KT] This is correct.

  1.  It is not clear what the penultimate router that has received such a request but cannot implement it is supposed to do.

[KT] This is not a request to the penultimate SR Endpoint Node. The source SR Node explicitly instructs the penultimate SR Endpoint Node when it wants it do PSP operation. A router which does not support PSP operation (i.e. does not advertise SIDs with those flavors), then the source SR Node will not be able to instruct it to do PSP. Ultimately the SR Source Node decides.

Thanks,

Ketan

My 2c,

Sasha

Office: +972-39266302

Cell:      +972-549266302

-----Original Message-----
From: Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, March 4, 2020 11:49 AM
To: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>; Joel M. Halpern <[email-masked]<mailto:[email-masked]>>; Andrew G. Malis <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Martin Vigoureux <[email-masked]<mailto:[email-masked]>>
Subject: RE: [spring] WGLC - draft-ietf-spring-srv6-network-programming

Hi Sasha,

Thanks,

Ketan

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

Joel, Andy and all,

My 2c,

Regards,

Sasha

Office: +972-39266302

Cell:      +972-549266302

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

Yours,

Joel

spring mailing list

spring mailing list

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 4 Mar 2020 11:37:07 +0100

Hi Ketan,

Let's assume following scenario:

                      ----- T1
                     |
A ----  Z ----  P ---- T2
                    |
                      ----- T3

A - is ingress
P - is potential PSP performer
Ts - are egress (from SR pov)

Q1:

Assume T1 and T3 signal capability to handle SRH depth = 4 and T2 = 2
Assume P signals PSP = 5 for SID P
SRH depth required is 3

How does A can build SRH for all three SR paths to do PSP only to node T2 ?

sub-Q1:  Is it legal today to signal by P two SIDs one with PSP depth
supported = N and the other with depth = 0 ?

Q2:

Assume T1, T2 and T3 signal capability to handle SRH depth = 4
Assume P signals PSP = 5 for SID P
SRH depth required is 3

How can A build SRH such that PSP will happen only for very fat flows ?

Q3:

Assume T1, T2 and T3 signal capability to handle SRH depth = 2
Assume P signals PSP = 0
SRH depth required is 3

Would A not be able to insert SRH and do any SR in this case ?

Many thx,
R.

On Wed, Mar 4, 2020 at 11:17 AM Ketan Talaulikar (ketant) <ketant=
[email-masked]> wrote:

> *From:* Alexander Vainshtein <[email-masked]>
> *Sent:* 04 March 2020 15:41
> *To:* Ketan Talaulikar (ketant) <[email-masked]>
> *Cc:* [email-masked]; Martin Vigoureux <[email-masked]>;
> Joel M. Halpern <[email-masked]>; Andrew G. Malis <[email-masked]>
> *Subject:* RE: [spring] WGLC - draft-ietf-spring-srv6-network-programming
>
>
>
> Ketan,
>
> 4.4
> <https://tools.ietf.org/html/draft-ietf-lsr-isis-srv6-extensions-06#section-4.4>.
> Maximum End D MSD Type
>
>
>
>
>
>    [I-D.ietf-spring-srv6-network-programming <https://tools.ietf.org/html/draft-ietf-lsr-isis-srv6-extensions-06#ref-I-D.ietf-spring-srv6-network-programming>].
>
>
>
>    1. The request for PSP (expressed as inability to process the SRH and
>    to perform certain lookup by the originator of an SID) is global and not
>    local between the originator and the penultimate node
>
> *[KT] This is correct.*
>
>    1. It is not clear what the penultimate router that has received such
>    a request but cannot implement it is supposed to do.
>
> *[KT] This is not a request to the penultimate SR Endpoint Node. The
> source SR Node explicitly instructs the penultimate SR Endpoint Node when
> it wants it do PSP operation. A router which does not support PSP operation
> (i.e. does not advertise SIDs with those flavors), then the source SR Node
> will not be able to instruct it to do PSP. Ultimately the SR Source Node
> decides.*
>
>
>
> *Thanks,*
>
> *Ketan*
>
>
>
> My 2c,
>
> Sasha
>
>
>
> Office: +972-39266302
>
> Cell:      +972-549266302
>
> To: Alexander Vainshtein <[email-masked]>; Joel M.
> Halpern <[email-masked]>; Andrew G. Malis <[email-masked]>
> There is the signalling from the "tail-end node" in SRv6 as well. Perhaps
> you missed
> https://clicktime.symantec.com/3Fjd1GocprnmRnQ68mT2Nv46H2?u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-lsr-isis-srv6-extensions-06%23section-4.4
> ?
>
>
>
> Thanks,
>
> Ketan
>
>
>
> I would also like to stress that, to the best of my understanding,  in
> MPLS PHP is a local behavior between the penultimate and ultimate nodes
> with the ultimate node explicitly requesting it and the penultimate one
> giving the option to agree (i.e.to pop the top label when forwarding the
> packet) or disagree (and to swap the top label to Explicit NULL). The
> head-end node (and the rest of the nodes on the path) remain completely
> ignorant of this behavior. I.e., PHP has been introduced - and remains -
> truly optional.
>
>
>
> I have not seen any specifications that would allow the tail-end node of
> an SRv6 path that wants to benefit from PSP to explicitly request this
> behavior from the penultimate one, nor do I see would the penultimate node
> that cannot support PSP do if requested to perform it.  The suggestions I
> have seen that it would be up to the head-end node (that inserts the SRH)
> to indicate that PSP is requested - on behalf of the tail-end node? -  look
> problematic to me as well.
>
>
>
> My 2c,
>
> Regards,
>
> Sasha
>
>
>
> Office: +972-39266302
>
> Cell:      +972-549266302
>
> In this case, it is even less relevant.  The PSP for SRv6 does not remove
> the double-processing.  It merely removes the need to ignore the SRH at the
> ultimate node.
>
>
>
> Yours,
>
> Joel
>
>
>
> > <mailto:[email-masked] <[email-masked]>>> wrote:
>
> >
>
> >     Hi Ron,
>
> >
>
> >     <mailto:[email-masked] <[email-masked]>>>
> wrote:
>
> >
>
> >         Folks,
>
> >
>
> >     [email-masked] <mailto:[email-masked] <[email-masked]>>
>
> >
>
> <https://clicktime.symantec.com/3HYxrbBRUMaCG5VTr1FEMZ96H2?u=https%3A%252>
>
> This e-mail message is intended for the recipient only and contains
> information which is CONFIDENTIAL and which may be proprietary to ECI
> Telecom. If you have received this transmission in error, please inform us
> by e-mail, phone or fax, and then delete the original and all copies
> thereof.
>

---

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 date: Monday, 2 March 2020 at 22:48

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

    Regards,

    Mark.

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Wed, 4 Mar 2020 11:01:07 +0000

Hi Robert,

From: Robert Raszuk <[email-masked]>
Sent: 04 March 2020 16:07
To: Ketan Talaulikar (ketant) <[email-masked]>
Cc: Alexander Vainshtein <[email-masked]>; [email-masked]
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

Hi Ketan,

                      ----- T1
                     |
A ----  Z ----  P ---- T2
                    |
                      ----- T3

A - is ingress

Q1:

sub-Q1:  Is it legal today to signal by P two SIDs one with PSP depth supported = N and the other with depth = 0 ?
[KT] The MSD support is advertised at node level. The node P can advertise say two End SID – one with PSP and another without it. The SR Source Node picks up which of the two End SIDs to pick based on the capabilities of the egress nodes. Ultimately, the SR Source Node A decides and instructs P what it needs to do for each of the 3 paths.

Q2:

How can A build SRH such that PSP will happen only for very fat flows ?
[KT] As in the previous example, A can make a choice on a per flow basis by picking up the PSP or non-PSP flavor of P’s SIDs.

Q3:

Would A not be able to insert SRH and do any SR in this case ?
[KT] Yes, A cannot generate a packet with SRH with 3 segments destined to the T nodes in such a case.

Thanks,
Ketan

Many thx,
R.

On Wed, Mar 4, 2020 at 11:17 AM Ketan Talaulikar (ketant) <ketant=[email-masked]<mailto:[email-masked]>> wrote:
Hi Sasha,

From: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>
Sent: 04 March 2020 15:41
To: Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>>
Cc: spring@ietf..org<mailto:[email-masked]>; Martin Vigoureux <[email-masked]<mailto:[email-masked]>>; Joel M. Halpern <[email-masked]<mailto:[email-masked]>>; Andrew G. Malis <[email-masked]<mailto:[email-masked]>>
Subject: RE: [spring] WGLC - draft-ietf-spring-srv6-network-programming

Ketan,

   [I-D.ietf-spring-srv6-network-programming<https://tools.ietf.org/html/draft-ietf-lsr-isis-srv6-extensions-06#ref-I-D..ietf-spring-srv6-network-programming>].

[KT] This is correct.

Thanks,

Ketan

My 2c,

Sasha

Office: +972-39266302

Cell:      +972-549266302

-----Original Message-----
From: Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, March 4, 2020 11:49 AM
To: Alexander Vainshtein <[email-masked]<mailto:Alexander.Vainshtein@ecitele..com>>; Joel M. Halpern <[email-masked]<mailto:[email-masked]>>; Andrew G. Malis <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Martin Vigoureux <[email-masked]<mailto:[email-masked]>>
Subject: RE: [spring] WGLC - draft-ietf-spring-srv6-network-programming

Hi Sasha,

Thanks,

Ketan

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

From: spring <spring-bounces@ietf..org<mailto:[email-masked]>> On Behalf Of Alexander Vainshtein

Joel, Andy and all,

I would also like to stress that, to the best of my understanding,  in MPLS PHP is a local behavior between the penultimate and ultimate nodes with the ultimate node explicitly requesting it and the penultimate one giving the option to agree (i.e.to<http://i.e.to> pop the top label when forwarding the packet) or disagree (and to swap the top label to Explicit NULL). The head-end node (and the rest of the nodes on the path) remain completely ignorant of this behavior. I.e., PHP has been introduced - and remains - truly optional.

My 2c,

Regards,

Sasha

Office: +972-39266302

Cell:      +972-549266302

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

From: spring <spring-bounces@ietf..org<mailto:[email-masked]>> On Behalf Of Joel M. Halpern

Yours,

Joel

> On Tue, Mar 3, 2020 at 3:11 PM Robert Raszuk <[email-masked]<mailto:[email-masked]>

>     <rbonica=[email-masked]<mailto:[email-masked]>

> F%2Fwww.ietf.org<http://2Fwww.ietf.org>%2Fmailman%2Flistinfo%2Fspring

spring mailing list

spring mailing list

---

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: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Wed, 4 Mar 2020 12:31:55 +0000

Bruno,

As I announced in my email, the revision -11 aims at addressing the comments related to section 4.16.1 as per your email below.
Today I have posted another revision (-12) that addresses Brian’s editorial comments on that same section. There are no other changes in rev 12. I believe that this finalizes all the editorial comments on this section.

We are also addressing recent comments received. I personally don’t think this will result in a change in the draft, but we can discuss on the mailer.

Regarding your comment on sending diff before publishing: thanks for the hint.

Thanks,
Pablo.

From: "[email-masked]" <[email-masked]>
Date: Tuesday, 3 March 2020 at 14:45
To: "Pablo Camarillo (pcamaril)" <[email-masked]>
Cc: Brian E Carpenter <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: WGLC - draft-ietf-spring-srv6-network-programming

Hi Pablo,

Thank you,
--Bruno

Hi all,

Please read and comment.

Thanks,
Pablo.

Pablo, authors, WG,

Thank you,
--Bruno

Hello SPRING,

Thank you,

Bruno

Thank you.

Thank you.

Thank you.

---

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]

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 4 Mar 2020 14:31:03 +0100

Hi Ketan,

So essentially you are confirming that subject to topology in worst case I
need to double the flooding amount of SIDs in my network to support both
PSP and non PSP operation. I think if we would consider PSP as optional or
on-demand behaviour we could architect it without the need for double
flooding node's SIDs just to indicate in one PSP=0 and in the other one PSP
!=0 (which by itself is still subject to given IGP and SR code even
allowing you to do that).

Thx,
R.

On Wed, Mar 4, 2020 at 12:01 PM Ketan Talaulikar (ketant) <[email-masked]>
wrote:

> *From:* Robert Raszuk <[email-masked]>
> *Sent:* 04 March 2020 16:07
> *Cc:* Alexander Vainshtein <[email-masked]>;
> [email-masked]
> *Subject:* Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming
>
>
>
>
>
> Hi Ketan,
>
>
>
> *[KT] The MSD support is advertised at node level. The node P can
> advertise say two End SID – one with PSP and another without it. The SR
> Source Node picks up which of the two End SIDs to pick based on the
> capabilities of the egress nodes. Ultimately, the SR Source Node A decides
> and instructs P what it needs to do for each of the 3 paths.*
>
>
>
> Q2:
>
>
>
> *[KT] As in the previous example, A can make a choice on a per flow basis
> by picking up the PSP or non-PSP flavor of P’s SIDs.*
>
>
>
> Q3:
>
>
>
> *[KT] Yes, A cannot generate a packet with SRH with 3 segments destined to
> the T nodes in such a case.*
>
>
>
> *Thanks,*
>
> *Ketan*
>
>
>
> Many thx,
>
> R.
>
>
>
>
>
>
>
>
>
> *Cc:* spring@ietf..org <[email-masked]>; Martin Vigoureux <
> [email-masked]>; Joel M. Halpern <[email-masked]>;
> Andrew G. Malis <[email-masked]>
>    [I-D.ietf-spring-srv6-network-programming <https://tools.ietf.org/html/draft-ietf-lsr-isis-srv6-extensions-06#ref-I-D..ietf-spring-srv6-network-programming>].
>
>
>
> To: Alexander Vainshtein <[email-masked]
> <Alexander.Vainshtein@ecitele..com>>; Joel M. Halpern <[email-masked]>;
> Andrew G. Malis <[email-masked]>
> From: spring <spring-bounces@ietf..org <[email-masked]>> On
> Behalf Of Alexander Vainshtein
>
> From: spring <spring-bounces@ietf..org <[email-masked]>> On
> Behalf Of Joel M. Halpern
>
> information which is

---

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

Hi Joel, Ketan,
Let me share my points about the statement "The SRH removal does not remove the expensive part of the work, namely the need to decapsulate and process the inner header."
For the ultimate segment endpoint that is well capable of processing SRH, the statement is true I think. I guess the benefits may be around 50%?
While for the real network, the incremental deployment may be much more important ---- It is determining, from 1(success) to 0(fail) or vice versa!
No matter how good a feature you provided, it just doesn't work on the network with a bunch of PEs that is not capable of SRH, then it is useless.

**Maybe my previously suggested text can be referenced**
This has some very important benefits for deployment in some networks when the
final tunnel end point is a lower-end node which is not capable of processing
the SRH for reasons like the hardware is overloaded or unable to upgraded to
process well with SRH.

In case the final tunnel endpoint router is fully capable of the functionality
of SRH and the SRv6-NP defined in this document, it is recommended not to use
the PSP.
**End for reference**

Thanks
Jingrong

-----Original Message-----
From: spring [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Wednesday, March 4, 2020 4:34 PM
To: Ketan Talaulikar (ketant) <ketant=[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

Yours,
Joel

---

From: Joel Halpern Direct <[email-masked]>
Date: Wed, 4 Mar 2020 08:38:56 -0500

Jingrong, the only "processing" of the SRH required in the ultimate node 
is to ignore it.  Which is required by 8200.

Skipping the SRH is not a 50% performance penalty in any situation.

Yours,
Joel

---

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

Hi Joel,
I guarantee you there is case the performance penalty is more than 90%, only if the box send the IPv6 packet with RH or EH to the slow path (just to be compatible with RFC8200)!
And I think that's common even for not very old box.

Thanks
Jingrong

-----Original Message-----
From: Joel Halpern Direct [mailto:[email-masked]] 
Sent: Wednesday, March 4, 2020 9:39 PM
To: Xiejingrong (Jingrong) <[email-masked]>; [email-masked]
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

Jingrong, the only "processing" of the SRH required in the ultimate node is to ignore it.  Which is required by 8200.

Yours,
Joel

On 3/4/2020 8:36 AM, Xiejingrong (Jingrong) wrote:
> **Maybe my previously suggested text can be referenced** This has some 
> very important benefits for deployment in some networks when the final 
> tunnel end point is a lower-end node which is not capable of 
> processing the SRH for reasons like the hardware is overloaded or 
> unable to upgraded to process well with SRH.
> 
> In case the final tunnel endpoint router is fully capable of the 
> functionality of SRH and the SRv6-NP defined in this document, it is 
> recommended not to use the PSP.
> **End for reference**
> 
> Thanks
> Jingrong
> 
> To: Ketan Talaulikar (ketant) <ketant=[email-masked]>; 
> [email-masked]; [email-masked]
> header will be removed, and what is enclosed will be processed.  (In 
> the native case, the upper layer header.  In the encapsulated case, 
> the inner header.)
> 
>> /My take is that PSP is an _optional data plane optimization_. 
>> Judging its level of usefulness is _very hardware and implementation dependent_.
>> point (lack of hardware knowledge, lack of detailed information on 
>> the hardwares). The fact that this has been implemented by some 
>> platforms and deployed by some operators, is, to me, an indication 
>> that it is useful for those cases. (I believe that an English proverb 
>> is *"the proof of the pudding is in the eating"*. Although I'm 
>> certainly missing part of its meaning and culture, in it's literal 
>> reading, it seems to apply)./
>>
>> /UNQOUTE/
>>
>> I don’t believe we need to get into the details of the 18 [1] 
>> publicly disclosed (I understand there are more) hardware 
>> implementations from multiple vendors to debate the gains from PSP. I 
>> don’t believe that is appropriate for an IETF mailing list or 
>> pursuant to IETF policy or practice (as you say)?
>>
>> https://tools.ietf.org/html/draft-matsushima-spring-srv6-deployment-s
>> t
>> atus-05#section-4.2
>>
>> for one person to find something useful.  I was responding to what 
>> the chair said.  It is not true as stated.
>>
>> but rather the text you quoted.  Which is not an accurate statement 
>> of IETF policy or practice.
>>
>> If there is a claim that there is significant problems on the 
>> ultimate node for processing the SRH, I would like to see an 
>> explanation of how an 8200 compliant node would have such problems.  
>> In particular, unlike the MPLS case, the presence or absence of an 
>> SRH with SL=0 has no effect on the number of forwarding lookups that 
>> need to be performed.  And 8200 requires the ability to ignore a routing header with SL=0.
>>
>> Yours,
>>
>> Joel
>>
>>   > Put differently, no, putting something in because one person 
>> asked for it (even with the caeat that it appears not to break) is 
>> not how the IETF generally works.  I do not know where Bruno got that 
>> premise, but it does not match the history or written policies of the IETF.
>>
>>   >
>>
>>   > Yours,
>>
>>   > Joel
>>
>>   >
>>

---

From: "Wang, Weibin (NSB - CN/Shanghai)" <[email-masked]>
Date: Wed, 4 Mar 2020 13:56:41 +0000

Inline;
From: spring <[email-masked]> On Behalf Of Robert Raszuk
Sent: Wednesday, March 4, 2020 9:31 PM
To: Ketan Talaulikar (ketant) <[email-masked]>
Cc: [email-masked]; Alexander Vainshtein <[email-masked]>
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

Hi Ketan,

So essentially you are confirming that subject to topology in worst case I need to double the flooding amount of SIDs in my network to support both PSP and non PSP operation. I think if we would consider PSP as optional or on-demand behaviour we could architect it without the need for double flooding node's SIDs just to indicate in one PSP=0 and in the other one PSP !=0 (which by itself is still subject to given IGP and SR code even allowing you to do that).

Hi Robert:
In my understanding, one behavior id (16bits) is only correspond to one SID, and the 0 is reserved as defined in SRv6 NPG draft, PSP is flavor and is never used alone.

Thx;
WWB;

Thx,
R.

On Wed, Mar 4, 2020 at 12:01 PM Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Robert,

From: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Sent: 04 March 2020 16:07
To: Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>>
Cc: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

Hi Ketan,

                      ----- T1
                     |
A ----  Z ----  P ---- T2
                    |
                      ----- T3

A - is ingress

Q1:

Q2:

Q3:

Thanks,
Ketan

Many thx,
R.

Cc: spring@ietf...org<mailto:[email-masked]>; Martin Vigoureux <[email-masked]<mailto:[email-masked]>>; Joel M. Halpern <[email-masked]<mailto:[email-masked]>>; Andrew G. Malis <[email-masked]<mailto:[email-masked]>>

Ketan,

   [I-D.ietf-spring-srv6-network-programming<https://tools.ietf.org/html/draft-ietf-lsr-isis-srv6-extensions-06#ref-I-D...ietf-spring-srv6-network-programming>]..

[KT] This is correct.

Thanks,

Ketan

My 2c,

Sasha

Office: +972-39266302

Cell:      +972-549266302

-----Original Message-----
From: Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, March 4, 2020 11:49 AM
To: Alexander Vainshtein <[email-masked]<mailto:Alexander.Vainshtein@ecitele...com>>; Joel M. Halpern <[email-masked]<mailto:[email-masked]>>; Andrew G. Malis <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Martin Vigoureux <[email-masked]<mailto:[email-masked]>>
Subject: RE: [spring] WGLC - draft-ietf-spring-srv6-network-programming

Hi Sasha,

Thanks,

Ketan

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

Joel, Andy and all,

I would also like to stress that, to the best of my understanding,  in MPLS PHP is a local behavior between the penultimate and ultimate nodes with the ultimate node explicitly requesting it and the penultimate one giving the option to agree (i.e.to<http://i..e.to> pop the top label when forwarding the packet) or disagree (and to swap the top label to Explicit NULL). The head-end node (and the rest of the nodes on the path) remain completely ignorant of this behavior. I.e., PHP has been introduced - and remains - truly optional.

My 2c,

Regards,

Sasha

Office: +972-39266302

Cell:      +972-549266302

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

Yours,

Joel

spring mailing list

spring mailing list

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 4 Mar 2020 15:00:36 +0100

Dear WWB,

I think we are talking about the same thing ... behaviour to do or not to
do PSP is embedded into SID. So to have two options you have to have two
SIDs today advertised by IGP.

I am just gently suggesting that to support both you could have algorithmic
option (odd SID - PHP, even SID no PHP) and need to only signal one -
keeping the other one reserved per node but not signalled).

Thx,
R.

On Wed, Mar 4, 2020 at 2:56 PM Wang, Weibin (NSB - CN/Shanghai) <
[email-masked]> wrote:

> Inline;
>
> *From:* spring <[email-masked]> *On Behalf Of *Robert Raszuk
> *Sent:* Wednesday, March 4, 2020 9:31 PM
> *Cc:* [email-masked]; Alexander Vainshtein <
> [email-masked]>
> In my understanding, one behavior id (16bits) is only correspond to one
> SID, and the 0 is reserved as defined in SRv6 NPG draft, PSP is flavor and
> is never used alone.
>
>
>
> Thx;
>
> WWB;
>
>
>
> Thx,
> R.
>
>
>
> On Wed, Mar 4, 2020 at 12:01 PM Ketan Talaulikar (ketant) <
> [email-masked]> wrote:
>
> Hi Robert,
>
>
>
> *Cc:* spring@ietf...org <[email-masked]>; Martin Vigoureux <
>    [I-D.ietf-spring-srv6-network-programming <https://tools.ietf.org/html/draft-ietf-lsr-isis-srv6-extensions-06#ref-I-D...ietf-spring-srv6-network-programming>]..
>
>
>
> <Alexander.Vainshtein@ecitele...com>>; Joel M. Halpern <
> [email-masked]>; Andrew G. Malis <[email-masked]>
> giving the option to agree (i.e.to <http://i..e.to> pop the top label
> when forwarding the packet) or disagree (and to swap the top label to
> Explicit NULL). The head-end node (and the rest of the nodes on the path)
> remain completely ignorant of this behavior. I.e., PHP has been introduced
> - and remains - truly optional.
>
>
>

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 4 Mar 2020 15:01:15 +0100

sorry s/ odd SID - PHP, even SID no PHP/ odd SID - PSP, even SID no PSP/

On Wed, Mar 4, 2020 at 3:00 PM Robert Raszuk <[email-masked]> wrote:

> I am just gently suggesting that to support both you could have
> algorithmic option (odd SID - PHP, even SID no PHP) and need to only signal
> one - keeping the other one reserved per node but not signalled).
>
> Thx,
> R.
>
>> So essentially you are confirming that subject to topology in worst case
>> I need to double the flooding amount of SIDs in my network to support both
>> *[KT] Yes, A cannot generate a packet with SRH with 3 segments destined
>> to the T nodes in such a case.*
>>
>>
>>
>> *Thanks,*
>>
>> *Ketan*
>>
>>
>>
>> Many thx,
>>
>> R.
>>
>>
>>
>>
>>
>>
>>
>>
>>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 4 Mar 2020 09:06:43 -0500

Then don't pretend that box is part of the SR Domain.  It clearly isn't.
Yours,
Joel

---

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: <[email-masked]>
Date: Wed, 4 Mar 2020 17:08:44 +0000

Joel,

> Sent: Wednesday, March 4, 2020 8:56 AM
> To: Ketan Talaulikar (ketant); DECRAENE Bruno TGI/OLN; Martin Vigoureux; [email-masked]

It's very possible that my text was not clear enough.  So I'll point to a different text:

"A negative claim is a colloquialism for an affirmative claim that asserts the non-existence or exclusion of something.[10] The difference with a positive claim is that it takes only a single example to demonstrate such a positive assertion ("there is a chair in this room," requires pointing to a single chair), while the inability to give examples demonstrates that the speaker has not yet found or noticed examples rather than demonstrates that no examples exist (the negative claim that a species is extinct may be disproved by a single surviving example or proven with omniscience)."
https://en.wikipedia.org/wiki/Burden_of_proof_(philosophy)#Proving_a_negative

Coming back to your other argument, it does not mean that the IETF need to include all requirements from every single person.
It was only meant to say that it's difficult to state and prove that PSP is useless.

--Bruno
 
> >> the hardwares).

---

From: Ron Bonica <[email-masked]>
Date: Wed, 4 Mar 2020 20:01:59 +0000

Andy,

AFAIKS, the only use case PSP is to accommodate SRv6 egress nodes that:

  *   Can process an SRv6  SID that appears in the IPv6 Destination Address
  *   Can process the SRH with Segments Left equal to 0
  *   But cannot process the SRH with Segments Left equal to 0 at high speed

I am not aware that any such device exists. Does anybody know of one?

                                                   Ron

From: Andrew G. Malis <[email-masked]>
Sent: Tuesday, March 3, 2020 6:28 PM
To: Robert Raszuk <[email-masked]>
Cc: Ron Bonica <[email-masked]>; [email-masked]; [email-masked]; Joel M. Halpern <[email-masked]>; Martin Vigoureux <[email-masked]>
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

MPLS PHP was invented to solve a particular issue with some forwarding engines at the time - they couldn't do a final pop followed by an IP lookup and forward operation in a single forwarding cycle (it would impact forwarding speed by 50% best case). 20 years later, is this still an issue at the hardware/firmware level? If so, affected implementers should speak up, otherwise there's really no need for PSP.

Cheers,

On Tue, Mar 3, 2020 at 3:11 PM Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:
Hi Ron,

MPLS PHP does not remove label stack. MPLS PHP is just used to pop last label. After MPLS PHP packets continue with remaining label stack to the egress LSR (example L3VPN PE).

>  I don't think that you can compare MPLS PHP with SRv6 PSP

But I agree with that. Both operations have very little in common from packet's standpoint or forwarding apect. Well maybe except "penultimate" word :)

Kind regards,
R.

On Tue, Mar 3, 2020 at 8:30 PM Ron Bonica <rbonica=[email-masked]<mailto:[email-masked]>> wrote:
Folks,

                                                                                                                                      Ron
_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!QEhtnK3a_SkTtK5jFwY7ANmF22RCkp657bAyNJfcGg1xaI_ewfHQHKp7NIgQ3SpI$>

---

From: Ron Bonica <[email-masked]>
Date: Wed, 4 Mar 2020 20:38:53 +0000

Folks,

A WG can set its bar for acceptance anywhere it wants. Some WG's manage technologies where the need to innovation exceeds the need for stability. In those WG's, the bar is appropriately set low. Other WG's manage technologies where the need for stability exceeds the need for innovation. In those WG's, the bar is appropriately set high. That's all good.

However, when a WG moves the bar for unspecified reasons, it becomes dysfunctional. If the bar for PSP is low, the bar for alternative Routing header types should be equally low.

But this is really a topic upon which the AD and WG chair should be speaking. Maybe they want to chime in?

                                                   Ron

-----Original Message-----
From: spring <[email-masked]> On Behalf Of Ketan Talaulikar (ketant)
Sent: Wednesday, March 4, 2020 2:50 AM
To: Joel M. Halpern <[email-masked]>; [email-masked]; Martin Vigoureux <[email-masked]>; [email-masked]
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

Hi Joel,

Thanks,
Ketan

-----Original Message-----
From: Joel M. Halpern <[email-masked]>
Sent: 04 March 2020 13:16
To: Ketan Talaulikar (ketant) <[email-masked]>; [email-masked]; Martin Vigoureux <[email-masked]>; [email-masked]
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

Yours,
Joel

On 3/4/2020 2:43 AM, Ketan Talaulikar (ketant) wrote:
> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spring/or8086G4iYfee5_Icw4PnhkPLBo/__;!!NEt6yMaO-gk!RoMsrLt00PwzObp12rXzsVN1nwNO_r94uSmb4o6oAlGVSAktxykYS4q3oqNE6urz$ ):
> 
>  >>
> 
>  >> ---- cut here ----
> 
> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spri
> ng/ErcErN39RIlzkL5SKNVAeEWpn__;!!NEt6yMaO-gk!RoMsrLt00PwzObp12rXzsVN1n
> wNO_r94uSmb4o6oAlGVSAktxykYS4q3oj3Fz7Ru$
> 
>  > AI/
> 
>  >
> 
> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spri
> ng/CMSX7ijacRdG8qHlla61ylJNg__;!!NEt6yMaO-gk!RoMsrLt00PwzObp12rXzsVN1n
> wNO_r94uSmb4o6oAlGVSAktxykYS4q3omdHTq66$
> 
>  > go/
> 
>  >
> 
>  >
> 
> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spri
> ng/67ZG76XRezPXilsP3x339rG__;!!NEt6yMaO-gk!RoMsrLt00PwzObp12rXzsVN1nwN
> O_r94uSmb4o6oAlGVSAktxykYS4q3ooesyxsd$
> 
>  >>> pcso/
> 
>  >>> [2]
> 
>  >>>
> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spri
> ng/plidxjZFBnd4_mEzGsLC76F__;!!NEt6yMaO-gk!RoMsrLt00PwzObp12rXzsVN1nwN
> O_r94uSmb4o6oAlGVSAktxykYS4q3ouHMfFRe$
> 
>  >>> ZmQ0/
> 
>  >>> [3]
> 
>  >>>
> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spri
> ng/uBYpxPyyBY6bb86Y2iCh3jS__;!!NEt6yMaO-gk!RoMsrLt00PwzObp12rXzsVN1nwN
> O_r94uSmb4o6oAlGVSAktxykYS4q3omdTRgI-$
> 
>  >>> IKBc/
> 
>  >>>
> 
> https://urldefense.com/v3/__https://tools.ietf.org/html/draft-ietf-spr
> ing-srv6-network-programm__;!!NEt6yMaO-gk!RoMsrLt00PwzObp12rXzsVN1nwNO
> _r94uSmb4o6oAlGVSAktxykYS4q3oqs6U8hu$
> 
>  >>>> ing-05
> 
>  >>>>
> 
>  >>>>
> ng__;!!NEt6yMaO-gk!RoMsrLt00PwzObp12rXzsVN1nwNO_r94uSmb4o6oAlGVSAktxyk
> YS4q3ouCAL3e5$
> 
>  >>>>
> 
>  >>>
> 
> ng__;!!NEt6yMaO-gk!RoMsrLt00PwzObp12rXzsVN1nwNO_r94uSmb4o6oAlGVSAktxyk
> YS4q3ouCAL3e5$
> 
>  >>> .
> 
>  >>>
> 
>  >>
> 
>  >>
> 
>  >> --
> 
>  >> Fernando Gont
> 
> ng__;!!NEt6yMaO-gk!RoMsrLt00PwzObp12rXzsVN1nwNO_r94uSmb4o6oAlGVSAktxyk
> YS4q3ouCAL3e5$
> 
>  >
> 
>  >
> ng__;!!NEt6yMaO-gk!RoMsrLt00PwzObp12rXzsVN1nwNO_r94uSmb4o6oAlGVSAktxyk
> YS4q3ouCAL3e5$
> 
_______________________________________________
spring mailing list
[email-masked]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!RoMsrLt00PwzObp12rXzsVN1nwNO_r94uSmb4o6oAlGVSAktxykYS4q3ouCAL3e5$

---

From: Martin Vigoureux <[email-masked]>
Date: Wed, 4 Mar 2020 22:02:25 +0100

WG,

I wanted to bring more context to my decision.

This document has received a lot of valuable reviews and comments which 
improved it. That served me as a base to determine consensus on the 
overall document.

The point I'd like to insist on is the one I was mentioning in my 
previous e-mail. In my view, the remaining prominent discussion (and 
tension) point was about the text of 8200, its implications on the 
optional PSP capability, and the ramifications of it.
I have determined there is rough consensus, in SPRING, on the way to 
read the specific text of 8200, but also that certain aspects go beyond 
SPRING and would benefit from being discussed with a wider community.

I'd like to remind that this was a WG Chair level decision. Indeed, 
Bruno still needs to produce the shepherd write-up and submit the 
document for publication.

Martin

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Wed, 4 Mar 2020 21:21:39 +0000

Hi Ron

I don’t think you are really asking equipment vendors to provide that information on this list.  That will not happen.

I’ll simply repeat what has been stated by others on this list.
Products with limited ability to receive and process a packet containing a RH when SL==0 exist.
PSP provides a means of allowing those products to be used as a PE.

Thanks
  Darren

On Mar 4, 2020, at 3:01 PM, Ron Bonica <rbonica=[email-masked]<mailto:rbonica=[email-masked]>> wrote:

Andy,

                                                   Ron

From: Andrew G. Malis <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, March 3, 2020 6:28 PM
To: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Cc: Ron Bonica <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Joel M. Halpern <[email-masked]<mailto:[email-masked]>>; Martin Vigoureux <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

Cheers,

Kind regards,
R.

                                                                                                                                      Ron

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 4 Mar 2020 16:25:35 -0500

Darren, could you please comment on the behavioral / deployment 
implications I believe I identified in my recent email about the use 
case?  It does seem to me that something needs to be said about the 
implications of the use case.  Yes, we do sometimes make allowances in 
protocol design for deficient but complaint implementations.  But we do 
not pretend that there are not issues when doing so.  And we try to 
identify the needs clearly.

Yours,
Joel

On 3/4/2020 4:21 PM, Darren Dukes (ddukes) wrote:
> Hi Ron
> 
> I don’t think you are really asking equipment vendors to provide that 
> information on this list.  That will not happen.
> 
>> On Mar 4, 2020, at 3:01 PM, Ron Bonica 
>> <mailto:rbonica=[email-masked]>> wrote:
>>
>> Andy,
>> *From:*Andrew G. Malis <[email-masked] <mailto:[email-masked]>>
>> *Sent:*Tuesday, March 3, 2020 6:28 PM
>> *To:*Robert Raszuk <[email-masked] <mailto:[email-masked]>>
>> *Cc:*Ron Bonica <[email-masked] 
>> <mailto:[email-masked]>>;[email-masked] 
>> <mailto:[email-masked]>;[email-masked] 
>> <mailto:[email-masked]>; Joel M. Halpern <[email-masked] 
>> <mailto:[email-masked]>>; Martin Vigoureux 
>> <[email-masked] <mailto:[email-masked]>>
>> *Subject:*Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming
>>         I don't think that you can compare MPLS PHP with SRv6 PSP.
>>         MPLS PHP is a clear case of de-encapsulation. We do that all
>>         the time. In SRv6 PSP, we are removing something from the
>>         middle of a packet. That is quite a different story.
>>
>>                                                                      
>>                                                                      
>>                   Ron
>>
>>     <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!QEhtnK3a_SkTtK5jFwY7ANmF22RCkp657bAyNJfcGg1xaI_ewfHQHKp7NIgQ3SpI$>

---

From: Ron Bonica <[email-masked]>
Date: Wed, 4 Mar 2020 21:33:51 +0000

Darren,

I didn't expect you to provide a model number. Just an indication that such hardware exists.

>From your response, I assume that some vendors offer such hardware.

                                                  Ron

Juniper Business Use Only
From: Darren Dukes (ddukes) <ddukes=[email-masked]>
Sent: Wednesday, March 4, 2020 4:22 PM
To: Ron Bonica <[email-masked]>
Cc: Andrew G. Malis <[email-masked]>; Robert Raszuk <[email-masked]>; [email-masked]; [email-masked]; Joel M. Halpern <[email-masked]>; Martin Vigoureux <[email-masked]>
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

Hi Ron

I don't think you are really asking equipment vendors to provide that information on this list.  That will not happen.

I'll simply repeat what has been stated by others on this list.
Products with limited ability to receive and process a packet containing a RH when SL==0 exist.
PSP provides a means of allowing those products to be used as a PE.

Thanks
  Darren

Andy,

                                                   Ron

Cheers,

Kind regards,
R.

                                                                                                                                      Ron

Juniper Business Use Only
_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!UlrPKrKo1HKqgZx1MRR_utOnAfXfgi2lBMzVNQclE2S65bmsVBp7hJ7TRf5TdcXL$>

---

From: Andrew Alston <[email-masked]>
Date: Wed, 4 Mar 2020 21:58:07 +0000

I have to second the below from an operator perspective.

When a vendor is pushing me to implement a technology – yet not disclosing that implementing it could result in serious network degradation dependent on the boxes I have in the network and their positioning – that exposes me as an operator to a position of either roll back – or forced upgrades and potentially significant cost.

Thanks

Andrew

From: spring <[email-masked]> on behalf of "Joel M. Halpern" <[email-masked]>
Date: Thursday, 5 March 2020 at 00:25
To: "Darren Dukes (ddukes)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Martin Vigoureux <[email-masked]>
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

Yours,
Joel

On 3/4/2020 4:21 PM, Darren Dukes (ddukes) wrote:
>> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!QEhtnK3a_SkTtK5jFwY7ANmF22RCkp657bAyNJfcGg1xaI_ewfHQHKp7NIgQ3SpI$<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!QEhtnK3a_SkTtK5jFwY7ANmF22RCkp657bAyNJfcGg1xaI_ewfHQHKp7NIgQ3SpI$>>

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 4 Mar 2020 23:04:21 +0100

> When a vendor is pushing me to implement a technology

Last time I checked SRv6 is not enabled by default by any code base. What
type of "vendor push" are you referring to ? Maybe you can share which
vendor is pushing you with such strong push that you can not resist ?

Thx,
R.

On Wed, Mar 4, 2020 at 10:58 PM Andrew Alston <
[email-masked]> wrote:

> When a vendor is pushing me to implement a technology – yet not disclosing
> that implementing it could result in serious network degradation dependent
> on the boxes I have in the network and their positioning – that exposes me
> as an operator to a position of either roll back – or forced upgrades and
> potentially significant cost.
>
>
>
>
>
> Thanks
>
>
>
> Andrew
>
>
>
>
>
> *From: *spring <[email-masked]> on behalf of "Joel M. Halpern" <
> [email-masked]>
> *Date: *Thursday, 5 March 2020 at 00:25
> *To: *"Darren Dukes (ddukes)" <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>, Martin Vigoureux <
> [email-masked]>
> *Subject: *Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming
>
>
>
> >> <
> https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!QEhtnK3a_SkTtK5jFwY7ANmF22RCkp657bAyNJfcGg1xaI_ewfHQHKp7NIgQ3SpI$
> >

---

From: Satoru Matsushima <[email-masked]>
Date: Thu, 5 Mar 2020 07:39:07 +0900

Thank you Martin,

I support this clear statement. Even WG/AD management is expected to find the essence from bunch of emails, it shouldn't be easy task. Great job, thanks.

Best regards,
--satoru

> 2020/03/05 6:02、Martin Vigoureux <[email-masked]>のメール:
> 
> WG,
> 
> This document has received a lot of valuable reviews and comments which improved it. That served me as a base to determine consensus on the overall document.
> 
> The point I'd like to insist on is the one I was mentioning in my previous e-mail. In my view, the remaining prominent discussion (and tension) point was about the text of 8200, its implications on the optional PSP capability, and the ramifications of it.
> I have determined there is rough consensus, in SPRING, on the way to read the specific text of 8200, but also that certain aspects go beyond SPRING and would benefit from being discussed with a wider community.
> 
> 
> I'd like to remind that this was a WG Chair level decision. Indeed, Bruno still needs to produce the shepherd write-up and submit the document for publication.
> 
> Martin
> 
>> 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.
>> [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/

---

From: Fernando Gont <[email-masked]>
Date: Wed, 4 Mar 2020 20:43:58 -0300

> information on this list.  That will not happen.

I don't think you're really asking us to ship PSP without a proper 
rationale. That will not happen.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Wed, 4 Mar 2020 21:14:48 -0300

Martin,

On one hand, both Bruno and you 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 very different from the document 
on which you claimed consensus. Besides, the datatracker lists the 
document as "in WGLC", as opposed to "Waiting for WG Chair Go-Ahead" or 
"WG Consensus: Waiting for Write-Up".

Last, but not least, are you planning to do a second WGLC?

Thanks,

---

From: Andrew Alston <[email-masked]>
Date: Thu, 5 Mar 2020 01:51:36 +0000

Robert –

When I am told by a vendor – explicitly – with no ambiguity – that on certain platforms – they will never support IPv6 in the context of SR-MPLS on certain platforms – and it was SRv6 or nothing if I wanted SR  – then – yes – I am being pushed in a particular direction – without question.  For now – I will refrain from naming said vendor – but they are free to raise their hands and own up to it if they choose to do so

Andrew

From: Robert Raszuk <[email-masked]>
Date: Thursday, 5 March 2020 at 01:04
To: Andrew Alston <[email-masked]>
Cc: "Joel M. Halpern" <[email-masked]>, "Darren Dukes (ddukes)" <[email-masked]>, "[email-masked]" <[email-masked]>, Martin Vigoureux <[email-masked]>
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

> When a vendor is pushing me to implement a technology

Last time I checked SRv6 is not enabled by default by any code base. What type of "vendor push" are you referring to ? Maybe you can share which vendor is pushing you with such strong push that you can not resist ?

Thx,
R.

On Wed, Mar 4, 2020 at 10:58 PM Andrew Alston <[email-masked]<mailto:[email-masked]>> wrote:
I have to second the below from an operator perspective.

Thanks

Andrew

From: spring <[email-masked]<mailto:[email-masked]>> on behalf of "Joel M. Halpern" <[email-masked]<mailto:[email-masked]>>
Date: Thursday, 5 March 2020 at 00:25
To: "Darren Dukes (ddukes)" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Martin Vigoureux <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

Yours,
Joel

On 3/4/2020 4:21 PM, Darren Dukes (ddukes) wrote:
>> <mailto:rbonica<mailto:rbonica>=[email-masked]<mailto:[email-masked]>>> wrote:
>>
>> Andy,
>> *From:*Andrew G. Malis <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
>> *To:*Robert Raszuk <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
>> *Cc:*Ron Bonica <[email-masked]<mailto:[email-masked]>
>> <mailto:[email-masked]<mailto:[email-masked]>>>;[email-masked]<mailto:[email-masked]>
>> <mailto:[email-masked]<mailto:[email-masked]>>;[email-masked]<mailto:[email-masked]>
>> <mailto:[email-masked]<mailto:[email-masked]>>; Joel M. Halpern <[email-masked]<mailto:[email-masked]>
>> <mailto:[email-masked]<mailto:[email-masked]>>>; Martin Vigoureux
>> <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
>> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>>
>> Hi Ron,
>> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>>
>> Folks,
>>
>> [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>> [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>

---

From: "Pengshuping (Peng Shuping)" <[email-masked]>
Date: Thu, 5 Mar 2020 07:51:26 +0000

Hi Fernando,

My understanding on the Consensus expressed by Martin is that the SPRING WG has reached consensus on the direction of progressing this draft including what to improve in the draft and how to improve. What was left is just to update the text.

Now a new version of the draft has been posted with the new text based on the suggestions posted over the mailing list. You could have a further review and see whether you have any comments.

Best regards,
Shuping

-----Original Message-----
From: spring [mailto:[email-masked]] On Behalf Of Fernando Gont
Sent: Thursday, March 5, 2020 8:15 AM
To: Martin Vigoureux <[email-masked]>; [email-masked]
Cc: [email-masked]' <[email-masked]>
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

Martin,

On 4/3/20 18:02, Martin Vigoureux wrote:
> This document has received a lot of valuable reviews and comments 
> which improved it. That served me as a base to determine consensus on 
> the overall document.
> 
> read the specific text of 8200, but also that certain aspects go 
> beyond SPRING and would benefit from being discussed with a wider community.
> 
> 

On one hand, both Bruno and you 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 very different from the document on which you claimed consensus. Besides, the datatracker lists the document as "in WGLC", as opposed to "Waiting for WG Chair Go-Ahead" or "WG Consensus: Waiting for Write-Up".

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

---

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

> 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: 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.
> > >
> 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: Robert Raszuk <[email-masked]>
Date: Fri, 6 Mar 2020 17:36:09 +0100

Hi Andrew,

Well my point was that SR-MPLS with IPv6 has been supported by perhaps the
same vendor you have in mind .. the same who proposed SR ... back in 2015.
Sure it does not cover all platforms, but I guess this is pretty normal
for any vendor.

To the best of my knowledge they have no platform/software where they would
ship SRv6 before shipping SR-MPLS with IPv6 (at least with one IGP
extensions) so this is quite contrary to your claim made below.

Thx,
R.

On Thu, Mar 5, 2020 at 2:51 AM Andrew Alston <
[email-masked]> wrote:

> Robert –
>
>
>
> When I am told by a vendor – explicitly – with no ambiguity – that on
> certain platforms – they will never support IPv6 in the context of SR-MPLS
> on certain platforms – and it was SRv6 or nothing if I wanted SR  – then –
> yes – I am being pushed in a particular direction – without question.  For
> now – I will refrain from naming said vendor – but they are free to raise
> their hands and own up to it if they choose to do so
>
>
>
> Andrew
>
>
>
>
>
> *From: *Robert Raszuk <[email-masked]>
> *Date: *Thursday, 5 March 2020 at 01:04
> *To: *Andrew Alston <[email-masked]>
> *Cc: *"Joel M. Halpern" <[email-masked]>, "Darren Dukes (ddukes)" <
> [email-masked]>, "[email-masked]" <[email-masked]>, Martin Vigoureux <

---

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

> 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

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.

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

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: "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,

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