Subject: [spring] Network Programming - Penultimate Segment Popping

From: Ron Bonica <[email-masked]>
Date: Wed, 4 Dec 2019 16:37:32 +0000

Pablo,

It seems to me that the following are equally controversial:

  *   A transit node inserting a Routing header
  *   A transit node removing a Routing header

We have agreed to move discussion of RH insertion out of the Network Programming draft and into another draft. Shouldn't discussion of RH removal be treated similarly.

This comment applies to Penultimate Segment Popping (PHP) in the Network Programming draft.

                                                                 Ron

Juniper Business Use Only

---

From: Fernando Gont <[email-masked]>
Date: Wed, 4 Dec 2019 16:09:56 -0300

On 4/12/19 13:37, Ron Bonica wrote:
[...]
> We have agreed to move discussion of RH insertion out of the Network
> Programming draft and into another draft. Shouldn’t discussion of RH
> removal be treated similarly.

Of course yes.

It seems there's some level of recurrency in this area. Folks trying to
do an under-the-cover update of RFC8200 (wrt header insertion), or
simply ignoring what RFC8200 says.

We have been a long way in this area (to an extent of having to send
back to the wg what would become RFC8200 (then rfc2460bis) because folks
from one specific vendor were trying to push that agenda.

It would seem to me that having us wg participants remind folks that you
can't just violate specs (RFC8200, and Internet Standard) at will, or
keep an eye on every move that is taken in this respect (e.g.
<https://mailarchive.ietf.org/arch/msg/ipv6/12Qwp_eeQT2EmbUrSxBLL5HTcnM>) does
not seem to be the best way to spend our time, and also becomes
uncomfortable.

It also seems to me that the work of spring and 6man should be better
coordinated. At times it would seem to me like things are cooked up in
spring, and then 6man is expected to adapt to that. -- when, if you want
to change a standard, the place to do it is 6man, and not elsewhere.

So, to make the point clear, until there is a point where there is wg
consensus in 6man to formally update RFC8200, an Internet Standard, can
we please remove from all wg documents any sort of EH
insertion/removal/mangling?

In that light, may I ask the ADs that these things are better taken care
of? And that given the controversy around the topic, any decision taken
in this respect is CC'ed to 6man, and a decision is taken *on the
maIling list* (as it should)?

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

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Thu, 5 Dec 2019 16:50:03 +0000

Hello Ron, I believe this is the fifth time you have raised this comment in 6man and/or spring.
The comment has been addressed in earlier iterations.

Let me recap.

With the PSP behavior, the SRH is only removed by the node identified in the destination address field of the IPv6 header.

That destination address was placed in the SRH by the SR Source node, fully expecting the behavior.

Thanks
  Darren

Iterations:
[2019-09-06] https://mailarchive.ietf.org/arch/msg/spring/7zMgIwEY9AipZCCGO9KnT2CGH3o
[2019-09-27] https://mailarchive.ietf.org/arch/msg/spring/4_Slu3kkHwduZZPFJJmRUkmoTVo
[2019-10-14] https://mailarchive.ietf.org/arch/msg/spring/u536YH4tv7kKRq_b9_x9gBYpO9c
[2019-10-21] https://mailarchive.ietf.org/arch/msg/spring/4pikRli_HSECun9AbwfpmOF5KLI
[2019-12-04] https://mailarchive.ietf.org/arch/msg/spring/oDWLbRDqKCaF5Xa-QvKY6mk_D5E

On Dec 4, 2019, at 11:37 AM, Ron Bonica <rbonica=[email-masked]> wrote:

Pablo,

We have agreed to move discussion of RH insertion out of the Network Programming draft and into another draft. Shouldn’t discussion of RH removal be treated similarly.

                                                                 Ron

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

---

From: Ron Bonica <[email-masked]>
Date: Thu, 5 Dec 2019 20:39:16 +0000

Darren,

I understand that the PSP operation:

  *   Is executed on the penultimate segment endpoint only
  *   Is signaled by the source node using bits in the IPv6 destination address
However, those facts are orthogonal to the question that I asked. So, I will try to ask my question again. Please read it carefully and answer the question that is asked. (Dismissive responses will only make me grumpier.)

Currently, there is no consensus that IPv6 allows insertion of extension headers by intermediate nodes, even if those intermediate nodes are segment endpoints . Given this lack of consensus, the authors of network programming have wisely agreed to remove header insertion from the draft.

Likewise, there is no consensus that IPv6 allows removal of extension headers by intermediate nodes, even if those intermediate nodes are segment endpoints. Why, then, have the authors of network programming not agreed to remove PSP from the draft?

                                                                                           Ron

Juniper Business Use Only
From: Darren Dukes (ddukes) <[email-masked]>
Sent: Thursday, December 5, 2019 11:50 AM
To: Ron Bonica <[email-masked]>
Cc: SPRING WG <[email-masked]>; 6man <[email-masked]>
Subject: Re: Network Programming - Penultimate Segment Popping

Let me recap.

Thanks
  Darren

Iterations:
[2019-09-06] https://mailarchive.ietf.org/arch/msg/spring/7zMgIwEY9AipZCCGO9KnT2CGH3o<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/spring/7zMgIwEY9AipZCCGO9KnT2CGH3o__;!8WoA6RjC81c!T981Kv39IIsXJ2I3jiE36cVdwwLgIWJoFBUg_AnU8IEb9Y_6GbNWAykRc82ck-xk$>

On Dec 4, 2019, at 11:37 AM, Ron Bonica <rbonica=[email-masked]<mailto:rbonica=[email-masked]>> wrote:

Pablo,

                                                                 Ron

Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!8WoA6RjC81c!T981Kv39IIsXJ2I3jiE36cVdwwLgIWJoFBUg_AnU8IEb9Y_6GbNWAykRc6EiWnkb$>

---

From: Fernando Gont <[email-masked]>
Date: Thu, 5 Dec 2019 17:50:41 -0300

On 5/12/19 13:50, Darren Dukes (ddukes) wrote:
> With the PSP behavior, the SRH is only removed by the node identified in
> the destination address field of the IPv6 header.

The question if simple: If SRH is removed by the very node identified by
the destination address when SL !=0, then that's a middlebox mangling
with SRH, and not allowed by RFC8200.

> fully expecting the behavior.

Yes, SRv6 folks have expected insertion, too. However, we have an
internet standard that forbids that (including removal by middleboxes),
and hence that's not allowed -- unless you get consensus to update RFC8200.

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

---

From: [email-masked]
Date: Thu, 5 Dec 2019 21:57:01 +0100

Ron,

> Likewise, there is no consensus that IPv6 allows removal of extension headers by intermediate nodes, even if those intermediate nodes are segment endpoints. Why, then, have the authors of network p…

With regards to working group process; may I gently remind you that it is the chairs that call consensus.

Best regards,
Ole

---

From: Ron Bonica <[email-masked]>
Date: Thu, 5 Dec 2019 21:04:58 +0000

Ole,

Point taken. Could you comment on the current state of WG consensus?

                                                              Ron

-----Original Message-----
From: [email-masked] <[email-masked]> 
Sent: Thursday, December 5, 2019 3:57 PM
To: Ron Bonica <[email-masked]>
Cc: Darren Dukes (ddukes) <[email-masked]>; SPRING WG <[email-masked]>; 6man <[email-masked]>
Subject: Re: Network Programming - Penultimate Segment Popping

Ron,

Best regards,
Ole

---

From: [email-masked]
Date: Thu, 5 Dec 2019 22:16:09 +0100

Ron,

> Point taken. Could you comment on the current state of WG consensus?

The working group session in Singapore ended with what appeared to be a view that we should continue work on both documents (Mark's and the Voyer draft).
For the state of the wg consensus, I haven't checked with Bob, but I think he will agree with it being classified as "evolving".

Best regards,
Ole

---

From: Fernando Gont <[email-masked]>
Date: Thu, 5 Dec 2019 18:23:34 -0300

Ole,

> With regards to working group process; may I gently remind you that it is the chairs that call consensus.

At the time of this writing, there's no document that has been adopted
to update RFC8200 to allow for EH insertion/removal.

Therefore, it's actually the other way around: unless there's such
document (which there isn't, since such a document has never been
adopted by 6man), the onus is on folks trying to change the status quo.
And that case, progressing the document "as is" would be an outright
violation of our existing standards.

This has been repeated numerous times already.

I think we are at a point where the ADs should take action. Most
importantly Int-AD, since the spec being violated is RFC8200.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 5 Dec 2019 18:32:09 -0300

Ole,

> For the state of the wg consensus, I haven't checked with Bob, but I think he will agree with it being classified as "evolving".

I polled you about this decision
(https://mailarchive.ietf.org/arch/msg/ipv6/12Qwp_eeQT2EmbUrSxBLL5HTcnM), and
you never responded.

Suresh (INT AD) clarified this one list, here:
https://mailarchive.ietf.org/arch/msg/ipv6/Db6_SGfmeIDzaE56Ps5kUDCYEzY

Suresh noted that there wasn't consensus call, even at the f2f meeting
(not to mention that the list was never polled in this respect).

I would say that it seems we have not been following the processes that
should be followed. This has happened repeatedly over time, for this
very same topic. The process seems to be biased, and thus unfair to the
rest of the wg participants.

Thanks,

---

From: [email-masked]
Date: Thu, 5 Dec 2019 22:41:33 +0100

Fernando,

> (https://mailarchive.ietf.org/arch/msg/ipv6/12Qwp_eeQT2EmbUrSxBLL5HTcnM), and

Sorry, which decision is that supposed to be?

> (not to mention that the list was never polled in this respect).

Right, neither of these two documents are adopted as working group documents. And perhaps a more correct phrasing above would be that "The working group session in Singapore ended with what appeared to be a view that work could continue on both of these documents".

> rest of the wg participants.

Which process are you talking about? Is that documented in an RFC?
You seem to take it on yourself to represent the "rest of the wg participants", but from my perspective it looks like a few very loud voices.
Perhaps we should let others speak up, if there is anything more to be said on this topic.

Ole

---

From: Fernando Gont <[email-masked]>
Date: Thu, 5 Dec 2019 18:50:32 -0300

> Sorry, which decision is that supposed to be?

The documents were adopted, or they were not. In this case, they were
not. Hence the current standards need to be complied with, and folks
cannot processes this document with text that results in an outright
violation of RFC8200.

> Right, neither of these two documents are adopted as working group documents. And perhaps a more correct phrasing above would be that "The working group session in Singapore ended with what appeare…

Not sure what you mean. Yes, sure: these are individual contributions.
The authors can do what they please with their individual contributions,
since they don't represent wg consensus. That includes continue working
on them, abandoning them, or simply delete all content and revise the
document as blank documetns with just boiler-plates.

Until the point the wg has adopted such documents, I have no idea
whatsoever why the mere existence of such *individal submissions* should
affect the requirement to comply with our existing specs.

> Which process are you talking about? Is that documented in an RFC?

Yes: RFC2026 and RFC2418.

> You seem to take it on yourself to represent the "rest of the wg participants", but from my perspective it looks like a few very loud voices.

I don't. Again: unless folks get consensus to update RFC8200, thy should
comply with it. The onus is on them, not on us asking folks to comply
with existing standards.

Thanks,

---

From: [email-masked]
Date: Thu, 5 Dec 2019 23:01:08 +0100

> Yes: RFC2026 and RFC2418.

More specifically?
And if you feel you need to the conflict resolution and appeals process is described in rfc2026, section 6.5.

> comply with it. The onus is on them, not on us asking folks to comply

Yes, we have heard your position on this now.
There is of course a lot more nuance to this argument.

Best regards,
Ole

---

From: Tom Herbert <[email-masked]>
Date: Thu, 5 Dec 2019 14:02:59 -0800

Ole,

I'm not sure what the outcome to the working group session means in
terms of the process. Basically, we have two documents that almost
directly contradict each other (the EH insertion is bad one was in
fact written in response to the EH insertion is good document). They
both can't be right, and Network programming is still assuming the
outcome that EH insertion/intermediate node removal is correct. So to
continue to work on both documents seems to be akin to punting the
disagreement without clarity on how this will ever be resolved. Also,
I'd point out that the EH insertion document is over a year old and
has already been reviewed, I don't see what new information could be
provided at this point that would change the fundamental arguments
against it.

Can we ask for call for working group adoption call on these?

Tom

> [email-masked]

---

From: Ron Bonica <[email-masked]>
Date: Thu, 5 Dec 2019 22:08:53 +0000

Peace Gentlemen,

For the purpose of this thread, I think that we have all of the information that we need. Consensus regarding header insertion and removal is "evolving". 

We need to let that evolution progress, and not make any assumptions regarding its outcome.

                                                        Ron

-----Original Message-----
From: [email-masked] <[email-masked]> 
Sent: Thursday, December 5, 2019 4:42 PM
To: Fernando Gont <[email-masked]>
Cc: Ron Bonica <[email-masked]>; SPRING WG <[email-masked]>; 6man <[email-masked]>; [email-masked]; rtg-ads <[email-masked]>
Subject: Re: We don't seem to be following our processes (Re: Network Programming - Penultimate Segment Popping)

Fernando,

> (https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/ipv
> 6/12Qwp_eeQT2EmbUrSxBLL5HTcnM__;!8WoA6RjC81c!QH6T9eu4QEGAh1tVtPAiXW2SjsZMxfQdUYen3nv2CPDS4DWlFeKu7c4TwztzwnbH$ ), and you never responded.

> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/ipv6
> /Db6_SGfmeIDzaE56Ps5kUDCYEzY__;!8WoA6RjC81c!QH6T9eu4QEGAh1tVtPAiXW2Sjs
> ZMxfQdUYen3nv2CPDS4DWlFeKu7c4Tw1iPjJAl$
> 

> I would say that it seems we have not been following the processes 
> that should be followed. This has happened repeatedly over time, for 
> this very same topic. The process seems to be biased, and thus unfair 
> to the rest of the wg participants.

Ole

---

From: Fernando Gont <[email-masked]>
Date: Thu, 5 Dec 2019 19:19:00 -0300

Ole,

On 5/12/19 19:01, [email-masked] wrote:
[...]
> There is of course a lot more nuance to this argument.

Could you please, as wg chair, elaborate on this?

Thanks,

---

From: Enno Rey <[email-masked]>
Date: Thu, 5 Dec 2019 23:27:40 +0100

Hi Ole,

> There is of course a lot more nuance to this argument.

could you please explain said 'nuance' in more detail?

thank you in advance for your efforts

Enno

-- 
Enno Rey

Cell: +49 173 6745902
Twitter: @Enno_Insinuator

---

From: Enno Rey <[email-masked]>
Date: Thu, 5 Dec 2019 23:47:46 +0100

Hi Ron,

> For the purpose of this thread, I think that we have all of the information that we need. Consensus regarding header insertion and removal is "evolving". 

not meaning to nitpick and admittedly I'm not super-familiar with all nuances of IETF processes but this means that no type of consensus has been reached yet, correct?

thanks

Enno

-- 
Enno Rey

Cell: +49 173 6745902

---

From: Ron Bonica <[email-masked]>
Date: Fri, 6 Dec 2019 00:20:00 +0000

Enno,

That is how I parse Ole's message. But we can let Ole speak for himself.

                                           Ron

-----Original Message-----
From: Enno Rey <[email-masked]> 
Sent: Thursday, December 5, 2019 5:48 PM
To: Ron Bonica <[email-masked]>
Cc: [email-masked]; Fernando Gont <[email-masked]>; SPRING WG <[email-masked]>; 6man <[email-masked]>; [email-masked]; rtg-ads <[email-masked]>
Subject: Re: We don't seem to be following our processes (Re: Network Programming - Penultimate Segment Popping)

Hi Ron,

thanks

Enno

> Cc: Ron Bonica <[email-masked]>; SPRING WG <[email-masked]>; 
> 6man <[email-masked]>; [email-masked]; rtg-ads 
> <[email-masked]>
> Subject: Re: We don't seem to be following our processes (Re: Network 
> Programming - Penultimate Segment Popping)
> 
> Fernando,
> 
> > /Db6_SGfmeIDzaE56Ps5kUDCYEzY__;!8WoA6RjC81c!QH6T9eu4QEGAh1tVtPAiXW2S
> > js ZMxfQdUYen3nv2CPDS4DWlFeKu7c4Tw1iPjJAl$
> > 
> > Suresh noted that there wasn't consensus call, even at the f2f 
> > meeting (not to mention that the list was never polled in this respect).
> 
> > this very same topic. The process seems to be biased, and thus 
> > unfair to the rest of the wg participants.
> 
> Administrative Requests: 
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6
> __;!8WoA6RjC81c!TjLEU67_JCgw5HSu4C7UhFOC61xLkOhpmW0Ev51wqvHbECMOysxK3t
> 9RS5pxqO3g$

--
Enno Rey

Cell: +49 173 6745902

---

From: Bob Hinden <[email-masked]>
Date: Thu, 5 Dec 2019 16:29:51 -0800

Hi,

> On Dec 5, 2019, at 16:20, Ron Bonica <rbonica=[email-masked]> wrote:
> 
> Enno,
> 

To clarify, the current consensus is the text in RFC8200.   

There is discussion ongoing in 6man on this topic, but it is impossible to say how that will turn out, or when. 

Bob

---

From: Fernando Gont <[email-masked]>
Date: Thu, 5 Dec 2019 21:49:38 -0300

Hello, Bob,

> There is discussion ongoing in 6man on this topic, but it is impossible to say how that will turn out, or when. 

Thanks for the clarification!

So we go back to the original issue: The document being lastcalled in
spring/6man contains text (Penultimate Segment Popping) that causes the
SRH to be removed while on flight to the destination.

Since such text violates RFC8200, it should be removed from the document
(in the same way that the authors have already removed the insertion part).

Thanks!

Cheers,

---

From: [email-masked]
Date: Fri, 6 Dec 2019 09:34:46 +0100

Enno,

> could you please explain said 'nuance' in more detail?

I could try, although I fear it will be a rehash of what has already been said many times already in this debate.

The IETF and the Internet architecture has a pugnacious relationship with packet mangling in the network.
Steve embodied the Internet architeure principles in the IPv6 protocol suite.
The IPv6 architecture consists only of routers and hosts (no middleboxes).
Ensuring that routers would not need to process further into the packet than the IPv6 header, and ensure that extension header chains were expensive to parse in hardware. As well as requiring all implementations to support IPsec. Knowing that encryption was the only way to guarantee end to end transparency.

Now, contrast that with the "real world", I challenge you to find a service on the Internet where the packet isn't mangled in some way between the two end-points. Be that IPv4 or IPv6.

The problems with header insertion on the open Internet are well understood.

That's not what is being discussed here though.
What is discussed here is what is acceptable to do within a limited domain.
To packets that _you_ own, i.e. originate and terminate within a domain where you control all devices.

If I own and manage three routers, R1 -- R2 -- R3.
You are saying that if R1 sends a packet to R3, it is not allowed to off-load some functions to R2?
Going to be difficult to do stuff like service chaining then.

When putting in the restrictions in RFC8200, which makes a lot of sense on the open Internet, it was always clear that there could and would be exceptions to this. Those are the ones we are discussing now.

Conflating the two use cases and claiming that the arguments for why it's a bad idea on the open Internet also applies to a limited domain, only serves to polarise the debate.

My suspicion is that the header insertion argument is a straw-man.

Best regards,
Ole

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 6 Dec 2019 10:09:29 -0500

Ole, there is no IETF accepted definition of "limited domain".
There is no IETF rough consensus that it is sensible for us to 
standardize things for "limtied domains".
While there are standards that are designed for specific deployments, 
they do not to date use that as an excuse to violate existing RFCs.

Hence, as far as I can tell, the assertion that SRv6 is for limited 
domains does not justify or excuse violating RFC 8200.  And "I want to 
save some bytes", while very nice, is not a sufficient reason to violate 
an approved RFC, must less a Full Standard.

Yours,
Joel

---

From: Sander Steffann <[email-masked]>
Date: Fri, 6 Dec 2019 16:12:48 +0100

Hi Ole,

> Going to be difficult to do stuff like service chaining then.

This bit I don't mind that much, but what about:

R1 -- R2 -- [open internet] -- R3
or
R1 -- [open internet] -- R2 -- R3
or even
R1 -- [open internet] -- R2 -- [open internet] -- R3

And what if you're an ISP and R1 is your customer's device? It is in your routing domain but not in your administrative domain. What then?

> When putting in the restrictions in RFC8200, which makes a lot of sense on the open Internet, it was always clear that there could and would be exceptions to this. Those are the ones we are discuss…

This has never been clear to me. Quite the opposite actually…
There was a reason the text discussing this was tightened while RFC8200 was still a draft.

> Conflating the two use cases and claiming that the arguments for why it's a bad idea on the open Internet also applies to a limited domain, only serves to polarise the debate.

The problem is in the definition (and viability) of a domain.

> My suspicion is that the header insertion argument is a straw-man.

Not to me. I care about my packets not being mangled by a third party (my ISP). If there is a way that they can mangle the packet and restore it to its original 100% of the time before a box outside the ISP network is able to see it (for debugging or whatever) then I don't mind. I care about observable behaviour, and whether my ISP uses MPLS, SR or something else isn't my problem. But the moment the packet leaves their network it'd better be exactly as I sent it. And the way the domain is defined, as well as the operator experience with limited domains, points to potential leaks.

Cheers,
Sander

---

From: Tom Herbert <[email-masked]>
Date: Fri, 6 Dec 2019 07:58:39 -0800

> There is discussion ongoing in 6man on this topic, but it is impossible to say how that will turn out, or when.
Bob,

The advice from the chairs seems to be continue discussion. The
problem with that is that EH insertion has been discussed ad nauseum
over the past two years since the draft first appeared. It seems like
we are at the point where the same arguments on the topic are just
being rehashed on the list. As you mention above, the current
consensus is that the EH insertion conflicts with RFC8200. Right now
it seems like further discussion is open ended and without any
constraints a likely outcome will be attrition and eventual
acquiescence to accepting yet another non-conformant protocol that
became so widely deployed so that it can be fixed.

In light of this, can the chairs or AD provide some guidance or
expectations on framing any further discussion on the topic to ensure
that it's productive and the process is moving forward.

Thanks,
Tom

>over the

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 6 Dec 2019 17:15:12 +0100

Hi Sander,

To your specific first question this is very popular deployment model ..
just look at SDWANs. So Internet is just a L3 transport for all routers in
your administrative domain or global WAN. Spot on. I do sincerely hope that
whatever the result be of this debate all features will be legal to run on
my boxes regardless how I choose to interconnect them.

As (Internet) transit boxes would never be destination addresses of the
outermost header what problem do you see running anything one likes on R1
or R2 or R3 and transporting it via open Internet or perhaps some third
party networks ?

Just pls limit the answer to technical points if at all possible.

And if your first point is MTU then assume I have this solved by code
running between my routers in the overlay even including making sure that
my probe is inline with the data - hence identical ECMP hashing.

Best,
R.

On Fri, Dec 6, 2019 at 4:13 PM Sander Steffann <[email-masked]> wrote:

> And what if you're an ISP and R1 is your customer's device? It is in your
> routing domain but not in your administrative domain. What then?
>
>

---

From: Sander Steffann <[email-masked]>
Date: Fri, 6 Dec 2019 17:21:32 +0100

Hi Robert,

> To your specific first question this is very popular deployment model .. just look at SDWANs. So Internet is just a L3 transport for all routers in your administrative domain or global WAN. Spot on. I do sincerely hope that whatever the result be of this debate all features will be legal to run on my boxes regardless how I choose to interconnect them.
> 
> As (Internet) transit boxes would never be destination addresses of the outermost header what problem do you see running anything one likes on R1 or R2 or R3 and transporting it via open Internet or perhaps some third party networks ?

So this is basically a tunnel over the open internet with all tunnel endpoints in the same (or cooperating) administrative domain. In that case it's indeed up to the participants to deal with and debug.

So the tunnel model I don't mind. Can we be certain it indeed fits all deployments and leaking isn't possible. Theory and practice are the same in theory, but not in practice :)

Cheers,
Sander

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 6 Dec 2019 17:31:47 +0100

Hi,

Inline.

On Fri, Dec 6, 2019 at 5:21 PM Sander Steffann <[email-masked]> wrote:

> So this is basically a tunnel over the open internet with all tunnel
> endpoints in the same (or cooperating) administrative domain. In that case
> it's indeed up to the participants to deal with and debug.
>

Ok very cool. So it looks like we have quick and easy agreement on that
one. Chairs please take a note on that.

So the tunnel model I don't mind. Can we be certain it indeed fits all
> deployments and leaking isn't possible. Theory and practice are the same in
> theory, but not in practice :)
>

Very true - no argument. But what is "leaking" ? If I am forwarding within
my own address space as we just agreed this is ok - no leaking. Now if I
will construct the packet stuff it with whatever legal or illegal EHs and
send it towards the address that does not belong to me - this is not
leaking but an attack vector.

Can this happen - oh yes. Almost certainly it will happen. So we need to
protect our edges from such attacks regardless what 6man or spring or xyz
will standardize or allow to insert or remove from the packet header.

Sounds to me like a very important topic but a bit orthogonal to subject of
this specific thread.

Many thx,
R.

---

From: Bob Hinden <[email-masked]>
Date: Fri, 6 Dec 2019 08:52:55 -0800

Hi Tom,

> On Dec 6, 2019, at 7:58 AM, Tom Herbert <[email-masked]> wrote:
> 

I think the difference in what is happening now, is that we have two drafts that are being discussed instead of just volumes of email.   This is the process that should allow us to see if there is a consensus beyond what is in RFC8200.   I won’t speculate what the outcome of this will be.

IETF standards are voluntary, and are designed to create interoperability between different implementations.   Since we don’t have IETF Protocol Police we can’t do anything about other approaches.   However, I note that many customers prefer products that support interoperability between different implementations and vendors.

> that it's productive and the process is moving forward.

My take is that the discussion of the two drafts in 6man should continue.   Any work that wants to rely an outcome of that discussion, should wait.   As I said earlier, it’s hard to say when that will be done.   Otherwise, I think the other work should be compatible with what is in RFC8200.

Bob

---

From: Fernando Gont <[email-masked]>
Date: Fri, 6 Dec 2019 13:58:22 -0300

Ole,

Let me highlight a few things before getting into specific comments.

1) The IETF has no consensus about the concept of "limited domains" that
you are referring to. That means that there are no nuances in this
respect: a document that violates RFC8200, violates RFC8200. And if
there is no consensus to formally update RFC8200, then it should not be
violating it.

2) No document has been adopted in that line. Not wg call for adoption
was even done in that line. Hence, the status of an individual proposal
in that respects bears no change when it comes to #1 above.

