Subject: Re: [spring] Question about SRv6 Insert function

From: li zhenqiang <[email-masked]>
Date: Mon, 2 Sep 2019 00:54:50 +0000

Totally agree. After the intensive discussion and debates, we reached RFC 8200 which specifies one IPv6 packet header can only has one routing extension header and only the source or destionation node of a packet can do the EH  insertion operation.

I think the two documents are contradict with RFC8200.

Best Regards,
Zhenqiang Li
________________________________
[email-masked]

From: Fernando Gont<mailto:[email-masked]>
Date: 2019-08-31 22:02
To: li zhenqiang<mailto:[email-masked]>; draft-voyer-6man-extension-header-insertion<mailto:[email-masked]>; draft-ietf-spring-srv6-network-programming<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
CC: [email-masked]<mailto:[email-masked]>
Subject: Re: Question about SRv6 Insert function
Folks,

There was a very significant discussion during the IETF LC to make it
crystal clear that IPv6 EHs cannot be inserted. This is clearly codified
in RFC8200.

Are the two documents referenced bellow going against the RFC8200 standard?

Thanks,
Fernando

On 30/8/19 12:52, li zhenqiang wrote:
> Hello all,
>
> End.B6.Insert specified in draft-ietf-spring-srv6-network-programming-01
> will insert a new SRH in the received IPv6 packet, which results in two
> SRHs in one IPv6 packet. It is contradict with RFC8200 that says Each
> extension header should occur at most once, except for the Destination
> Options header.
>
> In draft-voyer-6man-extension-header-insertion-06, an intermediate node
> executes the insert function to implement a sub-50 milliseconds FRR
> operation upon link failure. It is contradict with RFC8200 that
> says 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.
>
> Best Regards,
> Zhenqiang Li
> ------------------------------------------------------------------------
> [email-masked]
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

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

---

From: li zhenqiang <[email-masked]>
Date: Mon, 2 Sep 2019 01:15:44 +0000

Hi Ron,

Thank you for your discussion.
I think the texts of the two documents only describe the option 2 you mentioned, which is contradict with RFC 8200.

Best Regards,
Zhenqiang Li

From: Ron Bonica<mailto:[email-masked]>
Date: 2019-08-31 01:24
To: li zhenqiang<mailto:[email-masked]>; draft-voyer-6man-extension-header-insertion<mailto:[email-masked]>; draft-ietf-spring-srv6-network-programming<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: Question about SRv6 Insert function
Li,

In the scenarios that you mention, below, SRv6 nodes have the following options:

  1.  To prepend and IPv6 header, with its own SRH
  2.  To insert an SRH, as described below

Option 1 is in keeping with the word and spirit of RFC 8200. As you point out, Option 2 contradicts RFC 8200.

So, we should probably explore the motivation for Option 2). If the motivation is not sufficient, we should probably standardize on Option 1.

                                                                                                               Ron

Juniper Business Use Only
From: spring <[email-masked]> On Behalf Of li zhenqiang
Sent: Friday, August 30, 2019 5:53 AM
To: draft-voyer-6man-extension-header-insertion <[email-masked]>; draft-ietf-spring-srv6-network-programming <[email-masked]>; [email-masked]; [email-masked]
Subject: [spring] Question about SRv6 Insert function

Hello all,

End.B6.Insert specified in draft-ietf-spring-srv6-network-programming-01 will insert a new SRH in the received IPv6 packet, which results in two SRHs in one IPv6 packet. It is contradict with RFC8200 that says Each extension header should occur at most once, except for the Destination Options header.

In draft-voyer-6man-extension-header-insertion-06, an intermediate node executes the insert function to implement a sub-50 milliseconds FRR operation upon link failure. It is contradict with RFC8200 that says 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.

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

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 2 Sep 2019 12:07:20 -0400

Hi Fernando,

> On Aug 31, 2019, at 10:09 AM, Fernando Gont <[email-masked]> wrote:
> 
> On 30/8/19 20:24, Ron Bonica wrote:
>> Li,
>> 
>>  
>> 
>> Option 1 is in keeping with the word and spirit of RFC 8200. As you
>> point out, Option 2 contradicts RFC 8200.
>> 
>>  
>> 
>> So, we should probably explore the motivation for Option 2). If the
>> motivation is not sufficient, we should probably standardize on Option 1.
> 
> My argument would be:
> Folks would do whatever they please with 1). If somehow they feel the
> need to do 2), they should *refrain from even suggesting it*, post an
> internet draft that proposes to update RFC8200 to allow for the
> insertion of EHs, wait for that to be adopted and published, and only
> then suggest to do EH insertion.

I have put down my thoughts on the future of header insertion work in a mail to the 6man list in May 2017. The mail can be found below

https://mailarchive.ietf.org/arch/msg/ipv6/4MevopH9_iQglUizhoT5Rl-TjRc <https://mailarchive.ietf.org/arch/msg/ipv6/4MevopH9_iQglUizhoT5Rl-TjRc>

> 
> P.S.: Given the amount of discussion there has been on this topic in the
> context of RFC8200, I'd like to hope that there's no draft-ietf document
> suggesting EH-insertion or, if there is, the relevant ADs and chairs
> make sure that's not the case anymore.

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

Thanks
Suresh

---

From: Ca By <[email-masked]>
Date: Mon, 2 Sep 2019 10:09:46 -0700

On Mon, Sep 2, 2019 at 9:07 AM Suresh Krishnan <[email-masked]>
wrote:

> I have put down my thoughts on the future of header insertion work in a
> mail to the 6man list in May 2017. The mail can be found below
>
> https://mailarchive.ietf.org/arch/msg/ipv6/4MevopH9_iQglUizhoT5Rl-TjRc
>
>
>
> Yes. If a draft violates RFC8200 and it hits the IESG for evaluation, I
> will certainly hold a DISCUSS position until the violations are fixed.
>
> Thanks
> Suresh
>

Thanks. It sounds to me the the SR folks are re-inventing NSH in ipv6.

The internet layer is a narrow waist.

My humble opinion is SR has the same real market traction as  LISP and NSH,
meaning very niche, but loud.

They should look at publishing in the experimental track before asking for
the world.

Regards,
Cameron

---

From: Ron Bonica <[email-masked]>
Date: Mon, 2 Sep 2019 20:58:27 +0000

Cameron,

I hear you. SRv6+ will try to limit its ask to the following:

  *   Enough community review to make sure that we aren't doing anything dangerous
  *   Four code points (i.e., two IPv6 Routing types and two IPv6 options)
  *   One registry (i.e., Special purpose SIDs)

Beyond that, we will try to keep the noise to a minimum.

                                          Ron

From: Ca By <[email-masked]>
Sent: Monday, September 2, 2019 1:10 PM
To: Suresh Krishnan <[email-masked]>
Cc: [email-masked]; Fernando Gont <[email-masked]>; Ron Bonica <[email-masked]>; draft-ietf-spring-srv6-network-programming <[email-masked]>; draft-voyer-6man-extension-header-insertion <[email-masked]>; [email-masked]
Subject: Re: Question about SRv6 Insert function

