Subject: 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: Alexandre Petrescu <[email-masked]>
Date: Fri, 6 Dec 2019 16:47:18 +0100

I would like to mention something.

> Ole, there is no IETF accepted definition of "limited domain".

There is an I-D about limited domains in general.  I agree with it 
partially, towards the positive half.

The limited domain concept was felt needed in other concepts, not just 
SR.  The ULA discussion, to name one of the largest I have seen, relates 
directly to motivate ULA RFC acceptance withing limited domain.

The reason of things working ok in limited domains and not on Internet 
at large was invoked several times when pushing other I-Ds through, even 
though the reason was not called 'limited domain'.

I would go as far as saying that MPLS and IPv6/6lo are _only_ for 
limited domains and will never work for Internet at large.

People joked about the existence of limited domains that cant be seen, 
even though they did not call them that way.

> an approved RFC, must less a Full Standard.

I agree partially.

Alex

>> I could try, although I fear it will be a rehash of what has already 
>> been said many times already in this debate.
>>
>> 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.
>>
>> 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.
>>

---

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: Fernando Gont <[email-masked]>
Date: Fri, 6 Dec 2019 13:59:49 -0300

On 6/12/19 12:47, Alexandre Petrescu wrote:
> There is an I-D about limited domains in general.  

An I-D is not IETF consensus.

---

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: Brian E Carpenter <[email-masked]>
Date: Sat, 7 Dec 2019 08:38:34 +1300

> An I-D is not IETF consensus.

And there will not be IETF consensus on that draft, since we submitted it to
the Independent stream. It's very consciously architectural in nature, but
since the authors aren't in the IAB, the Independent Stream was the only
way to go.

    Brian

---

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: 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: 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: [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: Brian E Carpenter <[email-masked]>
Date: Sat, 7 Dec 2019 09:55:24 +1300

Joel,

> standardize things for "limtied domains".

That's correct, and that's exactly why the "limited domains" draft
was submitted to the Independent Stream. It is a fact, documented in
that draft, that quite a lot of chartered IETF work is directed at
limited domains.

> they do not to date use that as an excuse to violate existing RFCs.

I'm not sure that statement is literally 100% correct, because some instances
may well have passed unnoticed or without controversy. SRH insertion
has not tried to pass unnoticed, and has become controversial.
 
> an approved RFC, must less a Full Standard.

On the other hand, running code in a variety of real and deployed
products is something that we have a long tradition of documenting for
informational purposes. RFC1094 or RFC3954 for example.

Regards
   Brian

---

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: Fernando Gont <[email-masked]>
Date: Fri, 6 Dec 2019 18:22:33 -0300

> that draft, that quite a lot of chartered IETF work is directed at

I'm not necessarily arguing against your point. But I'd note that, when
it comes to IETF consensus, there's no such a thing as "limited
domains", and IPv6 is IPv6 -- we don't have any concept of "IPv6 for the
capital 'I' Internet" and "Modifications for closed domains".

IIRC, I did support your document on int-area (?). So it is not that I'm
against the concept of limited domains. Just noting that, as
IETF-conseusns, there's no such a thing.

That said (and without re-looking at your document right now), there's a
difference between a protocol being effectively employed in a limited
domain (mDNS, if you wish), vs something like this, in which you are
*hoping* that your changes don't leak out of your domain... but in fact
you are not really operating in a limited domain if the src/dst
addresses of packets span past your "limited domain".

> has not tried to pass unnoticed, and has become controversial.

My own impression is that it did try to pass unnoticed. Even the latest
rev of the EH insertion draft doesn't even have a reference to RFC8200.

And if you've read the initial exchange that triggered all other
comments, an author (?) was kind of trying to educate Ron about the
document not doing eh insertion/removal.

> products is something that we have a long tradition of documenting forEven the latest rev of the        

Major difference: None of the two protocols you've reference do an
outright violation of an IETF standard --- even less an Internet Standard.

Thanks,

---

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: Brian E Carpenter <[email-masked]>
Date: Sat, 7 Dec 2019 11:57:15 +1300

On 07-Dec-19 10:22, Fernando Gont wrote:
> My own impression is that it did try to pass unnoticed. 

draft-voyer-6man-extension-header-insertion-00, a document that I strongly
criticised, came out March 28, 2017 and its first sentence read "The network
operator and vendor community has clearly indicated that IPv6 header insertion
is useful and required." I *really* think that your impression is wrong. This
has been public for almost 3 years now.

> Even the latest

Well, the current document editor already said that will be fixed.

> outright violation of an IETF standard --- even less an Internet Standard.

That wasn't my point. (If you want an example that does violate an IS, try RFC1631.)

My point is that we have often document reality.

Regards,
    Brian

---

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: "Joel M. Halpern" <[email-masked]>
Date: Fri, 6 Dec 2019 18:13:55 -0500

Trimmed.
While the age of the documents you cite prevents proof, they sure look 
like what we now publish as Independent Stream documents.

If the draft in question were an Independent Stream RFC, was clearly 
informational, and with clear indications that the authors understood 
that their deployed behavior violates RFC 8200, I would not have much 
objection.  But to date we have not reached nay of those three 
conditions, much less all three.

Yours,
Joel

> On 07-Dec-19 04:09, Joel M. Halpern wrote:
...
> informational purposes. RFC1094 or RFC3954 for example.
...

---

From: Tom Herbert <[email-masked]>
Date: Fri, 6 Dec 2019 15:22:21 -0800

> My point is that we have often document reality.
Brian,

This would seem to establish the blueprint as to how a large vendor
can do whatever they want: simply write your protocols however you
wish, put it into products and get some deployment, and then take it
to IETF to publish as being a "de facto" standard that can't be undone
since it's already a reality. What a great way to circumvent the
standards process!

Tom

---

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

Hi, Brian,

[....]
> has been public for almost 3 years now.

Sorry, what I meant was that "it did try to pass its violation of
RFC8200 unnoticed" -- hence e.g. my comment that even the latest version
does not reference RFC8200.

> Well, the current document editor already said that will be fixed.

I would imagine that would be the first thing I would have included in
version -00 of the document, as opposed to try to pretend there are
reasons for which RFC8200 is not really being violated (which seems to
have been the strategy here).

> My point is that we have often document reality.

I'd have a few comments here:

1) I'm in a way amused that some folks (not you) are more keen to
violate or post a spec that clearly violates a specification, even
without a proper justification, that things' like measurements (RFC7872,
which only got published after dodging way too many bullets), or even
draft-gont-v6ops-ipv6-ehs-packet-drops (probably a good example of
reality being neglected at the IETF). The only explanation that I have
is that in some cases, there's a bit of NIH (Not Invented Here)
syndrome, and/or that there are vendors with big pockets and more power
involved than some of us mere individual participants.

2) The example you reference (RFC1631) is of course a good one. NATs
have been, at the very least, an unavoidable reality. And there's no
nice way to do NAT44. It is what it is. Now, it has been mentioned a few
times here and other lists that the right way to avoid EH-insertion is
encapsulation. I believe that the proponents of EH-insertion could have
tried to take advantage of such advice, and try to build consensus in
that direction. If they explicitly decided to violate the existing
specs, and dismiss the input that was provided by this group, what would
be the point of rubber-stamping their "EH insertion thing" -- "we are a
big vendor, and have the power to publish our spec whether there's
consensus or not?"  -- the fact that they have running code doesn't
obviate the "rough consensus" requirement.

