Subject: Re: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

From: "Zafar Ali (zali)" <[email-masked]>
Date: Wed, 26 Feb 2020 17:43:09 +0000

+1,

Just to add, in the spirit of IETF https://www.ietf.org/how/runningcode/ …
implementation, commercial deployment and Inter-op status has been documented in https://datatracker.ietf.org/doc/draft-matsushima-spring-srv6-deployment-status/

Thanks

Regards … Zafar

From: spring <[email-masked]> on behalf of Lizhenbin <[email-masked]>
Date: Wednesday, February 26, 2020 at 6:55 AM
To: "[email-masked]" <[email-masked]>, 'SPRING WG List' <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, draft-ietf-spring-srv6-network-programming <[email-masked]>
Subject: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

Hi Bruno and WG,
The LC has lasted for almost 3 months which greatly exceeds the expected 2 week. In the process all the comments have been resolved while some issues is raised again and again with little value.
On the other hand, there have been multiple commercial implementation and inter-op test and almost 20 deployments for SRv6 which justify the solution proposed by the draft in practice.

We sincerely request to close the LC of the draft and move forward.

Best Regards,
Zhenbin (Robin)

From: [email-masked] [mailto:[email-masked]]
Sent: Friday, December 06, 2019 1:15 AM
To: 'SPRING WG List' <[email-masked]>
Cc: [email-masked]; draft-ietf-spring-srv6-network-programming <[email-masked]>
Subject: WGLC - draft-ietf-spring-srv6-network-programming

Hello SPRING,

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

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

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

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

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

Thank you,

Bruno

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

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.

---

From: Dirk Steinberg <[email-masked]>
Date: Wed, 26 Feb 2020 19:52:17 +0200

+1

Cheers
Dirk

On Wed, Feb 26, 2020 at 7:43 PM Zafar Ali (zali) <zali=
[email-masked]> wrote:

> implementation, commercial deployment and Inter-op status has been
> documented in
> https://datatracker.ietf.org/doc/draft-matsushima-spring-srv6-deployment-status/
>
>
>
> Thanks
>
>
>
> Regards … Zafar
>
>
>
> *From: *spring <[email-masked]> on behalf of Lizhenbin <
> [email-masked]>
> *Date: *Wednesday, February 26, 2020 at 6:55 AM
> *To: *"[email-masked]" <[email-masked]>, 'SPRING WG
> List' <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>,
> draft-ietf-spring-srv6-network-programming <
> [email-masked]>
> *Subject: *[spring] Request to close the LC and move forward//RE: WGLC -
> draft-ietf-spring-srv6-network-programming
>
>
>
> Hi Bruno and WG,
>
> The LC has lasted for almost 3 months which greatly exceeds the expected 2
> week. In the process all the comments have been resolved while some issues
> is raised again and again with little value.
>
> On the other hand, there have been multiple commercial implementation and
> inter-op test and almost 20 deployments for SRv6 which justify the solution
> proposed by the draft in practice.
>
>
>
> *From:* [email-masked] [mailto:[email-masked]]
> *Sent:* Friday, December 06, 2019 1:15 AM
> *To:* 'SPRING WG List' <[email-masked]>
> *Cc:* [email-masked]; draft-ietf-spring-srv6-network-programming <
> [email-masked]>
> *Subject:* WGLC - draft-ietf-spring-srv6-network-programming
>
>
>
> Hello SPRING,
>
>
>
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>

---

From: Fernando Gont <[email-masked]>
Date: Wed, 26 Feb 2020 15:00:55 -0300

> https://datatracker.ietf.org/doc/draft-matsushima-spring-srv6-deployment-status/ 

You probably missed the "small" detail of having rough consensus to 
change an existing spec.

Just sayin'...

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

---

From: Bob Hinden <[email-masked]>
Date: Wed, 26 Feb 2020 10:22:19 -0800

Zafar,

> On Feb 26, 2020, at 9:43 AM, Zafar Ali (zali) <zali=[email-masked]> wrote:
> 
> +1,
> 

I think the proper question is there a consensus to advance this document.

There seems to be questions about its relationship with RFC8200.  I am not seeing this as being resolved.

Bob

---

From: John Leddy <[email-masked]>
Date: Wed, 26 Feb 2020 11:01:09 -0800

+1 in support of moving the document forward.

John Leddy

Sent from my iPhone

> On Feb 26, 2020, at 10:22 AM, Bob Hinden <[email-masked]> wrote:
> 
> Zafar,
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Warren Kumari <[email-masked]>
Date: Wed, 26 Feb 2020 14:15:30 -0500

I would suggest that people read RFC 7282 - "On Consensus and Humming
in the IETF", especially Sections 3 & 6 (it is a short document, you
should read the whole thing, but pay special attention to these
sections).

It doesn't really matter how many people say +1 for moving it forwards
-- if there are valid technical objections these have to be dealt with
- and I think that the relationship with RFC8200 falling into this
category...

W

-- 
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: Mike Simpson <[email-masked]>
Date: Wed, 26 Feb 2020 19:24:30 +0000

> - and I think that the relationship with RFC8200 falling into this

+1 for not violating RFC8200

Mike

---

From: "john leddy.net" <[email-masked]>
Date: Wed, 26 Feb 2020 15:09:38 -0500 (EST)

The understanding at IETF98 with rfc2460 moving to rfc8200 was that any tightening in header processing language was to get to an adopted standard and NOT to be used as club to bludgeon innovation by a small group of loud hummers. 

> On February 26, 2020 at 2:15 PM Warren Kumari <[email-masked]> wrote:
> 
>

---

From: Fernando Gont <[email-masked]>
Date: Wed, 26 Feb 2020 17:25:44 -0300

> The understanding at IETF98 with rfc2460 moving to rfc8200 was that any tightening in header processing language was to get to an adopted standard and NOT to be used as club to bludgeon innovation…

1) My understanding is that decisions are taken on the mailing-list.

2) There is a reason for the different maturity levels, and a reason 
why, given a standard, you have to do a formal update if you want to 
change it. And the onus to get consensus is on the folks proposing the 
changes, as opposed to the folks asking for existing specs to be respected.

Rather than wasting our time trying to explain why or how existing specs 
don't apply to you, as well as lecturing folks that spend their time 
helping RFC8200 and previous efforts, you should have probably tried to 
make a case for updating RFC8200.

Nobody is stopping you from coming up with a proposal. We're simply 
kindly asking that you stop trying to violate existing specs, and 
circumvent IETF process.

This whole thing (including previous similar issues while working on 
rfc2460bis), is the perfect example of how individual participation 
(i.e., outside of a small group of big vendors) are highly discouraged 
from participating at the IETF.

It is a shame we have had to insist on this so much.

Thanks,

---

From: Mark Smith <[email-masked]>
Date: Thu, 27 Feb 2020 08:00:01 +1100

