Subject: some feedback on feedback on draft-bonica-6man-ext-hdr-update-03

From: 神明達哉 <[email-masked]>
Date: Tue, 5 May 2020 18:12:03 -0700

I'd like to clarify a few things about
draft-bonica-6man-ext-hdr-update-03 based on the comments made in
today's interim meeting.  I speak only for myself as a coauthor of the
draft, of course, but I believe I'm generally on the same page as Ron
for these points.

First off, the purpose of this draft is NOT to prevent future
"innovations" on using extension headers (especially in terms
of insertions and deletions) forever.  Protocols evolve over time, and
RFCs have been and will be continuously updated or obsoleted with new
requirements, changes in assumptions, or "innovations".  Even if this
draft intended to prevent such changes it wouldn't be impossible in
practice.  I thought that's too obvious to mention, but if we really
worry about this draft to act as an "innovation blocker", we could add
the obvious note.

Secondly, in a sense this draft indeed clarifies an "obvious" point:
"the node identified in the Destination Address field of the IPv6
header" in Section 4 of RFC8200 means the ultimate destination, not an
intermediate node specified in a routing header, regarding "not [...]
inserted, or deleted by any node".  It was actually obvious to me and
so it's unfortunate that we have to clarify such a point.  But the
recent discussion on draft-ietf-spring-srv6-network-programming proves
that it's not obvious for some others and can even be used as a reason
to pass a WGLC (and, in fact, I surprisingly realized that the RFC text
could literally read in a different way).  So I believe we need an
explicit clarification.

