Subject: Re: I-D Action: draft-voyer-6man-extension-header-insertion-02.txt

From: Brian E Carpenter <[email-masked]>
Date: Tue, 28 Nov 2017 11:31:23 +1300

Hi,

I'm probably repeating myself, but it seems clear that this draft
in its present form will never get anywhere. Firstly I will try to
justify this statement, and secondly I'll try to make some
constructive suggestions.

I. The problems with the current draft:

I.1. No RFC is allowed to have more than five authors without
an extremely good reason. If six or seven people have contributed 
roughly equal amounts you might just be able to persuade the
RFC Editor to list everybody, but 18? Never.
https://tools.ietf.org/html/rfc7322#section-4.1.1

I.2. More serious is the tone, which starts with the Abstract.
"The network operator and vendor community has clearly indicated..."
is, to put it mildly, out of place in an IETF document. We work
by facts and rough consensus, not by declarations by vested
interests. I think a lot of people will simply stop reading
the draft after that sentence.

The tone needs to be rational and factual argument about why
the proposed mechanism is both desirable and harmless. The
abstract needs to be a factual summary.

I.3. A detail is that since this draft recommends ignoring
a rule in RFC 8200, it needs to be aimed at the standards
track with Updates: 8200.

I.4. Another detail is that in some places the draft seems
to assume that only segment routing headers will be
candidates for insertion. That may be true today, but
probably not for ever.

II. Constructive suggestions.

I understand that the idea is to propose that this rule
in https://tools.ietf.org/html/rfc8200#section-4 :

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

MAY be ignored within an administrative domain for packets that
terminate within that domain. If that's the intention, I think
there are several logical steps in the argument that need to
be laid out. A lot of the ideas are already in the draft; this
is mainly about making a clear and logical case that the whole
community can understand.

1. Introduction, outline of use cases [1].
2. Precise definition of a domain and of its boundary, ingresses and egresses.
3. Explanation of how the class of packets eligible for header insertion are identified [2].
4. Explanation of how the well-known issues are avoided (PMTUD, fragmentation, IPSec).
5. Clear statement of what header manipulations are allowed and which devices may perform them.
6. Precise statement of which text in RFC 8200 is updated.
7. Security considerations 

[1] More details on use cases could be an appendix. 

[2] https://tools.ietf.org/html/draft-voyer-6man-extension-header-insertion-02#section-3 
is IMHO correct as far as transit packets go. But it
should be presented as a mainstream part of the proposal,
not as an example.

I hope this is helpful.
   Brian Carpenter

On 21/11/2017 07:33, [email-masked] wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
>         Title           : Insertion of IPv6 Segment Routing Headers in a Controlled Domain
>         Authors         : Daniel Voyer
>                           Daniel Bernier
>                           John Leddy
>                           Clarence Filsfils
>                           Darren Dukes
>                           Stefano Previdi
>                           Stefano Salsano
>                           Antonio Cianfrani
>                           David Lebrun
>                           Olivier Bonaventure
>                           Prem Jonnalagadda
>                           Milad Sharif
>                           Hani Elmalky
>                           Ahmed Abdelsalam
>                           Robert Raszuk
>                           Arthi Ayyangar
>                           Dirk Steinberg
> 	Filename        : draft-voyer-6man-extension-header-insertion-02.txt
> 	Pages           : 14
> 	Date            : 2017-11-20
> 
> Abstract:
>    The network operator and vendor community has clearly indicated that
>    IPv6 header insertion is useful and required.  This is notably the
>    case when the entire journey of the packet remains in its source
>    domain.  In such a context, it does not matter where the extension
>    header is inserted.  The source domain may decide to place the IPv6
>    extension header insertion where it suits its best: at the source of
>    the packet or at any midpoint within the source domain.
> 
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-voyer-6man-extension-header-insertion/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-voyer-6man-extension-header-insertion-02
> https://datatracker.ietf.org/doc/html/draft-voyer-6man-extension-header-insertion-02
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-voyer-6man-extension-header-insertion-02
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

---