> The understanding at IETF98 with rfc2460 moving to rfc8200 was that any tightening in header processing language was to get to an adopted standard and NOT to be used as club to bludgeon innovation…

If you think I'm against innovation with IPv6, then you haven't seen
my IPv6 formal and functional anycast address proposal -
https://tools.ietf.org/html/draft-smith-6man-form-func-anycast-addresses-01.

draft-ietf-spring-srv6-network-programming-10 doesn't say "Updates
RFC8200", nor does it provide any technical justification for PSP,
including comparison with the existing alternative.

As RFC 8200 is also one of only 92 full Internet Standards, and of
course has met the required criteria to be promoted to full Internet
Standard, fundamental changes to it have to be very significantly
justified and considered.

The SPRING WG are also supposed to be actively trying to avoid such
changes. From the charter:

"SPRING WG should avoid modification to existing data planes that would
make them incompatible with existing deployments. Where possible,
existing control and management plane protocols must be used within
existing architectures to implement the SPRING function."

(+1 to everybody reading RFC 7282)

Regards,
Mark "Loud Hammer" Smith.

"What you allow, you encourage." - Michael Josephson.

---

From: "Voyer, Daniel" <[email-masked]>
Date: Wed, 26 Feb 2020 21:37:22 +0000

+1

Thanks
dan

From: Dirk Steinberg <[email-masked]>
Date: Wednesday, February 26, 2020 at 12:52 PM
To: "Zafar Ali (zali)" <zali=[email-masked]>
Cc: Lizhenbin <[email-masked]>, Bruno Decraene <[email-masked]>, SPRING WG List <[email-masked]>, "[email-masked]" <[email-masked]>, "Zafar Ali (zali)" <[email-masked]>, draft-ietf-spring-srv6-network-programming <[email-masked]>
Subject: [EXT]Re: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming
Resent-From: <[email-masked]>
Resent-To: <[email-masked]>, <[email-masked]>, John Leddy <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Resent-Date: Wednesday, February 26, 2020 at 12:52 PM

+1

Cheers
Dirk

On Wed, Feb 26, 2020 at 7:43 PM Zafar Ali (zali) <zali=[email-masked]<mailto:[email-masked]>> wrote:
+1,

Thanks

Regards … Zafar

From: spring <[email-masked]<mailto:[email-masked]>> on behalf of Lizhenbin <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, February 26, 2020 at 6:55 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, 'SPRING WG List' <[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: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

Hi Bruno and WG,

Best Regards,
Zhenbin (Robin)

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Friday, December 06, 2019 1:15 AM
To: 'SPRING WG List' <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; draft-ietf-spring-srv6-network-programming <[email-masked]<mailto:[email-masked]>>
Subject: WGLC - draft-ietf-spring-srv6-network-programming

Hello SPRING,

Thank you,

Bruno

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

---

From: Bob Hinden <[email-masked]>
Date: Wed, 26 Feb 2020 13:55:46 -0800

John,

> On Feb 26, 2020, at 12:09 PM, john leddy.net <[email-masked]> wrote:
> 

To repeat what has been said before, the way to do this is to write a draft that defines how these constraints could be relaxed and build a consensus around that.  This has not been completed.

We had a constructive discussion on this topic at IETF 106, it’s recorded in the minutes at:

https://datatracker.ietf.org/meeting/106/materials/minutes-106-6man-01.txt

I have not seen any further discussion after IETF 106.

Bob

---

From: Satoru Matsushima <[email-masked]>
Date: Thu, 27 Feb 2020 07:45:05 +0900

+1

Cheers,
--satoru

> 2020/02/27 6:37、Voyer, Daniel <[email-masked]>のメール:
> 
> +1
>  
> Thanks
> dan
>  
> On Wed, Feb 26, 2020 at 7:43 PM Zafar Ali (zali) <zali=[email-masked]> wrote:
>> +1,
>>

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Wed, 26 Feb 2020 23:18:28 +0000

Writing this without any hat,

Please note that on the logical side, it still have to be "proven" that this idea is strictly forbidden by RFC 8200. Moreover, this 'proof' can technically wait until the IETF last call or even until the IESG ballot. I see little point in postponing the closing of the WGLC and advancing the document (of course, the document shepherd will need to carefully write the section about the rough WG consensus).

Finally, as far as I know, at the IETF we have no religion... else we would still be running NCP or IPv4 :-)

-éric

-----Original Message-----
From: ipv6 <[email-masked]> on behalf of Warren Kumari <[email-masked]>

...%<...%<....

---

From: Gaurav Dawra <[email-masked]>
Date: Wed, 26 Feb 2020 15:20:15 -0800

+1

Sent from my iPhone

---

From: Fernando Gont <[email-masked]>
Date: Wed, 26 Feb 2020 20:45:13 -0300

Hello, Eric,

On 26/2/20 20:18, Eric Vyncke (evyncke) wrote:
> Please note that on the logical side, it still have to be "proven" that this idea is strictly forbidden by RFC 8200. 

Here's the proof part:

1) Isn't IPv6 end to end?

2) How do core components of IPv6, such as AH and PMTUD work in the 
present of intermediate nodes that can add and/or remove arbitrary 
extension headers?

It should be clear from the above that EH insertion/deletion is forbidden.

Since this topic has been brought up again and again, I have submitted 
an errata to RFC8200 which clarifies the intended behaviour:
* https://www.rfc-editor.org/errata/eid5933

(that's what Errata's are for, after all... and it should be clear that 
the EH processing part, overall, needs improvements).

Thanks!

Cheers,

---

From: Fernando Gont <[email-masked]>
Date: Wed, 26 Feb 2020 20:48:06 -0300

> Please note that on the logical side, it still have to be "proven" that this idea is strictly forbidden by RFC 8200. Moreover, this 'proof' can technically wait until the IETF last call or even unt…

I'm not sure how the document could advance with clear and sound 
technical objections. For instance... if anything, can anybody claim 
consensus on this point?

> Finally, as far as I know, at the IETF we have no religion... else we would still be running NCP or IPv4 :-)

There's a difference between us forcing the use of specific technologies 
(.e., a specific routing protocol in your network) and aiming at 
consistency in our specs.

We are a standards organization. If we can't keep our specs consistent, 
and we violate our specs at will, I'm not sure our work will be taken 
seriously.

Thanks,

---

From: Stefano Salsano <[email-masked]>
Date: Thu, 27 Feb 2020 00:50:07 +0100

+1

Regards,
Stefano

-- 
*******************************************************************
Stefano Salsano
Professore Associato
Dipartimento Ingegneria Elettronica
Universita' di Roma Tor Vergata
Viale Politecnico, 1 - 00133 Roma - ITALY

http://netgroup.uniroma2.it/Stefano_Salsano/