On Mon, Sep 2, 2019 at 9:07 AM Suresh Krishnan <[email-masked]<mailto:[email-masked]>> wrote:
Hi Fernando,

On Aug 31, 2019, at 10:09 AM, Fernando Gont <[email-masked]<mailto:[email-masked]>> wrote:

In the scenarios that you mention, below, SRv6 nodes have the following
options:

My argument would be:

https://mailarchive.ietf.org/arch/msg/ipv6/4MevopH9_iQglUizhoT5Rl-TjRc<https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_ipv6_4MevopH9-5FiQglUizhoT5Rl-2DTjRc&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=d-vzMZODP_ALHfMhubf5WRxJTGOhRzUKJbOtu85Dffk&s=fbmh6fqc8mAnydHmPoIhor-HPFSjlsvhAIwCflKUbSk&e=>

Thanks
Suresh

My humble opinion is SR has the same real market traction as  LISP and NSH, meaning very niche, but loud.

They should look at publishing in the experimental track before asking for the world.

Regards,
Cameron

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ipv6&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=d-vzMZODP_ALHfMhubf5WRxJTGOhRzUKJbOtu85Dffk&s=CJjpcqScEQwVpIUZyR6cQhyDb5ouN7wH6aIrmCLoIMM&e=>
--------------------------------------------------------------------

---

From: Fernando Gont <[email-masked]>
Date: Tue, 3 Sep 2019 14:17:41 +0300

Hello, Suresh,

On 2/9/19 19:07, Suresh Krishnan wrote:
[....]
> https://mailarchive.ietf.org/arch/msg/ipv6/4MevopH9_iQglUizhoT5Rl-TjRc

This seems e bit misleading. What I would expect is that before any work
is published on EH-insertion, the IPv6 standard is updated to allow for
EH insertion. (plese see bellow)

> will certainly hold a DISCUSS position until the violations are fixed.

Since there have been plenty of attempts to do EH insertion or leave the
IPv6 standard ambiguous in this respect, and the IETF has had consensus
that EH insertion is not allowed, I think it would be bad, wastefull,
tricky, and even dangerous to let a document go through the whole
publication process, and just rely on the AD to keep the "DISCUSS"
button pressed.

Put another way: what'd be the rationale for having a draft-ietf and
have the corresponding wg ship the document with something that clearly
goes against IETF consensus, and that the relevant AD has declared that
wouldn't let pass?

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 3 Sep 2019 22:23:43 -0400

Hi Fernando,

> On Sep 3, 2019, at 7:17 AM, Fernando Gont <[email-masked]> wrote:
> 
> Hello, Suresh,
> 

> goes against IETF consensus, and that the relevant AD has declared that

In short, this is not the case. I am *not* the relevant AD for the SRv6 Network Programming draft. If this document was in 6man I would have flagged it much earlier like I did for the SRH draft.

Thanks
Suresh

---

From: Fernando Gont <[email-masked]>
Date: Wed, 4 Sep 2019 05:50:14 +0300

On 4/9/19 05:23, Suresh Krishnan wrote:
>> On 2/9/19 19:07, Suresh Krishnan wrote: [....]
[....]
>> 
>> Since there have been plenty of attempts to do EH insertion or
>> leave the IPv6 standard ambiguous in this respect, and the IETF has
>> had consensus that EH insertion is not allowed, I think it would be
>> bad, wastefull, tricky, and even dangerous to let a document go
>> through the whole publication process, and just rely on the AD to
>> keep the "DISCUSS" button pressed.
>> 
>> Put another way: what'd be the rationale for having a draft-ietf
>> and have the corresponding wg ship the document with something that
>> clearly goes against IETF consensus, and that the relevant AD has
>> declared that wouldn't let pass?
> 
> In short, this is not the case. I am *not* the relevant AD for the
> SRv6 Network Programming draft. If this document was in 6man I would
> have flagged it much earlier like I did for the SRH draft.

Sorry, what I meant by "relevant AD" is: "one of the responsible ADs for
the spec that's being violated".