3) As a wg participant, of course you are entitled to have any view
whatsoever on the topic. But as a wg chair, I would expect you to
respect and pursue the above, which are our existing processes,
practices, and ruls. Otherwise that would seem like an indication of
conflict of interests to me.

Do you want to change that? -- Fine. Write a draft, and get consensus to
push it forward. That's what mere mortals like myself that do not work
for a big powetful vendor are normally required to do.

More in-line....

On 6/12/19 05:34, [email-masked] wrote:
> Ensuring that routers would not need to process further into the packet than the IPv6 header, and ensure that extension header chains were expensive to parse in hardware. As well as requiring all implementations to support IPsec. 

Some folks have provided anecdotal evidence that rather than the goal
being "make them hard to process in hardware", the thing is that
software processing was common at the time. (i.e., change in paradigm,
if you want)

[...]
> Now, contrast that with the "real world", I challenge you to find a service on the Internet where the packet isn't mangled in some way between the two end-points. Be that IPv4 or IPv6.

All these documents are about mangling, as opposed to processing. e.g. a
firewall does process packets, but does not heavy surgery as in SRv6.

> The problems with header insertion on the open Internet are well understood.

Unless you are doing SRv6 in an isolated network (some community
network?)m then you are doing EH insertion in the open Internet.

The argument behind folks pushing EH-insertion is "I have my network
(part of the Internet) and can do SR in a way that I can clean up before
the packets leave the network". But that's still the Internet. And the
issues in draft-smith-6man-in-flight-eh-insertion-harmful still apply.