E-mail  : [email-masked]
Cell.   : +39 320 4307310
Office  : (Tel.) +39 06 72597770 (Fax.) +39 06 72597435
*******************************************************************

---

From: "Weiqiang Cheng" <[email-masked]>
Date: Thu, 27 Feb 2020 08:12:01 +0800

+1

Cheers

Weiqiang Cheng

发件人: spring [mailto:[email-masked]] 代表 Voyer, Daniel
发送时间: 2020年2月27日 05:37
收件人: Dirk Steinberg; Zafar Ali (zali)
抄送: SPRING WG List; [email-masked]; [email-masked]; Zafar Ali (zali); Lizhenbin; draft-ietf-spring-srv6-network-programming
主题: Re: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

+1

Thanks

dan

+1

Cheers

Dirk

+1, 

Thanks

Regards … Zafar 

Hi Bruno and WG,

 

Best Regards,

Zhenbin (Robin)

Hello SPRING,

 

Thank you,
Bruno

 

 

  _____

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 27 Feb 2020 14:14:05 +1300

Eric,

The draft uses an undefined term ("pop") but it does *explicitly* state in a section called "Penultimate Segment Pop of the SRH":

>> S14.4.      Remove the SRH from the IPv6 extension header chain

If the word "penultimate" means what it means in every dictionary, this is in-flight removal of a header, and that is explicitly against RFC 8200, section 4, first paragraph below the diagram.

It's possible that "penultimate" means something else, e.g. "ultimate". I don't know. I've been puzzling over this language for months and it doesn't change. Maybe someone can finally post an explanation, but until they do, I don't see how any WG Chair could assert rough consensus. An obviously organised +1+1+1+1 campaign is not consensus. I don't know about you, but when I see a message whose only content is "+1" I just delete it.

   Brian

> Moreover, this 'proof' can technically wait until the IETF last call or even until the IESG ballot. I see little point in postponing the closing of the WGLC and advancing the document (of course, the document shepherd will need to carefully write the section about the rough WG consensus).
>

---

From: Stefano Salsano <[email-masked]>
Date: Thu, 27 Feb 2020 02:42:43 +0100

> If the word "penultimate" means what it means in every dictionary, this is in-flight removal of a header, and that is explicitly against RFC 8200, section 4, first paragraph below the diagram.

Brian,

"penultimate segment" means what it means in every dictionary, but this 
is not in-fligth removal of a header.

When the packet has reached the "penultimate segment", it has reached a 
node "identified in the Destination Address field of the IPv6 header" as 
stated in RFC 8200, section 4, first paragraph below the diagram

Please note that at the very end of section 3 the "Destination address" 
is defined as "address of the intended recipient of the packet (possibly 
not the ultimate recipient, if a Routing header is present)"

Stefano

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 27 Feb 2020 15:29:56 +1300

Stefano,
> stated in RFC 8200, section 4, first paragraph below the diagram

So in what sense is it penultimate (i.e. next to last)? If it has reached
the destination address, what happens next? 

I understand this for the following case, Ultimate Segment Pop, where the
text refers to processing the packet inside the receiving node. But the
text is completely lacking an explanation of the "penultimate" case,
and I found nothing about it in other SRH documents either.

If I was writing code for this, I would have no idea how to generate a
test case.

It's also obscure in the text how the node receiving a packet knows
which of "PSP, USP and USD flavors" applies. They don't seem to be marked
in the packet in any way.

It seems to me that there is something blindingly obvious to SRH specialists
that is not stated at all in the draft, so the rest of us simply can't make
sense of it. It may or may not be a gap in the protocol, but there is 
definitely a gap in the description.

    Brian

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 27 Feb 2020 11:26:58 +0800

Based on the value of this doc, it deserves an extension of WGLC, even a second WGLC.
It is obvious that some technical isssues and comments are still boiled in this list. So, in my opinion I am afraid that the WGLC can not reach the rough consensus that the doc is ready to move forward.

Since the issues are mainly ralated to the flavor section, why not extract this part from this main doc to a separate doc and try to move the main doc forward. We can discuss the separate flavor doc further. 

Best Regards,
Zhenqiang Li

[email-masked]
 
From: Warren Kumari
Date: 2020-02-27 03:15
To: John Leddy
CC: SPRING WG List; [email-masked]; Bob Hinden; Zafar Ali \(zali\)
Subject: Re: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming
I would suggest that people read RFC 7282 - "On Consensus and Humming
in the IETF", especially Sections 3 & 6 (it is a short document, you
should read the whole thing, but pay special attention to these
sections).

W

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Thu, 27 Feb 2020 04:46:45 +0000

Hi Spring WG colleagues,

I am really concerned at the attempts made to drag this WGLC out further. Let me summarize why.

  1.  The only sticking point that I am aware of (since I’ve been following all discussions closely) is about the claim being made by some members that PSP violates RFC8200. Most of the WG members that are actually developing and deploying SRv6 claim otherwise. In the end, it depends on how each person is interpreting the RFC8200 text. It’s been debated ad nauseam – there is nothing more/new that I see coming. It will continue to remain an endless loop unless a closure is called on it – question is when during the draft progression and who does this?
  2.  When all the arguments have already been answered during the earlier part of the WGLC, they are still being repeated as if they were not answered and new ones are being made up (and I fear this continues until WGLC closure). I see Pablo and others have answered them. So there is just (1) above that remains.
  3.  I even see recent attempts to associate PSP with the “insertion debate” and arguments like PMTUD (that is relevant for PSP). The authors of SRv6 have followed the spirit of the IETF consensus building process by removing all those aspects related to SRH insertion and placed them in a separate draft that is now contingent on its counterpart draft on SRH insertion achieving consensus in 6man. I can’t understand the motivation of those attempting to bring SRH insertion into the WGLC for this document – is it to slow down or derail SRv6 work in Spring?
  4.  Finally, there is this argument to move PSP out of this draft to allow the document to progress. Besides (1) there is no technical case being made for this request. PSP (though an optional flavor in the spec), is strongly desired by many of us working on SRv6 – implementors and operators who have deployed. It is only right that we at IETF document what is really out there and relevant in the industry – not lower the standards down to the least common denominator when there is a non-technical opposition.

In the end, all that remains is a (religious?) interpretation of RFC8200 text against PSP that stands in the way of the completion of the WGLC.

Therefore, it is time for us (Spring WG) to NOW call this WGLC to end.

Thanks,
Ketan

From: ipv6 <[email-masked]> On Behalf Of [email-masked]
Sent: 27 February 2020 08:57
To: [email-masked]; John Leddy <[email-masked]>
Cc: [email-masked]; [email-masked]; Bob Hinden <[email-masked]>; Zafar Ali (zali) <zali=[email-masked]>
Subject: Re: Re: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