From: Tom Herbert <[email-masked]>
Date: Mon, 27 Nov 2017 17:22:11 -0800

> candidates for insertion. That may be true today, but
+1

I'm also leary of proposals that redefine protocol behavior on the
basis that it will only be used in a controlled domain. This entails
assumptions that all devices (both intermediate devices and end hosts)
in the domain play by these rules, creates several corner cases that
need to be dealt with, and necessitates rationalization that packets
using non-interoperable protocol are never leaked out of the domain.

For instance, here is a corner case that I see...

>From the draft:

"The source domain may decide to place the IPv6 extension header
insertion where it suits its best: at the source of the packet or at
any midpoint within the source domain"

This statement implies that all hosts are under control of the source
domain, but that is not typically the case. A source host on its own
accord may create a packet with extension headers, some of which might
be the same type that intermediate devices insert and remove. It's not
clear what the disposition is of such packets and their extension
headers in in this draft.

Another question that comes to mind is why encapsulation does not work
here. That is encapsulate the packet on ingress to the domain, use
whatever extension headers are needed in the outer header, and
decapsulate on egress (i.e. this was the original "answer" to
extension header insertion). I'm guessing this might be because of
packet overhead, but it would be nice to see the reasons articulated.

Tom

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

---

From: Fernando Gont <[email-masked]>
Date: Thu, 30 Nov 2017 17:14:07 +0800

On 11/28/2017 06:31 AM, Brian E Carpenter wrote:
[...]
> be laid out. 

IMO, #1 thing to be discussed is why normal encapsulation wouldn't work
-- this is the standard, straightforward and most clean approach.

Thanks,
-- 
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, 30 Nov 2017 13:45:39 +0100

> -- this is the standard, straightforward and most clean approach.

The best example I've heard is when you don't have a natural tunnel endpoint to encapsulate to.

Ole

---

From: Fernando Gont <[email-masked]>
Date: Thu, 30 Nov 2017 21:14:10 +0800

> The best example I've heard is when you don't have a natural tunnel endpoint to encapsulate to.

What's a natural tunnel-endpoint here? Aren't you expecting such
endpoint to exist, to remove the inserted EH, after all? (and listing it
in the RH)

I seem to remember some folks arguing that the rationale for EH
insertion is that performance go to hell if they do proper encapsulation...

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 30 Nov 2017 20:34:58 +0100

Hi Fernando,

So in the case of encapsulation you normally put the node performing the
encap as source address. That may impact how you handle this packet via
number of services or even by src-dst routing correct ?

So while perhaps some may consider it "cleaner" I think both variants have
their own use cases and should be supported.

Thx,
R.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 1 Dec 2017 08:35:26 +1300

> insertion is that performance go to hell if they do proper encapsulation...

There will be 40 extra bytes, and they are bytes that could in fact
duplicate the effect of a routing header by changing the apparent
destination address. And if some additional DPI is needed, a node
would need to look through the encapsulation anyway.

This is a question that the draft does indeed need to address.

    Brian

---

From: Fernando Gont <[email-masked]>
Date: Fri, 1 Dec 2017 04:59:47 +0800

On 12/01/2017 03:34 AM, Robert Raszuk wrote:
> So while perhaps some may consider it "cleaner" I think both variants
> have their own use cases and should be supported. 

Inserting an EH as suggested is not IPv6, and can break a number of
things. The very least I would expect for a proposal to do so is why
that cannot be done with proper encapsulation. --> i.e., add an outter
IPv6 header with a RH header, and do your thing, as oppose to insert the
RH in there.

Of the top of my head, if part of the claim is the controlled
environment, and that this controlled environment will take care of the
"butchered" packets to be brought back into their original shape, I'd
expect that having a dst addr of a system that can actually do that (as
in the normal encapsulation case) is kind of a requirement...

---

From: Tom Herbert <[email-masked]>
Date: Thu, 30 Nov 2017 13:19:04 -0800

> number of services or even by src-dst routing correct ?
Robert,