3) Besides the technical arguments against EH insertion (which have been
codified in draft-smith-6man-in-flight-eh-insertion-harmful, I have
asked *lots* of times what's the technical motivation for doing EH
insertion. It boils down to "to save 40 bytes", which doesn't seem to me
as a compelling argument to violate the spec -- even less in a design
that employs 128-bit waypoints and is claimed to be operated in a
limited domain.

---

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: [email-masked]
Date: Sat, 7 Dec 2019 01:02:34 +0100

> that employs 128-bit waypoints and is claimed to be operated in a

You seem to be wrong. You must have missed the 6man header insertion session in Singapore.

Can you please watch:
https://www.youtube.com/watch?v=ZJU0m1EhjaI
Starting at 26:20. Particularly 33:20. TILFA

Ole

---

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

> since it's already a reality. What a great way to circumvent the

As Joel pointed out, many of the historical cases would be Independent
Stream submissions today. But yes, the mechanism you describe was invented
about 30 years ago as far as I can tell. In the end, running code wins.
We got TLS that way, for example.

If draft-voyer- ends up published in the Independent Stream, that
would be fine by me.

Regards
   Brian

---

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:23:21 -0300

> Starting at 26:20. Particularly 33:20. TILFA

When did we start operating on youtube videos as opposed to Internet-Drafts?

Can you you point where in
draft-voyer-6man-extension-header-insertion-08 there's a rationale for
header insertion? -- I'll save you time: just to be able to provide an
educated response to you, I read the document yet again, and there is no
such thing.

I have been asking since the SRH was first discussed on the list (which
predated draft-voyer-6man-extension-header-insertion on the order of
years) what the motivation is for EH insertion. Never got much of a
response other than some agreemet that it is to save 40 bits.

It don't think the wg is being taking seriously when trying to violate
existing IETF specifications, to have a "proposal" (or should i SAY
"notification to the ietf community?") that doesn't even argue why it's
needed, and why they have decided not to follow the advice that this
very wg gave.

So... you see why I need to repeat myself?

---

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

> If draft-voyer- ends up published in the Independent Stream, that

I wonder how the EH insertion document does *not* conflict with the work
of any existing WG -- or for instance, existing standard.

---

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: Tom Herbert <[email-masked]>
Date: Fri, 6 Dec 2019 18:17:07 -0800

Ole,

I've watched the video. I don't see how #3 was addressed. I refer you
to 44:06 when Joel explicitly asked why header insertion is required.
Darren's answer was essentially that they want to have options and
that regardless of any discussion it's going to happen. No technical
explanation has been offered why extension header insertion is needed,
nor has any explanation been offered as to why the alternative of
encapsulation is insufficient to solve the problem. To quote Joel's
response: "The answer is you want it, that's not a good answer.''

Tom

---

From: Ole Troan <[email-masked]>
Date: Sat, 7 Dec 2019 03:44:25 +0100

Tom,

And you are familiar with the TILFA work for SR?

https://tools.ietf.org/html/draft-ietf-rtgwg-segment-routing-ti-lfa-01

Cheers 
Ole

> On 7 Dec 2019, at 03:17, Tom Herbert <[email-masked]> wrote:
>

---

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

Comment at the end...

On 07-Dec-19 14:31, Fernando Gont wrote:
> of any existing WG

Well, 6man has no current work item on EH... except draft-voyer- or
draft-smith-, if we choose to adopt one or both. (In case it isn't
obvious, where we are right now is in a discussion *before* considering
WG adoption, since there's been no adoption call from the chairs.)

>  -- or for instance, existing standard.

The rules for independent submissions don't forbid that, but they do
require that it is stated:
https://tools.ietf.org/html/rfc4846#section-2
"Any submission that constitutes an alternative to, or is in conflict
with, an IETF Standard or proposal for Standards-Track adoption must
clearly indicate that relationship."
And of course the IESG is given a chance to review the draft according
to RFC5742.

   Brian

---

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: "Joel M. Halpern" <[email-masked]>
Date: Fri, 6 Dec 2019 21:52:33 -0500

The TI-LFA task can clearly be done with encapsulation.  That the 
proponents do not desire to do so is clear and understood.  Not desiring 
to do so is not a reason to violate a Full Standard RFC.

That is why I asked what the purpose was for header insertion.  And 
citing the TI-LFA draft does not answer the quesiton.

Yours,
Joel

---

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

> https://tools.ietf.org/html/draft-ietf-rtgwg-segment-routing-ti-lfa-01

Is it really a serious way to try to achieve consensus to routinely fail
to answer the questions that wg participants ask .. which one might
argue that should have already been in version -00 of the document?

The document has been around for about two years. Version -02 had 18
co-authors (!), and yet we're now in version -08 and the document fails
to say why they want to do EH insertion instead of encapsulation.

I point this out, and you ask me to go look at the video. Tom did check
the video, and it turns out that the question was asked, but not answer
-- this confirmed by Joel.

Now you point him to another document.

Do you really think you are being fair and neutral here?

---

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: Fernando Gont <[email-masked]>
Date: Sat, 7 Dec 2019 00:23:02 -0300

>>>>>> On 6/12/19 17:55, Brian E Carpenter wrote:
[,,,,]
> And of course the IESG is given a chance to review the draft according

Agreed.

That, as you correctly noted, is different from having an IETF document
that represents IETF consensus. And of course is of no use as a
reference that backs why an IETF-track document is violating a spec, though.

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: "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: [email-masked]
Date: Sat, 7 Dec 2019 11:30:12 +0100

Joel,

> The TI-LFA task can clearly be done with encapsulation.  That the proponents do not desire to do so is clear and understood.  Not desiring to do so is not a reason to violate a Full Standard RFC.
> 
> That is why I asked what the purpose was for header insertion.  And citing the TI-LFA draft does not answer the quesiton.

The point I tried to make was that propopents of EH insertiona had a slightly more nuanced motivation for doing what they are doing,

>> that employs 128-bit waypoints and is claimed to be operated in a

I see it necessary to speak up when I see participants consistently arguing against strawman.
And call upon higher deities (RFC8200).

Strawman #1:
The proponents of EH insertion proposes to do insertion/deletion directly on user (Internet) traffic.

=> There may be a suspicion that this is what they want, but it is not what they have written down, nor claim.
Take an example of 3 routers A, B and C that is under the same control.
Traffic travels from left to right.

A -- B -- C

A has a tunnel to C using ULA source and destination.
A packet ingresses on A, is encapsulated and forwarded towards C.
A has for reasons unknown to us outsourced a function to B. Where B insert an extension header in the packet originated by A.
C is also in on the game, being a tunnel end-point, removing the encapsulating header and extension header.

If you can leave the nuances of SR and the whatever they propose on the shelf for a minute.

Do you agree in principle that this approach of "header insertion in a controlled domain" can be made to work,
and should be indiscernible from A inserting the extension header itself?

Ole

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 7 Dec 2019 06:19:18 -0500

On the one hand, as is attributed to Milo Medin, with sufficient thrust 
pigs will fly.  So I can not assert that something can not be made to work.

But I have not seen any clear demonstrationthat header insertion in a 
controlled domain is actually safe.   Even if you upgrade all the hosts 
and routers in the domain (a quite significant and difficult to achieve 
hurdle) many of the problems with header insertion by nodes other than 
the origin still apply.  For example, even if the origin "knows" what 
may happen, that does not mean it can properly attribute or respond to 
errors it receives caused by modifications it did not make to the packet.

But the important question is why is it even desirable.  No, 8200 is not 
a religious text.  But it is the product of our standards effort.  We 
reached an agreement that this was not a good idea.  As such, it seems 
to me it requires clear and explicit need before we agree to change the 
rules, even in "controlled domain".  We do not have an IETF agreement 
that "controlled domains" get an arbitrary pass.  We sometimes relax 
some requirements when a need can be shown.   That has not been shown here.

Yours,
Joel

---

From: Mark Smith <[email-masked]>
Date: Sat, 7 Dec 2019 22:33:14 +1100

On Sat, 7 Dec 2019, 21:30 , <[email-masked]> wrote:

> proponents do not desire to do so is clear and understood.  Not desiring to
> do so is not a reason to violate a Full Standard RFC.
> >
> The point I tried to make was that propopents of EH insertiona had a
> slightly more nuanced motivation for doing what they are doing,
> A has for reasons unknown to us outsourced a function to B. Where B insert
> an extension header in the packet originated by A.
> C is also in on the game, being a tunnel end-point, removing the
> encapsulating header and extension header.
>

Why can't they use Link-Local Addresses to tunnel between each hop, i.e.,
between A and B, and then B and C?

LLAs are required for all IPv6 interfaces per RFC4291. IGPs already
discover and use them as next hops. The tunnels to carry the added EHs
between SR routers do not need to be configured, they're implicit in the
universal availability of interfaces Link Local Addresses. These will be
single hop tunnels between SR routers to carry the added EHs.

This is the same processing MPLS uses. MPLS doesn't preserve link-layer
frames through an LSR, it replaces them at each LSR, with new SA and DA at
LSR egress, even when the ingress LSR encapsulation is the same as the
egress encapsulation.

So, just to be clear, if A, B and C were MPLS LSRs, the link-layer frame
used between A and B is a different and unrelated one to the link-layer
frame used between B and C, with the main difference being the frame's SAs
and DAs. MPLS labels aren't inserted into existing link-layer frames,
they're  inserted into a label stack at the time a new link-layer frame is
created to send to the next LSR. The label stack might be modified through
insertion, but the link-layer frames aren't - they're replaced at each and
every LSR hop.

Swap Ethernet for IPv6 tunnelling using Link-Local Addresses, and you are
now following the MPLS model, with your "link-layer" being IPv6.

Using Link Local Addresses creates an even more controlled domain, limited
to a link.

It complies with RFC8200, because the egress outer IPv6 tunnel packet is a
new one, with a new SA and DA, that can have a new set of EHs. Originating
a new tunnel packet is the opportunity to assemble a new set of EHs, some
copied, some copied and modified, and some new.

At B, there is no looking past the IPv6 fixed header to determine if there
is a EH to process - that deeper EH processing is explicitly indicated and
encoded in B's Link Local address, in the outer tunnel header packet's DA.

To functionally compare MPLS over Ethernet and IPv6, LSRs are IPv6 hosts
(anything not an IPv6 router), and Ethernet bridges/switches are IPv6
routers (forwarding frames/packets with non-local addresses).

MPLS over Ethernet isn't typically deployed with bridges/switches between
LSRs, so perhaps that's why people might be thinking that IPv6 routers are
the equivalent of MPLS LSRs, and therefore EH insertion at an IPv6 router
is the same sort of operation that occurs at an MPLS LSR.

Regards,
Mark.

---

From: [email-masked]
Date: Sat, 7 Dec 2019 12:39:43 +0100

Fernando,

> argue that should have already been in version -00 of the document?

If it is not something I would consider productive use of the working groups
time, nor mine, I refrain to answer questions that have both been asked
and answered before. I am not aware of any unanswered questions.

I have made my views on your mailing list behaviour quite clear.
I do not think it is productive use of working group time that
_I_ continue to engage in conversation with you.

If you have any unresolved process issues, take it up with my co-chair or our ADs.

Ole

---

From: [email-masked]
Date: Sat, 7 Dec 2019 12:43:01 +0100

Mark,

> Why can't they use Link-Local Addresses to tunnel between each hop, i.e., between A and B, and then B and C?

There are of course many alternative approaches, depending on use case.
But that isn't an answer to the question I asked.

In the example I gave, "do you in principle see any reason why it could not be made to work"?

Best regards,
Ole

---

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: "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:17:09 -0300

> and answered before. I am not aware of any unanswered questions.

PLease let me clarify:
This document has been around for about two years. It doesn't contain a
motivation, not even a reference to RFC8200, and a note why they need to
do this, and what something else doesn't work for them.

I asked that question numerous times. Do you really think that, two
years later, I should be directed to a video to find the answer, instead
of the authors inclusing the motivation in the draft?

The draft had 18 authors at some time... I don't think I'm asking much.

Thanks,

---

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: "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:17:00 -0800

> of the authors inclusing the motivation in the draft?

I agree. The questions of motivation and necessity for the protocol
have been raised many times both on the list as well in the f2f now.
These are fundamental questions that should be asked of all protocols.
Asking the WG participants to watch videos and then referring them to
yet another draft to answer their questions is frustrating.

Tom

---

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: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: 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: Mark Smith <[email-masked]>
Date: Sun, 8 Dec 2019 10:39:56 +1100

> In the example I gave, "do you in principle see any reason why it could

Sure, it could be made to work. Anything that can be implemented in
software or hardware can be made to work.

However, that's a low success threshold.

It is ignoring other factors like if the mechanism is efficient (doing
things right) and effective (doing the right things).

It is ignoring whether the mechanism is the best performing for the least
cost (efficient restated).

It is ignoring how the mechanism fits within an existing architecture.

It is ignoring how obvious the mechanism's operation is, and how well it
utilises and aligns with existing, proven and well known mechanisms.

It is ignoring how easy and quickly it is to rectify faults when they
inevitably occur, a critical factor in production commercial networks.

It is ignoring how consistent the mechanism is with existing specifications
and existing knowledge.

Showing something works doesn't really prove anything other than it can be
made to work with software or hardware.

Something working well expects all these other factors are used as
judgement criteria.

In my experience there is a big gap between working* and working well.

These other "works well" factors are ones that matter the more when the
mechanism is deployed operationally, because operators can automatically
assume it works when they buy it as it has become a commercial product.

Regards,
Mark.

* This works, but I wouldn't say it works well by the above criteria.
Notice the recommendation at the end.

"A dirty trick to save a couple of IPv4
addresses on a LAN link"
https://www.ausnog.net/sites/default/files/ausnog-2018/presentations/2.10.2_Mark_Smith_AusNOG2018_Lightning.pdf

---

From: [email-masked]
Date: Sun, 8 Dec 2019 10:24:56 +0100

Mark,

[...]
[renamed thread]

> and should be indiscernible from A inserting the extension header itself?

Yes, there are obviously many ways of skinning this cat.
In this thread I don't want to try solve whatever problem the EH insertion camp wants solved. I don't think I understand it well enough.
And I'm unconvinced the 6man group in general understands the underlaying routing problems leading to the proposed solution.
What I was interested in exploring in this thread was if we could reach agreement that there in principle is a safe way of doing header insertion.

In my simple example above.
Do you agree that in a controlled distributed system there is no perceivable difference between node A inserting the header or node B doing it?
Conceptually you could think of it as a tunnel with muliple endpoints (although that's a bit hard to visualize ;-)).

Can we agree that inserting headers and changing the packet size among participating nodes in a distributed system is not inherently unsafe?
As far as I can think of the only complication to be considered is that node A must be aware of packet size changes when doing PMTU estimation.
(typically though in these types of networks, one simply declares that "MTU must be well managed. i.e. large enough".

Cheers,
Ole

---

From: [email-masked]
Date: Sun, 8 Dec 2019 10:34:02 +0100

Mark,

> Sure, it could be made to work. Anything that can be implemented in software or hardware can be made to work.

I don't think that's correct. At least not for my definition of work.
We agree on a higher success threshold.

> However, that's a low success threshold.

Your points below are quite abstract.
Can you think of anything that would break?
Or make it "unsafe"?

I am not suggesting that header insertion is the _best_ approach. That I tihnk has to be evaluated on a per use case basis.
I just want to see if we can reach agreement that it's a solution candidate, that given the deployment restrictions is technically sound.
Deployment restrictions that aren't conceptually very different from deploying e.g. OSPF.

> It is ignoring other factors like if the mechanism is efficient (doing things right) and effective (doing the right things).
> 
> It is ignoring whether the mechanism is the best performing for the least cost (efficient restated).
> 
> It is ignoring how obvious the mechanism's operation is, and how well it utilises and aligns with existing, proven and well known mechanisms.
> 
> It is ignoring how easy and quickly it is to rectify faults when they inevitably occur, a critical factor in production commercial networks.
> 
> It is ignoring how consistent the mechanism is with existing specifications and existing knowledge.
> 
> Showing something works doesn't really prove anything other than it can be made to work with software or hardware.
> 
> Something working well expects all these other factors are used as judgement criteria.
> 
> These other "works well" factors are ones that matter the more when the mechanism is deployed operationally, because operators can automatically assume it works when they buy it as it has become a commercial product.

Best regards,
Ole

---

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

> In this thread I don't want to try solve whatever problem the EH insertion camp wants solved. I don't think I understand it well enough.

That's a good thing. If you don't understand the problems that folks
argue in order to do EH insertion solved, that's an indication that we
should stay safe, and stick to consensus.

In fact, I'd believe that it's quite interesting that we're even
bothering to talk about EH insertion when the folks proposing it didn't
even bother to do a proper analysis, and argue why they need it, and why
the problem can't be solved in any other way.

Datapoint: As a measure of process fairness: when we were doing RFC7217,
we were kind of required to do RFC7721 in order to eventually do
RFC8064. (and we were talking about a host-local policy thing).

So it is quite nice to see that now you are open to screw up the
architecture just because a big vendors wants it, with the only
rationale for doing it, "the operator community want it".

Thanks,

---

From: [email-masked]
Date: Sun, 8 Dec 2019 11:20:57 +0100

Fernando,

Please stop hijacking every thread for your own purposes.

Ole

> On 8 Dec 2019, at 11:02, Fernando Gont <[email-masked]> wrote:
>

---

From: Sander Steffann <[email-masked]>
Date: Sun, 8 Dec 2019 13:49:03 +0100

Hi Ole,

> I just want to see if we can reach agreement that it's a solution candidate, that given the deployment restrictions is technically sound.

If the mechanisms to make sure the rest of the internet doesn't need to suffer from header insertion are in place and reliable, then I don't care much what other operators do on their network. The IETF is about interoperability, and as long as others don't cause me trouble they can do whatever they want on their network. As Randy would say: "I'd recommend all my competitors to do header insertion" :)

As you said: whether header insertion is appropriate is something that everybody can decide for themselves on a per use case basis.

And based on my own experience and the research done by Fernando et all, I decide that header insertion isn't going to happen on my networks. So back to SPRING: I want a solution that works without header insertion (reasons given above). Please work on such a solution. I want to be able to choose an appropriate solution for my network, and something that includes header insertion isn't it. If the feelings about the architectural decision are so strongly opposite, we clearly need multiple solutions to choose from.

Cheers,
Sander

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 8 Dec 2019 10:24:49 -0500

On Sun, Dec 8, 2019 at 4:25 AM <[email-masked]> wrote:

> > A has for reasons unknown to us outsourced a function to B. Where B
> insert an extension header in the packet originated by A.
> In this thread I don't want to try solve whatever problem the EH insertion
> camp wants solved. I don't think I understand it well enough.
> And I'm unconvinced the 6man group in general understands the underlaying
> routing problems leading to the proposed solution.
> What I was interested in exploring in this thread was if we could reach
> agreement that there in principle is a safe way of doing header insertion.
>
> Do you agree that in a controlled distributed system there is no
> perceivable difference between node A inserting the header or node B doing
> it?
> Conceptually you could think of it as a tunnel with muliple endpoints
> (although that's a bit hard to visualize ;-)).
>
> Can we agree that inserting headers and changing the packet size among
> participating nodes in a distributed system is not inherently unsafe?
> As far as I can think of the only complication to be considered is that
> node A must be aware of packet size changes when doing PMTU estimation.
> (typically though in these types of networks, one simply declares that
> "MTU must be well managed. i.e. large enough".

Ole

I think the in flight eh insertion done on the node doing the encapsulation
node A  is safer from a security perspective then an intermediate node
adding a eh header without encapsulation.  I think even though you add an
encapsulation but if the node doing the encapsulation is not the one adding
the eh header it’s no different in my opinion then the node A not doing an
encapsulation at all which was proposed initially by Spring.

So we have to enforce that the EH insertion is only done by the node
performing the encapsulation.

With SRv6 I don’t think there would be a case where intermediate node B is
doing the EH insertion without encapsulation as well.  We should verify
that with Spring and even if they are doing do we should ensure they add an
encapsulation as well for each instance.

See below:

>From a SR perspective this is what the flow would look like in a controlled
SR domain like a SP core which is one of the primary use cases for SRv6.

     A(CE) - B(PE) - C(P) - D(P) - E (PE) - Z(CE)

Each node in the SR domain has a /64 which is the SID locator in the SID
list.

The main goal of the SRH header insertion is to source route the packer
Along the defined traffic engineered path hop by hop.

At each hop along the path the SRH is processed PSSI (per service segment
instruction) SID locator /64 defined on each node in the SR domain is
copied to the DA of each of the intermediate nodes along the path.  This
allows the flow to be hop by hop source routed.

A customer originating flow

A & B have the identical VRF PE-CE relationship as with MPLS L3 vpn VRF
with routing protocol enabled

B ingress of SR domain adds encapsulation and SRH routing header type 4.

C performs PSSI and copies SR SID locator /64 to destination address in
outer IP header

D Egress P performs PSP Penultimate segment pop and removes outer header
encapsulation and EH inserted at node A

E egress PE Performs USP Ultimate segment pop if explicit null is enabled
and removes the encapsulation and EH header.  This node pops all remaining
encapsulations such as L3 VPN AFIs identical function of MPLS PE
( end node in the SR domain)

Packet is forwarded natively to the CE

Z CE - receives the native IPv4 or IPv6 packet

In all cases the originating PE node of the SR domain is the node that
added the outer header encapsulation and SRH EH header.

With SRv6 you would never have node B adding EH header unless special case
below and then it would be also adding an encapsulation as well.

There maybe cases where Ti-LFA is enabled along the SRv6 path for node
protection.  In those cases there would be an additional encapsulation and
SRH header header at the point of local repair(PLR).  That additional
encapsulation would get removed prior to reaching node D in example above.

There also maybe cases of tunnel stitching use where you may have
additional encapsulations added as well along with SRH header which would
follow the same process as above.

I think as long as Spring adheres to only allowing the node performing the
encapsulation to be allowed to add the SRH header then I think we should be
safe and also not in violation of RFC 8200.  Also no security issues with
in flight eh insertion is now eliminated.

Gyan

-- 

Gyan S. Mishra

IT Network Engineering & Technology

Verizon Communications Inc. (VZ)

13101 Columbia Pike FDC1 3rd Floor

Silver Spring, MD 20904

United States

Phone: 301 502-1347

Email: [email-masked]

www.linkedin.com/in/networking-technologies-consultant

---

From: [email-masked]
Date: Sun, 8 Dec 2019 17:03:47 +0100

Gyan,

> I think the in flight eh insertion done on the node doing the encapsulation node A  is safer from a security perspective then an intermediate node adding a eh header without encapsulation.  I think even though you add an encapsulation but if the node doing the encapsulation is not the one adding the eh header it’s no different in my opinion then the node A not doing an encapsulation at all which was proposed initially by Spring.  
> 
> So we have to enforce that the EH insertion is only done by the node performing the encapsulation.

With regards to your comment that node B doing insertion on a packet with SA=A and DA=C, is equivalent to doing insertion on the original packet without encapsulation, I think the risks of that is defined in Mark's draft/8200.

Let me dig down on the security issue a bit.
Still given the simple example I gave earlier.
Can you ellaborate on what security issue you see, and why doing insertion at B is less secure than at A?

Best regards,
Ole

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 8 Dec 2019 11:10:25 -0500

Ole, as far as I can tell, to answer the apparently simple quesiton you 
propose "is there a s safe way to do header insertion?" we would need
o a clear definition of the domain in which it is to be done
o a clear definition of the participants
o and a full re-examination of the discussion which led to the 
prohibition against doing so in RFC 8200

We do not have in front of us a document which achieves either of the 
first two bullets. Without that, it is very hard for us to perform the 
third bullet.

I note for example that the presentation in Sngapore did not disucss the 
implications or behaviors of hosts inside the Segment Routing v6 domain. 
  But the rfc-to-be explicitly includes hosts inserting the information 
in the original header.
the presentation in Singapore did not discuss how SR header creators 
will deal with errors caused by in=-path header insertion, when the 
errors arrive at places that did not perform the insertion.

But there is a more important issue.  The usual IETF practice (not the 
rule, but a practice we have found to be good) is to ask what problem is 
being solved BEFORE we evaluate solutions.  There are many good reasons 
why we have found this helpful.  You seem to be asking for the opposite.

I find myself forced to repeat my question:  what benefit is header 
insertion bringing to justify working group consideration.
I understand your earlier request not to repeat points.  But for me at 
least, it is very hard to answer your question without that.

Yours,
Joel

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 8 Dec 2019 11:15:54 -0500

On Sun, Dec 8, 2019 at 11:03 AM <[email-masked]> wrote:

> Gyan,
>
> > I think the in flight eh insertion done on the node doing the
> encapsulation node A  is safer from a security perspective then an
> intermediate node adding a eh header without encapsulation.  I think even
> though you add an encapsulation but if the node doing the encapsulation is
> not the one adding the eh header it’s no different in my opinion then the
> node A not doing an encapsulation at all which was proposed initially by
> Spring.
> >
> With regards to your comment that node B doing insertion on a packet with
> SA=A and DA=C, is equivalent to doing insertion on the original packet
> without encapsulation, I think the risks of that is defined in Mark's
> draft/8200.
>

     I was thinking the obvious man in middle attack tampering with v6
header by intermediate node and possible impact to AH if used.

-- 

Gyan S. Mishra

Silver Spring, MD 20904

United States

Phone: 301 502-1347

---

From: [email-masked]
Date: Sun, 8 Dec 2019 17:19:54 +0100

Joel,

> Ole, as far as I can tell, to answer the apparently simple quesiton you propose "is there a s safe way to do header insertion?" we would need
> o and a full re-examination of the discussion which led to the prohibition against doing so in RFC 8200
> 
> We do not have in front of us a document which achieves either of the first two bullets. Without that, it is very hard for us to perform the third bullet.

While I appreciate the filibustering, for this particular thread I am only interested in exploring if there is _any_ topology where header insertion can be considered workable.
The topology in question is as I stated initially, A -- B -- C. Using ULA addresses.
If we find that even in this case, you cannot do header insertion safely, then I think we can at least suspect that there is no topology where this can be done.
But so far I have not seen any technical argument for what would break in this case.

And after multiple documents and thousands of emails I'm pretty sure you also can reason quite well about this simplistic example.

Best regards,
Ole

> I note for example that the presentation in Sngapore did not disucss the implications or behaviors of hosts inside the Segment Routing v6 domain.  But the rfc-to-be explicitly includes hosts inserting the information in the original header.
> the presentation in Singapore did not discuss how SR header creators will deal with errors caused by in=-path header insertion, when the errors arrive at places that did not perform the insertion.
> 
> But there is a more important issue.  The usual IETF practice (not the rule, but a practice we have found to be good) is to ask what problem is being solved BEFORE we evaluate solutions.  There are many good reasons why we have found this helpful.  You seem to be asking for the opposite.
> 
> I find myself forced to repeat my question:  what benefit is header insertion bringing to justify working group consideration.
> I understand your earlier request not to repeat points.  But for me at least, it is very hard to answer your question without that.

---

From: Tom Herbert <[email-masked]>
Date: Sun, 8 Dec 2019 08:25:51 -0800

Ole,

IMO, even before we ask the of how to make header insertion work, we
need to ask and get answers to the question why it's needed. That's
why I created the thread on necessity (please comment on it). Until
there is a clear justification for this mechanism, I personally don't
see why the WGshould spend time trying to "make it work".

> Can we agree that inserting headers and changing the packet size among participating nodes in a distributed system is not inherently unsafe?

Please see draft-smith-6man-in-flight-eh-insertion-harmful-01.
Contrary to some interpretations of that draft, it is intended to be
applicable to the whole Internet and not just saying that EH insertion
is harmful on the "open Internet". For instance, loss of attribution
and ICMP breakage will be problems in controlled domains. One might
argue that those problems can be mitigated in such domains, however
have worked in large operator networks I am skeptical that any
mitigations will be sufficient.

Tom

---

From: [email-masked]
Date: Sun, 8 Dec 2019 17:24:07 +0100

Gyan,

>      I was thinking the obvious man in middle attack tampering with v6 header by intermediate node and possible impact to AH if used.

If AH is used, wouldn't A add the signature, and C when validating would know that B added the header and could do verification accordingly?
For a controlled domain where all of A,B and C are acting in cohort, then that wouldn't be too far fetched to assume.
At least a lot more probable than that AH would be used at all. ;-)

Any other security issues you see?

Cheers,
Ole

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 8 Dec 2019 12:12:53 -0500

On Sun, Dec 8, 2019 at 11:24 AM <[email-masked]> wrote:

> > With regards to your comment that node B doing insertion on a packet
> with SA=A and DA=C, is equivalent to doing insertion on the original packet
> If AH is used, wouldn't A add the signature, and C when validating would
> know that B added the header and could do verification accordingly?
> For a controlled domain where all of A,B and C are acting in cohort, then
> that wouldn't be too far fetched to assume.

    With AH the hash signature has to match between source and destination
so in this case with eh insertion it would not

-- 

Gyan S. Mishra

Silver Spring, MD 20904

United States

Phone: 301 502-1347

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 8 Dec 2019 12:17:15 -0500

>> Any other security issues you see?
        I think in a controlled domain like an SP core I don’t see any
other impact.  Also you would not have  AH in the outer headers and only in
the payload so no impact really even with AH used by customers.

Is it possible if we don’t see any impact to make an exception to 8200 for
controlled domains and give example of an SP core.

Gyan S. Mishra

Silver Spring, MD 20904

United States

Phone: 301 502-1347

---

From: [email-masked]
Date: Sun, 8 Dec 2019 18:19:03 +0100

Tom,

> see why the WGshould spend time trying to "make it work".

I started this thread to see if there was agreement that the mechanism _could_ be made to work in the most simple topology.
I don't think "why" is required to have that discussion.

> mitigations will be sufficient.

Right, I would imagine those could be mitigated.
A tunnel head-end must implement an ICMP proxy anyway.

With regards to the open Internet, I think we know and agree that EH insertion cannot be made to "work" there.
(At least not for my definition of work).

Best regards,
Ole

---

From: [email-masked]
Date: Sun, 8 Dec 2019 18:21:34 +0100

Gyan,

>     With AH the hash signature has to match between source and destination so in this case with eh insertion it would not

Right, but C could in theory restore the packet before checking the signature.
In a similar way to what is already required by using a routing header.

A more likely outcome is to declare that AH isn't supported in this case.

Best regards,
Ole

---

From: [email-masked]
Date: Sun, 8 Dec 2019 18:39:34 +0100

>         I think in a controlled domain like an SP core I don’t see any other impact.  Also you would not have  AH in the outer headers and only in the payload so no impact really even with AH used by customers.
> 
> Is it possible if we don’t see any impact to make an exception to 8200 for controlled domains and give example of an SP core.

That's what draft-voyer suggest(s/ed).
Let's consider the consequences in draft-smith and any other we can think of before going there.
(Given that it's already deployed in the "real-world(tm), the discussion is really what status we want to give this in IETF documents,
and if we can give further guidance to how it can be deployed and what restrictions that must be put on it).

There are also other options that I don't think has been considered yet. E.g. the RFC791 record route option approach.
Node A leaves enough scratch space in header for node B to fill in. That way packet size does not need to change.

Best regards,
Ole

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 8 Dec 2019 18:54:15 +0100

Le 07/12/2019 à 12:33, Mark Smith a écrit :
> 
> 
> On Sat, 7 Dec 2019, 21:30 , <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Joel,
> 
>     proponents do not desire to do so is clear and understood.  Not
>     desiring to do so is not a reason to violate a Full Standard RFC.
>      >
>      > That is why I asked what the purpose was for header insertion. 
>     And citing the TI-LFA draft does not answer the quesiton.
> 
>     => There may be a suspicion that this is what they want, but it is
>     not what they have written down, nor claim.
>     Do you agree in principle that this approach of "header insertion in
>     a controlled domain" can be made to work,

A tunnel is defined by around 6 addresses, and the scope requirements
between these addresses are relatively clear.  The 6 addresses are
configured on precisely two computers (never 3, nor 1).  The addresses
are called 'local' and 'remote' (on the virtual interface), and
'next-hop' (in the rt entry).

To answer the question, I think it is possible to use LL addresses as
the 'local' address on each one of the interfaces on A and C, but then
there would be a need of another tunnel.  Also possile for the 'remote' 
addresses.

Alex

> frames through an LSR, it replaces them at each LSR, with new SA and DA 
> at LSR egress, even when the ingress LSR encapsulation is the same as 
> the egress encapsulation.
> 
> frame used between B and C, with the main difference being the frame's 
> SAs and DAs. MPLS labels aren't inserted into existing link-layer 
> frames, they're  inserted into a label stack at the time a new 
> link-layer frame is created to send to the next LSR. The label stack 
> might be modified through insertion, but the link-layer frames aren't - 
> they're replaced at each and every LSR hop.
> 
> Swap Ethernet for IPv6 tunnelling using Link-Local Addresses, and you 
> are now following the MPLS model, with your "link-layer" being IPv6.
> 
> Using Link Local Addresses creates an even more controlled domain, 
> limited to a link.
> 
> It complies with RFC8200, because the egress outer IPv6 tunnel packet is 
> a new one, with a new SA and DA, that can have a new set of EHs. 
> Originating a new tunnel packet is the opportunity to assemble a new set 
> of EHs, some copied, some copied and modified, and some new.
> 
> At B, there is no looking past the IPv6 fixed header to determine if 
> there is a EH to process - that deeper EH processing is explicitly 
> indicated and encoded in B's Link Local address, in the outer tunnel 
> header packet's DA.
> 
> MPLS over Ethernet isn't typically deployed with bridges/switches 
> between LSRs, so perhaps that's why people might be thinking that IPv6 
> routers are the equivalent of MPLS LSRs, and therefore EH insertion at 
> an IPv6 router is the same sort of operation that occurs at an MPLS LSR.
> 
> Regards,
> Mark.
> 
> 
>     Ole
> 
> 
> 
>     [email-masked] <mailto:[email-masked]>

---

From: Sander Steffann <[email-masked]>
Date: Sun, 8 Dec 2019 19:05:16 +0100

Hi,

> A more likely outcome is to declare that AH isn't supported in this case.

I don't think we should standardise any standard that has such a restriction, considering the importace of security these days. So if this is indeed the outcome I would consider that a blocker.

Cheers,
Sander

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 9 Dec 2019 08:30:42 +1300

> Any other security issues you see?

Two comments on this thread:

1) It isn't just AH that is broken; any form whatever of cryptographic authentication of the packet header or the packet as a whole between A and C is impossible unless the key is shared between A and B. But whether that matters or not is a domain-specific decision. If I'm outside the domain, why would I care?

2) For me the test that matters is not whether this all works, but whether the fact that it's happening can in principle be detected from outside the domain. If it can't be detected from outside, why would I care?

Note that NAT fails test 2. I'm not convinced that SRH insertion inside a tunnel does so.

    Brian

---

From: Warren Kumari <[email-masked]>
Date: Sun, 8 Dec 2019 16:13:45 -0500

[no-hats]

> o a clear definition of the domain in which it is to be done

Joel, can I make a small addition to this?
o a clear definition of the domain in which it is to be done, and how
the domain boundary is enforced (I'm not sure if you would have viewed
this as 2 bullets or just one).
Defining the domain might be (somewhat) easy, but it's also important
that the boundary is enforceable - requiring the operator take action
to *block* traffic leaving the boundary is a very different thing to
having the operator intentionally opt devices into the boundary.

W

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

---

From: "[email-masked]" <[email-masked]>
Date: Sun, 08 Dec 2019 16:20:21 -0500

Thank you Warren.  That seems an appropriate and useful addition.Yours,JoelSent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
-------- Original message --------From: Warren Kumari <[email-masked]> Date: 12/8/19  16:14  (GMT-05:00) To: "Joel M. Halpern" <[email-masked]> Cc: Ole Troan <[email-masked]>, 6man WG <[email-masked]> Subject: Re: IPv6 header insertion in a controlled domain [no-hats]On Sun, Dec 8, 2019 at 11:10 AM Joel M. Halpern <[email-masked]> wrote:>> Ole, as far as I can tell, to answer the apparently simple quesiton you> propose "is there a s safe way to do header insertion?" we would need> o a clear definition of the domain in which it is to be doneJoel, can I make a small addition to this?o a clear definition of the domain in which it is to be done, and howthe domain boundary is enforced (I'm not sure if you would have viewedthis as 2 bullets or just one).Defining the domain might be (somewhat) easy, but it's also importantthat the boundary is enforceable - requiring the operator take actionto *block* traffic leaving the boundary is a very different thing tohaving the operator intentionally opt devices into the boundary.W> o a clear definition of the participants> o and a full re-examination of the discussion which led to the> prohibition against doing so in RFC 8200>> We do not have in front of us a document which achieves either of the> first two bullets. Without that, it is very hard for us to perform the> third bullet.>> I note for example that the presentation in Sngapore did not disucss the> implications or behaviors of hosts inside the Segment Routing v6 domain.>   But the rfc-to-be explicitly includes hosts inserting the information> in the original header.> the presentation in Singapore did not discuss how SR header creators> will deal with errors caused by in=-path header insertion, when the> errors arrive at places that did not perform the insertion.>> But there is a more important issue.  The usual IETF practice (not the> rule, but a practice we have found to be good) is to ask what problem is> being solved BEFORE we evaluate solutions.  There are many good reasons> why we have found this helpful.  You seem to be asking for the opposite.>> I find myself forced to repeat my question:  what benefit is header> insertion bringing to justify working group consideration.> I understand your earlier request not to repeat points.  But for me at> least, it is very hard to answer your question without that.>> Yours,> Joel>> On 12/8/2019 4:24 AM, [email-masked] wrote:> > Mark,> >> > [...]> > [renamed thread]> >> >> Take an example of 3 routers A, B and C that is under the same control.> >> Traffic travels from left to right.> >>> >> A -- B -- C> >>> >> A has a tunnel to C using ULA source and destination.> >> A packet ingresses on A, is encapsulated and forwarded towards C.> >> A has for reasons unknown to us outsourced a function to B. Where B insert an extension header in the packet originated by A.> >> C is also in on the game, being a tunnel end-point, removing the encapsulating header and extension header.> >>> >> If you can leave the nuances of SR and the whatever they propose on the shelf for a minute.> >>> >> Do you agree in principle that this approach of "header insertion in a controlled domain" can be made to work,> >> and should be indiscernible from A inserting the extension header itself?> >> > Yes, there are obviously many ways of skinning this cat.> > In this thread I don't want to try solve whatever problem the EH insertion camp wants solved. I don't think I understand it well enough.> > And I'm unconvinced the 6man group in general understands the underlaying routing problems leading to the proposed solution.> > What I was interested in exploring in this thread was if we could reach agreement that there in principle is a safe way of doing header insertion.> >> > In my simple example above.> > Do you agree that in a controlled distributed system there is no perceivable difference between node A inserting the header or node B doing it?> > Conceptually you could think of it as a tunnel with muliple endpoints (although that's a bit hard to visualize ;-)).> >> > Can we agree that inserting headers and changing the packet size among participating nodes in a distributed system is not inherently unsafe?> > As far as I can think of the only complication to be considered is that node A must be aware of packet size changes when doing PMTU estimation.> > (typically though in these types of networks, one simply declares that "MTU must be well managed. i.e. large enough".> >> > Cheers,> > Ole> >> >>> --------------------------------------------------------------------> IETF IPv6 working group mailing list> [email-masked]> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6> ---------------------------------------------------------------------- I don't think the execution is relevant when it was obviously a badidea in the first place.This is like putting rabid weasels in your pants, and later expressingregret at having chosen those particular rabid weasels and that pairof pants.   ---maf

---

From: [email-masked]
Date: Sun, 8 Dec 2019 23:03:18 +0100

Brian,

> 1) It isn't just AH that is broken; any form whatever of cryptographic authentication of the packet header or the packet as a whole between A and C is impossible unless the key is shared between A…

Right. I think Gyan's point was that header insertion made it harder to secure the tunnel between A and C.
So mainly a problem for the controlled domain itself.
ESP NULL would work fine probably, since it doesn't include payload length in the signature.
And you can ensure whatever is inserted is also treated as mutable.
Regardless, this is an inside the controlled domain problem, and one could probably define a suitable security scheme for it if required.

> Note that NAT fails test 2. I'm not convinced that SRH insertion inside a tunnel does so.

I suppose header insertion has to pass both tests.
It has to be transparent to the outside, and it has to be possible to secure within the domain.

Cheers,
Ole

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 8 Dec 2019 18:49:58 -0500

On Sun, Dec 8, 2019 at 5:03 PM <[email-masked]> wrote:

> >> If AH is used, wouldn't A add the signature, and C when validating
> would know that B added the header and could do verification accordingly?
> >> For a controlled domain where all of A,B and C are acting in cohort,
> then that wouldn't be too far fetched to assume.
> > 1) It isn't just AH that is broken; any form whatever of cryptographic
> authentication of the packet header or the packet as a whole between A and
> C is impossible unless the key is shared between A and B. But whether that
> matters or not is a domain-specific decision. If I'm outside the domain,
> why would I care?
>
> Regardless, this is an inside the controlled domain problem, and one could
> probably define a suitable security scheme for it if required.
>
> > 2) For me the test that matters is not whether this all works, but
> whether the fact that it's happening can in principle be detected from
> outside the domain. If it can't be detected from outside, why would I care?
> >

   I think since this is within the operators domain that they have full