Best Regards,
Zhenqiang Li
________________________________
[email-masked]<mailto:[email-masked]>

From: Warren Kumari<mailto:[email-masked]>
Date: 2020-02-27 03:15
To: John Leddy<mailto:[email-masked]>
CC: SPRING WG List<mailto:spring@ietf..org>; [email-masked]<mailto:[email-masked]>; Bob Hinden<mailto:[email-masked]>; Zafar Ali \(zali\)<mailto:zali=[email-masked]>
Subject: Re: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming
I would suggest that people read RFC 7282 - "On Consensus and Humming
in the IETF", especially Sections 3 & 6 (it is a short document, you
should read the whole thing, but pay special attention to these
sections).

W

On Wed, Feb 26, 2020 at 2:01 PM John Leddy <[email-masked]<mailto:[email-masked]>> wrote:
> > On Feb 26, 2020, at 10:22 AM, Bob Hinden <[email-masked]<mailto:[email-masked]>> wrote:
> >
> > Zafar,
> >
> >> On Feb 26, 2020, at 9:43 AM, Zafar Ali (zali) <zali=[email-masked]<mailto:zali=[email-masked]>> wrote:
> >>
> >> +1,
> >>
> > [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

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

---

From: Dirk Steinberg <[email-masked]>
Date: Thu, 27 Feb 2020 09:51:56 +0200

On Thu, Feb 27, 2020 at 1:45 AM Fernando Gont <[email-masked]> wrote:

> > Please note that on the logical side, it still have to be "proven" that
> this idea is strictly forbidden by RFC 8200.
>
> Here's the proof part:
>

As I already explained to you this is not true.
The wording of RFC8200 clearly allows this.
The node addresses by the DA of the packet can do this.
I understand that you would like to modify the wording of
RFC8200 to make your point true but it simply is not.
Repeating a false statement does not make it true.

Cheers
Dirk

---

From: Fernando Gont <[email-masked]>
Date: Thu, 27 Feb 2020 05:05:30 -0300

On 27/2/20 04:51, Dirk Steinberg wrote:
> 
> 
> On Thu, Feb 27, 2020 at 1:45 AM Fernando Gont <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Hello, Eric,
> 
>      > Please note that on the logical side, it still have to be
>     "proven" that this idea is strictly forbidden by RFC 8200.
> 
>     Here's the proof part:
> 

Please answer the questions I've asked, and you'll get the response:

IPv6 is end to end, and does not support header insertion or deletion 
en-route to the final destination. It would break core IPv6 components 
such as PMTUD and AH.

If you find that the wording in RFC8200 should be improved, so be it: we 
already have to improve it from RFC2460, and it seems you still trying 
to find ways to circumvent the spec.

If the spec warrants a *clarification*, so be it: we already did it from 
RFC2460, we did it for RFC8200 for the fragmentation part, and we may 
also have to do it for EH processing (and not only for this issue).

I have given it a shot here: https://www.rfc-editor.org/errata/eid5933

That's what erratas are for.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 27 Feb 2020 05:14:17 -0300

> The node addresses by the DA of the packet can do this.

FWIW, this is not even true for PSP.

Brian raised this so many times already... but it looks like the 
procedure is busted anyway. You claim IPv6 behavior that never existed, 
you ignore objections, and a dozen of folks post "+1" as if that meant 
the issues raised had been addressed.

I have asked numerous times the same questions I asked above, and they 
have never been answered -- because we all know they make the rest obvious.

But go ahead.  I'll appeal or escalate if necessary.

Thanks,

---

From: Mark Smith <[email-masked]>
Date: Thu, 27 Feb 2020 19:23:03 +1100

> The node addresses by the DA of the packet can do this.

Can you quote this text please?

Can you also explain why AH considers the fields necessary to do this
- the Next Header and Payload Length - immutable, and would consider
such packet modification within the network to be an attack?

---

From: <[email-masked]>
Date: Thu, 27 Feb 2020 08:41:20 +0000

Fernando,

> From: ipv6 [mailto:[email-masked]] On Behalf Of Fernando Gont
> Sent: Thursday, February 27, 2020 12:45 AM
> 
> Hello, Eric,
> 

This draft does not propose that intermediate node add extension header. 
 - If this is not clear to you, please read the draft.
 - If it's clear, please let's stick to technical comment on _this_ draft. Bringing irrelevant points to the discussion is really not helping (both the discussion  and the argument).

This draft does not propose that intermediate node add/or remove arbitrary  extension header.

This draft, and more specifically the PSP flavor [1], is about removing the SRH header by an SR EndPoint.
- with regards to PMTUD, can you clarify how reducing the size of the packet break PMTUD? And if there is an impact, let's remember that this is the source of the packet which instruct the SR EndPoint to remove the SRH. 
- with regards to AH, the SRH specification explicitly states that the use of SRH with AH by an SR source node is _not_ defined [2]. I don't think you can break something which is not working/defined. That been said, as an individual contributor, I think the PSP section should explicitly raise that point.

[1] https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-10#section-4.16.1
[2] https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26#section-7.5

> the EH processing part, overall, needs improvements).

Again, thank you for that, I believe this is useful.
But while this errata is not reviewed and accepted, RFC 8200 stands as is.

--Bruno

---

From: Fernando Gont <[email-masked]>
Date: Thu, 27 Feb 2020 06:07:14 -0300

Bruno,

>   - If this is not clear to you, please read the draft.

What is this:????

4.16.1.  PSP: Penultimate Segment Pop of the SRH

    The SRH processing of the End, End.X and End.T behaviors are
    modified: after the instruction "S14.  Update IPv6 DA with Segment
    List[Segments Left]" is executed, the following instructions must be
    executed as well:

  S14.1.   If (Segments Left == 0) {
  S14.2.      Update the Next Header field in the preceding header to the
                 Next Header value of the SRH
  S14.3.      Decrease the IPv6 header Payload Length by the Hdr Ext Len
                 value of the SRH
  S14.4.      Remove the SRH from the IPv6 extension header chain
  S14.5.   }

Isn't this having the penultimate segment fo a packet removing an 
extension header for a packet whose Destination Address is not even it's 
own?

Doesn't this read a bit as "the router was the DA of the packet, after 
you change the DA to that of the next waypoint, if you realize Segments 
Left == 0, remove the SRH"?