> If I own and manage three routers, R1 -- R2 -- R3.

IPv{4,6} as internet protocols. We don't have variants of them.

Besides,

H1 --- R1 ---R2 --- R2 ----- Other networks --- H2

is still the internet. The fact that you operate part of it means just that.

> When putting in the restrictions in RFC8200, which makes a lot of sense on the open Internet, it was always clear that there could and would be exceptions to this. Those are the ones we are discuss…

That is obviously not true.

Even when RFC8200 does not have RFC2119, it does have wording that uses
"must" in the area of not mangling with EHs. In fact, I should remind
you that rfc2460bis wouldn't go past its first IETF LC without making
this change and making the topic crystal clear.

Thanks,

---

From: [email-masked]
Date: Fri, 6 Dec 2019 18:06:10 +0100

Tom,

> that it's productive and the process is moving forward.

You should absolutely continue the discussion.
Let me share a secret with you. Please don't share.
The 6man working group has been tasked by the IETF leadership to
ensure engaging discussions all year around.
I have not been told the hidden establishment agenda behind this,
but I can only presume that it is to keep the IPv6 enthusiasts
away from affecting the real work being done in other areas of the IETF.

The leadership has tasked us with circulating the discussions between the following topics:
 - 64 bit boundary
 - M/O bits
 - ULA or not ULA
 - Extension headers
 - Defining new mechanisms for IID formats

There is a scheduled switch to the M/O bits topic in mid January.
Please continue to the good work on EH in the meantime.

Ole

---

From: Fernando Gont <[email-masked]>
Date: Fri, 6 Dec 2019 14:16:42 -0300

Bob,
[....]
> I think the difference in what is happening now, is that we have two drafts that are being discussed instead of just volumes of email.   This is the process that should allow us to see if there is…

There is a side "question" on the table: the spring/5man document
currently being wglc'ed violates RFC8200.

Are we all in agreement that until the point there's consensus to update
RFC8200 to allow EH-insertion, our specs should be complied with, and
the relevant text should be removed from the spring document?

> 
> IETF standards are voluntary, and are designed to create interoperability between different implementations.   Since we don’t have IETF Protocol Police we can’t do anything about other approaches.  

But we do produce standards and have a say on what we publish.

> My take is that the discussion of the two drafts in 6man should continue.   Any work that wants to rely an outcome of that discussion, should wait.   As I said earlier, it’s hard to say when that w…

Agreed. And this answers the question I posed above.

Thanks!

Cheers,

---

From: Tom Herbert <[email-masked]>
Date: Fri, 6 Dec 2019 09:38:42 -0800

Ole,

Bear in mind that quality discussion is real work by those
participating. It is a lot of effort to carefully read drafts, give
clear feedback, and respond to rebuttals. I would like to think that
the work individuals put in is justified by the outcome, and I assume
it the chairs prerogative to steer the discussion as necessary to
drive towards a discernible outcome in a finite amount of time.

Tom

---

From: [email-masked]
Date: Fri, 6 Dec 2019 20:13:57 +0100

Tom,

> drive towards a discernible outcome in a finite amount of time.

Absolutely.
Unfortunately the IETF process is open to attacks.
It appears that something akin to a proxy war is being fought.
Some things has to be in place for a consensus based process to work,
which looks to be missing here.

While the chairs have some tools to their disposition; for this to work
it requires the actors and the whole community to respect and
self-police that process.

How frustrating it may be for the spectators,
letting it play out may be the best option we got.

Best regards,
Ole

---

From: Andrew Alston <[email-masked]>
Date: Fri, 6 Dec 2019 19:25:51 +0000

Ole,

While I may agree with you that is an attack on process here – and you may even find consensus on that statement – I am far from convinced you would find consensus on the question of which group is conducting the attack on process.

Andrew

From: spring <[email-masked]> on behalf of "[email-masked]" <[email-masked]>
Date: Friday, 6 December 2019 at 22:14
To: Tom Herbert <[email-masked]>
Cc: Ron Bonica <rbonica=[email-masked]>, SPRING WG <[email-masked]>, 6man <[email-masked]>, "[email-masked]" <[email-masked]>, Bob Hinden <[email-masked]>, rtg-ads <[email-masked]>, Fernando Gont <[email-masked]>
Subject: Re: [spring] We don't seem to be following our processes (Re: Network Programming - Penultimate Segment Popping)

Tom,

Absolutely.

Best regards,
Ole

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

---

From: [email-masked]
Date: Fri, 6 Dec 2019 20:42:03 +0100

> While I may agree with you that is an attack on process here – and you may even find consensus on that statement – I am far from convinced you would find consensus on the question of which group is…

From https://mailarchive.ietf.org/arch/browse/ipv6/?qdr=m&so=frm

The last month's 10 top posters are:
Fernando: 25
Ole:      17 (including this message :-))
Bob:      12
Brian:    11
Ron:      10
Tom:       9
Gyan:      8
Sander:    8
Andrew:    7
Enno:      6

Ole

---

From: Andrew Alston <[email-masked]>
Date: Fri, 6 Dec 2019 19:48:13 +0000

So you have a bunch of people who have actively read and participated in the process – in order to ensure that was emerges from the IETF are documents that are satisfactory and do not violate other drafts and impose things on operators that some operators find unacceptable?

I would believe that these people should be applauded for their participation – they actually read the drafts and took the time to do the reviews.  I’m proud my name is on this list

Andrew

From: "[email-masked]" <[email-masked]>
Date: Friday, 6 December 2019 at 22:42
To: Andrew Alston <[email-masked]>
Cc: Tom Herbert <[email-masked]>, Ron Bonica <rbonica=[email-masked]>, SPRING WG <[email-masked]>, 6man <[email-masked]>, "[email-masked]" <[email-masked]>, Bob Hinden <[email-masked]>, rtg-ads <[email-masked]>, Fernando Gont <[email-masked]>
Subject: Re: [spring] We don't seem to be following our processes (Re: Network Programming - Penultimate Segment Popping)

> While I may agree with you that is an attack on process here – and you may even find consensus on that statement – I am far from convinced you would find consensus on the question of which group is…

From https://mailarchive.ietf.org/arch/browse/ipv6/?qdr=m&so=frm<https://mailarchive.ietf.org/arch/browse/ipv6/?qdr=m&so=frm>

Ole

---

From: Ron Bonica <[email-masked]>
Date: Fri, 6 Dec 2019 19:48:39 +0000

Ole,

I am not quite sure how to take this email. Are you suggesting that we should review less, post less, and let the rubber stamping begin?

Since you have named me, personally, are you suggesting that my contributions have been less than helpful.

                                                                                                 Ron
                                                                                                  (fairly upset)

-----Original Message-----
From: [email-masked] <[email-masked]> 
Sent: Friday, December 6, 2019 2:42 PM
To: Andrew Alston <[email-masked]>
Cc: Tom Herbert <[email-masked]>; Ron Bonica <[email-masked]>; SPRING WG <[email-masked]>; 6man <[email-masked]>; [email-masked]; Bob Hinden <[email-masked]>; rtg-ads <[email-masked]>; Fernando Gont <[email-masked]>
Subject: Re: [spring] We don't seem to be following our processes (Re: Network Programming - Penultimate Segment Popping)

> While I may agree with you that is an attack on process here – and you may even find consensus on that statement – I am far from convinced you would find consensus on the question of which group is…

From https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/browse/ipv6/?qdr=m&so=frm__;!8WoA6RjC81c!S6FKrq2Xdn2_T2g0140QWYsg_JFo3VitTbn1Jsdnz7Hvh5mRgNDATSSm3OJBQ82k$ 

Ole

---

From: [email-masked]
Date: Fri, 6 Dec 2019 21:16:34 +0100

Hi Ron,

> I am not quite sure how to take this email. Are you suggesting that we should review less, post less, and let the rubber stamping begin?

No, not at all. And if it was open for that interpretation I am sorry.
But there are a should's all of us could improve on.
- not repeat the same argument again and again
- think twice before sending another email (yes, I know I have failed terribly today)
- contribute positively, and contribute to document text
- try to find consensus with our opponents
- ...

> Since you have named me, personally, are you suggesting that my contributions have been less than helpful.

No, of course not. A list of top ten posters in the last 30 days does of course not give any indication of quality of contribution.
And the only thing that statistics says is that within the last 30 days you are ranked 5th in the number of messages you have sent.
(Not that I think we would want to or could measure such a thing.)

112 of 162 messages in the last 30 days are sent by the top ten posters.
Most of them are on one side of the EH insertion argument.