control of maintaining the trust boundaries and enforcement of what can be
seen outside the domain.

A good example of this enforcement in the MPLS world is that you don’t
allow any entity or customer outside the operator domain to trace through
the domain.  Real would scenario is using the “no mpls ttl-propagate” to
prevent traceroute through an operators mpls core.

My point is the onus is on the operator to enforce the boundary and allow
or not allow visibly into the operators network.  So 2 can be easily
accomplished but the onus is on the operator.

Ole had a valid point about AH that the probability of the nodes in the
domain having a common security stance is more probable then the operator
using AH within the domain.

-- 

Gyan S. Mishra

Silver Spring, MD 20904

United States

Phone: 301 502-1347

---

From: Ron Bonica <[email-masked]>
Date: Mon, 9 Dec 2019 02:11:01 +0000

Ole,

In TI-LFA, extension header insertion is not the only, and may not even be the best, design option.

You could create a restoration tunnel by prepending a new IPv6 header whose source address is the PLR and whose ultimate destination is the repair node. This new IPv6 header could have its own SRH.

                                                      Ron

Juniper Business Use Only
From: ipv6 <[email-masked]> On Behalf Of Ole Troan
Sent: Friday, December 6, 2019 9:44 PM
To: Tom Herbert <[email-masked]>
Cc: Fernando Gont <[email-masked]>; 6man WG <[email-masked]>
Subject: Re: We don't seem to be following our processes (Re: Network Programming - Penultimate Segment Popping)