(which does not even comply with the now infamous "interpretation" of 
RFC8200 that if you are the DA, you can add/remove EHs.

> This draft, and more specifically the PSP flavor [1], is about removing the SRH header by an SR EndPoint.

Seriously?

> - with regards to AH, the SRH specification explicitly states that the use of SRH with AH by an SR source node is _not_ defined [2]. 

Do you understand that AH should be usable for all IPv6 traffic?

[....]
> But while this errata is not reviewed and accepted, RFC 8200 stands as is.

The errata is a clarification, not a change. Of course RFC8200 stands: 
EHs are not deleted or added en route to destination.

Thanks,

---

From: Stefano Salsano <[email-masked]>
Date: Thu, 27 Feb 2020 12:42:34 +0100

Brian,

Il 2020-02-27 03:29, Brian E Carpenter ha scritto:
> the destination address, 

if the segment list is [S1, S2, S3] (where S1 is the first segment and 
S3 the final destination)

S2 is the penultimate segment and the packet is received by S2 with 
Destination Address = S2, I repeat that at the very end of section 3 of 
RFC 8200 the "Destination address" is defined as "address of the 
intended recipient of the packet (possibly not the ultimate recipient, 
if a Routing header is present)"

> what happens next?

next the packet needs to be forwarded to S3

> in the packet in any way.

it is not marked in the packet, likewise it is not marked in the packet 
which SRv6 behavior is associated with a SID

Stefano

---

From: <[email-masked]>
Date: Thu, 27 Feb 2020 11:53:24 +0000

Fernando,
 
> From: Fernando Gont [mailto:[email-masked]] 
> 
> Bruno,
> 

This is _removal_ not _addition_.
 
> extension header for a packet whose Destination Address is not even it's 

 So you seem to agree that this is _removal_ not _addition_
The Destination Address is its own. This is even your summary in your below sentence "the router was the DA of the packet"
 
> RFC8200 that if you are the DA, you can add/remove EHs.

It's clear that there are different interpretations of RFC 8200. I really wish there were not. One option is to ask the IESG to review that point and make the call. 

> > This draft, and more specifically the PSP flavor [1], is about removing the SRH header by an SR EndPoint.

? Please be more specific.

I thought that:
a) this email thread is about PSP
b) in the draft, PSP is about removing the SRH header by an SR End Point

Please clarify on which point we are not in sync

> > - with regards to PMTUD, can you clarify how reducing the size of the packet break PMTUD? And if there is an impact, let's remember that this is the source of the packet which instruct the SR End…

I note that you do not clarify that point.

> Do you understand that AH should be usable for all IPv6 traffic?

My sentence was purposely written as a quote of  https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-24#section-7.5

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

That draft, hence above text, has been approved by the 6MAN WG and the IESG.
It you have an issue with it, please raise it on the 6MAN WG in a relevant thread.

As of today, we are discussing draft-ietf-spring-srv6-network-programming

> The errata is a clarification, not a change.

That is the claim of the author of the errata.
My understanding of the errata process is that point remains to be decided:

" Status: Reported"
https://www.rfc-editor.org/errata/eid5933

" Reported 	The erratum has been reported but is unverified."
https://www.rfc-editor.org/errata-definitions/

--Bruno

> Of course RFC8200 stands:

---

From: Stefano Salsano <[email-masked]>
Date: Thu, 27 Feb 2020 14:26:01 +0100

Fernando,

Il 2020-02-27 10:07, Fernando Gont ha scritto:
>>>> Please note that on the logical side, it still have to be "proven" 
>>>> that this idea is strictly forbidden by RFC 8200.
>>>
>>> Here's the proof part:
>>>

no, this is a wrong interpretation
the penultimate segment is removing the extension header for a packet 
whose Destination Address *is its own address*
> RFC8200 that if you are the DA, you can add/remove EHs.

during the processing, as described in the pseudo code, there is an 
intermediate step in which the packet *processed inside the router* has 
the destination address of the last segment and the router removes the SRH

it is never suggested/allowed in the draft that a router can remove the 
SRH from a received packet that does not have a router address as DA

Stefano

> 
> 
> 
>>   - If it's clear, please let's stick to technical comment on _this_ 
>> draft. Bringing irrelevant points to the discussion is really not 
>> helping (both the discussion  and the argument).
>>
>> This draft, and more specifically the PSP flavor [1], is about 
>> removing the SRH header by an SR EndPoint.
> 
> Seriously?
> 
> 
>> - with regards to PMTUD, can you clarify how reducing the size of the 
>> packet break PMTUD? And if there is an impact, let's remember that 
>> this is the source of the packet which instruct the SR EndPoint to 
>> remove the SRH.
>> - with regards to AH, the SRH specification explicitly states that the 
>> use of SRH with AH by an SR source node is _not_ defined [2]. 
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 27 Feb 2020 08:43:51 -0500

Even if one assumes that the violation has not been proven, I think it 
has been shown clearly that PSP pushes the limits of 8200.  If there is 
a strong reason for PSP, then pushing those limits is sensible.  But the 
vast majority of the response we are getting to the issue on this list 
is either:
1) It does not actually violate, so we can do what we want, even if the 
value is marginal
2) the limits do not apply

Neither of those seem to address the question.  And that gap is a 
concern with closing the last call.

Yours,
Joel

---

From: John Scudder <[email-masked]>
Date: Thu, 27 Feb 2020 15:21:52 +0000

On Feb 26, 2020, at 8:14 PM, Brian E Carpenter <[email-masked]> wrote:
> 
> I don't know about you, but when I see a message whose only content is "+1" I just delete it.

+1

;-)

—John

---

From: Warren Kumari <[email-masked]>
Date: Thu, 27 Feb 2020 13:09:01 -0500

On Wed, Feb 26, 2020 at 8:14 PM Brian E Carpenter
<[email-masked]> wrote:

[SNIP]

> It's possible that "penultimate" means something else, e.g. "ultimate". I don't know. I've been puzzling over this language for months and it doesn't change. Maybe someone can finally post an expla…

Actually, when I see a message whose content is just "+1" (or
something similar like "I support this"), and the sender hasn't been
deeply involved in the conversation, I start thinking it is vote
stuffing. If this happens repeatedly I become increasingly convinced
of this.
"We reject: kings, presidents, and voting. We believe in: rough
consensus and running code." - we don't vote. Having a thousand people
who have not made good technical points / provided substantive text /
review / contributed to the discussion in a meaningful way suddenly
say "I support this" is not just meaningless, it is actively harmful -
who are they? what do they know? what does their opinion matter? why
did someone feel it necessary to recruit them?
This is true for a bunch of *known* people from the same company /
group / organization / similar all suddenly arriving and supporting or
objecting to a position without good (and distinct!) reasons.

Over time people build up credibility -  if Brian Carpenter (or Randy
Bush or Russ Housley or John Scudder or ...) simply adds a "I support
foo" (or "+1") message to a thread it *does* carry weight; their
statement isn't made in a vacuum - I consider if they have
demonstrated previous knowledge *in the topic*, if they have made
useful contributions, etc. before deciding if their comment *means*
anything, and what bias it carries.

I can spend all day supporting <insert some topic here>, but unless I
have *demonstrated* knowledge, skillset and a track record, my support
isn't useful..

W

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 27 Feb 2020 19:59:22 +0100