Third, several people suggested we should rather focus on conditions
where we can loosen the restrictions.  That effort is certainly highly
appreciated and I'll support that, but I'd say that's a different
topic than this draft, nor can it substitute for this draft.  RFC 8200
specified the most generic principle and behavior of the IPv6
protocol.  If we leave the ambiguity (I'd rather say a "bug") in the
general protocol, we'll also leave it open for future protocols to
casually violate the intent without giving considerations on the
conditions that allow the exception.  So IMO we need both: fixing the
"bug" of the general case, and work on detailing the conditions to
allow exceptions.

I don't expect everyone agrees on all of my points, but at least I
hope it helps understand the motivation of the draft more accurately.

--
JINMEI, Tatuya

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 6 May 2020 14:52:45 +1200

Due to the real world intervening, I had to drop off the meeting before
this came up. So I appreciate this clarification.
 
> intermediate node specified in a routing header, ...

I do agree that this was my interpretation at the time, but as I already
mentioned we completely forgot to consider the case of routing headers
(also forgotten in RFC7045), so it is understandable that some readers
made a different interpretation.

If we clarify this with a MUST NOT strength, what does that mean?
It means (IMHO) that a specification which allows the MUST NOT to be
ignored needs to say so explicitly, and needs to explain why it's safe.
Since all IETF standards are voluntary standards, it's hard to argue
that is unthinkable. (If it gets IETF rough consensus at Last Call,
of course.)

Regards
    Brian

On 06-May-20 13:12, 神明達哉 wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: [email-masked]
Date: Wed, 6 May 2020 11:33:10 +0200

> On 6 May 2020, at 04:52, Brian E Carpenter <[email-masked]> wrote:
> 

Wouldn't we as part of the consensus process require an explanation why any form of header or packet mangling is safe regardless of this particular draft existing or not?
Or am I missing something here?

Ole

---

From: Philip Homburg <[email-masked]>
Date: Wed, 06 May 2020 12:31:21 +0200

>worry about this draft to act as an "innovation blocker", we could add

I'm in favor of this draft, but I'm sad that this draft is necessary.

We write our RFCs in English. Not some kind of formalized English, not legal
English. Just plain, simple English.

This comes with ambiguities. In my opinion the way to deal with with 
ambiguities is to explicitly writedown what you want to happen. Having an
endless discussion what the words as the are written mean is counter
productive.

A few people mentioned innovations. I don't think innovations are served by
vague, ambigous language. We have decades of experience with extensible
protocols. In many cases we can explictly leave room for future developments.

However, many big innovations cannot be forseen. For example, IPv4 NAT
radically refined the IPv4 architecture. In those cases, we can either 
ignore that there is an issue with our standards, or we can adapt them.
Of course, with any protocol that carries production data, we have to be
careful with innovations to not impact existing systems.

So I assumed that after the discusson surrounding the draft that became RFC
8200, the proponants of inserting routing headers along the path would
write an RFC to update RFC 8200.

This RFC should answers questions like what happens to PMTU discovery,
what happens with authentication, error ICMPs. Ideally there would also be
a justification why this is needed. I think that in the case of segment router,
it can be explained why we don't expect negative effects. But somebody has
to do the work writing that down in a way people outside the segment
routing community can understand it.

That would make it clear to any reader of RFC 8200, that header insertion
does occur and why it has limited impact.

Instead we got the argument that a particular reading of RFC 8200 would make
header insertion possible.

So I would very much like to see drafts that update RFC 8200 in new directions.
However, given that that doesn't seem to be happening. The next best
alternative is to clarify the language of RFC 8200 such that it is clear that
header insertion is not possible without first updating RFC 8200.

---

From: 神明達哉 <[email-masked]>
Date: Wed, 6 May 2020 13:30:14 -0700

At Wed, 6 May 2020 14:52:45 +1200,

> ignored needs to say so explicitly, and needs to explain why it's safe.

Yes, that's what I hope this draft helps.  I also hope it will help
catch accidental violations of this MUST NOT in the process of
standardization (even in a WG discussion, then WGLC, IESG evaluation,
IETF LC).

> that is unthinkable.

It's difficult for me to parse this sentence due to the kind of double
negation...do you mean that we should be able to expect the above
"what it means" happens without the help of this draft?

--
JINMEI, Tatuya

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 7 May 2020 08:51:45 +1200

Hi Ole,

> Or am I missing something here?

No, I think your generalisation is correct (and has been an issue since RFC1631 or thereabouts). IPv6 header mangling is no different in that respect than IPv4 address mangling.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 7 May 2020 08:54:43 +1200

On 07-May-20 08:30, 神明達哉 wrote:
> negation...

Sorry about that, I couldn't think of a more simple way to say it.

>  do you mean that we should be able to expect the above

In the ideal world, yes. But in the real world I think it's
better to publish your draft, to avoid future misunderstandings.

Regards,
   Brian

---

From: Fernando Gont <[email-masked]>
Date: Wed, 6 May 2020 23:11:08 -0300

> Or am I missing something here?

There's a claim that the specification is ambiguous, and, while for 
virtually everyone involved in rfc2460bis it was and is clear the intent 
of the meaning, in retrospective, the resulting text is sloppy.

This draft, and the errata I've submitted on the topic, try to fix that.

I personally believe that, being a bug for which the intent is and was 
clear, it can be done with an erratum (and, indeed, there's pending 
processing of an erratum I've submitted). This shouldn't require consensus.

But, if folks want to fix this problem with a draft (such as this one), 
I don't mind. That's fine.

Once we have a clean slate, folks proposing to change the status quo can 
certainly submit a draft, and argue for a change. That's normal workflow 
for any IETF wg.

P.S.: whether this latter draft is within the charter of 6man is a 
different question.

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

---

From: Fernando Gont <[email-masked]>
Date: Wed, 6 May 2020 23:13:47 -0300

Hello, Philip,

Completely agree with you.

Thanks,
Fernando

On 6/5/20 07:31, Philip Homburg wrote:
> .

---

From: 神明達哉 <[email-masked]>
Date: Fri, 8 May 2020 09:20:34 -0700

At Thu, 7 May 2020 08:54:43 +1200,

> better to publish your draft, to avoid future misunderstandings.

Ah, okay, thanks for the clarification (I actually thought you might
be trying to say the opposite:-).  It's nice to know there's at least
someone other than the authors seeing the need for publishing it.

--
JINMEI, Tatuya

---

From: Ole Troan <[email-masked]>
Date: Fri, 8 May 2020 18:57:53 +0200

> On 8 May 2020, at 18:21, 神明達哉 <[email-masked]> wrote:
> 

What I am struggling with is what can we possibly hope to achieve by publishing this draft...

Cheers 
Ole

---

From: 神明達哉 <[email-masked]>
Date: Fri, 8 May 2020 10:18:10 -0700

At Fri, 8 May 2020 18:57:53 +0200,

> What I am struggling with is what can we possibly hope to achieve by publishing this draft...

In case you missed it, I explained *my hope* in my earlier message:
https://mailarchive.ietf.org/arch/msg/ipv6/GRys9-16AgxCKw8X_Dt-9V4VimM/

For example, if we had had this draft (or even better, published it as
an RFC) before the discussion of draft-ietf-spring-srv6-network-programming,
we could have had more constructive discussions on why its approach is
safe/acceptable even if it would violate the sense of RFC8200 (and the
hypothetical RFC based on this draft) from the beginning, instead of
spending a lot of our time for not very constructive ones regarding
whether it actually conforms to RFC8200 (and therefore no further
consideration is necessary).

Of course, it's just my hope.  I wouldn't be surprised if someone else
is more pessimistic.  My other hope is that we can have a rough
consensus on a more optimistic view on this as a wg and will try to
reach it, but ultimately it's up to the wg.

--
JINMEI, Tatuya

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 8 May 2020 13:47:35 -0400

On Fri, May 8, 2020 at 1:19 PM 神明達哉 <[email-masked]> wrote:

> an RFC) before the discussion of
> draft-ietf-spring-srv6-network-programming,

Gyan> That is the real crux of the why? as to this update to help with the
constant battle with Spring on in flight EH insertion.  There maybe other
cases where tightening the RFC 8200 verbiage maybe helpful but the SRv6 is
the only one so far.  The other one is with TI-LFA with rtgwg with EH
insertion at the PLR node.  In the SRv6 programming draft and with TI-LFA
the workaround was to do encapsulation +  EH insertion to accommodate both
sides.  At the end of last year and into this year it boiled down to the
PSP and Spring after many discussions would not budge on removal of PSP as
a violation.

-- 

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

Email: [email-masked]

---

From: Philip Homburg <[email-masked]>
Date: Fri, 08 May 2020 20:03:45 +0200

> by publishing this draft...

It seems to me that the interpretation of RFC 8200 that an intermediate
router in the context of a routing header may arbitrarily insert, delete, or
modify any extension headers, makes routing headers a very dangerous concept.

To the extent that this is obviously wrong, it make sense to adopt Fernado's
erratum (https://www.rfc-editor.org/errata/eid6003).

However, it can be said that this particular case was never discussed before
RFC 8200 was published. In that case the erratum can be rejected, and we
can see if this draft reaches (rough) consensus.

Independent of merrits of segment routing, allowing arbitrary inserts, deletes,
or modifications is not a good thing.

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 8 May 2020 15:13:26 -0400

I was digging through the many threads with Spring and here is excerpt from
my reply to Darren Dukes and Jingrong which states exact area where the
issue arises with EH removal with PSP and the area of confusion.  I wonder
maybe we can add this example in a stick diagram in the update so it’s
crystal clear.

Excerpt below:

The key is that to the PSP node the incoming SL is 1 - but after the final
DA is copied the SL pointer is updated so  the outgoing SL is 0  - this
satisfying the pseudocode criteria and RFC 8200 to remove the SRH since the
final DA is now set.

If you look at this before the packet is received then it appears as in
flight and not final destination so it may appear not in RFC 8200
conformance which has been the contention all along.  However,  if you look
at it after PSP node has received and processed the PSP function psuedocode
you are now in RFC 8200 conformance.

Kind regards

Gyan

-- 

Gyan  Mishra

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

---

From: Ron Bonica <[email-masked]>
Date: Fri, 8 May 2020 19:21:10 +0000

Folks,

The paragraphs in question state a rule in the negative. They tell us that transit node (i.e., nodes that are neither segment endpoints nor the packet's ultimate destination) must not insert, process or delete extension headers other than the HBH.

This leaves the reader to infer what the rule would be if it were state in the positive. Possible inferences are:

	- Segment endpoints and the packet's ultimate destination node can do whatever they want
	- Some set of unstated rules govern the behavior of segment endpoints and the packet's ultimate destination

Two reasonable individuals might argue about which interpretation is most appropriate. They might even find a compromise position.
The purpose of this draft is to facilitate (if not force) that conversation. Regardless of which conclusion we reach, we need to document it. 

Flexible standards are a good thing. A good standard allows appropriate degrees of freedom and describes them clearly.

Ambiguous standards are a bad thing. They lead to unproductive and irresolvable debates.

Gyan is correct when he observes that our attention would not have been drawn to this paragraph had it not been for SPRING. But we need to disassociate this discussion from SPRING and our passions about it. Let's worry about IPv6 in this WG. Once we reach a conclusion, we can figure out what allowances need to be made for SPRING.

                                                  Ron

Juniper Business Use Only

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Philip Homburg
Sent: Friday, May 8, 2020 2:04 PM
To: [email-masked]
Subject: Re: some feedback on feedback on draft-bonica-6man-ext-hdr-update-03 

[External Email. Be cautious of content]

> What I am struggling with is what can we possibly hope to achieve by 

It seems to me that the interpretation of RFC 8200 that an intermediate router in the context of a routing header may arbitrarily insert, delete, or modify any extension headers, makes routing headers a very dangerous concept.

To the extent that this is obviously wrong, it make sense to adopt Fernado's erratum (https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid6003__;!!NEt6yMaO-gk!Uui_6Edvm9V1eIojAqFcloT_bUU0-WA8ooY9S_dZ4jTn0S8o6cO983hUc2nqIloz$ ).

However, it can be said that this particular case was never discussed before RFC 8200 was published. In that case the erratum can be rejected, and we can see if this draft reaches (rough) consensus.

Independent of merrits of segment routing, allowing arbitrary inserts, deletes, or modifications is not a good thing.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!Uui_6Edvm9V1eIojAqFcloT_bUU0-WA8ooY9S_dZ4jTn0S8o6cO983hUc8QvMqb7$
--------------------------------------------------------------------

---

From: Philip Homburg <[email-masked]>
Date: Fri, 08 May 2020 21:26:10 +0200

>    However,  if you look at it after PSP node has received and
>    processed the PSP function psuedocode you are now in RFC 8200
>    conformance.  

If you say only the final destination of the IPv6 packet removes the 
extension headers and no intermediate router inserts or removes anything,
then there is no conflict with draft-bonica-6man-ext-hdr-update-03 or
with Fernado's erratum. So we just accept either of those as a
clarification of RFC 8200 and move on.

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 8 May 2020 23:21:56 +0200

Hello Philip,

I am not sure if you have carefully followed 100s of emails so far on
either 6man or spring WG lists.

Your comments lead me to believe that perhaps you missed the key point
here. Lecture of the subject draft also does not help at all to clarify
what the behaviour should be as it just does not talk about the problem at
hand. It talks about something which IMHO is obvious to all of us. It mixes
end to end required behaviour with transport behaviour - completely
different layers of transport all within layer 3.

So let me for clarity restate the problem - hoping that those who do care
about technical points will find it useful:

Application opens a socket and original IPv6 packets get's send from node
N1 to final/ultimate/etc destination N2.

Obviously it contains some v6 base header and may contain some extension
headers.

No one here is doing *anything* to this very headers. For those calling it
end to end principle of IPv6 no one is changing a bit. Those stay intact.

But as it is unfortunately the case N1 and N2 may not be directly
connected. Worse to get from N1 to N2 packets may need to transit via third
party network or networks.

So it is very common that each transit network today implements some form
of encapsulation for various reasons. Some use IPv4 encap, some use
MPLS-LDP, some use RSVP-TE, some use IPv6 in IPv6. Even if you go and try
to buy "a circuit" you will be getting an emulated circuit over someone's
IPv4 or IPv6 network.

Transport network operator is responsible for his network - so all claims
that oh if I insert a bit here or there packets may exceed MTU and will be
dropped while theoretically true really do not happen in real life as no
one sane accepts the larger packet which it would not be able to carry as
transit provider. Besides if someone would he would be out of business
already so nothing for IETF to worry about.

So now comes the crux of what some call "the issue". On the edge of transit
network T1 packets is getting a new IPv6 header. Original packet intact is
wrapped and placed into the new envelope.

Sometimes DST of the packet T2 means egress from transit network. Sometimes
it means a middle hop which by network programming will know how to handle
it and apply new destination Tn.

I do not see anything wrong with any  "intermediate destination of the
packet" to do what it considers best in order to deliver packet to the
transit network egress node.

Now comes the topic of an additional hander mangling even by nodes which
are not intermediate destinations, yet all within transit network. Real use
case example of this would be the local path or node protection. The less
overhead it incurs the better for the end to end service hence those
arguing let's apply new IPv6 header there are just off in the efficiency
curve - even if it perhaps simplifies some of the hardware processing. If
we can insert arbitrary MPLS stack anywhere in transit why one would not be
able to insert a new SRH into his own IPv6 transit header ? SIDs are much
larger - oh no ... take a look at our vSID proposal.

Finally packet gets to the ultimate egress of transit network and continues
its journey towards N2.

To conclude - all what transit does with the packet has nothing to do with
end to end principle. If someone is trying to fit today's networking into
OSI model I am afraid it will fail as OSI model does not map today's
flavors of IP layer 3 transport planes.

If some would like to see N1 to N2 traversing without any encapsulation I
believe need to build new Internet by themselves starting with dark fiber.
Mean time folks trying to use IPv6 to deliver better services are facing
some fascinating oppositions which can not even in technical terms explain
the issue.

I am really puzzled what the subject draft is trying to clarify. Plain
mortal reading does not reveal the mystery behind it. Maybe printing it on
good printer and flashing UV light would help ? Maybe some have special
decoder which would reveal the real text. No idea.

Kind regards,
Robert.

PS. Another way to look at this space is to either accept that
encapsulation of IPv6 in IPv6 is allowed or not. And as we are rewriting L2
header at each L3 hop - one can consider SRv6 technology as rewriting IPv6
header at each L3 hop within a given network. If so all header operations
are permitted by each hop if not by RFC8200 then by RFC2473.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 9 May 2020 10:04:32 +1200

Gyan,

On 09-May-20 07:13, Gyan Mishra wrote:
> I was digging through the many threads with Spring and here is excerpt from my reply to Darren Dukes and Jingrong which states exact area where the issue arises with EH removal with PSP and the area of confusion.  I wonder maybe we can add this example in a stick diagram in the update so it’s crystal clear.
> 
> Excerpt below:
> 
>> The key is that to the PSP node the incoming SL is 1 - but after the final DA is copied the SL pointer is updated so  the outgoing SL is 0  - this satisfying the pseudocode criteria and RFC 8200 to remove the SRH since the final DA is now set.  
>> 

The problem with that is that standards for protocol data units are about what goes on the link, not about what happens inside a node. PSP is applied to a PDU with SL>0 and that is allowed by RFC8200 only if you interpret "destination address" as the current destination address rather than the ultimate destination address. The draft removes that ambiguity in RFC8200 (and in answer to Ole, the draft is necessary precisely because RFC8200 is ambiguous, which is also why this cannot be fixed by an erratum).

In other words, +1 to Philp Homburg's message.

   Brian

> 
> If you look at this before the packet is received then it appears as in flight and not final destination so it may appear not in RFC 8200 conformance which has been the contention all along.  However,  if you look at it after PSP node has received and processed the PSP function psuedocode you are now in RFC 8200 conformance.
> 
> Kind regards
> 
> Gyan
> 
> On Fri, May 8, 2020 at 2:04 PM Philip Homburg <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     [email-masked] <mailto:[email-masked]>
> Email: [email-masked] <mailto:[email-masked]>
> 
> 
> 
>

---

From: Philip Homburg <[email-masked]>
Date: Sat, 09 May 2020 00:41:56 +0200

>are not intermediate destinations, yet all within transit network. 

So this is the key point. RFC 8200 applies to all IPv6 packets. So if
RFC 8200 allows additional header mangling, then that can happen in lots of 
other places as well, which is quite undesirable.

So RFC 8200 has to state that in general this sort of thing cannot happen.
Next we can update RFC 8200 with a narrowly crafted exception tailored to
this use case.

We have two possibilities:
- either RFC 8200 allows mangling by hops in a routing header. In that
  case we have a problem that needs to be fixed while creating an exception
  for segment routing, or
- RFC 8200 does not allow this kind of mangling and we need to create an
  exception for segment routing.

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 9 May 2020 01:06:20 +0200

Hi Philip,

Sounds very reasonable.

IMO what is needed here is a short spec which would explicitly call out the
case of using IPv6 as transport layer. Then it would allow the transport
owner sufficient flexibility (insertion, modification, deletion) into
applied by his own ingress new IPv6 header at any transit hop he seems
required. Ultimate goal is to deliver carried payload (here original IPv6
or IPv4 packets) via a given network the best quality possible.

Thx a lot,
Robert.

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 8 May 2020 19:27:53 -0400

Given that SRv6 PGM draft has left the station awaiting publication I think
the most prudent recourse for 6MAN is to grant the exception for SRV6
technology to allow insertion and removal on any transit node within the
carriers administrative domain.

https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-network-programming/

DocumentType Active Internet-Draft (spring WG
<https://datatracker.ietf.org/wg/spring/>)
Last updated 2020-04-14 (latest revision 2020-03-27)
Replaces draft-filsfils-spring-srv6-network-programming
<https://datatracker.ietf.org/doc/draft-filsfils-spring-srv6-network-programming/>
Stream IETF
Intended RFC status Proposed Standard
Formats  plain text
<https://www.ietf.org/id/draft-ietf-spring-srv6-network-programming-15.txt>
 xml
<https://www.ietf.org/id/draft-ietf-spring-srv6-network-programming-15.xml>
 pdf
<https://tools.ietf.org/pdf/draft-ietf-spring-srv6-network-programming-15.pdf>
htmlized
(tools)
<https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-15>
 htmlized
<https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-network-programming-15>
 bibtex
<https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-network-programming/bibtex>
StreamWG state <https://datatracker.ietf.org/help/state/draft/ietf> Submitted
to IESG for Publication
Document shepherd Bruno Decraene

In the verbiage as to reasons why this being allowed is that SRv6 would
always be used in a closed domain with standard security protection
mechanisms at ingress and egress of the domain.  Domain definition would
have to be defined as a carriers administratrative domain where the
carriers transport network could span multiple ASs that are inter connected
via SR-TE bsid or inter-as L3 vpn.

One caveat loophole does exist is that inter administrative domain intent
based SR flows would also be allowed so in theory you could have a chain of
SRV6 domains over the internet or even private inter connected domains so
then maybe not bother with the domain concept as it really goes out the
window.

So then it’s just an exception to allow SRv6 to do as they please as
impossible to control at that point so any and all use cases of SRv6 would
be granted the exception.

As Robert mentioned that it’s the carriers domain so they have to take care
of any security issues related to AH on the SRv6 outer IPV6 transport
header.

Also as noted by Robert that all customer traffic is kept in tact and not
altered and that no insertion or removal of any EH headers occurs to the
inner header customer payload.  So no impact to customers use of AH etc as
that is remains unaltered.

Thanks

Gyan

On Fri, May 8, 2020 at 7:06 PM Robert Raszuk <[email-masked]> wrote:

> Hi Philip,
>
> Sounds very reasonable.
>
> IMO what is needed here is a short spec which would explicitly call out
> the case of using IPv6 as transport layer. Then it would allow the
> transport owner sufficient flexibility (insertion, modification, deletion)
> into applied by his own ingress new IPv6 header at any transit hop he seems
-- 

Gyan  Mishra

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 8 May 2020 19:33:09 -0400

The SRv6 PGM document that was approved does not do arbitrary insertion. 
  It does the very specific PSP removal.  I think it inappropriate for 
us to say that given that this one piece was allowed, anything and 
everything should be allowed.

Also, it is normal for RFCs to be understood to be only applicable going 
forward.  The most that should be said about PSP in this draft 
explicitly would be a note indicating that the PSP behavior predates 
this, and is not affected by it.

And even that much would wait on the resolution of the pending appeal on 
the topic.

Yours,
Joel

On 5/8/2020 7:27 PM, Gyan Mishra wrote:
> 
> Given that SRv6 PGM draft has left the station awaiting publication I 
> think the most prudent recourse for 6MAN is to grant the exception for 
> SRV6 technology to allow insertion and removal on any transit node 
> within the carriers administrative domain.
> 
> Document	Type		Active Internet-Draft (spring WG 
> <https://tools.ietf.org/pdf/draft-ietf-spring-srv6-network-programming-15.pdf> htmlized 
> (tools) 
> <https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-network-programming-15> bibtex 
> Stream	WG state <https://datatracker.ietf.org/help/state/draft/ietf>	 
> Submitted to IESG for Publication
> carriers transport network could span multiple ASs that are inter 
> connected via SR-TE bsid or inter-as L3 vpn.
> 
> One caveat loophole does exist is that inter administrative domain 
> intent based SR flows would also be allowed so in theory you could have 
> a chain of SRV6 domains over the internet or even private inter 
> connected domains so then maybe not bother with the domain concept as it 
> really goes out the window.
> 
> impossible to control at that point so any and all use cases of SRv6 
> would be granted the exception.
> 
> As Robert mentioned that it’s the carriers domain so they have to take 
> care of any security issues related to AH on the SRv6 outer IPV6 
> transport header.
> 
> Also as noted by Robert that all customer traffic is kept in tact and 
> not altered and that no insertion or removal of any EH headers occurs to 
> the inner header customer payload.  So no impact to customers use of AH 
> etc as that is remains unaltered.
> 
> Thanks
> 
> Gyan
> 
> 
> 
> 
> On Fri, May 8, 2020 at 7:06 PM Robert Raszuk <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Hi Philip,
> 
>     Sounds very reasonable.
> 
>     IMO what is needed here is a short spec which would explicitly call
>     out the case of using IPv6 as transport layer. Then it would allow
>     the transport owner sufficient flexibility (insertion, modification,
>     deletion) into applied by his own ingress new IPv6 header at any
>     transit hop he seems required. Ultimate goal is to deliver carried
>     payload (here original IPv6 or IPv4 packets) via a given network the
>     best quality possible.
> 
>     Thx a lot,
>     Robert.
> 
> 
>     On Sat, May 9, 2020 at 12:42 AM Philip Homburg
>     <[email-masked]
>     <mailto:[email-masked]>> wrote:
>

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 9 May 2020 01:39:57 +0200

> And even that much would wait on the resolution of the pending appeal on

If we would decouple end to end IPv6 from encapsulated transport IPv6 as
well as allow required flexibility in the transport part there would no
longer be any basis for the appeal.

Where does it say that we must wait for the result of the appeal if WG
would like to propose the solution which turns the entire appeal in
progress into a moot point ?

Thx,
R.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 8 May 2020 19:46:27 -0400

Robert, the usage of IPv6 as a Transport is not different from other 
uses of IPv6.  While there are times when we allow some behaviors in 
controlled domains, we do not consider that an arbitrary get-out-of-jail 
free card.  In particular, a controlled domain does not solve most of 
the problems with header insertion or removal.

Also, A transport tunnel is not the same as a controlled domain, so the 
use of IPv6 for a tunnel would do even less to relax the rules of 8200. 
The one thing the use of an IPv6 tunnel does achieve, and is already 
understood and accepted, is that because it is a new IPv6 header, the 
creator of that header gets to choose what they put in it, and the 
terminator is allowed to remove it.

Yours,
Joel

---

From: Mark Smith <[email-masked]>
Date: Sat, 9 May 2020 09:57:19 +1000

> everything should be allowed.

The trouble is that now that there is now implicit permission to do so.

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

Any special use case will now be used to justify IPv6 packet mangling.

Any working group other than 6man will now be able to take IPv6 and
modify it to suit what they want to do, ignoring the specs and the
6man WG's intent, using PSP and what SPRING has been allowed to do to
justify it.

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 9 May 2020 02:04:56 +0200

> 6man WG's intent, using PSP and what SPRING has been allowed to do to

And that to me sounds like a feature.

The best protocols are those which are used way beyond their original
author's intentions.

Experience shows that we as humans are pretty bad in predicting the future
so all we can is do to define things in an extensible style such that
others may ride on it.

If they would be denied to modify it and use it as it seems fit to realize
their ideas - they would need to reinvent the wheel - not the best use of
time.

---

From: 神明達哉 <[email-masked]>
Date: Fri, 8 May 2020 17:35:04 -0700

At Fri, 8 May 2020 19:27:53 -0400,

> Given that SRv6 PGM draft has left the station awaiting publication I
think
> carriers administrative domain.

Could we at least change the subject, please?  (I'm now actually
changing it).

As Ron already clarified, while the unfortunate discussion for
draft-ietf-spring-srv6-network-programming was indeed a major
background motivation of draft-bonica-6man-ext-hdr-update-03, whether
6man should grant the exception for SRV6 is irrelevant to it.  It's
for the general protocol spec, rather than whatever exceptions grated
to the general protocol.

But on a slightly related point on the relationship between these two:
I don't think "SRv6 PGM draft has left the station awaiting
publication" in the first place.  It's not even in an IETF last call;
it can be returned to the WG at the AD evaluation stage, and even if
it passes the AD there will certainly be more discussions at the stage
of IETF last call.  It's not uncommon that a proposal that passes a
WGLC is returned or even dropped in these phases.  And, I'd certainly
oppose it if and when the draft reaches an IETF last call in its
current shape, since it's not distinguishable from an abuse of the
text bug of RFC8200 for an easy shortcut, attempting to avoid tougher
discussions.  That's unfortunate especially because it seems to me
that PGM has a pretty good chance of justifying it as an exception
(though probably still controversial) and an update to RFC8200 in that
sense, instead of claiming it's just already standard compliant.

The expected meta discussion at that stage will be non-constructive,
and I suspect it can even take more time than just trying to justify
it as an exception/update due to its meta level controversy (in which
case it's also unfortunate for those who just want it to be published
sooner).  My hope with draft-bonica-6man-ext-hdr-update-03 is that it
will prevent such unnecessary and unfortunate discussions in future,
if not for draft-ietf-spring-srv6-network-programming.

--
JINMEI, Tatuya

---

From: Mark Smith <[email-masked]>
Date: Sat, 9 May 2020 11:22:12 +1000

> The best protocols are those which are used way beyond their original
Modifying something is not using it.

I have modified blade screw drivers to suit are special purpose. They're
not blade screwdrivers anymore (they're bicycle wheel spoke nipple
drivers), and cannot be used as blade screwdrivers.

Modifying IPv6 is not using IPv6.

> so all we can is do to define things in an extensible style such that
Extensibility is being able to add to something that already exists without
interfering with the existing thing's operation. Modifying something that
already exists and has fixed definitions, changing its behaviour, is not
extensibility.

There are areas where IPv6 is extensible, such as via the creation of new
EHs, and other areas where it is not.

> their ideas - they would need to reinvent the wheel - not the best use of
I don't think SPRING have tried that hard to follow this principle, because
there are a number of examples where existing and proven mechanisms that
work could have been used; instead reinvention occurred.

uSID is trying to reinvent the purpose of the IPv6 Destination Address
field, by encoding a set of multiple packet destinations in that field,
despite the word "Address" being singular in RFC 8200.

SRv6 Network Programming needs to reinvent IPv6 DA matching at the
destination in 3. SRv6 SID because it doesn't assign SIDs (that have become
IPv6 addresses) to interfaces, contrary to the RFC 4291 addressing
architecture, which dictates that IPv6 addresses are assigned to interfaces
not nodes.

SPRING tried to reinvent the meaning of the No Next Header EH (type 59) to
implicitly mean an Ethernet payload followed.

SPRING needed to reinvent AH via the SRH HMAC TLV, because the operations
being performed on IPv6 packets weren't compliant with RFC8200, and
therefore AH couldn't be used.

There may be a 5th example I can't quite remember right now.

It has seemed to me that SPRING have had too much of a "greenfield"
mentality, allowing other existing specs to be taken and casually modified,
rather than proposing modifications only as a last resort, when there is no
other way to make the function work within existing proven mechanisms.

In all these cases changing SR methods to fit within the existing would
have been far less time and effort than the reinvention that has occurred
or was proposed.

Regards,
Mark.

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 8 May 2020 22:46:19 -0400

Joel

Thanks for the correction.  Sorry for any confusion.

So there are tire spots in an SRv6 implementation where an SRH routing
header type 4 is inserted.

SRV6 source node - 1st 6in6 outer transport encapsulation- customer PE-CE
traffic is tunneled inner payload

TI-LFA - The latest version of the PGM draft was modified to fix this
violation.  FRR link and node protection backup path where at the PLR node
EH header could be inserted on any transit node.  This was the worst
violator of RFC 8200.  So the agreed upon solution to resolve this
violation was to add another 6in6 encapsulation + SRH to steer bypass
traffic to the merge point PQ node.

The only remaining RFC 8200 violation was related to PSP the removal of the
SRH on the PSP node is a violation and deemed a violation due SRH being
removed on destination endpoint that is not the final destination endpoint
SL=0.  So what counts is the incoming SL=1 prior to the PSP node processing
and   final destination Segment copies to DA.

So we can be very explicit in the verbiage with regards to SRv6 intra
domain PSP function exception.

Gyan

On Fri, May 8, 2020 at 7:33 PM Joel M. Halpern <[email-masked]> wrote:

> >       Replaces
> draft-filsfils-spring-srv6-network-programming
> > <
> https://datatracker.ietf.org/doc/draft-filsfils-spring-srv6-network-programming/
> >
> >       Stream          IETF
> > <
> https://www.ietf.org/id/draft-ietf-spring-srv6-network-programming-15.txt>
>
> >   xml
> > <
> https://www.ietf.org/id/draft-ietf-spring-srv6-network-programming-15.xml>
>
> >   pdf
> > <
> https://tools.ietf.org/pdf/draft-ietf-spring-srv6-network-programming-15.pdf> htmlized
>
> > (tools)
> > <
> https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-15>
>
> >   htmlized
> > <
> https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-network-programming-15> bibtex
>
> > <
> https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-network-programming/bibtex
> >
> > Stream        WG state <
> https://datatracker.ietf.org/help/state/draft/ietf>
-- 

Gyan  Mishra

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

---

From: Fernando Gont <[email-masked]>
Date: Sat, 9 May 2020 05:44:21 -0300

>    exception for segment routing.

I'd say that firstly folks need to make a case why insertion/removal is 
needed. That's a bit different from the traditional hand-washing 
approach that have plagged the spring¡s network-programming draft an 
other related work.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Sat, 9 May 2020 05:50:33 -0300

On 8/5/20 20:27, Gyan Mishra wrote:
> 
> Given that SRv6 PGM draft has left the station awaiting publication 

Maybe you've not been listening to the loudphones: the IESG is 
processing an Appeal on that decision: 
https://mailarchive.ietf.org/arch/msg/ietf/tvhCmlcHt9b2vwrNxR70W9cT4sE/

> I 

That would be (yet again) an outright violation of our processes. Things 
need to happen the other way around: firstly you make the case for an 
exception to RFC8200, and get RFC8200 formally updated. *Then* you 
pursue efforts like network-programming. FWIW, I believe modifying 
RFC8200 to allow eh-insertion/removal would be outside of the 6man charter.

I'm CC'ing our AD. Hope he can save everyone's energy this time.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Sat, 9 May 2020 05:53:38 -0300

> everything should be allowed.

That piece wasn't allowed. Actually, the spring wg shipped the document 
via a process that was appealed: 
https://mailarchive.ietf.org/arch/msg/ietf/tvhCmlcHt9b2vwrNxR70W9cT4sE/

Since the Appeal has not yet been addressed, there hasn't been IETF 
consensus on the network programming draft, and, ultimately, the IESG 
has not yet approved the document, I don't think anyone can or should 
consider that any such behavior has been allowed.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Sat, 9 May 2020 05:57:58 -0300

> progress into a moot point ?

You might need to re-read the Appeal: 
https://mailarchive.ietf.org/arch/msg/ietf/tvhCmlcHt9b2vwrNxR70W9cT4sE/

It includes five (5) explicit technical objections, plus three (3) 
explicit procedural concerns.

I have no idea why trying to address one of the five technical concerns, 
and even more so *after the fact*, would turn the appeal into a moot point.

Maybe this is just a confirmation that some folks seem to thing that 
they can violate our processes at will.

Thanks,

---

From: Philip Homburg <[email-masked]>
Date: Sat, 09 May 2020 12:23:52 +0200

>approach that have plagged the spring¡s network-programming draft an 

I think we can leave the justification of insertion/removal to the Spring
wg. There is no need to discuss in 6man the fine details of how efficient
various options are. 

I think what we should discuss (if there ever comes a draft that tries to
update RFC 8200 in this direction) is whether this is safe. How come inserts
doesn't cause PMTU problems. How does it interact with authentication headers,
and what effect does it have on error ICMPs. And possibly other things that
may go wrong.

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 9 May 2020 12:37:07 +0200

/* adjusting the subject */

Hi Mark,

> other way to make the function work within existing proven mechanisms.

I think you have hit the nail here.

There are two roles IETF WGs could endorse:

*option 1*

Be the strong policer of protocols encoding and its operations invented 20+
years ago. Forbid innovation even if it almost fits with the given protocol
definitions as written.

*option 2*

Create and standardize protocol building blocks (lego bricks), make sure
header or attribute types handling is interoperable while in the same time
allow transit networks behaviours to be defined using those blocks by the
operators itself or by their vendors. Almost all modern data planes can be
programmable either by P4 or other languages.

- - -

Pls observe that option 2 is already happening pretty much outside of IETF
meeting rooms and corridors.

Who will tell big service/content provider or enterprise that they can not
either build a custom chip or program their data plane behaviour in
software ?

Sure option 2 is very hard for legacy vendors who are not able to support
it. Sure it is hard for traditional operators as network operator job may
now require solid programming skills. But stating that a WG which just
tries to accommodate option 2 "have had too much of a "greenfield"
mentality" is just precise illustration where the real problem is.

Best,
Robert.

PS.

As an exercise for the reader I have a question. Imagine that I want to
standardize a variable length SA and DA to be used as transport addresses
in my network. 128 bits to be used within single domain or single
enterprise is just pure waist. Note that I am talking about variable length
IP address fields but I am actually assuring a fixed exact match locator
part.

Where would I go with that draft ?

Going to 6man and claiming that I was to shrink your 128 dogmatic fields
may likely fail.

Going to MPLS stating that I would like to extend MPLS with MPLSv2 giving
it new life could maybe even work out well ... it is just it would be
almost identical to IPv6 format with SRv6 with just few small encoding
changes.

Go figure ...

---

From: Andrew Alston <[email-masked]>
Date: Sat, 9 May 2020 11:23:21 +0000

Get Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: ipv6 <[email-masked]> on behalf of 神明達哉 <[email-masked]>
Sent: Saturday, May 9, 2020 03:35
To: Gyan Mishra
Cc: 6man WG
Subject: whether to grant exception for SRV6 (Re: some feedback on feedback on draft-bonica-6man-ext-hdr-update-03)

> Given that SRv6 PGM draft has left the station awaiting publication I think

I would hardly say it has left the station awaiting publication - the document is under appeal on a multitude of points - both technical related to psp and a raft of process issues.

Let us await the outcome of the appeal before declaring the document a done deal.

Andrew

---

From: Fernando Gont <[email-masked]>
Date: Sat, 9 May 2020 08:21:33 -0300

On 9/5/20 07:23, Philip Homburg wrote:
>> approach that have plagged the springÂ¡s network-programming draft an
>> other related work.
> 

That's indeed what I meant to say. Thanks for summarizing it!

Cheers,

---

From: Andrew Alston <[email-masked]>
Date: Sat, 9 May 2020 11:26:44 +0000

Get Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: ipv6 <[email-masked]> on behalf of Robert Raszuk <[email-masked]>
Sent: Saturday, May 9, 2020 02:40
To: Joel M. Halpern
Cc: 6man WG
Subject: Re: some feedback on feedback on draft-bonica-6man-ext-hdr-update-03

If we would decouple end to end IPv6 from encapsulated transport IPv6 as well as allow required flexibility in the transport part there would no longer be any basis for the appeal.

Where does it say that we must wait for the result of the appeal if WG would like to propose the solution which turns the entire appeal in progress into a moot point ?

Robert I suggest you read the appeal - the psp issue is not the only issue in the appeal - so while whatever is done here may resolve that issue - it is hardly the only issue and resolving this would not render the entire appeal moot - it would resolve that one point

Andrew

---

From: Fernando Gont <[email-masked]>
Date: Sat, 9 May 2020 08:29:12 -0300

On 9/5/20 07:37, Robert Raszuk wrote:
>     mentality, allowing other existing specs to be taken and casually
>     modified, rather than proposing modifications only as a last resort,
>     when there is no other way to make the function work within existing
>     proven mechanisms.
> 
> 

There's one role that WGs MUST endorse: RFC2026.

If you feel otherwise, feel free to publish a draft that updates 
RFC2026, have it gain IETF-wide consensus, and get the IETF to do 
whatever it feels it should be doing.

Thanks,

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 9 May 2020 13:40:28 +0200

> Robert I suggest you read the appeal - the psp issue is not the only issue
> in the appeal - so while whatever is done here may resolve that issue - it
> is hardly the only issue and resolving this would not render the entire
> appeal moot - it would resolve that one point
>
> Andrew
>

I did.

If we (here in 6man) define notion of IPv6 transit and agree that it is
formally ok to modify IPv6 transit headers as it seems fit by the transit
owner then:

* Points 1-3 of the appeal no longer apply
* Point 4 does not apply as format of the address again would be fully up
to transit owner
* Point 5  does not apply as it is not up to participants but up to transit
owner to make sure it is deployable

But I am seeing some emails asking AD if 6man can even formally do all of
that ? If not 6man then who ?

Conflict of interests & non technical process points 1-3 I am not going to
comment on. I am also in no capacity questioning RFC2026.

But even if any of them would be found real then what - draft comes back to
SPRING, goes via another WGLC and goes back to IESG ? What is the point &
benefit ?

More process ?

Cheers,
Robert.

---

From: Fernando Gont <[email-masked]>
Date: Sat, 9 May 2020 08:52:14 -0300

On 9/5/20 08:40, Robert Raszuk wrote:
>     Robert I suggest you read the appeal - the psp issue is not the only
>     issue in the appeal - so while whatever is done here may resolve
>     that issue - it is hardly the only issue and resolving this would
>     not render the entire appeal moot - it would resolve that one point
> 
>     Andrew 
> 
> 
> I did.
> 
> formally ok to modify IPv6 transit headers as it seems fit by the 
> transit owner then:
> 

You don't fix the procedural issues represented by dismissing valid 
technical issues by trying to do spec-manship once an appeal has been 
filled.

This is the equivalent of the responsible AD for spring trying to 
process and address WGLC comments once WGLC consensus had already been 
declared.

I think you got the std process exactly backwards.

> * Point 4 does not apply as format of the address again would be fully 
> up to transit owner
> * Point 5 does not apply as it is not up to participants but up to 
> transit owner to make sure it is deployable
> 
> But I am seeing some emails asking AD if 6man can even formally do all 
> of that ? If not 6man then who ?

For the record, that's me making that claim. I'd have to check whether 
that'd be within the scope of int-area, or maybe a new wg might need to 
be created.

The 6man charter says:
"It is not chartered to develop major changes or additions
to the IPv6 specifications. "

Changing an e2e protocol into something that's not e2e, by allowing 
header insertion/removal in transit is certainly a major 
change/addition, and hence htat doesn't seem to me like within the scope 
of 6man.

> But even if any of them would be found real then what - draft comes back 
> to SPRING, goes via another WGLC and goes back to IESG ? What is the 
> point & benefit ?

Draft goes back to wg. Issues get addressed, or else document doesn't 
move forward. And WGLC is evaluated in a fair and non-biased way.

> More process ?

RFC2026-process. Which I believe has not happened for the network 
programming draft in spring.

Thanks,

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 9 May 2020 09:03:53 -0400

> Could we at least change the subject, please?  (I'm now actually

  Gyan> That’s fine

> sense, instead of claiming it's just already standard compliant.

    Gyan>  I saw the draft in awaiting publication state and that it had
already went through IETF LC.

If it’s two late to pull back or contest this draft do you agree to making
an exception.  I think at that point we have to from a 6MAN perspective so
the standard is in sync with new technologies that have received WG
adoption and have been deployed such as SRv6.  This draft updates RFC 8200
so I think this draft should provide that exception if and when the train
leaves the station.

I agree their is a good chance that PGM can justify an exception.

I asked Jingrong and a few others on a number of instances as to why PGM is
necessary and technical merit as drawing parity to MPLS PHP implicit null
is default on all routers, however issues have existed since Day 1 related
to QOS scheduling on the PHP node when the MPLS label is popped form PE-P,
and the workaround that has been employed has been explicit null pipe mode
QOS groups tagging to preserve the exp markings from Ingress to egress.

The respone from Spring given has been that for brownfield migration
deployments or SRv6 that the PSP function allows the egress PE to be legacy
and offloads the SRH removal to the one hop prior PSP P node.

>From my experience working with MPLS as well as SR SR-MPLS and SRv6, all
PEs have to be upgraded to support SRH SRv6 EH type 4 since all LSPs are
unidirectional in both directions from ingress to egress so every PE acts
as an Ingres PE as well as egress PE.  I was given some use cases but they
did not make sense to me as to why the LSP would only be in one direction.
If Spring can convince the AD and IETF LC review that the hardware issue on
the egress PE is a real mandatory issue that can only be ee

> if not for draft-ietf-spring-srv6-network-programming.

  Gyan>. I agree that if we still have time to dispute the draft then their
is no need to discuss PGM draft exceptions as it’s to early for that and we
need to stay course on plans to dispute PGM  from a 6MAN perspective.  I
agree with the merit in the Bonica draft to prevent future occurrences of
misinterpretation and violations of the draft by tightening up the verbiage.

-- 

Gyan  Mishra

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Sat, 09 May 2020 06:42:52 -0700

At Sat, 9 May 2020 09:03:53 -0400,

> > > Given that SRv6 PGM draft has left the station awaiting publication

To be sure, I assumed you meant this draft:
https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-network-programming/
as you referred to the link in your message:
https://mailarchive.ietf.org/arch/msg/ipv6/Z90hy4KibEyJA8tABw9_gqdmZTM/

The datatracker page indicates its IESG state is "Publication
Requested".  Are you saying "Publication Requested" means the
following?

> already went through IETF LC.

then, no, it doesn't mean that; check this
https://datatracker.ietf.org/help/state/draft/iesg

If you mean something different, please clarify it.

--
JINMEI, Tatuya

---

From: Tony Przygienda <[email-masked]>
Date: Sat, 9 May 2020 06:59:40 -0700

I quote Yakov here pretty much directly: "There is nothing that prevents
peoiple from doing funky things with IETF specifications in the privacy of
their bedrooms or when pushed by one of their clients but that does NOT
mean that IETF has any role in standardizing them or should allow it". The
interesting dichotomy of lots participants @ all levels where they would
like not to conform to IETF processes/existing specs where they find them
inconvienent, however still enjoy the full benefits and credibility of hard
gained IETF standardization processes and standing is nothing new by a very
long stretch. It was already quite old when I was still young ;-) Those
things are not a "one-off, never again, finger crossed". Those things are
precedents that can change IETF for long time to come so need watching from
hopefully impartial folks @ the top ...

--- tony

On Sat, May 9, 2020 at 3:37 AM Robert Raszuk <[email-masked]> wrote:

> Be the strong policer of protocols encoding and its operations invented
> 20+ years ago. Forbid innovation even if it almost fits with the given
> protocol definitions as written.
>
> *option 2*
>

---

From: Fernando Gont <[email-masked]>
Date: Sat, 9 May 2020 10:35:27 -0300

On 9/5/20 10:03, Gyan Mishra wrote:
[...]
>      Gyan>  I saw the draft in awaiting publication state and that it 
> had already went through IETF LC.

No. It hasn't gone through IETF LC, nor has it been reviewed by the IESG.

> If it’s two late to pull back or contest this draft do you agree to 
> making an exception.

Certainly not. Particularly when the issue was raised multiple times and 
incorrectly dismissed.

>  I think at that point we have to from a 6MAN 
> perspective so the standard is in sync with new technologies that have 
> received WG adoption and have been deployed such as SRv6.  This draft 
> updates RFC 8200 so I think this draft should provide that exception if 
> and when the train leaves the station.

Certainly not. Unless you want to encourage violation of IETF standards 
and violation of IETF process.

[...]
>    Gyan>. I agree that if we still have time to dispute the draft then 
> their is no need to discuss PGM draft exceptions as it’s to early for 
> that and we need to stay course on plans to dispute PGM  from a 6MAN 
> perspective.  I agree with the merit in the Bonica draft to prevent 
> future occurrences of misinterpretation and violations of the draft by 
> tightening up the verbiage.

THere is plenty of time to discuss network-programming. As noted, it 
hasn't gone through IETF LC yet. And it might even be retorned to the 
spring wg.

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

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 9 May 2020 11:09:34 -0400

> If you mean something different, please clarify it.

   That link clarifies the state for me so their is plenty of time to
contest.  As far as Bonica draft we can proceed as you mentioned with goal
of now being able to better address future violations and drop any
exception related discussion.

-- 

Gyan  Mishra

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

---

From: S Moonesamy <[email-masked]>
Date: Sat, 09 May 2020 08:14:46 -0700

Hello,
At 04:27 PM 08-05-2020, Gyan Mishra wrote:
>I think the most prudent recourse for 6MAN is to grant the exception 
>for SRV6 technology to allow insertion and removal on any transit 
>node within the carriers administrative domain.

The above comment about draft-ietf-spring-srv6-network-programming-15 
is accurate as the draft is awaiting publication.  The following 
might not be accurate as I have not gone through the archive to 
verify all the details.  I don't recall seeing any request where this 
working group would have to be asked to grant an exception so that 
publication of the draft can progress.

With respect to draft-bonica-6man-ext-hdr-update-03, the draft 
proposes to update the IPv6 standard as there is some ambiguity in 
that standard.  From what I recall, that is in line with the guidance 
provided by the Responsible Area Director during the discussion of an erratum.

Regards,
S. Moonesamy

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 9 May 2020 11:35:30 -0400

> Certainly not. Particularly when the issue was raised multiple times and

Ok. This is all hypocritical that PGM gets published as we are far from
that stage.  So exception as you see it is completely out of question even
just isolated to the specific intra domain PSP function.  How would the
IETF deal with the inconsistency of PGM RFC not following 6MAN
specification.  Do we have any recourse after publication to dispute the
violation.  What are next steps to resolve or would this inconsistency
remain unresolved.

> Agreed.  We don’t want to set the wrong precedence by allowing this to
> happen.

> hasn't gone through IETF LC yet. And it might even be retorned to the

    Agreed.

Gyan  Mishra

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

---

From: Fernando Gont <[email-masked]>
Date: Sat, 9 May 2020 12:59:06 -0300

Hello, Gyan,

On 9/5/20 12:35, Gyan Mishra wrote:
[...]
> Certainly not. Particularly when the issue was raised multiple times
>  and incorrectly dismissed.
> 
> 
> Ok. This is all hypocritical that PGM gets published as we are far 
> from that stage.  So exception as you see it is completely out of 
> question even just isolated to the specific intra domain PSP 
> function. 

No, I don't believe it is out of question. I believe that, given a 
well-backed proposal, the proposal should be considered. That said, 
there has not been such a proposal. And I believe such proposal would 
not be within the scope of 6man.

> How would the IETF deal with the inconsistency of PGM RFC 
> not following 6MAN specification.

I would expect that the 6man chairs or, ultimately the INT ADs, would 
raise it to the chairs of the WG this document is being targeted at.

If that doesn't happen, one/some of us may do it.

And if this is ignored, there is always the option to Appeal any 
decision. Me, I'd prefer to stay as away from an Appeal as possible (but 
not farther).

> Do we have any recourse after 
> publication to dispute the violation.  What are next steps to
> resolve or would this inconsistency remain unresolved.

So far, the pgm draft is an individual submission. Folks are free to 
publish anything as an individual submission. Then, if a wg plans to 
adopt or work on the proposal, that's a different business, and we can 
weigh in the decision process, or appeal any decisions if we believe due 
process has not been followed.

FWIW, I flagged both drafts to the relevant ADs, such we don't need to 
waste more time later.

Thanks,

---

From: Tom Herbert <[email-masked]>
Date: Sat, 9 May 2020 09:12:22 -0700

Hi Robert,

Some comments in line...

On Sat, May 9, 2020 at 3:37 AM Robert Raszuk <[email-masked]> wrote:
>> It has seemed to me that SPRING have had too much of a "greenfield" mentality, allowing other existing specs to be taken and casually modified, rather than proposing modifications only as a last resort, when there is no other way to make the function work within existing proven mechanisms.
>
>
> Be the strong policer of protocols encoding and its operations invented 20+ years ago. Forbid innovation even if it almost fits with the given protocol definitions as written.
>
> *option 2*
>
> Create and standardize protocol building blocks (lego bricks), make sure header or attribute types handling is interoperable while in the same time allow transit networks behaviours to be defined using those blocks by the operators itself or by their vendors. Almost all modern data planes can be programmable either by P4 or other languages.
>
> - - -
>
> Pls observe that option 2 is already happening pretty much outside of IETF meeting rooms and corridors.
>

Yes, that's because option 2 describes implementation concepts whereas
IETF is a standards organization to create interoperable protocols, we
don't define how those protocols are implemented. That being said, it
certainly makes sense to take input about possible implementation
techniques in protocol development, however implementation doesn't
dictate the protocols or specify them. Personally, my hope for
programmable data planes is more that we can fix protocol ossification
that is limiting our ability to use existing Internet protocols (like
EH, fragmentation, other transports than TCP, etc.).

> Who will tell big service/content provider or enterprise that they can not either build a custom chip or program their data plane behaviour in software ?
>

People are free to implement the protocols however they want. This
question isn't relevant in IETF.

> Sure option 2 is very hard for legacy vendors who are not able to support it. Sure it is hard for traditional operators as network operator job may now require solid programming skills. But stating that a WG which just tries to accommodate option 2 "have had too much of a "greenfield" mentality" is just precise illustration where the real problem is.
>

I think the "greenfield mentality" is more about creating new protocol
solutions as opposed to attempting to adapt existing solutions. SRV6
has done this in several ways. For instance, instead of figuring out
how to leverage AH, there is a new header authentication method in
SRV6; and for all the talk about extension header insertion, there
really has never been a good answer as to why just encapsulating in
IPV6 with the EH doesn't work.

> Best,
> Robert.
>
> PS.
>
> As an exercise for the reader I have a question. Imagine that I want to standardize a variable length SA and DA to be used as transport addresses in my network. 128 bits to be used within single domain or single enterprise is just pure waist. Note that I am talking about variable length IP address fields but I am actually assuring a fixed exact match locator part.
>
> Going to 6man and claiming that I was to shrink your 128 dogmatic fields may likely fail.

I don't think failure is guaranteed, however if someone wants to
suggest such a drastic change they really need to do their homework.
If you're going to be asking for a new IP version it should be obvious
that you'll need an exceedingly clear justification (just saying we
need smaller addresses because 128 bits are wasteful isn't remotely
sufficient). I suggest you take a look at the IPv10 proposal
discussion, there's a lot of lessons to be learned for anyone that
wants to propose a change of this magnitude.

Tom
>
> Going to MPLS stating that I would like to extend MPLS with MPLSv2 giving it new life could maybe even work out well ... it is just it would be almost identical to IPv6 format with SRv6 with just few small encoding changes.
>
> Go figure ...
>

---

From: Sander Steffann <[email-masked]>
Date: Sat, 9 May 2020 19:11:35 +0200

Hi,

> and what effect does it have on error ICMPs. And possibly other things that

+1

One of the things that I have noticed is that many restrictions on inserting/deleting headers is that it would be problematic for the original sending node (mostly ICMP errors that contain things it never sent). I would very much be in favour of a simple exception to header manipulation: if the sending node is aware of the manipulations that can be applied it is not a problem. In the case of SRv6 NP with PSP that would work: the sending node inserts the programming instruction to remove the RH, so it should not come as a surprise if it gets an ICMP error back without the RH.

It would make the logic on the sending side more complex, but that is the explicit choice of adding the programming instruction.

The one point I'm not sure about is how to handle this with stateful firewalls that match incoming ICMP errors to the session that caused them. Those firewalls would have a hard time knowing what header manipulations to expect. But I think that this is a choice that is up to the protocol designer to worry about.

So my simple suggestion: "header manipulation between the sender and the ultimate destination is allowed when it is done with agrement of the sender, either by explicit network programming instruction or because it is part of the protocol that the sender participates in".

Cheers,
Sander

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 9 May 2020 20:28:56 +0200

> sufficient).

Well on this topic - I am not even remotely suggesting a new IP version.

If implementation can parse DA with N number of uSIDs it means it can also
parse arbitrary string of bits.

Yes today hardware expects it to be of 128 bits and that is ok. Backwards
compatibility with current IPv6 forwarding plane could be easily
accomplished by local prepends of shorter addresses with zeros.

I just do not see any good reason to carry 100 bits == all ZEROs in SA & DA
during encapsulated transport when my network locator can be expressed in
less then 16 bits and local functions in less then 8.

But this goes back to global addressing vs local addressing. This goes also
back to lean base header + SRH vs full 40 octets + extensions headers and
rules defining their processing limits.

Yes perhaps some will say just use MPLS encapsulation - well it is far from
efficient to carry 8 bit function in 20 bit label. MPLS does not have a
notion of SRH either so lots of functionality required in NP would not be
readily available there (some sure like say L3VPNs ... but this is far not
enough).

Kind regards,
R.

PS. Leave alone the fact that to come to IETF with such a proposal is a
full time job ... perhaps not even for one person but min 10. And if
someone actually works and has time for IETF on a best effort / hobby basis
proposing anything like this is just impossible.

---

From: Tom Herbert <[email-masked]>
Date: Sat, 9 May 2020 11:44:14 -0700

On Sat, May 9, 2020 at 11:29 AM Robert Raszuk <[email-masked]> wrote:
> If implementation can parse DA with N number of uSIDs it means it can also parse arbitrary string of bits.
>
> Yes today hardware expects it to be of 128 bits and that is ok. Backwards compatibility with current IPv6 forwarding plane could be easily accomplished by local prepends of shorter addresses with zeros.
>
> I just do not see any good reason to carry 100 bits == all ZEROs in SA & DA during encapsulated transport when my network locator can be expressed in less then 16 bits and local functions in less then 8.
>
> But this goes back to global addressing vs local addressing. This goes also back to lean base header + SRH vs full 40 octets + extensions headers and rules defining their processing limits.
>

Robert,

I think you're conflating two uses of IP addresses, namely the source
and destination address in the IPv6 header versus carrying of
addresses elsewhere in the packet such as when a list of addresses is
contained in a routing header. If you want to change the address size
in the IP header, then that's a fundamental change to the IP protocol
and pretty much going to necessitate a new IP version (e.g. IPv4 to
IPv6 to go from thirty-two to 128 bit addresses). For other use cases
there is certainly interest in compressing IPv6 addresses to conserve
space. This has been raised as an issue several times with regards to
SRv6 that could potentially carry 100s of bytes of overhead in a list
IPv6 addresses, and there are already alternatives in the works to
reduce overhead like address compression in CRH.

Tom

> Yes perhaps some will say just use MPLS encapsulation - well it is far from efficient to carry 8 bit function in 20 bit label. MPLS does not have a notion of SRH either so lots of functionality required in NP would not be readily available there (some sure like say L3VPNs ... but this is far not enough).
>
> Kind regards,
> R.
>
> PS. Leave alone the fact that to come to IETF with such a proposal is a full time job ... perhaps not even for one person but min 10. And if someone actually works and has time for IETF on a best effort / hobby basis proposing anything like this is just impossible.
>

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 9 May 2020 22:54:59 +0200

Hi Tom,

I do realize that for what I gently suggested we would need new ethertype.
I do not have a problem with that and looking at the IANA ethertype
registry it seems that allocating new value for something useful would not
be such a huge issue.

And I am really not conflating IP address in the header with ways to signal
source routes + functions behind the IP header. I am just observing that we
carry the latter we can be much more efficient in the former.

As to the CRH which requires new control plane extensions, consistent
mapping scheme and brings nothing new on top what SR-MPLS already offers I
recommend you take a look at
https://tools.ietf.org/html/draft-decraene-spring-srv6-vlsid-03 where in
100% compatible way to SRv6 and SRH we compress its size.

Many thx,
Robert

On Sat, May 9, 2020 at 8:44 PM Tom Herbert <[email-masked]> wrote:

> > Yes today hardware expects it to be of 128 bits and that is ok.
> Backwards compatibility with current IPv6 forwarding plane could be easily
> > I just do not see any good reason to carry 100 bits == all ZEROs in SA &
> DA during encapsulated transport when my network locator can be expressed
> in less then 16 bits and local functions in less then 8.
> >
> > But this goes back to global addressing vs local addressing. This goes
> also back to lean base header + SRH vs full 40 octets + extensions headers
> and rules defining their processing limits.
> >
>
> Robert,
>
> > Yes perhaps some will say just use MPLS encapsulation - well it is far
> from efficient to carry 8 bit function in 20 bit label. MPLS does not have
> a notion of SRH either so lots of functionality required in NP would not be

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 25 May 2020 09:02:20 +1200

I believe there is one point that this draft still leaves unclear.

RFC8200 says:
"4.6.  Destination Options Header

   The Destination Options header is used to carry optional information
   that need be examined only by a packet's destination node(s)."

I believe we need to clarify whether this means the current destination node(s), or the final destination node(s), if a Routing Header is present.

Regards
   Brian Carpenter

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 25 May 2020 13:41:46 +1200

Replying to myself:

On another thread, James Guichard said:

> [1] RFC8200 section 4.1
> 
>       note 1: for options to be processed by the first destination that
>               appears in the IPv6 Destination Address field plus
>               subsequent destinations listed in the Routing header.
>
>       note 3: for options to be processed only by the final destination
>               of the packet.
> 
> ** note 1 is for DOH preceding routing header and note 3 is for DOH after routing header.

Fair enough, but that is a very obscure way of stating it, hidden inside the section about the ordering of headers. It should be stated in more explicit language in the discussion of the DOH itself.

   Brian

---

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Mon, 25 May 2020 04:56:05 +0000

Hi Brian,

Maybe the more you assume "Destination node" as "final/ultimate destination node", the more you will be confusing.
To me, "Destination node" is very simple to mean "the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field".

Just think of the "destination node" as a node who is "listening" to an address, either a unicast address, or a multicast address.
If a packet with the destination address being an address the "destination node" listening to, the "destination node" will <catch> it, and processing it either way, for example:
(1) it could just simply forward it according to further (not very deep) information in any EH.
(2) it could further dispatch it to the APP according to some (fairly deep) information.
(3) it could discard the packet when it doesn't even be able to know how deep the information is.

This way, the many text about EH (including the 4.6 DOH mentioned below) in RFC8200/2460/1883 is clear IMO.

If there is need to describes "final/ultimate destination node", the further qualifying text will be added to the "Destination address". 
There *ARE* many examples in the RFC8200/2460/1883, and one could find those text "final/ultimate" in those RFCs.

Thanks
Jingrong

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Brian E Carpenter
Sent: Monday, May 25, 2020 5:02 AM
To: 6MAN <[email-masked]>
Subject: Re: some feedback on feedback on draft-bonica-6man-ext-hdr-update-03

RFC8200 says:

Regards
   Brian Carpenter

On 06-May-20 13:12, 神明達哉 wrote:
> "innovations" on using extension headers (especially in terms of 
> insertions and deletions) forever.  Protocols evolve over time, and 
> to pass a WGLC (and, in fact, I surprisingly realized that the RFC 
> text could literally read in a different way).  So I believe we need 
> an explicit clarification.
>

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 25 May 2020 17:33:23 +1200

Hi Jinrong,
> To me, "Destination node" is very simple to mean "the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field".

That's exactly why the text in RFC8200 has been interpreted in two different ways, because some people have assumed the other meaning (i.e. the final destination, if there is a routing header). When we have such an ambiguity in a standard, it's necessary to fix the standard, in my opinion.

Regards
   Brian

---

From: Fernando Gont <[email-masked]>
Date: Mon, 25 May 2020 03:12:56 -0300

> To me, "Destination node" is very simple to mean "the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field".

Ironically, it would be quite interesting to have a multicast address as 
a "Destination Node", unless "Destination Node" implies final destination.

(note: rfc2460 banned both cases for RHT0)

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Mon, 25 May 2020 03:14:33 -0300

> (2) it could further dispatch it to the APP according to some (fairly deep) information.

(2) is actually never the case.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Mon, 25 May 2020 03:17:14 -0300

Hi, Brian,

> That's exactly why the text in RFC8200 has been interpreted in two different ways, because some people have assumed the other meaning (i.e. the final destination, if there is a routing header). Whe…

If anything, I think the possible confusion was introduced when as a 
follow-up to IETF LC the possible meanings of "processing" were spelled 
out along "processed". e.g., there's not such possibility of confusion 
in RFC2460 or RFC1883.  (Well, other than the fact that folks were 
claiming that "processed" might not include e,g, "insertion" (!) ;-) )