With regards to Andrew's comment, draw your own conclusion.

Best regards,
Ole

PS: To take my own advice, believing that I have made my points too many times already, I will try my best to avoid any further postings on this subject.
Have a nice weekend.

---

From: Ron Bonica <[email-masked]>
Date: Fri, 6 Dec 2019 20:26:07 +0000

Ole,

In that case, peace!

                               Ron

-----Original Message-----
From: [email-masked] <[email-masked]> 
Sent: Friday, December 6, 2019 3:17 PM
To: Ron Bonica <[email-masked]>
Cc: Andrew Alston <[email-masked]>; Tom Herbert <[email-masked]>; SPRING WG <[email-masked]>; 6man <[email-masked]>; [email-masked]; Bob Hinden <[email-masked]>; rtg-ads <[email-masked]>; Fernando Gont <[email-masked]>
Subject: Re: [spring] We don't seem to be following our processes (Re: Network Programming - Penultimate Segment Popping)

Hi Ron,

Best regards,
Ole

---

From: Fernando Gont <[email-masked]>
Date: Fri, 6 Dec 2019 18:08:59 -0300

[....]

I don't think there is much room for interpretation here, but anyway I
should ask: are you suggesting that I have attacked or been attacking
the process? -- that's quite a statement from a wg chair to a wg
participant. And if not, I wonder what you are trying to illustrate with
the posted stats.

While one may or may not like loud folks, I'm not sure there's much
process specified in that respect. We do have, however, a process that
involves things like "doing a wg call for adoption in order for a wg to
work on a document", or even "make decisions on the mailing list".

What triggered the subject of this thread was, indeed, the fact that you
were implying that 6man had made a decision to work on EH insertion,
without a call for adoption of the relevant document, and without the
list given the chance to have an opinion.

Similarly, we have IETF consensus on what's in RFC8200. You may like it
or not. It may be good or not. But that's the consensus that we have.
But then you start with your rationale about limited domains (for which
there's no consensus) as an argument for folks being able to violate our
*That* is what I would deem as an attack of the process.

The above, that is, not having the wg make the decisions, and finding
ways to violate existing spec without following the due process, is what
would seem to me as an attack to the process.

As someone that is very involved in 6man, that tries to follow the
process as closely as possible, of course I've been loud on the topic.
The above has a lot to do with the fairness environment in which we are
operating, and remaining silent about it would be part of the problem.

You are a 6man wg chair. What I have been trying hard to is for the
decisions to be taken by the wg in a fair way (e.g. when it comes to a
decision to work on a document), and for the existing specs to be
respected and complied with unless there's formal consensus not to
change the specs.

Is being loud about that "attacking the process"? Or is that actually
that should simply happen without any participant asking, anyway?

Other than the theories of "proxy wars" do you've mentioned... have you
considered that there might be a conflict of interests going on, here?
e.g. between the working group consensus and a vendor's agenda?  As
chair, it is the wg that you serve.

We have been a long way when it comes to SRv6. It can be summarized to
include things like:

* When it comes to EH-insertion, rather than come up with a proposal to
say "hey, we want to change the standard, and this is the reason why",
there have been all sorts of manipulations of different kinds.

*  The first one being the claim that there was ambiguity in RFC2460
related to EH-insertion. Which, of course, everyone knew wasn't true.

* But, given the discussion, a number of us suggested that it should be
made even more crystal clear. Even after the insistence of many of us,
6man managed to ship rfc2460bis with such "ambiguity" in, simply because
a large number of folks (from the same vendor with a strong interest in
doing EH insertion), popped up on the list to move things forward "as
is". I did note this to Suresh at the time.... but the document shipped,
anyway.

* An heterogeneous group of folks (Jinmei, Enno, myself, Mark, and
others) weighed in during IETF LC. And then finally the corresponding
"clarification" (which I think was clear to everyone, anyway) was added
to what would eventually become RFC8200.

* During IESG review, it was somehow suggested by a folk (from the same
vendor as in other cases of the previous bullets) that before proceeding
with the publication of this document, we should essentially wait for a
proposal for EH-insertion to be worked out. Fortunately, RFC8200 was
approved and published, anyway.

* spring seems to have continued operating as if EH-insertion was
allowed. -- what looks to me a bit like "cook things up far from 6man",
which is of course unacceptable, since it is 6man that's in charge of
IPv6 standardization.

* When this was raised on 6man, and pointed out, then  we now heard
(after the said failure of "ambiguity in rfc2460" try), that it's okay
for them to violate RFC8200 and do EH-insertion, because they are
operating in a "limited domain" (when the IETF has consensus even about
what a "limited domain" is).

* Then you noted that 6man had decided to work on EHs at Singapore. And
when I polled you about that (how come?), you essentially asked me to go
look at the videos and minutes. But it turns out that there was no call
for adoption of any eh-insertion document (either in favour or against),
and obviously the list wasn't polled about it, either.

As noted, I have simply been trying hard for the decisions to be taken
by the wg (as opposed to "magical consensus"), and for the existing
specs to be respected and complied with unless there's formal consensus
not to do so.

Is being loud about that "attacking the process"? Or is that actually
that should simply happen without any wg participant asking, anyway?

Thanks,

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Fri, 6 Dec 2019 21:13:56 +0000

Hi Ron. I am trying to be precise in my posts.  Please do not interpret them as dismissive.
I have observed, in your original post, the conflation of SRH insertion within an SR Domain with the PSP behavior defined in network programming.
Whether this was intentional or not, I do not know.
Regardless, it is wrong.

I have used very specific words to describe the PSP operation within an SR Domain since they are easy to find in RFC8200’s discussion on the topic.

“The SRH is only removed by the node identified in the destination address field of the IPv6 header.”

The PSP behavior does belong in network programming.

Thanks
  Darren

________________________________
From: Ron Bonica <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, December 5, 2019 3:39 PM
To: Darren Dukes (ddukes)
Cc: SPRING WG; 6man
Subject: RE: Network Programming - Penultimate Segment Popping

Darren,

                                                                                           Ron

Juniper Business Use Only
From: Darren Dukes (ddukes) <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, December 5, 2019 11:50 AM
To: Ron Bonica <[email-masked]<mailto:[email-masked]>>
Cc: SPRING WG <[email-masked]<mailto:[email-masked]>>; 6man <[email-masked]<mailto:[email-masked]>>
Subject: Re: Network Programming - Penultimate Segment Popping

Let me recap.

Thanks
  Darren

Iterations:

Pablo,

                                                                 Ron

---

From: Ron Bonica <[email-masked]>
Date: Fri, 6 Dec 2019 22:01:52 +0000

Darren,

We clearly disagree.  RFC 8200 addresses extension header insertion and deletion identically, in the same sentence.

                                                       Ron

---

From: Ole Troan <[email-masked]>
Date: Fri, 6 Dec 2019 23:02:13 +0100

> On 6 Dec 2019, at 22:09, Fernando Gont <[email-masked]> wrote:
> 
> the process?

I would rather say taking advantage of the process.

By reiterating the same assertive arguments again and again you contribute to polarization. Your strategy for consensus building seems to be one of attrition. 

If you want to help make the process work, I would encourage you to reconsider that approach.

Ole

---

From: Andrew Alston <[email-masked]>
Date: Fri, 6 Dec 2019 22:23:34 +0000

Ole - so - let me understand something.

The definition of consensus - among other things - say that all outstanding objections have been addressed (though not potentially resolved).  When you have multiple people saying - a draft violates RFC8200 and that is a concern - and if such a thing is required, an update to RFC8200 should be done.  Multiple concerns have been raised - a number of which have not been addressed to the satisfaction of those asking the questions.

Yet - we now see documents being pushed through to last call without these things being addressed.  So I would ask - what exactly do you, as a working group chair propose we do - swallow our technical concerns and our objections and because we've said it once, and it's been ignored or swept under the rug, shrug our shoulders and say - oh well - that’s ok - we tried - and let something we believe to be technically flawed sail through?

I stood and very clearly stated multiple times that I believe that work on this stuff and the drafts which I am co-author on should continue in parallel - because for one - I believe in some ways - they address different things - yet - at the same time - that does not mean that I believe that we should accept things which we have deep technical concerns about.  

The engineering must come first - and it seems very clear to me that both myself and others - have significant technical and operational concerns - and I find it rather bizarre that you seem to imply that once these concerns are stated once - we should swallow it and accept a situation where these are not addressed and documents are shoved through to last call in the face of serious technical objection.

So - please - clarify for me - are you asking us to swallow our objections and just accept something that violates another rfc for which there is consensus just because we asked once, and the issue wasn't addressed - so that makes it somehow disappear?  Or what exactly are you expecting of us?

Andrew

On 07/12/2019, 01:02, "Ole Troan" <[email-masked]> wrote:

    

    
    Ole

---

From: Sander Steffann <[email-masked]>
Date: Fri, 6 Dec 2019 23:24:39 +0100

Hi Ole,

> By reiterating the same assertive arguments again and again you contribute to polarization. Your strategy for consensus building seems to be one of attrition.

I resent this statement. The process is designed to put the onus of justifying changes to the proposer. The fact that Fernando has to keep repeating his objections are the failure of the process and the chairs.

> If you want to help make the process work, I would encourage you to reconsider that approach.

No, the chairs need to change their approach so that objections to proposals are properly addressed (whether the chairs like the proposal or not. I have had to do that in my time as chair as well, and it's not easy but it's part of the job).

When an objection has been properly, explicitly and publicly addressed, THEN you can tell people to stop posting.
Sander

---

From: Fernando Gont <[email-masked]>
Date: Fri, 6 Dec 2019 20:08:42 -0300

> If you want to help make the process work, I would encourage you to reconsider that approach.

I'm sad to hear you say that.

But let me try to says things in an even more brief and explicit way:

At the time of this writing, and for at least more than one year, I
haven't had any sort of employment relationship, contract, or received
any sort of compensation or payment of any form, neither from the folks
pushing SRv6, nor from people pushing against EH-insertion, or from
folks pushing any sort of alternative technology that might be seem as
competing with SR.

So, could you please explain to me what's the advantage that I'm taking?
And what for?

On the other hand, on this particular topic (and I've mentioned them in
my previous email, but could reiterate them, if you wish) you have taken
a number of decisions and positions which seem to circumvent our
processes, encourage violation of existing specifications, and
ultimately benefit an effort pushed by your own employer.

No single one of my messages in this thread have been about building
consensus. The have been about respecting our processes and rules. That
means, for example:

* polling the mailing list instead of deciding (on your own) that the
group wants to work on EH insertion, and,

* complying with existing specifications unless there's formal consensus
for them to be formally updated.

As a 6man chair, I would expect that you would be doing exactly that
 yourself, as opposed to essentially suggesting the group is going to
work on a document without polling the wg for adoption (particularly
when the topic has been, at best, controversial), or encourage other
groups to violate the same specs that this same wg produced.

Thanks,

---

From: [email-masked]
Date: Sat, 7 Dec 2019 00:55:47 +0100

> group wants to work on EH insertion, and,

Which decision are you referring to?
I have certainly never decided that working group wants to work on header insertion.

With regards to the documents, I believe I clarified the statement of the working group seeing no reason why both documents couldn't be continue to be worked on.
Those documents are not adopted, nor has any decision about adoption been made, nor is any adoption call of those documents planned.

I certainly don't want us as a group or myself personally to be working on header insertion.
You might not be alone, but you certainly keep repeatedly forcing the working group to consider the issue.

> for them to be formally updated.

I believe I have responded multiple times to this point.
I do not in principle see a conflict with specifying how header insertion can work in a specific case,
and the text in RFC8200. I would strongly oppose updating RFC8200, since header insertion is clearly
something that can only apply in specific use cases.

> groups to violate the same specs that this same wg produced.

I try to do the best job I can, and be fair, neutral, open and transparent.
That job is clearly not easy when this particular debate is as disruptive as it is.
You at least always have RFC2026, section 6.5.

Best regards,
Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 7 Dec 2019 14:15:44 +1300

Andrew,

I am a bit confused (not unusual). Can you get back to basics on my questions below?

On 07-Dec-19 11:23, Andrew Alston wrote:
> The definition of consensus - among other things - say that all outstanding objections have been addressed (though not potentially resolved).  When you have multiple people saying - a draft violates RFC8200 and that is a concern - 

Are you referring to draft-ietf-spring-srv6-network-programming-05?

If not, the subject header of this thread is a bit confusing.

If so, why are you asking Ole? The WG last call is in the spring WG, with a courtesy copy to 6MAN.

> and if such a thing is required, an update to RFC8200 should be done.

Why does that follow? Alternatively, draft-ietf-spring-srv6-network-programming could acknowledge that it deviates from RFC8200. Whether that's acceptable would be a question for the IETF Last Call rather than any single WG.

At the moment, the draft only mentions RFC8200 in a context that discusses neither insertion nor removal of extension headers, which is beside the point. Like draft-voyer, if it describes a violation of RFC8200, shouldn't that be explicit in the text?

There's a lot of jargon in draft-ietf-spring-srv6-network-programming. I can't tell from the jargon whether "insert" means "insert on the fly" and whether "Pop the SRH" means "delete on the fly". Should those terms be clarified before the draft advances?

> Multiple concerns have been raised - a number of which have not been addressed to the satisfaction of those asking the questions.
> 
> Yet - we now see documents being pushed through to last call 

Erm, that's what Last Call is for - finding the things that haven't been settled. But for draft-ietf-spring-*, it's the spring WG chairs you should be asking, IMHO.

Regards,
  Brian

> without these things being addressed.  So I would ask - what exactly do you, as a working group chair propose we do - swallow our technical concerns and our objections and because we've said it once, and it's been ignored or swept under the rug, shrug our shoulders and say - oh well - that’s ok - we tried - and let something we believe to be technically flawed sail through?
>

---

From: Fernando Gont <[email-masked]>
Date: Fri, 6 Dec 2019 22:10:30 -0300

> I have certainly never decided that working group wants to work on header insertion.

This is your note:
https://mailarchive.ietf.org/arch/msg/ipv6/j177aiqH6G4XNTWWrRfpsV23IVg

Then I re-asked:
https://mailarchive.ietf.org/arch/msg/ipv6/12Qwp_eeQT2EmbUrSxBLL5HTcnM
But you didn't respond.

Suresh clarified there had not been any sort of adoption call:
https://mailarchive.ietf.org/arch/msg/ipv6/Db6_SGfmeIDzaE56Ps5kUDCYEzY

Then again we were debating the topic here:
https://mailarchive.ietf.org/arch/msg/ipv6/56w4LQzYtkut43A46ADhW3dWT-Y

The reality is that there has not been a call for adoption for any of
these two documents. So.. I'm not sure what a say may the wg have on
documents that are individual documents.

On that ground, RFC8200 represents IETF consensus. And the spring
documents should be complying with it. TO be honest, I have no idea what
there is to debate here.

> With regards to the documents, I believe I clarified the statement of the working group seeing no reason why both documents couldn't be continue to be worked on.

The wg doesn't have a say on individual documents. So, yes, both
documents can continue to be worked on as much as I can continue
"working" on my BBQ.

Whatever the opinion of the wg, authors can work on individual I-Ds as
much as they please.

For the wg to have a say, I guess there has to be a conversation about
adoption. But such conversation hasn't taken place. (Me, myself, I'd
find it amusing to see the wg have two documents, one that says "this is
evil", and another about "doing evil" :-) But that's of course a
personal view).