i.e., isn't there in the IETF process -- whether formal or informal --
for this sort of thing to be flagged before documents get too far in the
publication process?  ("Hey, this document in your area is actually
breaking a spec of one of my wgs" sort of thing...)

Thanks!

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 3 Sep 2019 23:58:45 -0400

Hi Fernando,

> On Sep 3, 2019, at 10:50 PM, Fernando Gont <[email-masked]> wrote:
> 
> breaking a spec of one of my wgs" sort of thing…)

Nothing official. This is one of the main reasons that we have IESG evaluation (to find any cross area issues). That said, nothing stops an AD from doing this as a WG participant in the other area, but the real question is whether the issue still exists when the document hits the IESG. 

Thanks
Suresh

---

From: Ole Troan <[email-masked]>
Date: Wed, 4 Sep 2019 08:58:06 +0200

Fernando,

> breaking a spec of one of my wgs" sort of thing...)

I would prefer that we calmed down a bit on the protocol policing.

We know that header insertion breaks unsuspecting source hosts if done by the network.
It breaks (at least) PMTUD, ICMP errors and AH.

What we have said in the past is; explain how those issues are dealt with or do not apply to your proposal.
And some form of "doing on behalf of" is not necessarily problematic.

It's the "blind" "Thou shalt not do" that I object to. As opposed to arguing on technical grounds.

Ensuring interoperability is our purpose. Not protect 8200 as if it's a religious text.

Ole

---

From: Fernando Gont <[email-masked]>
Date: Thu, 5 Sep 2019 03:34:09 +0300

> I would prefer that we calmed down a bit on the protocol policing.

Sorry, but this has nothing to do with protocol policing. It has to do
with respecting the consensus this wg and the ietf as a whole had on the
topic. i.e., that EHs must not be inserted in the network.

We'd go into an interesting path to insanity if we publish specs, and
subsequently publish conflicting specs that simply ignore previous ietf
consensus.

If folks want to do EH insertion, the #1 step is to publish a document
that updates RFC8200 such that the "EHs must not be inserted..." is
replaced with something else or eliminated.

> What we have said in the past is; explain how those issues are dealt with or do not apply to your proposal.

That's what you and others may have said or thought. But the consensus
is what's in the standard (RFC8200). And the standard says that EHs
cannot be inserted in the network. If you want to do it, the first step
is to update RFC8200.

> And some form of "doing on behalf of" is not necessarily problematic.

It is rightaway problematic specs-wise when it violates a crystal-clear
requirement in RFC8200, that we arrived to after a very heated debate,
and lots of enegery and time from all the involved people.

The fact that after all the long story behind publication of rfc8200 as
standard (and the ongoing srv6 document we're doing here, which was
adopted on the condition that it wouldn't do eh-insertion), we can live
with other wgs violating specs that we produced here with so much effort
and time, is kind of amusing.

If folks want to allow EH-insertion (i.e., formally allowing middleboxes
to fiddle with packets), RFC8200 should be updated, and the work should
be done in 6man.

I don't think it's SPRING's call how the IPv6 protocol works.

> Ensuring interoperability is our purpose. Not protect 8200 as if it's a religious text.

My #1 concern (not that I don't have others) is one related to fairness
of the standardization process. I don't think we should simply
rubberstamp anything a big vendor wants to sell, no matter how big the
vendor is, or how much money may be involved.

And if this working group (and the IETF as a whole) published a spec on
which there was consensus, ignoring the spec and doing whatever one
pleases is not the way to go. Firstly, make e the case for updating
RFC8200. Then come up with the proposal to fiddle with packets in the
network.

P.S.: I've never been into the camp of protecting X (whether rfc8200 or
any other document) as if it was religious text. Quite ironically, I
have experienced such religious opposition in 6man itself (for instance,
your argument of "don't fix slaac-renumbering because ipv6 has not been
designed to support flash renumbering" seems pretty much a religious
argument against work that would not result in any major modifications
to any of the protocols involved -- as opposed to EH insertion).

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

---

From: Ole Troan <[email-masked]>
Date: Thu, 5 Sep 2019 10:23:07 +0200

Fernando,

See my email to Ron.

Just a short point with regards to your claim:
"If you want to do it, the first step is to update RFC8200".

Let's be clear that this is your own personal view and nothing more than that.

Best regards,
Ole

> On 5 Sep 2019, at 02:34, Fernando Gont <[email-masked]> wrote:
>

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 5 Sep 2019 10:28:48 +0200

Hi Fernando,

> replaced with something else or eliminated.

I have very basic question to close this debate.

Is IP encapsulation of the packet allowed by IPv6 specs or not ?

If it is I see no issue with any documents you quote since when I add a new
IPv6 header I can add any field to it. Moreover when I see myself as
destination address of the packet RFC8200 verbatim allows to add, delete or
modify EHs. I hope you agree with it.

If IP encapsulation is forbidden by IPv6 RFCs please provide a quote and
ref.

Many thx,
R.

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 5 Sep 2019 08:38:47 +0000

Robert,
I fully agree with you that RFC 8200 does not prevent a node that owns the destination address of the IPv6 header to insert EH.
However, RFCV 8200 recommends (?) not to have more than one EH header of any type (excluding the Destination Options header that can occur no more than twice – once before the Routing header and once again – before the upper layer header). I.e., two Routing Headers (of any type) in the same packet are, if not prohibited, then, at least, not recommended.

Do I miss something?

Regards,
Sasha

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

From: spring <[email-masked]> On Behalf Of Robert Raszuk
Sent: Thursday, September 5, 2019 11:29 AM
To: Fernando Gont <[email-masked]>
Cc: Ron Bonica <rbonica=[email-masked]>; [email-masked]; [email-masked]; Ole Troan <[email-masked]>; Suresh Krishnan <[email-masked]>; draft-voyer-6man-extension-header-insertion <[email-masked]>; draft-ietf-spring-srv6-network-programming <[email-masked]>
Subject: Re: [spring] Question about SRv6 Insert function

Hi Fernando,

If it is I see no issue with any documents you quote since when I add a new IPv6 header I can add any field to it. Moreover when I see myself as destination address of the packet RFC8200 verbatim allows to add, delete or modify EHs. I hope you agree with it.

If IP encapsulation is forbidden by IPv6 RFCs please provide a quote and ref.

Many thx,
R.

___________________________________________________________________________

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

---

From: li zhenqiang <[email-masked]>
Date: Thu, 5 Sep 2019 08:44:20 +0000

Hello Robert,

What you said is correct. But what the documents want to do is not what you said. Please see my email raised this discussion.

Best Regards,
Zhenqiang Li

From: Robert Raszuk<mailto:[email-masked]>
Date: 2019-09-05 16:28
To: Fernando Gont<mailto:[email-masked]>
CC: Ron Bonica<mailto:rbonica=[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Ole Troan<mailto:[email-masked]>; Suresh Krishnan<mailto:[email-masked]>; draft-voyer-6man-extension-header-insertion<mailto:[email-masked]>; draft-ietf-spring-srv6-network-programming<mailto:[email-masked]>
Subject: Re: [spring] Question about SRv6 Insert function
Hi Fernando,

Many thx,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 5 Sep 2019 11:06:33 +0200

*Dear Alexander, *

On Thu, Sep 5, 2019 at 10:38 AM Alexander Vainshtein <
[email-masked]> wrote:

> Robert,
>
> I fully agree with you that RFC 8200 does not prevent a node that owns the
> destination address of the IPv6 header to insert EH.
>

Great - Are we done with this "EH insertion" debate now ? :)

> However, RFCV 8200 recommends (?) not to have more than one EH header of
> any type (excluding the Destination Options header that can occur no more
> than twice
>
– once before the Routing header and once again – before the upper layer
> header). I.e., two Routing Headers (of any type) in the same packet are, if
> not prohibited, then, at least, not recommended.
>

SRH is TLV based could be as long as needed.

However sometimes it could be useful from processing pov to decouple some
functions to be placed in separate SRHs for example to clearly filter/boost
processing just by looking at the flags field. But it is just
optimization.

Sure one could ask for new type (or bunch of types) if this makes any
technical merit.

Btw since you point out that Destination Options also only allow to be
present twice we have the same problem there.

*Dear Zhenqiang, *

Would you recommend to define new type of EH for FRR protection ? Say PRH
(Protection Routing Header) extension header with type say 5 ?

Does it make really sense to define a new type just from bureaucracy pov
for each possible application - even if all functionality would still be
identical if we would have the same type 4 carry the data ? Does it make
any sense to do that from hardware processing point of view - to modify it
to recognize bunch of types and still do exact same processing on them ?

Cheers,
R.

---

From: li zhenqiang <[email-masked]>
Date: Thu, 5 Sep 2019 09:22:48 +0000

Dear Robert,

Yes, SRH is TLV based. But the two documents want to insert one more SRH in a packet, not more segments in one SRH.

I recommend nothing. Just post the question.

Best Regards,
Zhenqiang Li

From: Robert Raszuk<mailto:[email-masked]>
Date: 2019-09-05 17:06
To: Alexander Vainshtein<mailto:[email-masked]>
CC: Ron Bonica<mailto:rbonica=[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; draft-voyer-6man-extension-header-insertion<mailto:[email-masked]>; Suresh Krishnan<mailto:[email-masked]>; Fernando Gont<mailto:[email-masked]>; draft-ietf-spring-srv6-network-programming<mailto:[email-masked]>
Subject: Re: [spring] Question about SRv6 Insert function
Dear Alexander,

On Thu, Sep 5, 2019 at 10:38 AM Alexander Vainshtein <[email-masked]<mailto:[email-masked]>> wrote:
Robert,
I fully agree with you that RFC 8200 does not prevent a node that owns the destination address of the IPv6 header to insert EH.

However, RFCV 8200 recommends (?) not to have more than one EH header of any type (excluding the Destination Options header that can occur no more than twice
– once before the Routing header and once again – before the upper layer header). I.e., two Routing Headers (of any type) in the same packet are, if not prohibited, then, at least, not recommended.

However sometimes it could be useful from processing pov to decouple some functions to be placed in separate SRHs for example to clearly filter/boost processing just by looking at the flags field. But it is just optimization.

Sure one could ask for new type (or bunch of types) if this makes any technical merit.

Btw since you point out that Destination Options also only allow to be present twice we have the same problem there.

Dear Zhenqiang,

Would you recommend to define new type of EH for FRR protection ? Say PRH (Protection Routing Header) extension header with type say 5 ?

Does it make really sense to define a new type just from bureaucracy pov for each possible application - even if all functionality would still be identical if we would have the same type 4 carry the data ? Does it make any sense to do that from hardware processing point of view - to modify it to recognize bunch of types and still do exact same processing on them ?

Cheers,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 5 Sep 2019 11:35:45 +0200

Hi,

Ok but this extra insertion is just one of possible SR applications and has
no bearing on SRv6 architecture and all other SRv6 documents running via
various stages of IETF process like number of folks are voicing on the list
just to mud the waters.

There is valid problem statement presented in
https://tools.ietf.org/html/draft-voyer-6man-extension-header-insertion-06 and
if approved and processed via IETF it will update RFC8200.

If IETF decides that FRR is not needed for IPv6 packets that is fine. If WG
decides that this use case is valid but for IPv6 purity requires new EH
type I guess authors will take that feedback and discuss internally.

Cheers
Robert.

On Thu, Sep 5, 2019 at 11:22 AM li zhenqiang <[email-masked]>
wrote:

> Dear Robert,
>
> Yes, SRH is TLV based. But the two documents want to insert one more SRH
> in a packet, not more segments in one SRH.
>

---

From: Fernando Gont <[email-masked]>
Date: Thu, 5 Sep 2019 15:04:03 +0300

> Let's be clear that this is your own personal view and nothing more than that.

I have a few questions for you as 6man wg co-chair:

1) Can a specification (such as some being pursued in spring) violate a
standard (RFC8200) at will, without formally updating it?

2) Is it within spring's charter to specify behaviors that result in an
outright violation of specifications it does not "control"?