Warren,

Excellent note !!!

In the past I have been part of an employers forcing you to support a draft
just to push it regardless if it was even in your area of interest ...
leave alone expertise or your technical opinion about it.

It is very unfortunate that IETF does not have a good way of
retrieving judgement from real group of folks who understand given
proposal.

"+1" is just only one demonstration of it. Humming is another. Raising
hands one more. We say there is no voting but while there is no formal
ballot box nor even e-ballot version of it all of the above ways to gather
"consensus" are examples of voting.

Best,
R.

On Thu, Feb 27, 2020 at 7:10 PM Warren Kumari <[email-masked]> wrote:

> > It's possible that "penultimate" means something else, e.g. "ultimate".
> I don't know. I've been puzzling over this language for months and it
> doesn't change. Maybe someone can finally post an explanation, but until
> they do, I don't see how any WG Chair could assert rough consensus. An
> obviously organised +1+1+1+1 campaign is not consensus. I don't know about
> you, but when I see a message whose only content is "+1" I just delete it.
>
>
> > > Moreover, this 'proof' can technically wait until the IETF last call
> or even until the IESG ballot. I see little point in postponing the closing
> of the WGLC and advancing the document (of course, the document shepherd
> will need to carefully write the section about the rough WG consensus).
> > >

---

From: Ted Lemon <[email-masked]>
Date: Thu, 27 Feb 2020 14:07:29 -0500

On Feb 27, 2020, at 1:59 PM, Robert Raszuk <[email-masked]> wrote:
> It is very unfortunate that IETF does not have a good way of retrieving judgement from real group of folks who understand given proposal. 

We do.   It’s called “substantive comments.”

> "+1" is just only one demonstration of it. Humming is another. Raising hands one more. We say there is no voting but while there is no formal ballot box nor even e-ballot version of it all of the above ways to gather "consensus" are examples of voting. 

Actually, the purpose of humming is not to make a decision, but to figure out whether there is general consensus.   If you ask for a hum and you get a 50-50 response, there probably isn’t consensus, and you might just say “we don’t have consensus” and go on to figuring out how.   If the “no” hum has no loud participants, you might say “looks like we’re good to go, we’ll confirm on the list.”   If there’s someone humming loudly no when everybody else is in favor, and you don’t know why they’re humming that way, that’s a good time to ask them if they are willing to explain.

But bear in mind that humming does not take place on the mailing list, and that consensus is called on the mailing list, not in the room.

On the mailing list, people pretty much have to raise objections verbally.  No amount of +1s should be considered meaningful at all.   The work is chartered; the wg is supposed to do it.   If there are no objections, and people feel the document is ready, then it should move forward, whether there are +1s or not.   If objections are raised, and they are substantive (that is, not opinion or conjecture), then they have to be addressed.   They can be addressed by saying “we considered that, and the working group as a whole agrees that the problem exists, but it doesn’t need to be addressed because this document is only applicable in a situation where the objection raised doesn’t matter.”  Or it can add text to address the objection, as Brian I think has suggested.   Or it can do additional work to address the problem, as Brian has also suggested.

But the WG can’t simply ignore the objection.  That is not what “rough consensus” means.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 27 Feb 2020 14:27:54 -0500

THere is one nuance that is worth noting.  It is not for the case of a 
controversial document.

Rather, the case where +1 can be useful is when the question is whether 
the working group even cares about the document.  I have had several 
cases of calls for adoption or WG last call where there was almost no 
response on the mailing list.  In the absence of decent indication, I as 
chair feel compleed to say "no, I do not see enough support to adopt / 
advance / ... this document".
In that situation, even +1s can help.  (And yes, I do watch for the case 
of all the +1s coming from the same company as the author, and then 
start judging whether they are folks who participate, along the lines 
Warren outlined.)

Yours,
Joel

On 2/27/2020 2:07 PM, Ted Lemon wrote:
> On Feb 27, 2020, at 1:59 PM, Robert Raszuk <[email-masked] 
> <mailto:[email-masked]>> wrote:
>> ballot box nor even e-ballot version of it all of the above ways to 
>> gather "consensus" are examples of voting. 
> 
> Actually, the purpose of humming is not to make a decision, but to 
> figure out whether there is general consensus.   If you ask for a hum 
> and you get a 50-50 response, there probably isn’t consensus, and you 
> might just say “we don’t have consensus” and go on to figuring out how. 
>    If the “no” hum has no loud participants, you might say “looks like 
> we’re good to go, we’ll confirm on the list.”   If there’s someone 
> humming loudly no when everybody else is in favor, and you don’t know 
> why they’re humming that way, that’s a good time to ask them if they are 
> willing to explain.
> 
> But bear in mind that humming does not take place on the mailing list, 
> and that consensus is called on the mailing list, not in the room.
> 
> On the mailing list, people pretty much have to raise objections 
> verbally.  No amount of +1s should be considered meaningful at all.   
> The work is chartered; the wg is supposed to do it.   If there are no 
> objections, and people feel the document is ready, then it should move 
> forward, whether there are +1s or not.   If objections are raised, and 
> they are substantive (that is, not opinion or conjecture), then they 
> have to be addressed.   They can be addressed by saying “we considered 
> that, and the working group as a whole agrees that the problem exists, 
> but it doesn’t need to be addressed because this document is only 
> applicable in a situation where the objection raised doesn’t matter.” 
>   Or it can add text to address the objection, as Brian I think has 
> suggested.   Or it can do additional work to address the problem, as 
> Brian has also suggested.
>

---

From: Ted Lemon <[email-masked]>
Date: Thu, 27 Feb 2020 14:41:55 -0500

On Feb 27, 2020, at 2:27 PM, Joel M. Halpern <[email-masked]> wrote:
> Rather, the case where +1 can be useful is when the question is whether the working group even cares about the document.  I have had several cases of calls for adoption or WG last call where there was almost no response on the mailing list.  In the absence of decent indication, I as chair feel compleed to say "no, I do not see enough support to adopt / advance / ... this document".
> In that situation, even +1s can help.  (And yes, I do watch for the case of all the +1s coming from the same company as the author, and then start judging whether they are folks who participate, along the lines Warren outlined.)

In my experience this is actually the wrong thing to do.  If the work was chartered, and a bunch of people go off and do the work, and then by the time the work is done the working group has lost momentum other than those people, saying “Oh, I guess nobody cares, we won’t publish” is the wrong outcome.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 27 Feb 2020 14:59:51 -0500

Two different disagreements with you.
First, I did list adoption as well as last call.  In adoption the chairs 
can't very well look back at the adoption to see if there was really 
support.
Second, it is the WG, not the document authors, that send a document to 
the AD for IETF approval.  if the only people who think the AD and IESG 
should put in the work are the authors, how can the chairs say to the AD 
"the WG supports this".  At best, you would have to have a very 
wishy-washy shepherd writeup.  Particularly if it has been several years 
since the adoption.  Or worse, several years since the WG even touched 
the document.