> You might not be alone, but you certainly keep repeatedly forcing the working group to consider the issue.

And here we go again, for the Nth time: a big part of this thread came
up because folks at the spring are violating our specs. So I have
requested folks (including INT and RTG ADs), that the document remove
all text that violates RFC8200.

But then we see all this body of imagination of how they are not
violating RFC8200 (when they are), you talking about the topic being
nuanced and about "limited domains", etc.

> something that can only apply in specific use cases.

You have a spec that explicitly forbids it, with as strong of a wording
as available (it's not a "MUST NOT", because you and others opposed to
having rfc2460bis employ RFC2119 language). EH-insertion goes against an
explicitly forbidden behavior. Is not that you are playing in the MAY or
SHOULD area. So an update is warranted if this is to happen.

So yes, if you want to go against the spec, you have to update it. I
don't think we publish specs for folks to then come an note why they
have decided to violate them. And to the ocassional RFC reader, it will
be a bit of a mess to sail through a bunch of documents where some
specify behavior, and others simply do what they please.

A formal update is also warranted because, otherwise, if I read RFC8200
(and there's no metadata that points to EH-insertion), I can assume that
this packet mangling doesn't occur. But then if the same organization
(IETF) publishes another document that says how to mangle with IPv6
packets, without any formal update of RFC8200, I have nothing signaling
me to read it.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Fri, 6 Dec 2019 22:37:27 -0300

On 6/12/19 22:15, Brian E Carpenter wrote:
[...]
> Why does that follow? Alternatively, draft-ietf-spring-srv6-network-programming could acknowledge that it deviates from RFC8200.

You can deviate from s "should", not from a "must". This is an outright
violation of a spec, rather than a mere "deviation".

> Whether that's acceptable would be a question for the IETF Last Call rather than any single WG.

I would expect that a WG cannot ship a document that is violating an
existing spec, where the wg shipping the document is not in a position
of making decisions regarding the spec being violated.

That would be like a waste of energy and time for all.

> There's a lot of jargon in draft-ietf-spring-srv6-network-programming. I can't tell from the jargon whether "insert" means "insert on the fly" and whether "Pop the SRH" means "delete on the fly". S…

Well, if it's not clear to you, it would seem to me that the simple
answer would be "yes".

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 7 Dec 2019 15:47:53 +1300

Again, comment at the end...
> Well, if it's not clear to you, it would seem to me that the simple

But if "insert" refers to the encapsulating node at the SR domain ingress, it's no problem, and if "pop" simply means doing normal routing header processing, it's no problem. It simply isn't clear in the text, at least not clear to me.

   Brian

---

From: Fernando Gont <[email-masked]>
Date: Sat, 7 Dec 2019 00:07:08 -0300

> But if "insert" refers to the encapsulating node at the SR domain ingress, it's no problem, and if "pop" simply means doing normal routing header processing, it's no problem. It simply isn't clear…

The fact that a folk that has been deeply involved with IPv6 cannot
unequivocally tell what they talking about should be an indication with
respect to how ready the document is to be shipped.

(pop when you are the destination but SL!=0 is essentially 'in the
network removal')

THanks,

---

From: Suresh Krishnan <[email-masked]>
Date: Sat, 7 Dec 2019 07:13:37 +0000

(Apologies up front. I am about to get on a 10 hr flight and will be unable to respond for at least that period)

Hi all,
  Picking the last message in the thread to reply to. It looks to me that there are at least two different (but related) issues being discussed here

a) Spring SRv6 NP behavior (related to the WGLC of that draft)
b) The Header insertion drafts and how to deal with them

I really think that

a) should preferably stay in the spring ML and a pointer to the discussion sent to the 6man mailing list would be in order
b) should preferably stay in the 6man ML

I think the communities for the two drafts are different and I think the discussions can be more focused if the issues are addressed by the relevant wgs. As to what happens if the spring draft hits the IESG and contains text in violation of RFC8200, I had already sent my thoughts about this back in September

https://mailarchive.ietf.org/arch/msg/spring/uA-WxxgBJeMu65SkrKCTL5BJMcU

with the relevant text

"If a draft violates RFC8200 and it hits the IESG for evaluation, I will certainly hold a DISCUSS position until the violations are fixed.”

*In my view*, the authors of the SRv6 NP draft have made an effort to address these violations by removing the header insertion from the draft. We can continue discussing whether penultimate hop popping constitutes a violation on the spring mailing list (I intend to respond to Fernando’a mail there).

Thanks
Suresh

On Dec 7, 2019, at 11:07 AM, Fernando Gont <[email-masked]<mailto:[email-masked]>> wrote:

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

---

From: Suresh Krishnan <[email-masked]>
Date: Sat, 7 Dec 2019 07:19:48 +0000

(responding on spring mailing list)

Hi Fernando,

network removal’)

It is not obvious to me why you think this is a violation of RFC8200 though it is possible that I misread your comment. The relevant text I am looking at is

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

which seems to permit it. Can you please clarify where there is a violation?

Regards
Suresh

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Sat, 7 Dec 2019 10:03:24 +0000

+ 1 and I will also clarify, what I see as, a misunderstanding (or perhaps a misrepresentation) of the PSP behaviour on the other thread that Suresh has started.

From: ipv6 <[email-masked]> On Behalf Of Suresh Krishnan
Sent: 07 December 2019 12:44
To: 6man <[email-masked]>; SPRING WG <[email-masked]>
Cc: Ron Bonica <rbonica=[email-masked]>; [email-masked]; rtg-ads <[email-masked]>; Bob Hinden <[email-masked]>; Fernando Gont <[email-masked]>
Subject: Separating issues (was Re: [spring] We don't seem to be following our processes (Re: Network Programming - Penultimate Segment Popping))

Hi all,

I really think that

with the relevant text

Thanks
Suresh

THanks,

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Sat, 7 Dec 2019 10:13:47 +0000

+1

For some strange reason the PSP behaviour is being mixed with EH insertion and likely there is some misunderstanding here.

Fernando says:

This is NOT what PSP is (refer https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05#section-4.16.1) – the “pop” is done when the SL becomes 0.

FWIW, this has been stated in different ways and clarified on the mailing list previously by the authors as well as others involved in SRv6 development and deployments. There is no violation of RFC8200 here.

Thanks,
Ketan

From: spring <[email-masked]> On Behalf Of Suresh Krishnan
Sent: 07 December 2019 12:50
To: Fernando Gont <[email-masked]>; SPRING WG <[email-masked]>
Cc: Ron Bonica <rbonica=[email-masked]>; [email-masked]; Andrew Alston <[email-masked]>; rtg-ads <[email-masked]>; Bob Hinden <[email-masked]>; Ole Troan <[email-masked]>; Brian E Carpenter <[email-masked]>
Subject: [spring] Penultimate Segment Popping and RFC8200 (Was Re: We don't seem to be following our processes (Re: Network Programming - Penultimate Segment Popping))

Hi Fernando,

Regards
Suresh

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 7 Dec 2019 12:47:05 +0100

Hey Fernando,

> network removal')

I was trying to stay out of this but I have one fundamental question or
observation this entire debate seems to be about.

In the context of SRv6 there are two parallel discussions

*Discussion #1* - It is about inserting, modifying or deleting SRH by nodes
which are not in the outer IPv6 header of the packet

*Discussion #2* - It is about RFC8200 compliance when the node doing
insertion of SRH is *the* destination of the packet as read verbatim from
the outer IPv6 header.

*Discussion #3* - It is about RFC8200 compliance when the node doing
modification or removal of SRH is *the* destination of the packet as read
verbatim from the outer IPv6 header.

First let's observe that RFC8200 is only defining the behaviour regarding
EH processing in the context of destination address of the IPv6 outer
header: "identified in the Destination Address field of the IPv6
header.identified in the Destination Address field of the IPv6 header. "

Therefore stating that SL value before local decrement matters in this in
respect to being compliant to the IPv6 RFC is at best just an individual
interpretation. Besides the pseudocode says it black and white "S14.1.   If
(updated SL == 0) {". We do all sort of processing decision after
decrementing the values ... think TTL :)

So back to reality ...

*Discussion #1* - I think we all agree that to accomplish that RFC8200
would need to be updated.

*Discussion #2* - I think we also all agree here that to accomplish this
RFC8200 would need to be updated as it does says clearly that "Each
extension header should occur at most once, ..."

*Discussion #3* - It seems clearly that there is no issue with compliance
with RFC8200 and that if penultimate segment midpoint decides or is
instructed to pop SRH it sure can and still be 100% compliant with current
wording of RFC8200.

So other then so much foam what is this debate all about ?

Cheers,
Robert.

---

From: Alexandre Petrescu <[email-masked]>
Date: Sat, 7 Dec 2019 15:13:31 +0100

Le 06/12/2019 à 17:21, Sander Steffann a écrit :
> Hi Robert,
> 
>> To your specific first question this is very popular deployment 
>> model ... just look at SDWANs. So Internet is just a L3 transport 
>> for all routers in your administrative domain or global WAN. Spot 
>> on. I do sincerely hope that whatever the result be of this debate 
>> all features will be legal to run on my boxes regardless how I 
>> choose to interconnect them.
>> 
>> As (Internet) transit boxes would never be destination addresses
>> of the outermost header what problem do you see running anything
>> one likes on R1 or R2 or R3 and transporting it via open Internet
>> or perhaps some third party networks ?
> 
> endpoints in the same (or cooperating) administrative domain. In
> that case it's indeed up to the participants to deal with and debug.
> 
> So the tunnel model I don't mind. Can we be certain it indeed fits 
> all deployments and leaking isn't possible. Theory and practice are 
> the same in theory, but not in practice :)

YEs, a tunnel is a quantum leap between layers, a wormhole between
Universes; a tunnel makes possible what otherwise can not be imagined:
get restricted web content from a country as if one were there.

The limited domain draft does set a perspective with respect to tunnels,
although one might wonder whether questions like whether two limited
domains connected by a tunnel make for a single limited domain (a
reducibility principle).

Alex

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

---

From: Fernando Gont <[email-masked]>
Date: Sat, 7 Dec 2019 11:31:59 -0300

On 7/12/19 04:19, Suresh Krishnan wrote:
>>>>> Why does that follow? Alternatively,
>>>>> draft-ietf-spring-srv6-network-programming could acknowledge that
>>>>> it deviates from RFC8200.
>>>>
>>>>> At the moment, the draft only mentions RFC8200 in a context that
>>>>> discusses neither insertion nor removal of extension headers, which
>>>>> is beside the point. Like draft-voyer, if it describes a violation
>>>>> of RFC8200, shouldn't that be explicit in the text?
>>>>>
>>>>> There's a lot of jargon in
>>>>> draft-ietf-spring-srv6-network-programming. I can't tell from the
>>>>> jargon whether "insert" means "insert on the fly" and whether "Pop
>>>>> the SRH" means "delete on the fly". Should those terms be clarified
>>>>> before the draft advances?
>>>>
>>> But if "insert" refers to the encapsulating node at the SR domain
>>> ingress, it's no problem, and if "pop" simply means doing normal
>>> routing header processing, it's no problem. It simply isn't clear in
>>> the text, at least not clear to me.
>>
> It is not obvious to me why you think this is a violation of RFC8200
> though it is possible that I misread your comment. The relevant text I
> am looking at is
> 

In the context of RFC8200, where the text you have quoted is present,
can you tell me which address other than that of the final destination
can be in the Destination Address of the packet?

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Sat, 7 Dec 2019 11:34:48 -0300

On 7/12/19 07:13, Ketan Talaulikar (ketant) wrote:
> +1
> 
>  
> 
> For some strange reason the PSP behaviour is being mixed with EH
> insertion and likely there is some misunderstanding here.

You mean we're mixing EH insertion with EH removal?

---

From: Fernando Gont <[email-masked]>
Date: Sat, 7 Dec 2019 12:08:51 -0300

> which seems to permit it. Can you please clarify where there is a

May I add:

1) For some reason, the mechanism is called Penultimate Segment Popping?
-- Does "penultimate segment" ring any bells?

2) A related question I have for you: Is IPv6 an end-to-end protocol?
(The answer to this question also serves as an answer for the rest).