Thanks,

---

From: <[email-masked]>
Date: Thu, 5 Sep 2019 14:46:11 +0000

Fernando,

> From: spring [mailto:[email-masked]] On Behalf Of Fernando Gont
> Sent: Tuesday, September 3, 2019 1:18 PM
> 
> Hello, Suresh,
> 

draft-ietf-spring-srv6-network-programming has a normative reference to [I-D.voyer-6man-extension-header-insertion]
 https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-01#section-13.1

As such, from a process standpoint, it would not going to be published before [I-D.voyer-6man-extension-header-insertion] be itself published as RFC. And from its name, the latter is intended to be discussed and within control of the 6MAN WG. So I don't think that we can say that it "just rely on the AD to keep the "DISCUSS" button pressed."

In my mind, this should also be a clear indication that the question of header insertion is (to be) within the control of the 6MAN WG. But you may have a different opinion.

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

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire 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: Thu, 5 Sep 2019 17:55:33 +0300

> In my mind, this should also be a clear indication that the question of header insertion is (to be) within the control of the 6MAN WG. But you may have a different opinion.

Maybe my mental algorithm has a bug, but: what's the point of spring
working on a document that relies on something that 6man has so far
rejected?

You spend energy on the document and then... just sit on the I-D to see
if 6man adopts voyer-6man-extension-header-insertion? Ship the document
to the IESG for them to review? -- I'm lost, sorry.

---

From: <[email-masked]>
Date: Thu, 5 Sep 2019 16:25:12 +0000

> From: Fernando Gont [mailto:[email-masked]] 
> Sent: Thursday, September 5, 2019 4:56 PM
> 

I take your point that 6MAN has rejected, in the past, general header insertion. (under the control of the 6MAN WG as I feel some nuances depending on the speakers)
I don't know about the future 6MAN position with regards to SRH insertion specifically for SRv6, possibly restricted to a specific usage (e.g. TI-LFA) or context (e.g. source, transit and destinations nodes are within a single control domain). As of today, I'm expecting [I-D.voyer-6man-extension-header-insertion] to reflect this and I'm using it as a coordination and gating tooling between 2 IETF WGs. I'm open to considering others tools. But if your point is that the SPRING WG cannot discuss, envisage and document the usage of SRH insertion in the SPRING context, that is not my reading of the SPRING charter. As part of this discussion, you are very welcome to contribute.

Finally, let me remind that draft-ietf-spring-srv6-network-programming is NOT updating RFC8200, and is NOT meant to  update RFC8200. This has been explicitly stated "this document is not intended to update RFC 8200. If a behavior needs to update RFC 8200, it should be defined in a 6MAN draft in the 6MAN WG and normatively referenced."
https://mailarchive.ietf.org/arch/msg/spring/GyYapMbWJdv95hoDMjZNKl5WHG4

> to the IESG for them to review? -- I'm lost, sorry.

draft-ietf-spring-srv6-network-programming is not primarily about header insertion. Its scope is much wider.
So SPRING WG is working on the whole text of draft-ietf-spring-srv6-network-programming. If at some point the normative reference to [I-D.voyer-6man-extension-header-insertion] is holding the progression of the document, as of today I could see two paths: wait some more time/forever (i.e. never publish that document as RFC); remove the text blocking the progression. Personally, I would assume the latter. There could be others options, but I'd rather consider this when/if we face the problem. In the meantime, would you have an issue with any of those two/three hypothetic paths (wait, never publish, remove SRH insertion)?

Thank you.
--Bruno

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Thu, 5 Sep 2019 19:58:13 +0000

Hey Fernando, since you’re lost, here are some more waypoints to help you find your way ;)

- draft-ietf-spring-srv6-network-programming mentions SRH insertion in only 2 of 39 SID behaviors - i.e. it’s a small part of the draft, and all insert variants have an encapsulation variant defined.

- At IETF 101, the 6man WG confirmed that SRH insertion must be worked on before draft-ietf-spring-srv6-network-programming can progress to RFC - i.e. there are not surprises anywhere.

- draft-ietf-spring-srv6-network-programming added a normative reference to draft-voyer-6man-extension-header-insertion to document that fact.

Darren

> On Sep 5, 2019, at 10:55 AM, Fernando Gont <[email-masked]> wrote:
>

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Thu, 5 Sep 2019 20:44:26 +0000

inline…

> On Sep 5, 2019, at 4:01 PM, Fernando Gont <[email-masked]> wrote:
> 
> On 5/9/19 22:52, Darren Dukes (ddukes) wrote:
>> - draft-ietf-spring-srv6-network-programming mentions SRH insertion in
>> only 2 of 39 SID behaviors - i.e. it’s a small part of the draft, and
>> all insert variants have an encapsulation variant defined.
> 
> I don't see how this changes the discussion here.