Tom,

https://tools.ietf.org/html/draft-ietf-rtgwg-segment-routing-ti-lfa-01<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-rtgwg-segment-routing-ti-lfa-01__;!8WoA6RjC81c!XdwS-dVHQD5A5Sn5ZQILWHzH8IfnRIVdXJ6W-gkhgdC27nq4hWVcDjtKG-UJBowk$>

Cheers
Ole

On 7 Dec 2019, at 03:17, Tom Herbert <[email-masked]<mailto:[email-masked]>> wrote:
On Fri, Dec 6, 2019 at 4:02 PM <[email-masked]<mailto:[email-masked]>> wrote:

Can you please watch:

Ole,

Tom

Ole

---

From: Ron Bonica <[email-masked]>
Date: Mon, 9 Dec 2019 02:42:41 +0000

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

                                                              Ron

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Sander Steffann
Sent: Sunday, December 8, 2019 1:05 PM
To: Ole Troan <[email-masked]>
Cc: 6man WG <[email-masked]>
Subject: Re: IPv6 header insertion in a controlled domain

Hi,

Cheers,
Sander

---

From: Sander Steffann <[email-masked]>
Date: Mon, 9 Dec 2019 07:40:37 +0100

Hi Ron,

> See Section 7.5 of https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26

Not choosing to use AH to protect the SRH is one thing, but not supporting an AH in the existing packet when doing header insertion is quite another. I want to be sure the second doesn't apply.