Thanks,

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Sat, 7 Dec 2019 15:10:01 +0000

Ron, you say
>>  RFC 8200 addresses extension header insertion and deletion identically, in the same sentence.

This sentence you refer to clearly permits PSP as defined in network programming:
   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.

Clearly we process the SRH at the node identified in the destination address field of the IPv6 header.
With PSP we remove the SRH at the node identified in the destination address field of the IPv6 header.

I think it’s clear we can conclude this thread.

Darren

Darren,

                                                       Ron

---

From: Fernando Gont <[email-masked]>
Date: Sat, 7 Dec 2019 12:19:26 -0300

> I think it’s clear we can conclude this thread.

Can you tell me which address, other than the address of the final
destination, can be present in the DA of a pcket, in the context of RFC8200?

Thanks,

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 7 Dec 2019 16:29:13 +0100

> (The answer to this question also serves as an answer for the rest).

The moment IPv6 src <--> dst flow makes it legal to be encapsulated you are
dealing with end to end inner IPv6 and end to end outer IPv6.

You keep drawing false assumption that inner IPv6 header should mandate or
even influence action on outer IPv6 header which is simply not correct.

Cheers,
R.

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Sat, 7 Dec 2019 15:57:08 +0000

Hi Robert, thank you for injecting clarity to this thread.

draft-ietf-spring-network-programming defines PSP, and the only relevant portion of this thread to that draft is Discussion #3.

As I stated in another post, I consider #3 closed as this is clearly complying with RFC8200.
https://mailarchive.ietf.org/arch/msg/ipv6/6Uy_JuMm7W66kTql_o7FYisxkg0

The remainder of the discussion in this thread is unrelated to draft-ietf-spring-network-programming.

Thanks
  Darren

On Dec 7, 2019, at 6:47 AM, Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:

Hey Fernando,

I was trying to stay out of this but I have one fundamental question or observation this entire debate seems to be about.

Discussion #1 - It is about inserting, modifying or deleting SRH by nodes which are not in the outer IPv6 header of the packet

Discussion #2 - It is about RFC8200 compliance when the node doing insertion of SRH is *the* destination of the packet as read verbatim from the outer IPv6 header.

Discussion #3 - It is about RFC8200 compliance when the node doing modification or removal of SRH is *the* destination of the packet as read verbatim from the outer IPv6 header.

First let's observe that RFC8200 is only defining the behaviour regarding EH processing in the context of destination address of the IPv6 outer header: "identified in the Destination Address field of the IPv6 header.identified in the Destination Address field of the IPv6 header. "

Therefore stating that SL value before local decrement matters in this in respect to being compliant to the IPv6 RFC is at best just an individual interpretation. Besides the pseudocode says it black and white "S14.1.   If (updated SL == 0) {". We do all sort of processing decision after decrementing the values ... think TTL :)

So back to reality ...

Discussion #1 - I think we all agree that to accomplish that RFC8200 would need to be updated.

Discussion #2 - I think we also all agree here that to accomplish this RFC8200 would need to be updated as it does says clearly that "Each extension header should occur at most once, ..."

Discussion #3 - It seems clearly that there is no issue with compliance with RFC8200 and that if penultimate segment midpoint decides or is instructed to pop SRH it sure can and still be 100% compliant with current wording of RFC8200.

Cheers,
Robert.

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 7 Dec 2019 17:03:54 +0100

Exactly - That is why I thought  it does make sense to make this crystal
clear to everyone here.

>From some comments it seemed that either folks do not understand or want on
purpose to make false assertions only to mud the waters :)

All - have a great weekend,
Robert.

On Sat, Dec 7, 2019 at 4:57 PM Darren Dukes (ddukes) <[email-masked]>
wrote:

> draft-ietf-spring-network-programming defines PSP, and the only relevant
> portion of this thread to that draft is Discussion #3.
>
> On Dec 7, 2019, at 6:47 AM, Robert Raszuk <[email-masked]> wrote:
>
> Hey Fernando,
>
> *Discussion #1* - It is about inserting, modifying or deleting SRH by
> nodes which are not in the outer IPv6 header of the packet
>

---

From: Tom Herbert <[email-masked]>
Date: Sat, 7 Dec 2019 08:26:29 -0800

Darren,

I believe you are assuming a very liberal interpretation of the
wording in RFC8200. If intermediate hosts in the routing list are able
to add or remove SRH per RFC8200, then they are allowed to add or
remove any and all extension headers per the same interpretation. I do
not believe that is at all the intent of RFC8200. Also note that the
liberal interpretation it would validate other cases of arbitrary
extension header manipulation like in NAT devices for instance.

Tom

> On Dec 6, 2019, at 5:01 PM, Ron Bonica <[email-masked]> wrote:
>

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 7 Dec 2019 17:48:59 +0100

Tom,

> If intermediate hosts in the routing list are able to add or remove SRH
per RFC8200

"Routing list" contained in SRH does not matter at all here in terms of
compliance with RFC8200.

At each segment midpoint the outer IPv6 destination is *rewritten*. For
illustrative purposes you may visualize like outer IPv6 header is removed
and new IPv6 header is added with new destination address at each segment
midpoint.

It is this principal of SRv6 operation which is being used and which in no
way contradicts nor stretches RFC8200 as it is written today.

Besides it is basic thing that SR segment may end in the middle of the
network then native routing will take the packet to the dst. Is that also
being considered violation of something ?

Your analogy to NAT is pretty false as NAT box is never an intended
destination of the packet.

All the best,
R.

On Sat, Dec 7, 2019 at 5:27 PM Tom Herbert <[email-masked]> wrote:

> > >> I have observed, in your original post, the conflation of SRH
> insertion within an SR Domain with the PSP behavior defined in network
> programming.
> > We clearly disagree.  RFC 8200 addresses extension header insertion and
> deletion identically, in the same sentence.
> >
> >
> >                                                        Ron
> >
> >
> >
> >
> >
> >
> https://www.ietf.org/mailman/listinfo/spring
>

---

From: Fernando Gont <[email-masked]>
Date: Sat, 7 Dec 2019 14:37:56 -0300

On 7/12/19 13:03, Robert Raszuk wrote:
> From some comments it seemed that either folks do not understand or want
> on purpose to make false assertions only to mud the waters :) 

FWIW, I will wait for a few days for Suresh to answer the question I
have asked, and for the spring chairs and RTG AD to weigh in.

That said, I have already begun to write and appeal I'll (initially)
direct to the IESG as a whole. Besides, given that there's background to
this situation (what happened in the context of rfc2460bis), I will
raise the issue in other forums.

I guess it should be clear to everyone that we are being mocked at. And
I think the situation is unacceptable.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Sat, 7 Dec 2019 14:42:49 -0300

On 7/12/19 12:29, Robert Raszuk wrote:
> The moment IPv6 src <--> dst flow makes it legal to be encapsulated you
> are dealing with end to end inner IPv6 and end to end outer IPv6. 
> 
> You keep drawing false assumption that inner IPv6 header should mandate
> or even influence action on outer IPv6 header which is simply not correct. 

The online possible instantiation of "Destination Address" as in RFC8200
is the final destination of the packet. As such, if you mangle with
mackets anywhere else other than at the final destination, you are
violating RFC8200.

You don't seem to be reading the spec properly, or are intentionally
trying to read it in a very curious way to circumvent it.

An honest way to go against specs is to write an Internet-Draft, make a
case for going against the spec, and changing it. And convince folks
that it makes sense.

Another way to do it is by leveraging the power of specific vendors.

I clearly don't have that power, but will be loud enough for the
community to be aware about what's going on (including the formal appeal
process).

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Sat, 7 Dec 2019 14:43:42 -0300

> As I stated in another post, I consider #3 closed as this is clearly

Sorry Darren. Which wg do you chair?

Thanks,

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 7 Dec 2019 19:40:46 +0100

Hi Fernando,

> is the final destination of the packet.

No. That is incorrect.

Hint: Please read carefully RFC2473.

Please focus on sections: 3.1, 3.2, 3.3, 5.1 etc ...

Kindly read this part of section 3.2 at least few times:

a tunnel Destination Options extension header is processed *at the
tunnel exit-point node.*

. . .

   Upon receiving an IPv6 packet destined to an IPv6 address of a tunnel
   exit-point node, its IPv6 protocol layer processes the tunnel
   headers.

...

5.1 <https://tools.ietf.org/html/rfc2473#section-5.1> Tunnel IPv6
Extension Headers

   Depending on IPv6 node configuration parameters, a tunnel entry-point
   node may append to the tunnel IPv6 main header one or more IPv6
   extension headers, such as a Hop-by-Hop Options header, a Routing
   header, or others.

...

Then you may continue with your appeal.

- - -

Darren and others,

While this is clear for most folks I see that perhaps any SRv6 spec (NP in
particular) should clearly distinguish the notion of final packet
destination address from segment endpoint destination address inserted in
the encapsulation header.

Today document only defines  "DA: Destination Address" - I can see why this
may confuse some folks as it is used interchangeably with original
destination address.

IMO it would be a good change to redefined "DA" as "Segment Endpoint
Destination Address" and when referring to original packet destination
address perhaps call it Original DA (O-DA) and original source address
(O-SA). That way there would be no confusion at all (one may hope ;-).

Just a hint.