Perhaps you should read the whole document Fernando.

> Are you suggesting
> that EH insertion can be removed from the document and there would still
> be value in pursuing the document?
> 
> 
>> - At IETF 101, the 6man WG confirmed that SRH insertion must be worked
>> on before draft-ietf-spring-srv6-network-programming can progress to RFC
>> - i.e. there are not surprises anywhere.
>> 
>> - draft-ietf-spring-srv6-network-programming added a normative reference
>> to draft-voyer-6man-extension-header-insertion to document that fact.
> 
> Among the possible options is that EH-insertion is never worked out. In
> which case, what's the point of basing something on EH insertion when
> the status quo is that EH insertion is not allowed, and there does not
> seem to be any indication that that will change anytime soon?
> 

Ah, an excellent reason to never work on anything: if its not easy then don’t bother with the work!

Perhaps we should all grab a martini instead ;)

Darren

---

From: Ron Bonica <[email-masked]>
Date: Fri, 6 Sep 2019 00:09:27 +0000

Darren,

Your comment, and the discussion that elicited it, are very helpful. They remind us that draft-ietf-spring-network-programming are far from maturity. If the END.B6.INSERT and END.B6.INSERT.RED SIDs are to survive, draft-voyer-6man-extension-header-insertion must progress ahead of it.

And if neither END.B6.INSERT nor END.B6.INSERT.RED survive, one would wonder the PSP and USP flavors of the END and END.X are still needed.

These are among the many issues that merit discussion. 

                                                                            Ron

"All who wander are not lost." - J.R.R. Tolkien

-----Original Message-----
From: spring <[email-masked]> On Behalf Of Darren Dukes (ddukes)
Sent: Thursday, September 5, 2019 3:58 PM
To: Fernando Gont <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [spring] Question about SRv6 Insert function

Darren

>>>>>> So, we should probably explore the motivation for Option 2). If 
>>>>>> the motivation is not sufficient, we should probably standardize on Option 1.
>>>>> 
>>>>> My argument would be:
>>>>> Folks would do whatever they please with 1). If somehow they feel 
>>>>> the need to do 2), they should *refrain from even suggesting it*, 
>>>>> post an internet draft that proposes to update RFC8200 to allow 
>>>>> for the insertion of EHs, wait for that to be adopted and 
>>>>> published, and only then suggest to do EH insertion.
>>>> 
>>>> I have put down my thoughts on the future of header insertion work 
>>>> in a mail to the 6man list in May 2017. The mail can be found below
>>>> 
>>>> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/i
>>>> pv6/4MevopH9_iQglUizhoT5Rl-TjRc__;!8WoA6RjC81c!Q1FacHEtMFou8f-8Rus0
>>>> hRzuStyHfpGcZ5AAJPoyFKA59fUR9rDOHPUJzf2MV0sH$
>>> 
>>> This seems e bit misleading. What I would expect is that before any 
>>> work is published on EH-insertion, the IPv6 standard is updated to 
>>> allow for EH insertion. (plese see bellow)
>>> 
>>> 
>>> 
>>> 
>>>>> P.S.: Given the amount of discussion there has been on this topic 
>>>>> in the context of RFC8200, I'd like to hope that there's no 
>>>>> draft-ietf document suggesting EH-insertion or, if there is, the 
>>>>> relevant ADs and chairs make sure that's not the case anymore.
>>>> 
>>>> Yes. If a draft violates RFC8200 and it hits the IESG for 
>>>> evaluation, I will certainly hold a DISCUSS position until the violations are fixed.
>>> 
>>> IPv6 standard ambiguous in this respect, and the IETF has had 
>>> consensus that EH insertion is not allowed, I think it would be bad, 
>>> wastefull, tricky, and even dangerous to let a document go through 
>>> the whole publication process, and just rely on the AD to keep the "DISCUSS"
>>> button pressed.
>> 
>> draft-ietf-spring-srv6-network-programming has a normative reference 
>> to [I-D.voyer-6man-extension-header-insertion]
>> https://urldefense.com/v3/__https://tools.ietf.org/html/draft-ietf-sp
>> ring-srv6-network-programming-01*section-13.1__;Iw!8WoA6RjC81c!Q1FacH
>> EtMFou8f-8Rus0hRzuStyHfpGcZ5AAJPoyFKA59fUR9rDOHPUJzWANflGD$
>> 
> You spend energy on the document and then... just sit on the I-D to 
> see if 6man adopts voyer-6man-extension-header-insertion? Ship the 
> document to the IESG for them to review? -- I'm lost, sorry.
> 
> --
> Fernando Gont
> SI6 Networks
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spri
> ng__;!8WoA6RjC81c!Q1FacHEtMFou8f-8Rus0hRzuStyHfpGcZ5AAJPoyFKA59fUR9rDO
> HPUJzZjOoys5$

_______________________________________________
spring mailing list
[email-masked]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;!8WoA6RjC81c!Q1FacHEtMFou8f-8Rus0hRzuStyHfpGcZ5AAJPoyFKA59fUR9rDOHPUJzZjOoys5$

---

From: Fernando Gont <[email-masked]>
Date: Thu, 5 Sep 2019 23:01:42 +0300

> all insert variants have an encapsulation variant defined.

I don't see how this changes the discussion here. Are you suggesting
that EH insertion can be removed from the document and there would still
be value in pursuing the document?

---

From: Fernando Gont <[email-masked]>
Date: Thu, 5 Sep 2019 23:42:32 +0300

On 5/9/19 23:26, Darren Dukes (ddukes) wrote:
> inline.

I'm arguing that there is a document that relies on stuff that 6man
never even wanted to adopt as wg item. You respond "but the document has
other stuff". And I repeat: the document still assumes EH insertion is
possible, when it's actually forbidden.

> Ah, an excellent reason to never work on anything: if its not easy then don’t bother with the work!

That's clearly not my point. My point is that you are putting the cart
before the horse.

Make your case for EH insertion, and try to update RFC8200 such that EH
insertion is allowed (among other things, explain why you need it, and
why you want to insert EHs instead of encap/decap -- which
draft-voyer-6man-extension-header-insertion does not even mention). Then
do the rest.

Or pursue what you are doing in spring without any EH-insertion, and
postpone anything that has to do with EH insertion for when/if it is
actually allowed.

I'm all for you trying any of these options. But not for the very
curious interpretations of RFC2460 and/or RFC8200, or trying to avoid
updating RFC8200 before doing EH insertion.

Thanks,

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Fri, 6 Sep 2019 00:56:39 +0000

Hi Fernando.

The takeaway I attempted to highlight is that there is in fact agreement between 6man and spring on how to proceed, and we are proceeding as agreed to work on the relevant documents.

Thanks!
  Darren