I do try to find alternatives before just giving up.  Extending adoption 
or last call windows, with prompting notes about the work (usually) 
being in charter or even (when appropriate) how important the work is to 
the overall goal.

Yours,
Joel

On 2/27/2020 2:41 PM, Ted Lemon wrote:
> On Feb 27, 2020, at 2:27 PM, Joel M. Halpern <[email-masked] 
> <mailto:[email-masked]>> wrote:
>> Rather, the case where +1 can be useful is when the question is 
>> whether the working group even cares about the document.  I have had 
>> several cases of calls for adoption or WG last call where there was 
>> almost no response on the mailing list.  In the absence of decent 
>> indication, I as chair feel compleed to say "no, I do not see enough 
>> support to adopt / advance / ... this document".
>> In that situation, even +1s can help.  (And yes, I do watch for the 
>> case of all the +1s coming from the same company as the author, and 
>> then start judging whether they are folks who participate, along the 
>> lines Warren outlined.)
> 
> In my experience this is actually the wrong thing to do.  If the work 
> was chartered, and a bunch of people go off and do the work, and then by 
> the time the work is done the working group has lost momentum other than 
> those people, saying “Oh, I guess nobody cares, we won’t publish” is the 
> wrong outcome.
>

---

From: Warren Kumari <[email-masked]>
Date: Thu, 27 Feb 2020 15:06:02 -0500

> advance / ... this document".

That's a very good point - thank you.

> start judging whether they are folks who participate, along the lines

Yup.

Also specific flexibility / human judgement aspect is an important
part of the IETF - chairs are expected to have knowledge of their WG,
and be able to weight viewpoints, ignore clear company / coalition
bias, etc. If they abuse this, there is the appeal process. ADs are
equally make judgement calls -- and again, there is an appeal / recall
procedure. Appeals are a critical part of our process, and should be
used when appropriate (the very fact that they exist and can be
invoked is also a useful mechanism for mitigating abuse).

W

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Thu, 27 Feb 2020 20:38:43 +0000

Fernando,

In order for an IPv6 node to process the SRH (or other routing header) the address of such router needs to be in the IPv6 Destination Address. Right?

   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.

From this text it is clear to me that we can process extension headers when the packet reaches the node identified in the Destination Address field of the IPv6 header.
From this text it is clear to me that we can delete extension headers when the packet reaches the node identified in the Destination Address field of the IPv6 header.
Processing at the node identified in the Destination Address field of the IPv6 header has exactly the same treatment in the quote above as deletion at the node identified in the Destination Address field of the IPv6 header.

This has nothing to do with SRH insertion by a transit node. This was moved to a separate document and is out of scope of the draft that is being WGLC.

Cheers,
Pablo.

-----Original Message-----
From: ipv6 <[email-masked]> on behalf of Fernando Gont <[email-masked]>
Date: Thursday, 27 February 2020 at 10:07
To: "[email-masked]" <[email-masked]>, "Eric Vyncke (evyncke)" <evyncke=[email-masked]>, Warren Kumari <[email-masked]>, John Leddy <[email-masked]>
Cc: SPRING WG List <[email-masked]>, "[email-masked]" <[email-masked]>, Bob Hinden <[email-masked]>, "Zafar Ali (zali)" <zali=[email-masked]>
Subject: Re: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

    Bruno,

    What is this:????

    

    

    
    Seriously?

    [....]

    Thanks,

---

From: Keyur Patel <[email-masked]>
Date: Fri, 28 Feb 2020 00:16:22 +0000

+1 in support of moving the documentation forward.

Regards,
Keyur

From: spring <[email-masked]> on behalf of "Zafar Ali (zali)" <zali=[email-masked]>
Date: Wednesday, February 26, 2020 at 9:43 AM
To: Lizhenbin <[email-masked]>, "[email-masked]" <[email-masked]>, 'SPRING WG List' <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "Zafar Ali (zali)" <[email-masked]>, draft-ietf-spring-srv6-network-programming <[email-masked]>
Subject: Re: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

+1,

Thanks

Regards … Zafar

Hi Bruno and WG,

Best Regards,
Zhenbin (Robin)

Hello SPRING,

Thank you,

Bruno

Thank you.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 28 Feb 2020 14:47:28 +1300

Stefano,

The problem is that the draft simply doesn't explain (or refer to an explanation) of what this "penultimate segment" is. There are at least three hypotheses which I suspect different people are using, leading to this endless dialogue:

1) It's a forwarding node, a.k.a. a router, that blindly follows the PSP instructions by removing an IPv6 header before forwarding the packet, completely against the text of RFC 8200.

2) It's a node that receives and terminates the packet, and then makes a new one with its own address as source and a new (ultimate) destination address, which doesn't happen to contain an SRH header at all.

3) It's an offload processor in the destination node, that removes some crud (the SRH header) before passing the packet up to the IPv6 stack in the host.

At the moment, a reader of the draft who is not familiar with the details of at least one SRH implmentation cannot decide which of these hypotheses is correct.

Despite numerous requests, and several new versions, the draft still leaves this mystery intact, and is therefore simply not ready for the IESG.

So I repeat my request for the draft to explain what it means by "pop" and by "penultimate segment". If it turns out that we are in case 2) or 3) above, problem solved.

Regards
   Brian Carpenter

---

From: Stefano Salsano <[email-masked]>
Date: Fri, 28 Feb 2020 03:06:50 +0100

Brian,

> 1) It's a forwarding node, a.k.a. a router, that blindly follows the PSP instructions by removing an IPv6 header before forwarding the packet, completely against the text of RFC 8200.

it is a forwarding node, a.k.a. a router, which follows the PSP 
instructions and removes the SRH before forwarding the packet

let me disagree with you on the part "completely against the text of RFC 
8200" :-)

Stefano

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 28 Feb 2020 15:28:12 +1300

> instructions and removes the SRH before forwarding the packet

So could the draft make this explicit, because I guarantee you it is not in the least obvious to the non-expert reader?
 
> let me disagree with you on the part "completely against the text of RFC 

You are trying to squeeze through a very small hole in the relevant paragraph of RFC8200. Either the draft should not do that, or it should explain precisely what this hole is, so that the IETF & IESG can decide whether they agree.

Let's be clear, we're talking about a routing header which in some unclear circumstances instructs a certain router to delete the header en route. It's unclear because the draft doesn't really explain the "flavors" such as PSP or how a router knows algorithmically when to apply the PSP flavor. I don't see how that can be left as an implementation issue.

Regards
    Brian

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Fri, 28 Feb 2020 04:19:52 +0000

Hi Brian,