Best,
Robert

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 8 Dec 2019 08:49:29 +1300

Ketan,
> For some strange reason the PSP behaviour is being mixed with EH insertion and likely there is some misunderstanding here.

I found the language in draft-ietf-spring-srv6-network-programming very hard to understand, and your comment and those from Robert Raszuk really don't clear it up. No insult intended, but it seems that SRH exponents are so close to SRH that you don't understand why others find it hard to understand.

So let me ask for clarification on three points in the draft. (Please keep me in CC as I'm not on the spring list.)

(1) Where the draft uses the word "insert", does it refer *only* to the encapsulating node at the SR domain ingress?

(2) What does the phrase ""Pop the SRH" mean? Does it mean "delete" a header inserted as in (1),
at the same time as decapsulating the packet?

(3) In *very* elementary language, what is "updated SL" in statement S14.2? It isn't defined elsewhere as far as I can see. It may just be sloppy writing, because if "Segments Left" is a variable, then perhaps "updated SL" just means the current value of "Segments Left" after executing S14.

With specific answers to those questions, the text would be easier to interpret.

Some diagrams of the encapsulation would be helpful, too.

Regards
   Brian

> *From:*spring <[email-masked]> *On Behalf Of *Suresh Krishnan
> *Sent:* 07 December 2019 12:50
> *To:* Fernando Gont <[email-masked]>; SPRING WG <[email-masked]>
> *Cc:* Ron Bonica <rbonica=[email-masked]>; [email-masked]; Andrew Alston <[email-masked]>; rtg-ads <[email-masked]>; Bob Hinden <[email-masked]>; Ole Troan <[email-masked]>; Brian E Carpenter <[email-masked]>
> *Subject:* [spring] Penultimate Segment Popping and RFC8200 (Was Re: We don't seem to be following our processes (Re: Network Programming - Penultimate Segment Popping))
> 
>  
> 
>     On Dec 7, 2019, at 11:07 AM, Fernando Gont <[email-masked] <mailto:[email-masked]>> wrote:
> 
>      
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 7 Dec 2019 21:26:43 -0000

[Hmmm, there were a lot of people in the to/cc fields. I trimmed a bit because (hopefully) some of them are subscribed to the mailing lists.]

Brian,

I think some of the notion of "popping an SRH" may be associated with the idea of having more than one SRH present. Whether that is a good idea is a different question.

Cheers,
Adrian

-----Original Message-----
From: spring <[email-masked]> On Behalf Of Brian E Carpenter
Sent: 07 December 2019 19:49
To: Ketan Talaulikar (ketant) <[email-masked]>; Suresh Krishnan <[email-masked]>; Fernando Gont <[email-masked]>; SPRING WG <[email-masked]>
Cc: Ron Bonica <rbonica=[email-masked]>; [email-masked]; Andrew Alston <[email-masked]>; rtg-ads <[email-masked]>; Bob Hinden <[email-masked]>; Ole Troan <[email-masked]>
Subject: Re: [spring] Penultimate Segment Popping and RFC8200 (Was Re: We don't seem to be following our processes (Re: Network Programming - Penultimate Segment Popping))

Ketan,

Regards
   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 8 Dec 2019 11:06:25 +1300

On 08-Dec-19 00:47, Robert Raszuk wrote:
...
> Besides the pseudocode says it black and white "S14.1.   If (updated SL == 0) 

As I already pointed out, "updated SL" is undefined in the text and may in fact simply mean "Segments Left" after executing S14. Pseudocode really should be unambiguous.

Regards
   Brian

---

From: Fernando Gont <[email-masked]>
Date: Sat, 7 Dec 2019 21:55:13 -0300

> Hint: Please read carefully RFC2473. 

If you think a document on tunnels rules how IPv6 operates, and its
end-to-endianness, then you have a huge problem reading specs.

So I will not enter that game, because it would be accepting to be
mocked at.

I'll wait for a few days for our INT AD's response (Suresh), a response
from the spring chairs (if any), and a response from the RTG AD(s).

Then I will escalate the problem as required, including a formal appeal,
if necessary.

Thanks,

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 8 Dec 2019 11:15:34 +0100

>  end-to-endianness, then you have a huge problem reading specs.

So in your view building any solution which relies on
encapsulation/tunneling for IPv6 kills its end-to-endianness dogma then
this is a very interesting individual WG member comment.

In the meantime till IETF moves Standards Track  RFC2473 to historic status
or updates it with some other spec it remains a valid document.

Cheers,
Robert.

---

From: Fernando Gont <[email-masked]>
Date: Sun, 8 Dec 2019 07:22:28 -0300

> this is a very interesting individual WG member comment. 

Insertion/removal of EHs on the path to the destination kills it. Yes.

You can do whatever you please if you are at the node identified by the
Source Address of the packet, or at its final destination.

Thanks,

---

From: <[email-masked]>
Date: Mon, 9 Dec 2019 15:44:30 +0000

Fernando,
 
> From: ipv6 [mailto:[email-masked]] On Behalf Of Fernando Gont
> Sent: Saturday, December 7, 2019 2:10 AM
> 

It's not crystal clear to me what you are referring to.

If it's related to draft-ietf-spring-srv6-network-programming which is under WGLC, could you please comment as part of this  last call thread? And please quote the draft text that you are referring to. In particular the/all  "text that violates RFC8200".
So far your comments are: https://mailarchive.ietf.org/arch/browse/spring/?q=WGLC%20-%20draft-ietf-spring-srv6-network-programming&f_from=Fernando%20Gont  Hence as part of this last call, I'm not seen your "So I have requested folks (including INT and RTG ADs), that the document remove all text that violates RFC8200."
As of today, this document is under WGLC in the SPRING WG. So please review _the text from this document_ and comment in the SPRING WG.
Eventually, you will also have the opportunity to comment during IETF LC and to raise your points to the IESG. But your position will be stronger if you first comment during the WG LC.

If it's related to something else, e.g. some authors of SRv6 draft(s), please be more specific and refers to those drafts, rather than "folks at the spring".

Thank you,
--Bruno

> packets, without any formal update of RFC8200, I have nothing signaling

_________________________________________________________________________________________________________________________

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: Tue, 10 Dec 2019 13:16:38 +0000

Fernando,

> From: spring [mailto:[email-masked]] On Behalf Of Fernando Gont
> Sent: Sunday, December 8, 2019 1:55 AM
> 

I'm not sure what response to what question you expect from spring chairs.
draft-ietf-spring-srv6-network-programming is under WG LC: this is the time for everyone to comment on the document and hopefully improve it. At this stage, I'd rather not influence the discussion.

That been said, since you are insisting

>> From: spring [mailto:[email-masked]] On Behalf Of Fernando Gont
>> Sent: Saturday, December 7, 2019 6:43 PM
>>  The online possible instantiation of "Destination Address" as in RFC8200 is the final destination of the packet.

It appears to me that, at minimum, multiple opinions have been expressed on this point, including from Suresh. So, assuming that by "online" you meant "only", the statement "only possible" seems excessive to me.
But I have noted your reading of RFC8200 and your objection, which I believe concern the PSP and USP 'flavors' sections 4.16.1 and 4.16.2
https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05#section-4.16

Regards,
--Bruno

---

From: Fernando Gont <[email-masked]>
Date: Tue, 10 Dec 2019 13:02:20 -0500

On 10/12/19 08:16, [email-masked] wrote:
> Fernando,
> 
>> From: spring [mailto:[email-masked]] On Behalf Of Fernando
>> Gont Sent: Sunday, December 8, 2019 1:55 AM
>> 
>>> The online possible instantiation of "Destination Address" as in
>>> RFC8200 is the final destination of the packet.
>>> 
>>> 
>>> No. That is incorrect.
>>> 
>> If you think a document on tunnels rules how IPv6 operates, and
>> its end-to-endianness, then you have a huge problem reading specs.
>> 
>> I'll wait for a few days for our INT AD's response (Suresh), a
>> response from the spring chairs (if any), and a response from the
>> RTG AD(s).
> 

My understanding is that this is a clear objection to the document "as
is", and that since this document is violating an existing spec, it
would be unfeasible to declare consensus to move the document forward
"as is".

> draft-ietf-spring-srv6-network-programming is under WG LC: this is
> the time for everyone to comment on the document and hopefully
> improve it. At this stage, I'd rather not influence the discussion.

My question to you as a chair is:
Can this wg request publication of the document knowing that it violates
a specification that is not under the control of this wg, and that there
is no consensus to change that spec at the corresponding wg (6man)?

>>> From: spring [mailto:[email-masked]] On Behalf Of
>>> Fernando Gont Sent: Saturday, December 7, 2019 6:43 PM The online
>>> possible instantiation of "Destination Address" as in RFC8200 is
>>> the final destination of the packet.
> 
> It appears to me that, at minimum, multiple opinions have been
> expressed on this point, including from Suresh.

At the end of the day, it is fine for Suresh to have his opinion. HOwever,

1) His mandate will eventually end, so he obviously cannot make
commitments past the date he mandate ends.

2) MOre importantly, this document is being produced by spring, under
the RTG area. So while the INT ADs can make up their minds how they
would block the document if it eventually gets to them, ultimately it's
the spring chairs and RTG AD's call what this wg ships and requests
publication of.

> So, assuming that by
> "online" you meant "only", the statement "only possible" seems
> excessive to me. But I have noted your reading of RFC8200 and your
> objection, which I believe concern the PSP and USP 'flavors' sections
> 4.16.1 and 4.16.2 

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 10 Dec 2019 18:25:21 -0500

> I'm not sure what response to what question you expect from spring chairs.

A number og wg participants are letting the chairs and ADs aware that a
wg document contains an outright violation of an Internet Standard that
spring is not in a position of changing.

I deem that as a major issue, and I'm curious how you might possible
ignore it, declare consensus, and ship and request publication of this
document.

> It appears to me that, at minimum, multiple opinions have been expressed on this point, including from Suresh. So, assuming that by "online" you meant "only", the statement "only possible" seems ex…

I ask again: please read RFC8200, and in the context of RFC8200, please
tell me what can be in the Destination Address other than the ultimate
destination of the packet.

Then, if you cannot come up with a good answer, then you might need to
accept that "Destination Address", in the context of RFC8200, is the
ultimate destination of a packet.

And, since we are at it, please let me know if IPv6 is and end to end
protocol. And, if it is, how does that e2e-ness work with inserting and
removing EHs on the path to the ultimate destination of a packet.

Thanks,

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 11 Dec 2019 00:39:18 +0100

Dear Fernando,

Allow me to make something very clear here.

> removing EHs on the path to the ultimate destination of a packet.

The dream of IPv6 flat end to endless is long gone if it ever was
even real.

There is no end to end IPv6 or for that matter IPv4 delivery today across
any network. Regardless if this is private or public network of any
reasonable size and service portfolio.

Some form of encapsulation or tunneling is used in enterprises, in ISPs, in
SPs or even in largest public clouds.

So if you think that you can send an IPv6 packet and that this packet will
be delivered to its final destination without any encapsulation on the way
- this is just unreal. And the sooner you and others like you realize this
the better for everyone.

Think about L3VPNs reachability segmentation, think about SFC/NSH, think
about L2 transport emulation of your circuits, think about seamless
mobility, LISP  ...

Just a tiny reality check,

Thx,
R.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 10 Dec 2019 18:43:15 -0500

> The dream of IPv6 flat end to endless is long gone if it ever was

You seem to missing the point. You are proposing behavior that goes
against an Internet Standard.

The fact that you are doing Standards Track work while violating an
Internet Standard is simply amusing.

If you want to do that, formally update the relevan spec. *That* is the
way to go, as opposed to find your own reason for circumventing existing
specifications.

Thanks,

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 11 Dec 2019 00:50:50 +0100

By your books does RFC 2473 or RFC 4798 or 100s of other RFCs which
encapsulate IPv6 packets all violate Internet Standard I presume IPv6 spec
?

One of us clearly is missing the point. I will let list members judge which
one :)

Cheers,
R.

---

From: Mark Smith <[email-masked]>
Date: Wed, 11 Dec 2019 11:37:56 +1100

On Wed, 11 Dec 2019 at 10:39, Robert Raszuk <[email-masked]> wrote:
> The dream of IPv6 flat end to endless is long gone if it ever was even real.

I would have to question your understanding of the term "end to end"
if you're make such an assertion.