I don't understand your point. Isn't the underlying idea here to use
SR to source route a packet through a domain? I don't see why an outer
source address of a tunnel is relevant for that. Also, I'd point out
that encapsulation is hardly a new concept. It is well deployed in
various forms and many network services have already adapted to its
use.

> their own use cases and should be supported.
It's not just about being cleaner, there are questions about
correctness that need to be addressed.

Tom

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 30 Nov 2017 22:21:11 +0100

As I think it has been very clearly documented in number of drafts dst
address of the packet in the SRv6 domain is the address of the next segment
routing node which swaps it to next segment etc ... So dst address of the
imposed encapsulation will never be the end node which is seen as hope to
put the packet to the "original shape".

I was specifically referring to src address not dst address of the
encapsulated packet.

Thx,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 30 Nov 2017 22:25:33 +0100

Tom,

Imagine the case where packets are subject to go via service chains. I can
steer the packet to the router which has service nodes connected to it but
original src address may be used to decide which service given packet is
subject to take.

Sure I can impose an SR function and map it up front such that the router
above would never need to inspect src address, but why to construct such
architecture which only allows limited set of network programming as
opposed to offer the choice on how to setup things by network operators ?

Thx,
R.

On Thu, Nov 30, 2017 at 10:19 PM, Tom Herbert <[email-masked]> wrote:

> have

---

From: Mark Smith <[email-masked]>
Date: Fri, 1 Dec 2017 08:27:47 +1100

On 1 Dec. 2017 6:35 am, "Robert Raszuk" <[email-masked]> wrote:

Hi Fernando,

The trouble is they're not explained at all.

All there is is an assertion that "operators want this", which is the
logical fallacy of an appeal to authority.

 I'm an operator, and I don't want it. I think it'll be harder to
troubleshoot than NAT over the Internet and NAT is bad enough.

Thx,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 30 Nov 2017 22:44:35 +0100

>  I'm an operator, and I don't want it.

If you don't want it - do not use it.

> and NAT is bad enough.

While I am not a NAT supporter imagine you are running an enterprise with
15,000 CEs each connected to customers with different (and often
overlapping) IPv4 networks. You have a choice to do local proxy at all
customer sites for all types of services you offer or do NAT and get
customer's queries to your POPs. Just think what makes sense and what not
in such scenario.

Best,
R.

---

From: Tom Herbert <[email-masked]>
Date: Thu, 30 Nov 2017 13:54:43 -0800

On Thu, Nov 30, 2017 at 1:25 PM, Robert Raszuk <[email-masked]> wrote:
> architecture which only allows limited set of network programming as opposed
> to offer the choice on how to setup things by network operators ?
>
Robert,

Because the architecture, or at least protocol, is not correct.

Suppose a device inserts an EH into a packet that downstream causes
the packet to be dropped and generates an ICMP error which goes back
to the source. What is a source host supposed do with this? It might
be able to determine that it didn't send the EH, and if it's lucky it
might even be able to parse the offending EH and maybe even sees the
problem that caused the error. But then what? How does the host tell
the network to stop mucking with its packets so that they no longer
get dropped and the source host doesn't get blamed?

ICMP handling is just one of several issues that needs to be
addressed. If the only answer is that these aren't concerns because
the protocol is only deployed in controlled networks, then I claim
that's nothing more than hand waving which is not robust and doesn't
scale.

Tom

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 30 Nov 2017 23:07:43 +0100

Tom,

The biggest advantage of SRv6 in contrast to SR-MPLS is that the SRH (one
or more) are not modified through the SR applicability of the packets.

So node which understands SRv6 can generate ICMP to both src of the packet
(poor host) as well as ingress node in SR domain (as it is explicitly
listed in Ingress Node TLV of first SRH). Node which does not understand
SRv6 will likely only send it to original src .. but this is a feature not
a bug. This is how traceroute works.

If you do encap how will host now see all the nodes on the way traceroute
or tracepath ? Do you think that hosts admins will be happy to be blinded
by 6man ?

Btw I am not the one who ever claimed applicability to "controlled
networks" or "wall gardens" so don't try to use that one with me :)). For
me the much bigger question is what should go into data plane and what is
better to go in control plane. We may end up with both and let
customers/operators choose. But hand waving that doing innovation in data
plane is scary is not the approach I would endorse.