It is likely that things are not clear if one were to just try to read the text around just the specific section of the draft which covers PSP. The document does needs prior understanding of the SR Architecture RFC8402 and SRH draft in addition to reading of the entire network programming document as a whole to get a full perspective. While we can ask the authors to add text to clarify, it is only fair that we (Spring WG members or those in other WGs) as reviewers of this draft have done our part in studying the whole thing - then there is no mystery and no secrets!

I will try to explain inline below with references to text in drafts (s) inline below.

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Brian E Carpenter
Sent: 28 February 2020 07:17
To: Stefano Salsano <[email-masked]>; Eric Vyncke (evyncke) <evyncke=[email-masked]>; Warren Kumari <[email-masked]>; John Leddy <[email-masked]>
Cc: SPRING WG List <[email-masked]>; [email-masked]; Bob Hinden <[email-masked]>; Zafar Ali (zali) <zali=[email-masked]>
Subject: "penultimate segment" [Re: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming]

Stefano,

[KT] Let me explain with references to text in the draft(s):

It's a router (P router in our example) which has instantiated an SRv6 SID with End behaviour with PSP flavour (sec 4.1 to be read along with sec 4.16.1). The router may also instantiate other SRv6 SID with different behaviours and flavour. These SIDs are then signalled by the router via control plane protocols that include its behaviour (sec 8 and then sec 9.2).

Then we come to RFC8402 which describes the source routing model. Here the source learns of the SIDs in the network and then using the SID list “outsources” the handling to be done for the packet to SRv6 Endpoint Nodes (SRH draft sec 3.3). So the routers which are “waypoints” are actually and specifically instructed to do the operations that they do by the source node. This is fundamental concept of SR that might get missed out.

Then please check out https://tools.ietf.org/html/draft-filsfils-spring-srv6-net-pgm-illustration-01#section-2.8.1 which describes how things are setup and work. This text used to be in the networking programming draft but was removed since "they were just examples" and not normative specification. So you see that nothing here is "blind" here and the source is controlling all the packet processing.

[KT] This is not the case.

[KT] This is one of the use-cases for USP.

[KT] I can understand your pain, but some of these things are parts of a bigger solution and more context is required. The key thing is that there is no secret here and I hope I may have been able to help you.

Thanks,

Ketan

Regards

   Brian Carpenter

>>> "penultimate segment" means what it means in every dictionary, but

>>> this is not in-fligth removal of a header.

>>> When the packet has reached the "penultimate segment", it has

>>> reached a node "identified in the Destination Address field of the

>>> IPv6 header" as stated in RFC 8200, section 4, first paragraph below

>>> the diagram

>> So in what sense is it penultimate (i.e. next to last)? If it has

>> reached the destination address,

> Destination Address = S2, I repeat that at the very end of section 3

> of RFC 8200 the "Destination address" is defined as "address of the

>> I understand this for the following case, Ultimate Segment Pop, where

>> the text refers to processing the packet inside the receiving node.

>> But the text is completely lacking an explanation of the

>> "penultimate" case, and I found nothing about it in other SRH documents either.

>> If I was writing code for this, I would have no idea how to generate

>> a test case.

>> which of "PSP, USP and USD flavors" applies. They don't seem to be

>> marked in the packet in any way.

> it is not marked in the packet, likewise it is not marked in the

> packet which SRv6 behavior is associated with a SID

>> It seems to me that there is something blindingly obvious to SRH

>> specialists that is not stated at all in the draft, so the rest of us

>> simply can't make sense of it. It may or may not be a gap in the

>> protocol, but there is definitely a gap in the description.

>>> is defined as "address of the intended recipient of the packet

>>> (possibly not the ultimate recipient, if a Routing header is present)"

>>>>> Finally, as far as I know, at the IETF we have no religion... else

>>>>> we would still be running NCP or IPv4 :-)

>>>>> From: ipv6 <[email-masked]<mailto:[email-masked]>> on behalf of Warren Kumari

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

>>>>> ------------------------------------------------------------------

>>>>> -- IETF IPv6 working group mailing list [email-masked]<mailto:[email-masked]>

>>>>> Administrative Requests:

>>>>> https://www.ietf.org/mailman/listinfo/ipv6

>>>>> ------------------------------------------------------------------

>>>> -------------------------------------------------------------------

>>>> - IETF IPv6 working group mailing list [email-masked]<mailto:[email-masked]> Administrative

>>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6

>>>> -------------------------------------------------------------------

>>>> -

---

From: S Moonesamy <[email-masked]>
Date: Fri, 28 Feb 2020 01:36:09 -0800

Dear Mr Decraene,
At 12:58 AM 28-02-2020, [email-masked] wrote:
>1) People have the right to express, including to hum sometimes, but 
>decision is not based on the number of "+1".
>Do you have the impression that the decision is based on some voting 
>scheme? (Assuming the decision was made in the first place...) If 
>so, could you please help me see what makes you feel so?

My comment about the above was a response to the comment at 
https://mailarchive.ietf.org/arch/msg/spring/nIAqSeZJKq64QHbyy_ZrNqk_CXg/

>2) As regards to the timing, the duration of the call for comments 
>has indeed elapsed.
>If your comment is related to the actual work, as you may have seen, 
>there has been a high number of comments on the list so there is 
>work to be done on the resolution of the comments. The more 
>comments, the more time. The harder the comment, the more time. I 
>can't provide or force people to provide an ETA for the resolutions 
>of comments. I think that working on improving the document is more 
>important than a few weeks delay. BTW, I'm not aware of specific 
>timing requirement to advance a document to RFC. Closest things I've 
>seen is "SOON" [1] and "timely" [2]

I enquired about the working group process.  I don't see anything in 
the reference to RFC 2026 about Working Group procedures.  The second 
reference is to an Internet-Draft about the definition of the word 
"timely".  As far as I am aware, that Internet-Draft is not part of 
IETF Working Group procedures.

>If your question is related to formal state, is your point that the 
>datatracker state should have been moved from " In WG Last Call " to 
>" Revised I-D Needed - Issue raised by WGLC ". If so, I tend to 
>agree with you. Could/will also be " Doc Shepherd Follow-up 
>Underway" at some point.
>
>That been said, as I've said on the list, the end of the WG LC is 
>not the end of the ability for the WG to make technical comments on 
>the list. [3]. One example may be the latest comment from Chris Bowers.
>
>3) Your specific questions been answered, it's not crystal clear to 
>me what are you trying to achieve with your email. Do you believe 
>the document should advance faster, slower, not advance? That your 
>comments were not adequately answered? (although I'm not seen any 
>comment from your side on the mailing list). Please help me 
>understand your root concern.

My question was about when the the Working Group Last Call ends.  I 
don't view it as appropriate to determine whether the document should 
advance faster or slower as I am not responsible to make such a determination.

Regards,
S. Moonesamy