________________________________
From: Fernando Gont <[email-masked]>
Sent: Thursday, September 5, 2019 4:47 PM
To: Darren Dukes (ddukes)
Cc: [email-masked]; Fernando Gont; Ron Bonica; [email-masked]; [email-masked]; Suresh Krishnan; draft-voyer-6man-extension-header-insertion; li zhenqiang; draft-ietf-spring-srv6-network-programming
Subject: Re: [spring] Question about SRv6 Insert function

Thanks,

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 6 Sep 2019 10:17:59 +0200

Ron,

> They remind us that draft-ietf-spring-network-programming are far from
maturity.

To me it actually highlights something quite contrary. It is that some
folks are pretty far from appreciating or even grasping the value of the
proposal.

In your other note you have extensively elaborated well on how to
effectively kill innovation in IETF. If we would be following your advice
there would be almost non documents which build on former work and update
former work.

But most importantly documenting something does not force anyone to
actually use it if they choose so. This entire smoke about header insertion
from what I have been told has some technical concerns about real source
awareness about say MTU issues. Well for one if I am doing insertion in my
network I better make sure I do not drop the packet based on the MTU. It is
so basic ... of course I must clean up when I fwd the packet to other
domain but this is basic network hygiene.

In the same time folks are happy to encap + add EHs, DOs etc ... on the
grounds that src of the encap will be in the packet. Is this sufficient ..
even if ICMP is sent to such src (domian ingress) I bet such domain ingress
will not notify the original packet src anyway. And with encap the packet
gets much bigger anyway.

But I was not part of v6 creators and I think I will keep it that way based
on that little thread we had here :)

Best,
R.

---

From: Andrew Alston <[email-masked]>
Date: Fri, 6 Sep 2019 08:27:22 +0000

Robert, my problem here is – I believe that there could have been common ground found between various proposals except – what the current drafts do – is fundamentally rewrite the ipv6 protocol – the changes in the address semantics (twice over in incompatible ways between the programming draft and the uSID draft) – the violations of rfc8200 – etc – mean that – it becomes very hard to find a solution when there is a massive philosophical difference – where the philosophical difference is routed in – a v6 address is a 128bit identifier as defined by rfc4291 – vs – an address is well – insert a long list of other things on top of that.

We spent the better part of 25  years getting IPv6 to what it is – and now – fundamentally – there is an attempt to rewrite the very thing that IPv6 is – and therein lies one of my major problems – and no matter how many times I have raised the semantic issues – it seems to be an issue that is being blindly ignored.

Tell me – how do you do aggregation of addresses in the network programming draft – aggregate – lose the function bits
How do you do uSID in the network programming draft – shift – lose the function bits – or – retain the entire stack – and lose the entire point of uSID in the first place – to solve the overhead
By rewriting the IPv6 specification in the way this does – it introduces draft after draft to cater for what is essentially no longer IPv6 – vs – finding a way to work within the IPv6 specification to produce the same functionality as is required in a compatible manner that is more efficient.

Therein I believe lies half the root of this – on one side – you have an attempt to redefine an entire protocol that was 25 years in the making in the image of what one group of people believe it should be – on the other side – you have an acknowledgement of required functionality – and an attempt to provide it while not rewriting the entire protocol in the process.

Andrew

From: ipv6 <[email-masked]> On Behalf Of Robert Raszuk
Sent: Friday, 6 September 2019 11:18
To: Ron Bonica <rbonica=[email-masked]>
Cc: Fernando Gont <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [spring] Question about SRv6 Insert function

Ron,

> They remind us that draft-ietf-spring-network-programming are far from maturity.

To me it actually highlights something quite contrary. It is that some folks are pretty far from appreciating or even grasping the value of the proposal.

In your other note you have extensively elaborated well on how to effectively kill innovation in IETF. If we would be following your advice there would be almost non documents which build on former work and update former work.

But most importantly documenting something does not force anyone to actually use it if they choose so. This entire smoke about header insertion from what I have been told has some technical concerns about real source awareness about say MTU issues. Well for one if I am doing insertion in my network I better make sure I do not drop the packet based on the MTU. It is so basic ... of course I must clean up when I fwd the packet to other domain but this is basic network hygiene.

In the same time folks are happy to encap + add EHs, DOs etc ... on the grounds that src of the encap will be in the packet. Is this sufficient .. even if ICMP is sent to such src (domian ingress) I bet such domain ingress will not notify the original packet src anyway. And with encap the packet gets much bigger anyway.

But I was not part of v6 creators and I think I will keep it that way based on that little thread we had here :)

Best,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 6 Sep 2019 10:36:49 +0200

> what the current drafts do – is fundamentally rewrite the ipv6 protocol

I think you are giving small team of focused engineers way too much credit
here :)

What they tried to do is to merely make sure that if someone decides to use
IPv6 they have a chance to not only have functional parity with other
transports, but also could go a bit forward and turn v6 transport into more
innovation.

In that respect objectives of both SRv6 and SRv6+ are identical.

Now having seen stones being smashed at those who try to actually improve
IPv6 I am personally even more discouraged. It is now becoming even more
obvious why adoption of IPv6 in enterprise networks, enterprise compute
clusters or end users is so marginal after 25+ years ....

Cheers,
R.

On Fri, Sep 6, 2019 at 10:27 AM Andrew Alston <
[email-masked]> wrote:

> Robert, my problem here is – I believe that there could have been common
> ground found between various proposals except – what the current drafts do
> – is fundamentally rewrite the ipv6 protocol – the changes in the address
> semantics (twice over in incompatible ways between the programming draft
> and the uSID draft) – the violations of rfc8200 – etc – mean that – it
> becomes very hard to find a solution when there is a massive philosophical
> difference – where the philosophical difference is routed in – a v6 address
> is a 128bit identifier as defined by rfc4291 – vs – an address is well –
> insert a long list of other things on top of that.
>
>
>
> We spent the better part of 25  years getting IPv6 to what it is – and now
> – fundamentally – there is an attempt to rewrite the very thing that IPv6
> is – and therein lies one of my major problems – and no matter how many
> times I have raised the semantic issues – it seems to be an issue that is
> being blindly ignored.
>
>
>
> Tell me – how do you do aggregation of addresses in the network
> programming draft – aggregate – lose the function bits
>
> How do you do uSID in the network programming draft – shift – lose the
> function bits – or – retain the entire stack – and lose the entire point of
> uSID in the first place – to solve the overhead
>
> By rewriting the IPv6 specification in the way this does – it introduces
> draft after draft to cater for what is essentially no longer IPv6 – vs –
> finding a way to work within the IPv6 specification to produce the same
> functionality as is required in a compatible manner that is more efficient.
>
>
>
> Therein I believe lies half the root of this – on one side – you have an
> attempt to redefine an entire protocol that was 25 years in the making in
> the image of what one group of people believe it should be – on the other
> side – you have an acknowledgement of required functionality – and an
> attempt to provide it while not rewriting the entire protocol in the
> process.
>
>
>
> Andrew
>
>
>
>
>
> *From:* ipv6 <[email-masked]> *On Behalf Of *Robert Raszuk
> *Sent:* Friday, 6 September 2019 11:18
> *To:* Ron Bonica <rbonica=[email-masked]>
> *Cc:* Fernando Gont <[email-masked]>; [email-masked];
> [email-masked]
> *Subject:* Re: [spring] Question about SRv6 Insert function
>
>
>
> Ron,
>
>
>
> But I was not part of v6 creators and I think I will keep it that way
> based on that little thread we had here :)
>
>
>
> Best,
>
> R.
>
>