We would be still doing token ring or FDDI ....

Cheers,
R.

On Thu, Nov 30, 2017 at 10:54 PM, Tom Herbert <[email-masked]> wrote:

> opposed

---

From: Tom Herbert <[email-masked]>
Date: Thu, 30 Nov 2017 14:30:31 -0800

On Thu, Nov 30, 2017 at 2:07 PM, Robert Raszuk <[email-masked]> wrote:
> Tom,
>
> The biggest advantage of SRv6 in contrast to SR-MPLS is that the SRH (one or
> more) are not modified through the SR applicability of the packets.
>
> (poor host) as well as ingress node in SR domain (as it is explicitly listed
> in Ingress Node TLV of first SRH). Node which does not understand SRv6 will
> likely only send it to original src .. but this is a feature not a bug. This
> is how traceroute works.
>
But it is a bug. This is sending ICMP errors to hosts about packets
containing tcontent that they could not have possibly sent. What's
worse is that if the ICMP error contains the SR header this gives the
host a whole bunch of detail about the internal structure and paths of
the network which seems like a security issue to me.

> If you do encap how will host now see all the nodes on the way traceroute or
> tracepath ? Do you think that hosts admins will be happy to be blinded by
> 6man ?
>
A nice solution to the traceroute issue for encapsulation has already
proposed. See https://tools.ietf.org/html/draft-nordmark-nvo3-transcending-traceroute-03.
Many similar issues regarding encpasulation (dealing the MTU, ECN,
diff-serv propagation, etc.) have also been thought through in various
RFCs (RFC4459 for instance discusses the MTU and fragmentation).

Tom

Tom

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 30 Nov 2017 23:48:03 +0100

> transcending-traceroute-03.

​And where in the v6 header would you place a T-flag ? ​

The proposal above is about the overlay. SRv6 is not an overlay you want it
to become. *It is underlay.* I think this is biggest disconnect with this
and previous 6man discussions on that topic.

//RR.

---

From: Tom Herbert <[email-masked]>
Date: Thu, 30 Nov 2017 15:08:47 -0800

On Thu, Nov 30, 2017 at 2:48 PM, Robert Raszuk <[email-masked]> wrote:
>> proposed. See
>> https://tools.ietf.org/html/draft-nordmark-nvo3-transcending-traceroute-03.
>
>
> And where in the v6 header would you place a T-flag ?
>
It goes in an encapsulation header (GUE or VXLAN for instance). This
is also where bits can be put for OAM  instead of needing to overload
bits in the flow label that was previously proposed (another proposed
protocol exception that is justified by a "controlled environment"
constraint).

> and previous 6man discussions on that topic.

I don't think distinction of whether this is an overlay or underlay
relevant. What is relevant is whether the protocol is correct and
whether this justifies an exception to RFC8200 which explicitly states
that nodes in the path cannot insert extension headers.

In any case, there has been good feedback on this draft. I hope you
and the other authors will take all this into consideration for the
next draft version.

Tom

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 1 Dec 2017 13:15:24 +1300

> troubleshoot than NAT over the Internet and NAT is bad enough.

What I'm seeing in this thread are rational arguments for and against
the proposal. I agree about the logical fallacy in the abstract of the
current draft, but that's fixable with a few seconds use of the cursor
and Delete key. I'd like to see the rational arguments in the next version
of the draft.

   Brian

---

From: Tom Herbert <[email-masked]>
Date: Thu, 30 Nov 2017 17:03:08 -0800

> and Delete key. I'd like to see the rational arguments in the next version
It's not just the abstact that promote the logical fallacy, it occurs
elsewhere in the draft. For instance:

"Obviously, this FRR service increases the size of the packet during
its journey within domain D.  This is well-known to operators.
Well-known mitigation techniques have been deployed for more than 15
years"

This seems like a pretty useless statement in a protocol
specification. Either the mitigations should be articulated here or
the applicable RFCs describing them should be referenced.

Tom