Thanks,

---

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Mon, 25 May 2020 08:57:09 +0000

Hi Fernando,

A quick clarification: 
I mean "destination node" could be the "final/ultimate destination node", or "non-final/non-ultimate destination node".
The case (2) is a case where "destination node" is the "final/ultimate destination node" in my previous mail.

BTW: a node receiving a packet with the DA being the "destination node" does not know it is the "ultimate destination node" or "non-ultimate destination node" until the packet is further processed (possibly the 1/2/3/... in the previous mail).

Thanks
Jingrong

-----Original Message-----
From: Fernando Gont [mailto:[email-masked]] 
Sent: Monday, May 25, 2020 2:15 PM
To: Xiejingrong (Jingrong) <[email-masked]>; Brian E Carpenter <[email-masked]>; 6MAN <[email-masked]>
Subject: Re: some feedback on feedback on draft-bonica-6man-ext-hdr-update-03

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

---

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Mon, 25 May 2020 09:08:32 +0000

Hi Fernando,

It is not surprise to me that, the multicast address could be used as "non-final/non-ultimate destination" in IPv6-EH mechanism.

We could go back to the day when "multicast address" was first invented/introduced by Dr. Steve Deering (also a co-author of 1883/2460), firstly in RFC966, then 988, then 1112:
https://mailarchive.ietf.org/arch/msg/ipv6/gnp6W6QSuo_jMelU6jJys7wxcrU/