Cheers
Sander

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 9 Dec 2019 04:04:49 -0500

This draft is really the missing link that really helps give some clarity
to SRv6 and EH insertion issue.

This is from the BESS WG

https://tools.ietf.org/html/draft-dawra-bess-srv6-services-02

Imagine an overlay and network with underlay being MPLS LDP with overlay
BGP services IPv4 IPv6 VPNv4 VPNv6.

Now swap the MPLS underlay with the SRv6 keeping the BGP overlay intact.

That is what is described in this draft and is what is deployed by a number
of operators worldwide.

The key point to note is at the PE-CE junction where typically in an MPLS
domain label imposition happens on the PE towards the P core.

Now instead of label imposition we have 6in6 encapsulation occurring.

Note that this is like the bottom services label L3 vpn label not the
topmost label which is now IPv6 forwarding plane with SRv6.

So we had asked in the voyer eh draft for encapsulation to be complaint
with 8200 instead of doing in flight EH insertion.  That encapsulation I
believe is already occurring with the BGP overlay L2 or L3 services.

So with the overlay which is the tunneled payload customer traffic over
SRv6 that is encapsulated per the BESS overlay draft above.

Below describes BE L3 VPN but I believe even for all SRv6 scenarios, BGP
services overlay, an 6in6 encapsulation occurs which is what we want for
8200 compliance.