>
> There is no end to end IPv6 or for that matter IPv4 delivery today across any network. Regardless if this is private or public network of any reasonable size and service portfolio.

I don't think you understand what end-to-end means with those assertions.

NAT breaks end-to-end.

If your assertion was true about IPv6, then you are asserting that
literally every IPv6 packet is going through NAT66 at some point.
That's certainly not happening.

>
> Some form of encapsulation or tunneling is used in enterprises, in ISPs, in SPs or even in largest public clouds.
>
> So if you think that you can send an IPv6 packet and that this packet will be delivered to its final destination without any encapsulation on the way - this is just unreal. And the sooner you and others like you realize this the better for everyone.
>
> Think about L3VPNs reachability segmentation, think about SFC/NSH, think about L2 transport emulation of your circuits, think about seamless mobility, LISP  ...
>

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 11 Dec 2019 01:53:50 +0100

> if you're make such an assertion.

My description of end to end purity of IPv6 is based on Fernando's
comments. In his view if packet gets encapsulated with an arbitrary header
and if that header changes hop by hop end to end property of IPv6 is
violated.

NAT breaks end-to-end.

Of course ... and I would agree with that. But if so this entire discussion
of quote "violation of Internet Standard" just because outer header changes
is pure waist of time.

And I think it would be best for those from 6man who understand what IPv6
end to end is to chim in and comment on such emails like we have seen
earlier today.

Many thx,
R.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 10 Dec 2019 21:19:14 -0500

On 10/12/19 18:50, Robert Raszuk wrote:
> encapsulate IPv6 packets all violate Internet Standard I presume IPv6
> spec ? 
> 
> One of us clearly is missing the point. I will let list members judge
> which one :)

Could you please point at any RFC that inserts EHs or deletes EHs at any
place in the network other than the source or the ultimate destination?

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 11 Dec 2019 09:29:46 +0100

RFC 2473

Quotes have been already provided to the lists.

When encapsulating a packet I can put whatever EH is defined and when
decapsulating the packet I can remove any EH I inserted before. I "own" the
new IPv6 header. Very simple. It is like taking the cars on a ferry.

Your original packet (call it end to end ... call it original src going to
final/ultimate destination) is just a payload.

I can not believe that anyone can not grasp such basic concept.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 12 Dec 2019 08:36:53 +1300

Robert,
On 11-Dec-19 21:29, Robert Raszuk wrote:
> When encapsulating a packet I can put whatever EH is defined and when decapsulating the packet I can remove any EH I inserted before. I "own" the new IPv6 header. Very simple. It is like taking the cars on a ferry. 
> 
> Your original packet (call it end to end ... call it original src going to final/ultimate destination) is just a payload. 
> 

I think everyone grasps it. I think the problem is that the SRH proponents
use the word "insert" a little ambiguously. In IPv6-land, it's been assumed
to mean "insert an SRH header in the middle of an existing IPv6 packet header".
I suspect that in SRH-land, and in the IPv6 data plane context, it's mainly
being used to mean "encapsulate an IPv6 packet in a new IPv6 packet that includes
an SRH header." And in the MPLS data plane context it means "prepend an additional
MPLS label."

Right or wrong?

   Brian

> 
> 
> 
> On Wed, Dec 11, 2019 at 3:29 AM Fernando Gont <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     e-mail: [email-masked] <mailto:[email-masked]>

---

From: <[email-masked]>
Date: Wed, 11 Dec 2019 19:48:30 +0000

Fernando,

> From: Fernando Gont [mailto:[email-masked]] 
> Sent: Wednesday, December 11, 2019 12:25 AM
> 
> wg document contains an outright violation of an Internet Standard

That point is noted.
But given that a number of wg participants are saying the opposite, we need to go a bit deeper in the discussion. That's what I've tried to initiate and I believe that we have made progress.

My understanding is that you are saying that
PSP and USP, as defined in [1] and more specifically "Pop the SRH"  contradict with [2] and more specifically 
"   Extension headers [...]  are not
   processed, inserted, or deleted by any node along a packet's delivery
   path, until the packet reaches the node [...] identified in the Destination Address field
   of the IPv6 header."

More specifically, your point is that " the Destination Address field of the IPv6 header" is to be understood as " final destination node"
https://mailarchive.ietf.org/arch/msg/ipv6/Ku-kKBE-vG5QGdT2DvqLxMQpRik

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

Is there another technical point relating to your " outright violation of an Internet Standard" or is this the only one?

> that

6man consensus is written in RFC 8200. I can read it as any other one. Actually you are the one trying to modify that text.
But to your point, believe me, I'll be more than happy to give that ball to someone else. E.g. to my AD then IESG and flagging that point in the shepherd report.
I'll also monitor your above errata, to see if it's been accepted or rejected. That will typically be a strong input in the balance. 

> ignore it, declare consensus, and ship and request publication of this

Noted.
I'm not ignoring it. Quite the contrary I'm the one engaging the discussion with you in order to understand the real technical point that you want to make.
The exercise is not to 'declare consensus' but "rough consensus". Possibly, any position, including yours may be in the rough.
'Request publication' is not publishing the RFC. It's to give the ball to the AD, then IETF last call, then IESG to review beyond the WG. That's typically a way to handle points which are beyond the original WG. 

--Bruno

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Wed, 11 Dec 2019 20:02:22 +0000

Brian, 

I have updated draft-ietf-spring-srv6-network-programming-06 to clarify this. The new pseudocode is explicit. 

Also, merely informative, I would suggest reading the document draft-filsfils-spring-srv6-net-pgm-illustration-01 for a detailed example of PSP with a hop-by-hop packet examples. 
Particularly sections 2.1+2.2 (SID allocation and Reference Diagram) and Section 2.8.1 for the related example with PSP.
https://tools.ietf.org/html/draft-filsfils-spring-srv6-net-pgm-illustration-01#section-2.8.1

Thank you,
Pablo.

-----Original Message-----
From: spring <[email-masked]> on behalf of Brian E Carpenter <[email-masked]>
Date: Saturday, 7 December 2019 at 20:50
To: "Ketan Talaulikar (ketant)" <[email-masked]>, Suresh Krishnan <[email-masked]>, Fernando Gont <[email-masked]>, SPRING WG <[email-masked]>
Cc: Ron Bonica <rbonica=[email-masked]>, "[email-masked]" <[email-masked]>, Andrew Alston <[email-masked]>, rtg-ads <[email-masked]>, Bob Hinden <[email-masked]>, Ole Troan <[email-masked]>
Subject: Re: [spring] Penultimate Segment Popping and RFC8200 (Was Re: We don't seem to be following our processes (Re: Network Programming - Penultimate Segment Popping))

    Ketan,

    

    

    Regards
       Brian

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 11 Dec 2019 21:32:36 +0100

Hi Brian,

> to mean "insert an SRH header in the middle of an existing IPv6 packet

Well I got that. In fact I recommend to some friends to rename it in the NP
draft to "impose" or "place" so the text does not raise blood pressure
where it does not to :)

But again as you see from the subject line this discussion is about
deletion not imposition nor insertion. I bet 6man list will be the forum to
discuss Daniel's draft soon.

> an SRH header."

I think in the context of SRv6 it was/is used to mean both. Insert SRH with
new header or without one. And the context which exact action is required
is inferred from the situation.

Yes this adds unnecessary confusion and I am sure editors will be happy to
clear this in documents.

Said all this NP draft under this discussion does not have any issue with
any of this.

> And in the MPLS data plane context it means "prepend an additional
> MPLS label."
>

> Right or wrong?

Well in MPLS label stack insertion was more called label imposition.

Thx a lot,
R.

---

From: Fernando Gont <[email-masked]>
Date: Wed, 11 Dec 2019 17:34:59 -0500

On 11/12/19 03:29, Robert Raszuk wrote:
> decapsulating the packet I can remove any EH I inserted before. I "own"
> the new IPv6 header. Very simple. It is like taking the cars on a ferry. 
> 
> Your original packet (call it end to end ... call it original src going
> to final/ultimate destination) is just a payload. 
> 

The name says it all: "Penultimate Segment Popping". You remove the SRH
at a place other than the final destination.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Wed, 11 Dec 2019 17:48:49 -0500

Bruno,

On 11/12/19 14:48, [email-masked] wrote:
[....]
> But given that a number of wg participants are saying the opposite, we need to go a bit deeper in the discussion. That's what I've tried to initiate and I believe that we have made progress.

Filling an errata somehow warrants that a clarification on the topic is
about to come (in the event it was ever needed).

> https://mailarchive.ietf.org/arch/msg/ipv6/Ku-kKBE-vG5QGdT2DvqLxMQpRik

My point is that according to RFC8200, which does not specify any
routing header types, the destination cannot contain anything else other
than the final destination of the packet.

The spirit of what the text means is also well known  to all of us 6man
participants as we discussed the topic while working on what eventually
became RFC8200.

[...]
> I'll also monitor your above errata, to see if it's been accepted or rejected. That will typically be a strong input in the balance. 

Agreed on this last item. -- that was part of the motivation of
submitting it.

> I'm not ignoring it. Quite the contrary I'm the one engaging the discussion with you in order to understand the real technical point that you want to make.

The esensce of my technical point is that IPv6 does not support
inserting headers or deleting them on the packets delivery path. And PSP
requires exactly that, violating RFC8200.

Thanks,

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 12 Dec 2019 00:04:33 +0000

Hi Fernando,
  Answer inline.

> On Dec 7, 2019, at 9:31 AM, Fernando Gont <[email-masked]> wrote:
> 

RFC8200 *clearly* speaks about the possibility of the destination address not being the ultimate recipient in the presence of a Routing Header. This is from Section 3 defining the Destination Address as "128-bit address of the intended recipient of the packet (possibly not the ultimate recipient, if a Routing header is present).”

Thanks
Suresh

---

From: Fernando Gont <[email-masked]>
Date: Wed, 11 Dec 2019 19:22:00 -0500

> RFC8200 *clearly* speaks about the possibility of the destination address not being the ultimate recipient in the presence of a Routing Header. This is from Section 3 defining the Destination Addre…

Section 4.4 says:
   The Routing header is used by an IPv6 source to list one or more
   intermediate nodes to be "visited" on the way to a packet's
   destination.

(contrasts this to the statement with eh insertion/removal/processing)

While there could have been better use of terms, do you really think
that RFC8200 is allowing EH insertion/removal at waypoints? Or do you
think that, at best, the wording in RFC8200 could have been better?

How would eh insertion at waypoints work with AH, Path-MTU Discovery,
etc., etc.,etc?

Thanks,

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 13 Dec 2019 03:56:49 +0000

Hi Fernando,

On Dec 11, 2019, at 7:22 PM, Fernando Gont <[email-masked]<mailto:[email-masked]>> wrote:

On Dec 7, 2019, at 9:31 AM, Fernando Gont <[email-masked]<mailto:[email-masked]>> wrote:

Hi Fernando,

On Dec 7, 2019, at 11:07 AM, Fernando Gont <[email-masked]<mailto:[email-masked]>
<mailto:[email-masked]>> wrote:

Whether that's acceptable would be a question for the IETF Last
Call rather than any single WG.

which seems to permit it. Can you please clarify where there is a
violation?

Section 4.4 says:

For sure, I think the text in RFC8200 could have been more specific one way or another but it is impossible to tell at this point which direction the WG would have gone.

Thanks
Suresh

---

From: Fernando Gont <[email-masked]>
Date: Fri, 13 Dec 2019 13:50:01 -0500

[....]
>>>
>>> RFC8200 *clearly* speaks about the possibility of the destination
>>> address not being the ultimate recipient in the presence of a Routing
>>> Header. This is from Section 3 defining the Destination Address as
>>> "128-bit address of the intended recipient of the packet (possibly
>>> not the ultimate recipient, if a Routing header is present).”
>>
>> Section 4.4 says:
> For sure, I think the text in RFC8200 could have been more specific one
> way or another but it is impossible to tell at this point which
> direction the WG would have gone.

IPv6 has never allowed for EH insertion/deletion on the path to the
final destination. As noted, there are way too many things that would
break (PMTUD, AH, etc.).

If I understand correctly, the discussion here is regarding that current
state of affairs, and not about the possibility that the wg might, at
some point, decide to change the current spec.

That's why I've filled an errata, btw.

Thanks,