---

From: Ron Bonica <[email-masked]>
Date: Fri, 6 Sep 2019 15:46:54 +0000

Robert,

Your comment about killing innovation in the IETF strikes me as being odd. I never recommended shutting down SRv6 work. In fact, I support it.

It is you who are asking to shut down SRv6+ work.

So, who is looking to kill innovation in the IETF?

                                                     Ron

From: Robert Raszuk <[email-masked]>
Sent: Friday, September 6, 2019 4:18 AM
To: Ron Bonica <[email-masked]>
Cc: Darren Dukes (ddukes) <[email-masked]>; Fernando Gont <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [spring] Question about SRv6 Insert function

Ron,

Best,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 6 Sep 2019 17:55:47 +0200

Well the term "*shut* *down"* is not precise here. IETF can not shut any
work .. you can keep working on anything you like and keep submitting
individual drafts for it. If you are nice to an AD he me even sponsor it
for publication.

SPRING WG however already has spectrum of mature solutions which address
the problem space - so adopting new proposal now would be more of
distraction then anything else. Also note that SPRING WG adoption will have
an avalanche effect as number of WGs are waiting for SPRING to consider
SRv6+ related drafts to be adopted or not.

Thank you,
R.

On Fri, Sep 6, 2019 at 5:47 PM Ron Bonica <[email-masked]> wrote:

> Robert,
>
>
>
> Your comment about killing innovation in the IETF strikes me as being odd.
> I never recommended shutting down SRv6 work. In fact, I support it.
>
>
>
> *From:* Robert Raszuk <[email-masked]>
> *Sent:* Friday, September 6, 2019 4:18 AM
> *To:* Ron Bonica <[email-masked]>
> *Cc:* Darren Dukes (ddukes) <[email-masked]>; Fernando Gont <
> [email-masked]>; [email-masked]; [email-masked]

---

From: Andrew Alston <[email-masked]>
Date: Fri, 6 Sep 2019 16:03:09 +0000

I second this - and I was extremely clear in my email to spring a few weeks ago - I believe that there is place for both srv6+ and the alternatives - especially since I point out that srv6+ solves an overhead problem that was not solved by srh or the programming draft - and actually pre-dates the usid mechanism.

Do I believe that the NP draft needs work to bring it inline with the consensus agreed approach to rfc8200 and potentially an update to rfc4291 needs to be done to sort out the semantic issues? Certainly - but that is not to say I want the work to stop - on the contrary - I have said it before - and will say it again - I believe we should work on both - and potentially have an interop draft where necessary - and then - let the operators make the choice as to which they wish to use.

There are people on this list who can attest to the fact that I broached the subject of interop with several vendors - and even the authors of some of the drafts under discussion - and I am more than happy to do the work on this if people are willing to join the effort.

Andrew

Liquid Telecommunications - Group Head Of IP Strategy
________________________________
From: ipv6 <[email-masked]> on behalf of Ron Bonica <rbonica=[email-masked]>
Sent: Friday, September 6, 2019 18:50
To: Robert Raszuk
Cc: Fernando Gont; [email-masked]; [email-masked]
Subject: RE: [spring] Question about SRv6 Insert function

Robert,

It is you who are asking to shut down SRv6+ work..

                                                     Ron

---

From: Ron Bonica <[email-masked]>
Date: Fri, 6 Sep 2019 16:43:04 +0000

Robert,

So, you don’t want to prevent innovation. Just make it very difficult 😉

                                                                    Ron

Sent: Friday, September 6, 2019 11:56 AM

Well the term "shut down" is not precise here. IETF can not shut any work .. you can keep working on anything you like and keep submitting individual drafts for it. If you are nice to an AD he me even sponsor it for publication.

SPRING WG however already has spectrum of mature solutions which address the problem space - so adopting new proposal now would be more of distraction then anything else. Also note that SPRING WG adoption will have an avalanche effect as number of WGs are waiting for SPRING to consider SRv6+ related drafts to be adopted or not.

Thank you,
R.

On Fri, Sep 6, 2019 at 5:47 PM Ron Bonica <[email-masked]<mailto:[email-masked]>> wrote:
Robert,

                                                     Ron

From: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Sent: Friday, September 6, 2019 4:18 AM
To: Ron Bonica <[email-masked]<mailto:[email-masked]>>
Cc: Darren Dukes (ddukes) <[email-masked]<mailto:[email-masked]>>; Fernando Gont <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] Question about SRv6 Insert function

Ron,

Best,
R.

---

From: Ole Troan <[email-masked]>
Date: Sat, 7 Sep 2019 23:32:51 +0200

Fernando,

>> The takeaway I attempted to highlight is that there is in fact agreement
>> between 6man and spring on how to proceed, and we are proceeding as
>> agreed to work on the relevant documents.
> 
> I don't really know what the agreement is, other than the implicit
> agreement that if you're considering violating an IPv6 standard, you
> should come to 6man and do a Std Track document that updates the
> relevant standard...

if there ever is a corner case were header insertion can be done safely, and the issues it creates mitigated, then that should certainly not result in an update to the general rule in 8200.

Ole

---

From: Fernando Gont <[email-masked]>
Date: Sun, 8 Sep 2019 01:00:41 +0300

On 8/9/19 00:32, Ole Troan wrote:
> Fernando,
> 
>>> The takeaway I attempted to highlight is that there is in fact
>>> agreement between 6man and spring on how to proceed, and we are
>>> proceeding as agreed to work on the relevant documents.
>> 
>> agreement that if you're considering violating an IPv6 standard,
>> you should come to 6man and do a Std Track document that updates
>> the relevant standard...
> 
> if there ever is a corner case were header insertion can be done
> safely, and the issues it creates mitigated, then that should
> certainly not result in an update to the general rule in 8200.

1) As noted in the discussion, there's nothing that you can do with
EH-insertion that you cannot do with encap/decap. I don't see enough
motivation for an update of this sort -- other than "we want to save 40
bytes". In any case, I repeat what many others have already said: It's
on us to find problems on EH-insertion for it to not move forward. There
should first be a strong argument made in favor of it.

2) You cannot "mitigate" the implications of EH-insertion at the
protocol level (attribution of error messages, MTU issues...). The only
possible mitigations are operational, and those quite often fail.

3) While RFC8200 does not employ RFC2119 language (chair's call, not
mine), the statement in RFC8200 is pretty much a MUST. You do need to
update RFC8200. A reader of RFC8200 should now that there are scenarios
in which EH insertion is indeed allowed. Otherwise you end up with two
specs (IPv6 and SRv6) that contradict with each other.