1 <https://tools.ietf.org/html/draft-dawra-bess-srv6-services-02#section-1>.
Introduction

   SRv6 refers to Segment Routing instantiated on the IPv6 dataplane [I-
   D.ietf-spring-srv6-network-programming][I-D.ietf-6man-segment-routing
   -header].

   SRv6 based BGP services refers to the L3 and L2 overlay services with
   BGP as control plane and SRv6 as dataplane.

   SRv6 SID refers to a SRv6 Segment Identifier as defined in
   [I-D.ietf-spring-srv6-network-programming
<https://tools.ietf.org/html/draft-dawra-bess-srv6-services-02#ref-I-D.ietf-spring-srv6-network-programming>].

   SRv6 Service SID refers to an SRv6 SID associated with one of the
   service specific behavior on the advertising Provider Edge(PE)
   router, such as (but not limited to), END.DT (Table lookup in a VRF)
   or END.DX (cross-connect to a nexthop) behaviors in the case of L3VPN
   service as defined in [I-D.ietf-spring-srv6-network-programming
<https://tools.ietf.org/html/draft-dawra-bess-srv6-services-02#ref-I-D.ietf-spring-srv6-network-programming>].

   To provide SRv6 service with best-effort connectivity, the egress PE
   signals an SRv6 Service SID with the BGP overlay service route.  The
   ingress PE encapsulates the payload in an outer IPv6 header where the
   destination address is the SRv6 Service SID provided by the egress
   PE.  The underlay between the PEs only need to support plain IPv6
   forwarding [RFC8200 <https://tools.ietf.org/html/rfc8200>
].

   To provide SRv6 service in conjunction with an underlay SLA from the
   ingress PE to the egress PE, the egress PE colors the overlay serviceSo

Gyan

On Mon, Dec 9, 2019 at 1:40 AM Sander Steffann <[email-masked]> wrote:

> Hi Ron,
>
> > See Section 7.5 of
> https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26
>
> Not choosing to use AH to protect the SRH is one thing, but not supporting
> an AH in the existing packet when doing header insertion is quite another.
> I want to be sure the second doesn't apply.
>
> Cheers
> Sander
>
>
-- 

Gyan S. Mishra

Silver Spring, MD 20904

United States

Phone: 301 502-1347

---

From: Ron Bonica <[email-masked]>
Date: Mon, 9 Dec 2019 14:11:54 +0000

Steffann,

I believe that the second does apply.

                                  Ron

-----Original Message-----
From: Sander Steffann <[email-masked]> 
Sent: Monday, December 9, 2019 1:41 AM
To: Ron Bonica <[email-masked]>
Cc: Ole Troan <[email-masked]>; 6man WG <[email-masked]>
Subject: Re: IPv6 header insertion in a controlled domain

Hi Ron,

> See Section 7.5 of .....

Cheers
Sander

---

From: [email-masked]
Date: Mon, 9 Dec 2019 15:32:02 +0100

Ron,

> I believe that the second does apply.

That's not at all obvious to me.
Elaborate please.

Cheers,
Ole

---

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: Fernando Gont <[email-masked]>
Date: Mon, 9 Dec 2019 16:42:18 -0500

> I don't think "why" is required to have that discussion.

Well, you are going against the way I've seen IETF wg operate --
including 6man.

Every time I've seen anybody propose something, there was something to
be achieved, and there was an argument why a particular solution had
been selected and was being evaluated.

But, if we are at it: I want one solution that stuffed three SRHs, and
two DOHs. Will we evaluate that one, too? -- If you wonder why such
strange thing: I won't answer why, either.

Any proposal for EH insertion should explain why they need it, and why
the most obvious, and compliant, encapsulation doesn't work for solving
the problem.

Thanks,

---

From: Tom Herbert <[email-masked]>
Date: Mon, 9 Dec 2019 14:14:32 -0800

> been selected and was being evaluated.
I agree.

I would also point out that this proposal has been extensively
discussed for over two years, and it's unclear what the chairs are
expecting to get out of further discussion. The fact that discussion
has been mostly one sided in no way marginalizes the points made
already, there has been plenty of opportunity for the proponents of
the proposal to explain why it's needed and why alternative of IPIP
encapsulation is insufficient. But at this point we don't have any
answers.

IMO, as it stands, EH insertion is a solution looking for a problem.

Tom

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 9 Dec 2019 17:22:21 -0500

I would like to make a point which I tried to do earlier on this thread
that with SRv6 any flow entering the domain from an external CE device is
“encapsulated” upon entering the domain as an overlay BGP service instance
and then in the underlay is hop by hop routed based on explicit segment
list from SRH header inserted on the ingress PE node of the SR domain.

What I am trying to say is that we had asked Spring to do encapsulation
since in flight eh insertion violated 8200 IP6 spec.  It appears the fact
is that encapsulation is part of the SRv6 spec for flow entering the SR
domain from a customer CE external device.

So now if we have Spring do another encapsulation it would be a double
encapsulation.

In another thread with Adrian I have asked a detailed questions related to
the the TI-LFA 2nd EH header which I believe TI-LFA behavior is similar to
MPLS ldp remote LFA when with MPLS a label is added at the PLR junction
point.  So with TI-LFA I believe an encapsulation has to happen for that to
work and must already be in the specification.  I am still researching to
find the spec where that is stated.

So in a nutshell it is very possible we maybe good to go and SRv6 is
abiding by the IPv6 rules with eh insertion.

See draft below.

https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26
<https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26#section-3>

I had posted a draft from BESS WG that mentions the encapsulation as part
of the SRv6 spec.

So it does appear that SRv6 is following adherence to IPV6 specification.

3
<https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26#section-3>.
SR Nodes

   There are different types of nodes that may be involved in segment
   routing networks: source SR nodes originate packets with a segment in
   the destination address of the IPv6 header, transit nodes that
   forward packets destined to a remote segment, and SR segment endpoint
   nodes that process a local segment in the destination address of an
   IPv6 header.
3.1 <https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26#section-3.1>.
Source SR Node

   A Source SR Node is any node that originates an IPv6 packet with a
   segment (i.e.  SRv6 SID) in the destination address of the IPv6
   header.  The packet leaving the source SR Node may or may not contain
   an SRH.  This includes either:

      A host originating an IPv6 packet.

      An SR domain ingress router encapsulating a received packet in an
      outer IPv6 header, followed by an optional SRH.

   The mechanism through which a segment in the destination address of
   the IPv6 header and the Segment List in the SRH, is derived is
   outside the scope of this document.
3.2 <https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26#section-3.2>.
Transit Node

   A transit node is any node forwarding an IPv6 packet where the
   destination address of that packet is not locally configured as a
   segment nor a local interface.  A transit node is not required to be
   capable of processing a segment nor SRH.
3.3 <https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26#section-3.3>.
SR Segment Endpoint Node

   A SR segment endpoint node is any node receiving an IPv6 packet where
   the destination address of that packet is locally configured as a
   segment or local interface.

On Mon, Dec 9, 2019 at 4:45 PM Fernando Gont <[email-masked]> wrote:

> > I started this thread to see if there was agreement that the mechanism
> _could_ be made to work in the most simple topology.
-- 

Gyan S. Mishra

Silver Spring, MD 20904

United States

Phone: 301 502-1347

---

From: Fernando Gont <[email-masked]>
Date: Mon, 9 Dec 2019 17:29:56 -0500

On 9/12/19 17:22, Gyan Mishra wrote:
> that with SRv6 any flow entering the domain from an external CE device
> is “encapsulated” upon entering the domain as an overlay BGP service
> instance and then in the underlay is hop by hop routed based on explicit
> segment list from SRH header inserted on the ingress PE node of the SR
> domain.
> 
> since in flight eh insertion violated 8200 IP6 spec.  It appears the
> fact is that encapsulation is part of the SRv6 spec for flow entering
> the SR domain from a customer CE external device.
> 
> In another thread with Adrian I have asked a detailed questions related
> to the the TI-LFA 2nd EH header which I believe TI-LFA behavior is
> similar to MPLS ldp remote LFA when with MPLS a label is added at the
> PLR junction point.  So with TI-LFA I believe an encapsulation has to
> happen for that to work and must already be in the specification.  I am
> still researching to find the spec where that is stated.
> 
> 
> I had posted a draft from BESS WG that mentions the encapsulation as
> part of the SRv6 spec.
> 

What do you mean by SRv6? draft-ietf-6man-segment-routing-header?
Something else?

If you meant draft-ietf-6man-segment-routing-header, and without
re-reading now, I'd probably agree.

Now, if you mean network-programming, then the very words "Penultimate
segment popping" should probably ring some bells. Because if you are
popping anything at any place other than the last segment, you are
violating RFC8200.

Thanks,

---

From: Ron Bonica <[email-masked]>
Date: Mon, 9 Dec 2019 22:38:33 +0000

Ole,

If the Routing header is inserted by one transit node and not removed before it reaches its ultimate destination, authentication will fail. Won't it?

                                           Ron

-----Original Message-----
From: [email-masked] <[email-masked]> 
Sent: Monday, December 9, 2019 9:32 AM
To: Ron Bonica <[email-masked]>
Cc: Sander Steffann <[email-masked]>; 6man WG <[email-masked]>
Subject: Re: IPv6 header insertion in a controlled domain

Ron,

Cheers,
Ole

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 9 Dec 2019 19:28:27 -0500

On Mon, Dec 9, 2019 at 5:37 PM Fernando Gont <[email-masked]> wrote:

> > <
> https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26#section-3
> >
> >

   Yes SRH draft Sec 3.1

So from any external CE Ingress PE-CE link to source PE of SR domain the
traffic has to be encapsulated for the BGP services overlay vpnv4 vpnv6
IPv4 IPv6 so that becomes the payload and the new outer header
encapsulation added has the EH inserted.

IPv6 | SRH | Payload BGP overlay IPv4 or IPv6

Gyan S. Mishra

Silver Spring, MD 20904

United States

Phone: 301 502-1347

---

From: Fernando Gont <[email-masked]>
Date: Mon, 9 Dec 2019 20:23:44 -0500

Hello, Gyan,

On 9/12/19 19:28, Gyan Mishra wrote:
> 
> 
> On Mon, Dec 9, 2019 at 5:37 PM Fernando Gont <[email-masked]
> <mailto:[email-masked]>> wrote:
> 

I'm not sure I follow.

draft-ietf-6man-segment-routing-header is in the RFC Ed queue (as far as
I understand), and thus not under discussion.

What we *are* discussing is the network-programming draft, which does
violate RFC8200, as I already explained.

Thanks,

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 10 Dec 2019 10:36:50 +0100

Le 06/12/2019 à 18:06, [email-masked] a écrit :
[...]
>   - Defining new mechanisms for IID formats

This list of topics to circulate through deserves to be set aside.

> Please continue to the good work on EH in the meantime.

It is good to know there is a notion of time schedule for the topics.

Alex

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 10 Dec 2019 23:58:00 -0500

Thank you Alex!!

The leadership are you referring to Co chairs Bob & Ole and AD Warren
Kumari.

Did you mention the 64 bit boundary that we are working on a  SLAAC draft?

Where is the meeting being held?

I will try to attend if I can.

As far as the draft I will get the section added that Dusan mentioned as
soon as I get a chance.  Also try to finish the RFC href cleanup.

I think maybe after that meeting would be a good time to shoot for to
finalize and submit the draft.

Also we will get a good feeling or not of positive feedback on the slaac
change.

I am part of 14 different WG’s hard to imagine so the IETF keeps me pretty
busy along with my full time job along with consulting and of course
personal life.

Not enough hours in a day!!😊

-- 

Gyan S. Mishra

Silver Spring, MD 20904

United States

Phone: 301 502-1347

---

From: Erik Kline <[email-masked]>
Date: Tue, 10 Dec 2019 21:35:41 -0800

I've been assuming Ole was joking.

On Tue, 10 Dec 2019 at 20:58, Gyan Mishra <[email-masked]> wrote:

> Phone: 301 502-1347 <(301)%20502-1347>
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 11 Dec 2019 07:27:35 +0100

> I've been assuming Ole was joking.

I think there was indeed a joke about secrecy on a public list :-)

But I assumed the list of topics and the notion of time was right.

Alex

> 
> On Tue, 10 Dec 2019 at 20:58, Gyan Mishra <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> 
>     Thank you Alex!!
> 
>     The leadership are you referring to Co chairs Bob & Ole and AD
>     Warren Kumari.
> 
>     As far as the draft I will get the section added that Dusan
>     mentioned as soon as I get a chance.  Also try to finish the RFC
>     href cleanup.
> 
>     I think maybe after that meeting would be a good time to shoot for
>     to finalize and submit the draft.
> 
>     Also we will get a good feeling or not of positive feedback on the
>     slaac change.
> 
>     I am part of 14 different WG’s hard to imagine so the IETF keeps me
>     pretty busy along with my full time job along with consulting and of
>     course personal life.
> 
>     On Tue, Dec 10, 2019 at 4:36 AM Alexandre Petrescu
>     <[email-masked] <mailto:[email-masked]>>
>     wrote:
> 
> 
> 
>         Le 06/12/2019 à 18:06, [email-masked]
>         <mailto:[email-masked]> a écrit :
>         [...]
>          >
>     Phone: 301 502-1347 <tel:(301)%20502-1347>
> 
>     Email: [email-masked] <mailto:[email-masked]>
> 
>     <http://www.linkedin.com/in/networking-technologies-consultant>
> 
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 11 Dec 2019 07:33:21 +0100

> The leadership are you referring to Co chairs Bob & Ole and AD Warren 

It is Ole who referred to leadership.  I suppose he referred indeed to 
Chairmanship and AD.

> Did you mention the 64 bit boundary that we are working on a  SLAAC draft?

No, I did not.  I did however wrote publicly to Ole about about the 
problem he mentiond of lack of "permission-less extension of network", 
inthe v6ops WG.  I think it is worth putting that problem in our draft.

> I will try to attend if I can.

Dont hurry.  Re-read Ole's message.  He says these are topics to discuss 
(to 'circulate through').  That means there would be a time (a few 
weeks?) for header insertion discussion, then some other time for each 
of the topic in the list of topics.

So, I dont think there is a meeting.  I would just wait for the topics 
to be circulated through (maybe he meant 'round robin') on the public 
email list.
[...]

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 11 Dec 2019 08:17:53 +0100

Le 09/12/2019 à 23:38, Ron Bonica a écrit :
> Ole,
> 
> If the Routing header is inserted by one transit node and not removed
> before it reaches its ultimate destination, authentication will fail.
> Won't it?

I agree, authentication would fail, because the initial ICV computation 
covers headers that are absent at the reception.

Alex

> -----Original Message----- From: [email-masked]
> <[email-masked]> Sent: Monday, December 9, 2019 9:32 AM To: Ron
> Bonica <[email-masked]> Cc: Sander Steffann
> <[email-masked]>; 6man WG <[email-masked]> Subject: Re: IPv6
> header insertion in a controlled domain
> 
> Ron,
> 
> That's not at all obvious to me. Elaborate please.
> 
> Cheers, Ole
> 
>> -----Original Message----- From: Sander Steffann
>> <[email-masked]> Sent: Monday, December 9, 2019 1:41 AM To: Ron
>> Bonica <[email-masked]> Cc: Ole Troan <[email-masked]>;
>> 6man WG <[email-masked]> Subject: Re: IPv6 header insertion in a
>> controlled domain
>> 
>> Hi Ron,
>> 
>>> See Section 7.5 of .....
>> 
>> Not choosing to use AH to protect the SRH is one thing, but not
>> supporting an AH in the existing packet when doing header insertion
>> is quite another. I want to be sure the second doesn't apply.
>> 
>> Cheers Sander
>>

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 11 Dec 2019 08:54:58 +0100

> o a clear definition of the domain in which it is to be done

In that direction, I think there could be two distinct kinds of domains 
that would denote a limited domain:

- an Enterprise network.

- a single large computer with numerous virtual nodes.

In each of these the EH insertion/deletion might not disturb the 
Internet at large.  The sentinels could be DMZs or 'air gaps'.

Alex

>> In this thread I don't want to try solve whatever problem the EH 
>> insertion camp wants solved. I don't think I understand it well enough.
>> And I'm unconvinced the 6man group in general understands the 
>> underlaying routing problems leading to the proposed solution.
>> What I was interested in exploring in this thread was if we could 
>> reach agreement that there in principle is a safe way of doing header 
>> insertion.
>>
>> perceivable difference between node A inserting the header or node B 
>> doing it?
>> As far as I can think of the only complication to be considered is 
>> that node A must be aware of packet size changes when doing PMTU 
>> estimation.