and Let's imagine:
(1) in IPv4, a packet using Multicast address as destination address, and there is some "Option" in IP header.
(2) in IPv6, a packet using Multicast address as destination address, and there is some "Option" in IP header.

Thanks
Jingrong

-----Original Message-----
From: Fernando Gont [mailto:[email-masked]] 
Sent: Monday, May 25, 2020 2:13 PM
To: Xiejingrong (Jingrong) <[email-masked]>; Brian E Carpenter <[email-masked]>; 6MAN <[email-masked]>
Subject: Re: some feedback on feedback on draft-bonica-6man-ext-hdr-update-03

> To me, "Destination node" is very simple to mean "the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field".

Ironically, it would be quite interesting to have a multicast address as a "Destination Node", unless "Destination Node" implies final destination.

Thanks,

---

From: 神明達哉 <[email-masked]>
Date: Tue, 26 May 2020 17:44:38 -0700

At Mon, 25 May 2020 03:17:14 -0300,
Fernando Gont <[email-masked]> wrote:

> in RFC2460 or RFC1883.

Agreed, and in that sense Erik (Klein) was completely correct.

The unfortunate bug in RFC8200 is that it could now read as if the
term "Destination node" (which itself isn't ambiguous) applies to the
added phrase "inserted, or deleted" as well.  Once
draft-bonica-6man-ext-hdr-update fixes the bug, I suspect the text in
Section 4.6 Brian cited wouldn't look so confusing (again).

That said, I wouldn't necessarily oppose further clarifying that
particular part if the wg thinks it's worthwhile (not sure if it
should be done in draft-bonica-6man-ext-hdr-update though).

--
JINMEI, Tatuya