4) I expect that, as co-chair, you'd agree with me that allowing EH
insertion in IPv6 is a major modification/addition. According to our
charter, we don't seem allowed to do that:
The 6man working group is responsible for the maintenance, upkeep, and
advancement of the IPv6 protocol specifications and addressing
architecture. It is not chartered to develop major changes or additions
to the IPv6 specifications.

I'm quite surprised that a few years ago many of you guys wanted to
essentially freeze most work on IPv6, and now you're so open to such a
major and fundamental change.

Thanks,

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 8 Sep 2019 00:23:56 +0200

Hi,

> charter, we don't seem allowed to do that:

Do you need a new charter to be allowed to standardize extensions to IPv6
header and their operations like SRH ? That is not what AD and chairs said
and one would assume they know better how to guide the work in the group.

Because if this is really the case - we should indeed stop any efforts in
this regard and perhaps seriously start considering a new WG formation to
work on new IP header design perhaps even backwards compatible with current
IPv6 "legacy".

In the meantime - if what you communicate is true WG consensus - proposals
for addition of EH to IPv4 become not only nice to have, but in fact very
useful to have.

Thx,
r.

---

From: Fernando Gont <[email-masked]>
Date: Sun, 8 Sep 2019 01:40:43 +0300

On 8/9/19 01:23, Robert Raszuk wrote:
[...]
> Do you need a new charter to be allowed to standardize extensions to
> IPv6 header and their operations like SRH ? That is not what AD and
> chairs said and one would assume they know better how to guide the work
> in the group. 

WGs do have a charter, which specifies what the WG does. That's why, in
the extreme case, 6man doesn't do TCP stuff. Charters are not casted
into stone, though.

> Because if this is really the case - we should indeed stop any efforts
> in this regard and perhaps seriously start considering a new WG
> formation to work on new IP header design perhaps even backwards
> compatible with current IPv6 "legacy". 

Besides having my own personal opinion, I'd say that no matter the path
you want to follow (or need to follow) to pursue this, you really should
have a much stronger and complete document than the current proposal.

> In the meantime - if what you communicate is true WG consensus -

I'm not entitled to communicate things for the wg. I made a comment
about the charter -- a side comment that came up while noting that
EH-insertion does *not* seem to be a minor addition/modification to IPv6.

> proposals for addition of EH to IPv4 become not only nice to have, but
> in fact very useful to have. 

I'm not sure I follow...

---

From: Fernando Gont <[email-masked]>
Date: Sat, 7 Sep 2019 05:18:29 +0300

Thanks,

---

From: li zhenqiang <[email-masked]>
Date: Tue, 10 Sep 2019 10:14:14 +0000

Hi Bruno,

Thank you very much for your response and clarification.
I agree with you that as of today RFC8200 rejects EH insertion. Since draft-ietf-spring-srv6-network-programming is NOT updating RFC8200, it should not contain texts or mechanisms that contradict with RFC8200.
Of course, Internet Standards can be updated to reflect technical progress and satisfy new requirements following the updating procedure. Before an Internet Standard under update reaches new rough consensus, we have to follow the rules specified in the old one.

BTW, EH insertion was intensively discussed alot when we did RFC2460bis. Two years passed after RFC8200 was published. Is it time for us to reopen the discussion based on the requirement raised in I-D.voyer-6man-extension-header-insertion?

Best Regards,
Zhenqiang Li

From: [email-masked]<mailto:[email-masked]>
Date: 2019-09-06 00:25
To: Fernando Gont<mailto:[email-masked]>; Fernando Gont<mailto:[email-masked]>
CC: Ron Bonica<mailto:rbonica=[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Suresh Krishnan<mailto:[email-masked]>; draft-voyer-6man-extension-header-insertion<mailto:[email-masked]>; draft-ietf-spring-srv6-network-programming<mailto:[email-masked]>; li zhenqiang<mailto:[email-masked]>
Subject: RE: [spring] Question about SRv6 Insert function

Thank you.
--Bruno

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 11 Sep 2019 08:30:41 +1200

Hi Zhenqiang,
> BTW, EH insertion was intensively discussed alot when we did RFC2460bis. Two years passed after RFC8200 was published. Is it time for us to reopen the discussion based on the requirement raised in…

I don't believe that is the first discussion. IMHO, the first discussion should be whether we (as a community) believe we should standardise features that only work within a specified domain, or continue with the assumption that standardised features must work across the open Internet.

Regards
   Brian Carpenter

> 
> Best Regards,
> Zhenqiang Li
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> [email-masked]
> 
>      
>     *From:* [email-masked] <mailto:[email-masked]>
>     *Date:* 2019-09-06 00:25
>     *To:* Fernando Gont <mailto:[email-masked]>; Fernando Gont <mailto:[email-masked]>
>     *CC:* Ron Bonica <mailto:rbonica=[email-masked]>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; Suresh Krishnan <mailto:[email-masked]>; draft-voyer-6man-extension-header-insertion <mailto:[email-masked]>; draft-ietf-spring-srv6-network-programming <mailto:[email-masked]>; li zhenqiang <mailto:[email-masked]>
>     *Subject:* RE: [spring] Question about SRv6 Insert function

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 10 Sep 2019 22:49:13 +0200

Hi Brian,

> the first discussion should be whether we (as a community) believe we
should
> standardise features that only work within a specified domain, or
continue with
> the assumption that standardised features must work across the open
Internet.

Indeed I agree.

Just to rephrase the question:

Is IPv6 to be used only as end to end host to host protocol or should IPv6
also be used as transport protocol natively in the networks.

Solid deployments prove it can be used for both. Many people think it can
and should be used for both.

But if there is solid IETF formal statement that it is *only* to be used as
end to end host protocol then we should really start putting more work into
other encapsulations which will allow to simply transport IPv6 datagrams as
payload or alternatively industry will seek other standards to conitinue
work on IPv6 as transport protocol. Just imagine how it can be called ...
IPv6+ :)

Many thx,
R.

---

From: Mark Smith <[email-masked]>
Date: Wed, 11 Sep 2019 11:37:57 +0930

On Wed, 11 Sep 2019, 06:49 Robert Raszuk, <[email-masked]> wrote:

> also be used as transport protocol natively in the networks..
>
> But if there is solid IETF formal statement that it is *only* to be used
> as end to end host protocol then we should really start putting more work
> into other encapsulations which will allow to simply transport IPv6
> datagrams as payload or alternatively industry will seek other standards to
> conitinue work on IPv6 as transport protocol.
>

If IPv6 can't meet your requirements without dodgy hacks that decommodifies
IPv6, makes it not interoperable with existing IPv6 implementations and
deployments, and makes it much harder to troubleshoot, then no, you should
not use IPv6.

I'm reminded of advice from my Father. Don't use a good blade screwdriver
to open the lid of paint can, because you'll ruin the screwdriver. It's not
the right tool for the job.

Just imagine how it can be called ... IPv6+ :)