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

From: Brian E Carpenter <[email-masked]>
Date: Sun, 13 Oct 2019 10:57:59 +1300

Hi,

I'd like to comment on this version. It is in fact a complete rewrite compared to
its predecessors and I thank the authors for that. The tone is now purely technical,
and that's a great improvement.

It's also, IMHO, accurate in its statements about the relationship with RFC 8200.
In particular:

>    Action 2 inserts an SRH in a packet within the SR domain at a node
>    not in the destination address, and inserts more than one SRH in a
>    packet.  This does not appear to be permitted by the statements
>    quoted above from RFC8200.  However, the restrictions above are not
>    applicable within the SR domain.  Every source node participating in
>    the SR domain expects SRH insertion, relies on it for services
>    provided by the SR domain, correctly processes ICMP errors, and
>    according to RFC8200 must process multiple SRH in the same packet.

That statement "the restrictions above are not applicable within the SR domain"
is (it seems to me) a normative statement. It might be even clearer to state it
as such:
  ...the restrictions above SHOULD NOT be applied within the SR domain.

Clearly it's a WG question whether on not we want to put this on the standards
track. I hope we can discuss it as a technical question. My subsidiary
question is: does the description of an SR domain (here and in RFC8402)
provide enough security and operational assurance that this SHOULD NOT is
safe?

Regards
   Brian Carpenter

On 21-Sep-19 16:20, [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
>                           Clarence Filsfils
>                           Darren Dukes
>                           Satoru Matsushima
>                           John Leddy
> 	Filename        : draft-voyer-6man-extension-header-insertion-07.txt
> 	Pages           : 13
> 	Date            : 2019-09-20
> 
> Abstract:
>    Traffic traversing an SR domain is encapsulated in an outer IPv6
>    header for its journey through the SR domain.
> 
>    To implement transport services strictly within the SR domain, the SR
>    domain may require insertion or removal of an SRH after the outer
>    IPv6 header of the SR domain.  Any segment within the SRH is strictly
>    contained within the SR domain.
> 
>    The SR domain always preserves the end-to-end integrity of traffic
>    traversing it.  No extension header is manipulated, inserted or
>    removed from an inner transported packet.  The packet leaving the SR
>    domain is exactly the same (except for the hop-limit update) as the
>    packet entering the SR domain.
> 
>    The SR domain is designed with link MTU sufficiently greater than the
>    MTU at the ingress edge of the SR 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-07
> https://datatracker.ietf.org/doc/html/draft-voyer-6man-extension-header-insertion-07
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-voyer-6man-extension-header-insertion-07
> 
> 
> 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, 14 Oct 2019 08:53:19 -0700

>   ...the restrictions above SHOULD NOT be applied within the SR domain.
Brian,

Dissecting this a bit:

"Every source node participating in the SR domain expects SRH insertion"

That is awfully inclusive and seems to be retroactively creating a
fundamental property of SR domains. Also, no opt out form source? I
would expect that in most use cases, probably all in deployment today,
the SR EH is set at the ingress node into the SR domain and describes
the path to egress. The fact that some intermediate node might insert
an EH could conceivably be a security issue in such deployments more
than anything. IMO, if EH is allowed then source nodes should be able
to opt out, or even better EH insertion should always be opt in from
the source. If a source node wishes to enforce that no EHs are
inserted it can do that with AH (assuming that AH were properly
specified to interact with SRH)..

The draft also states that the source and destination are required to
be in the same SR domain for EH insertion. This needs to be specified
as a MUST. The obvious question this raises is: how does an
intermediate node know that a source and destination are in the SR
domain? I would infer that the authors are probably assuming that this
can be done by specifying a prefix for the SR domain or maybe a
whitelist of addresses? This is easy enough to propose, but on a
network of even moderate scale I'm not convinced it's manageable. I
suggest an alternative is for the source node to mark packets for
which EH insertion is permissible (i.e. the opt in model). This could
be done for instance by the source setting a null SR header (no SIDs)
with a flag that indicates EH insert is permitted.

"correctly processes ICMP errors"

That presumes that correct processing of ICMP errors is well defined.
Consider this scenario:

An intermediate node inserts an SRH with HMAC, a subsequent downstream
node attempts to verify the HMAC and fails to verify. The downstream
node sends an ICMP packet back to the source. What is source supposed
to do with this ICMP error? (note this is just one scenario, the
general case is how to deal with ICMP errors sent because of error in
the inserted EH). There is nothing that source host can do within the
protocol to avoid further occurrences of the error. At best they'll
log it, but since there's no attribution so now somebody someone needs
to track down who is inserting the EH-- in a complex network that may
be non-trivial.

Attribution is critical. One obvious way to address this would be for
the node inserting the EH to put its address into the SRH, but then
that reduces the overhead savings of SR EH insertion compared to
encapsulation to be just eight bytes (destination address in
encapsulation is same as last address in insert SID list). IMO, it
would be better to just do encapsulation instead.

Another hole is correct ICMP processing is reflected in:

"The SR domain ingress edge processing the ICMP error SHOULD log the
error and decrement the ingress edge MTU for traffic traversing the SR
domain (if it's greater than the IPv6 minimum MTU of 1280 bytes)"

Okay, but what if the source _is_ already at minimum MTU for PMTU?
Note that SRH can be hundreds of byte and now with insertion there can
be multiple SRHs of these is a packet, I don't think this is something
that can be easily dismissed with the typical assumption that all
networks can just set MTUs large enough.

"However, the restrictions above are not applicable within the SR domain"

I think the wording here is wrong for the intent of the draft. All the
normative "MUSTs" in RFC8200 and other appropriate standards are
applicable to _all_ use cases of the protocol. I see no provision in
RFC8200 that its requirements, like prohibition of EH insertion, are
conditional based on the environment in which the protocol is
deployed. So RFC8200 is applicable in SR domains, limited domains, and
the Internet. IMO, this draft is trying to justify an exception to the
requirements and should be written as such. Presumably, the exception
might be palatable if it maintains robustness, interoperability, and
spirit of requirements of RFC8200.

Tom

> >    the SR domain expects SRH insertion
Hi Brain,

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

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 15 Oct 2019 08:17:01 +1300

Tom,

> So RFC8200 is applicable in SR domains, limited domains, and
> requirements and should be written as such.

Absolutely; that's why I suggested a SHOULD, in fact. I didn't raise a
related standards-wonk question: whether the draft should be tagged as
"Updates: 8200" (or "Amends: 8200" in terms of draft-kuehlewind-update-tag).

If it's going to be done, it should be explicit.

Regards
   Brian

---

From: Mark Smith <[email-masked]>
Date: Tue, 15 Oct 2019 08:15:26 +1100

Now that tunnelling has been accepted, and that a distinct IP tunnel could
be created for each segment, 1:1, with tunnel/segment heads or tails being
the place where the SRH can be created or transferred, with or without
modification, or over from the previous segment/tunnel, which does comply
with RFC8200 (as tunnel endpoints are IPv6 hosts), there is no functional
need for mid-tunnel anonymous insertion.

So what is the reason to persist with it? It doesn't make sense to me that
people are clinging to an idea that has so many flaws and contradictions to
standard behaviour, when there is a method that works without these flaws
and contradictions.

Determining whether or not to perform deeper packet processing (SRH
processing in this case) on a packet, using the packets' DA, is
conventional, traditional, and implemented in billions of deployed devices,
both hosts and routers.

Contrast that with a device having to purposely ignore literally every
packets' DA that it looks at, to search all of those packets for an SRH to
then determine if it should perform SR processing on it. Unconventional,
non-traditional, and a capability I'd guess is likely to be deployed in way
less than 10 000 devices,  and likely less than 1000.

Not updating SAs after packet modification, and having to purposely
ignoring packets' DAs, is down a rat hole that NAT also lives in.

Regards,
Mark.

On Tue, 15 Oct 2019, 02:54 Tom Herbert, <[email-masked]> wrote:

> > >       Filename        :
> draft-voyer-6man-extension-header-insertion-07.txt
> > >       Pages           : 13
> > >       Date            : 2019-09-20
> > >
> > > Abstract:

---

From: Tom Herbert <[email-masked]>
Date: Mon, 14 Oct 2019 14:53:23 -0700

On Mon, Oct 14, 2019 at 2:15 PM Mark Smith <[email-masked]> wrote:
>
> Now that tunnelling has been accepted, and that a distinct IP tunnel could be created for each segment, 1:1, with tunnel/segment heads or tails being the place where the SRH can be created or transferred, with or without modification, or over from the previous segment/tunnel, which does comply with RFC8200 (as tunnel endpoints are IPv6 hosts), there is no functional need for mid-tunnel anonymous insertion.
>
Mark,

I would tend to agree. It seems that the only purported benefit of SR
insertion over tunneling is that it saves packet overhead. But I don't
think that really pans out. In insertion without attribution, the
difference is twenty-four bytes overhead, but if attribution is done
(like node modifying the packet puts it address in it somewhere), then
the overhead is as little as eight bytes (possibly even less if there
is only one entry in the SID list). Relative to the potential large
size of the SRH itself, I don't seethe potential savings in overhead
to be very impressive especially relative to the complexities of
defining a robust and secure protocol for EH insertion.

Tom

> So what is the reason to persist with it? It doesn't make sense to me that people are clinging to an idea that has so many flaws and contradictions to standard behaviour, when there is a method that works without these flaws and contradictions.
>
> Determining whether or not to perform deeper packet processing (SRH processing in this case) on a packet, using the packets' DA, is conventional, traditional, and implemented in billions of deployed devices, both hosts and routers.
>
> Contrast that with a device having to purposely ignore literally every packets' DA that it looks at, to search all of those packets for an SRH to then determine if it should perform SR processing on it. Unconventional, non-traditional, and a capability I'd guess is likely to be deployed in way less than 10 000 devices,  and likely less than 1000.
>
> Not updating SAs after packet modification, and having to purposely ignoring packets' DAs, is down a rat hole that NAT also lives in.
>
> Regards,
> Mark.
>

---

From: Fernando Gont <[email-masked]>
Date: Mon, 14 Oct 2019 17:02:54 -0500

> If it's going to be done, it should be explicit.

Agreed. I have been arguing this for a while.

A related question is: Is this really IPv6 maintenance?

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: Mon, 14 Oct 2019 17:12:46 -0500

> and that's a great improvement.

It is somewhat frustrating that the draft still fails to argue why EH
insertion instead of encapsulation.

---

From: Fernando Gont <[email-masked]>
Date: Mon, 14 Oct 2019 17:15:24 -0500

On 14/10/19 16:53, Tom Herbert wrote:
> insertion over tunneling is that it saves packet overhead.

If folks want to optimize things, then, may I ask: why are you using
128-bit SIDs in the first place?

P.S.: In any case, it's interesting to see version -07 still fail to
argue why insertion rather than encapsulation, and have participants
theorize about it, when that argument/discussion should be part of any
sensible proposal to change the current state of affairs.

Thanks,

---

From: Mark Smith <[email-masked]>
Date: Tue, 15 Oct 2019 09:55:20 +1100

Hi  Tom,

> defining a robust and secure protocol for EH insertion.

Once an IPv6 tunnel is considered a link-layer (because it is and is
being used that way), then there are opportunities to perform forms of
compression on the inner payload packet to reduce overhead between the
tunnel end-points, as link-layers don't process payloads (nothing new
here, no lower layers are supposed to process their upper layer
payloads at any layer).

I don't know much about it, however it looks like Robust Header
Compression (RoHC) could be used (RFC5795) to compress the inner
packet headers while the packet is in flight across the current IPv6
tunnel/SR segment/virtual link. A quick Internet search finds a few
implementations, including a couple of open source ones.

RoHC might be too stateful or not able to be performed fast enough on
high speed links. The following method is stateless, takes advantage
of IPv6 networks having many /64s, using them to identify tunnel
endpoints (rather than /128s), and leverages the common fields and
field semantics between the inner and outer header, using the outer
header fields as proxies for the inner header fields while the packets
are in flight.

"Skinny IPv6 in IPv6 Tunnelling"
https://tools.ietf.org/html/draft-smith-skinny-ipv6-in-ipv6-tunnelling-00

As long as it provides attribution (the source /64 in its case), and
is fully reverseable, excepting the mutable Traffic Class and Flow
Label fields, I think it too could be an option to reduce inner packet
overhead if 128 bit SIDs are used.

Regards,
Mark.

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 14 Oct 2019 19:31:43 -0400

On Mon, Oct 14, 2019 at 6:56 PM Mark Smith <[email-masked]> wrote:

> > > Now that tunnelling has been accepted, and that a distinct IP tunnel
> could be created for each segment, 1:1, with tunnel/segment heads or tails
> being the place where the SRH can be created or transferred, with or
> without modification, or over from the previous segment/tunnel, which does
> comply with RFC8200 (as tunnel endpoints are IPv6 hosts), there is no
> functional need for mid-tunnel anonymous insertion.
> > >
> > Mark,
> >
> [Gyan]  unfortunately we would have multiple EH insertions so that GRE
> tunnel won’t work.

In that stick diagram I had sent the 1st EH insertion is on the ingress PE
of the SRv6 domain and then for Ti-LFA at the PLR (point of local repair)
for IP fast reroute backup path a 2nd EH insertion which would be at mid
point somewhere  along the path to the 1st outer tunnel endpoint so you
would have at a minimum 2 encapsulations in following RFC 8200.  So 6in6
tunnel won’t work unfortunately.

     I think the only viable option is the using a virtual interface like a
loopback for the /64 SID to be in compliance with RFC 8200.

Gyan

>
>
>
>
>
> > Tom
> >
> >
> > > So what is the reason to persist with it? It doesn't make sense to me
> that people are clinging to an idea that has so many flaws and
> contradictions to standard behaviour, when there is a method that works
> without these flaws and contradictions.
> > >
-- 

Gyan S. Mishra

IT Network Engineering & Technology

Verizon Communications Inc. (VZ)

13101 Columbia Pike FDC1 3rd Floor

Silver Spring, MD 20904

United States

Phone: 301 502-1347

Email: [email-masked]

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

---

From: Mark Smith <[email-masked]>
Date: Tue, 15 Oct 2019 10:53:22 +1100

On Tue, 15 Oct 2019 at 10:31, Gyan Mishra <[email-masked]> wrote:
>> [Gyan]  unfortunately we would have multiple EH insertions so that GRE tunnel won’t work.
>
>
> In that stick diagram I had sent the 1st EH insertion is on the ingress PE of the SRv6 domain and then for Ti-LFA at the PLR (point of local repair) for IP fast reroute backup path a 2nd EH insertion which would be at mid point somewhere  along the path to the 1st outer tunnel endpoint so you would have at a minimum 2 encapsulations in following RFC 8200.  So 6in6 tunnel won’t work unfortunately.
>

Well firstly, I'm going to pretty much not bother trying to understand
anything where you suggest insertion, because I've literally spent
hours of my own time writing up why I disagree with it and the
problems it causes.

It sounds like you think there can't be a 6in6in6 tunnel. Or a
6in6in6in6 tunnel.

There's nothing that technically stops tunnels being inside tunnels.
Same as LSPs inside LSPs ...

Have a read of

"IP Tunnels in the Internet Architecture"
https://tools.ietf.org/html/draft-ietf-intarea-tunnels-10

if you haven't already.

>
>      I think the only viable option is the using a virtual interface like a loopback for the /64 SID to be in compliance with RFC 8200.
>
> Gyan
>>
>>
>>
>>
>>
>>
>> > Tom
>> >
>> >

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 17 Oct 2019 15:20:24 +0200

Le 15/10/2019 à 00:12, Fernando Gont a écrit :
>> I'd like to comment on this version. It is in fact a complete
>> rewrite compared to its predecessors and I thank the authors for
>> that. The tone is now purely technical, and that's a great
>> improvement.
> 
> It is somewhat frustrating that the draft still fails to argue why
> EH insertion instead of encapsulation.

As usual, I think one of the reasons is a difficulty in qualifying what
it means 'encapsulation'.

There is IP-in-IP encapsulation.

But there is also encapsulation like in transporting, or carrying, by
means of other intermediary headers, layer2, MPLS, security headers and
future internet shims and GRE and routing headers.

IP-in-IP encapsulation is clearly an alternative to EH insertion.

But all the other encapsulations are so messy that one may legitimately
think that a new EH insert/delete standardized according to good WG
principles would be proper, universal, and solve all  problems of GRE
for example.

Alex

---

From: Tom Herbert <[email-masked]>
Date: Thu, 17 Oct 2019 09:19:23 -0700

> principles would be proper, universal, and solve all  problems of GRE

Alex,

What are the problems of GRE to which you referring?

Tom

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 17 Oct 2019 21:04:23 -0400

Sent from my iPhone

> On Oct 14, 2019, at 7:53 PM, Mark Smith <[email-masked]> wrote:
> 

[Gyan] So in theory some say once this I-D becomes approved standard at some point vendors will implement the feature and support but anyone doing SRv6 today which is supported in Cisco XR 7.0 and I believe Juniper and Huawei supports however today the multi tunnel stacking feature is not an option for today’s deployments.

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 17 Oct 2019 23:58:45 -0400

In-line 

Sent from my iPhone

> On Oct 17, 2019, at 12:19 PM, Tom Herbert <[email-masked]> wrote:
> 
> 
> 
>> On Thu, Oct 17, 2019, 6:20 AM Alexandre Petrescu <[email-masked]> wrote:
>> 
>> 
> -[Gyan] Good old protocol 47.  GRE is the Swiss Army knife of every network designers toolbox that I have used countless times to solve routing issues where traditional native routing was not possible and GRE tunneling was the savior.  Hats off to GRE for being with us all these years.  The main caveat In my experience have seen with GRE is accounting for the GRE/IP 20-IP 4-GRE = 24 overhead bytes and having to adjust the MTU to accommodate bumping the MTU along the path or lowering the GRE tunnel MTU to prevent fragmentation which most vendor platforms punt to software path to the RP impacting CPU utilization.

> GRE can be very handy from a routing perspective to solve routing issues and can also be used in transition or migration strategy or to fix an issue or allow routing islands to communicate such as with transition technology tunnels. The big down side with GRE  example is using IPv6 transition technology 6to4 tunnels to provide routing reachability over between IPv6 islands over an IPv4 backbone which works for small use cases but can become unmanageable as the tunnel grow to any to any for very large use cases not practical.

> There are a number of protocol specification which adopted GRE as the transport mechanism such as Net to Net IPSEC VPN DMVPN MGRE VTI tunnel mode is handing for running a  routing protocol over the VTI.  Another good protocol specification using GRE is MVPN Rosen MT tunnel P-instance default and Data MDT PIM enabled mpls core for inclusive default MDT      I-PMSI or Selective Data MDT S-PMSI. GRE has also been used for vxlan evpn NVGRE tunnel to anycast VTEP for VNIs.  

> The main reason for using GRE encapsulation which requires termination endpoint is if you are going to run a routing instance over that tunnel.

> If not requiring a routing instance a similar analogy is IPEC VPN transport mode is used if you don’t need a routing instance and if you do then you use tunnel mode and have a VTI for the routing instance.  

> With SRv6 just as with mpls an encapsulation is what we are adding similar to IPSEC transport mode since we don’t need a routing instance there is not need to have to terminate the A and Z end and you can then add as many encapsulations as you want similar to an mpls label stack.  I think it does add complexity since you have to terminate the endpoints but also now to support Ti-LFA backup paths additional encapsulation for the new EH insertion for the SRH header routing type 4 I think it’s better to just do the 6in6 encapsulation and not add GRE 4 byte header protocol 47.  

> I read the link but I did not see where it stated you can stack GRE tunnels.

---

From: Mark Smith <[email-masked]>
Date: Fri, 18 Oct 2019 15:22:17 +1100

On Fri, 18 Oct 2019, 12:04 Gyan Mishra, <[email-masked]> wrote:

> >> In that stick diagram I had sent the 1st EH insertion is on the ingress
> PE of the SRv6 domain and then for Ti-LFA at the PLR (point of local
> repair) for IP fast reroute backup path a 2nd EH insertion which would be
> at mid point somewhere  along the path to the 1st outer tunnel endpoint so
> you would have at a minimum 2 encapsulations in following RFC 8200.  So
> 6in6 tunnel won’t work unfortunately.
> >>
> >
> [Gyan] So in theory some say once this I-D becomes approved standard at
> some point vendors will implement the feature and support but anyone doing
> SRv6 today which is supported in Cisco XR 7.0 and I believe Juniper and
> Huawei supports however today the multi tunnel stacking feature is not an
> option for today’s deployments.
>

The IETF isn't about what's available today, is about what will be
available in the future.

We need to consider problems that both exist today and that may exist in
the future, so that if and when a problem exists in the future, we already
have an engineered solution, hopefully with implementations already
available to deploy.

>
> >>
> >>     I think the only viable option is the using a virtual interface
> like a loopback for the /64 SID to be in compliance with RFC 8200.
> >>
> >> Gyan
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>> Tom
> >>>>
> >>>>
> >>>>> So what is the reason to persist with it? It doesn't make sense to
> me that people are clinging to an idea that has so many flaws and
> >>>>> Contrast that with a device having to purposely ignore literally
> every packets' DA that it looks at, to search all of those packets for an
> SRH to then determine if it should perform SR processing on it.
> Unconventional, non-traditional, and a capability I'd guess is likely to be
> deployed in way less than 10 000 devices,  and likely less than 1000.
> >>>>>
> rewrite compared to
> >>>>>>> Administrative Requests:
> https://www.ietf.org/mailman/listinfo/ipv6
> >>>>>>>

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 18 Oct 2019 11:23:03 +0200

Le 17/10/2019 à 18:19, Tom Herbert a écrit :
> 
> 
> On Thu, Oct 17, 2019, 6:20 AM Alexandre Petrescu 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> 

Tom,

If I remember correctly, on the negative side, GRE does not work with 
IPsec security, GRE has no IPv6-GRE-IPv6 deployment, GRE is for 
limited-domains and does not work across the Internet contrary to VPN.

On the positive side, thanks to its key field, only with GRE it is 
possible to link together several tunnels such as to increase available 
bandwidth by aggregating, whereas with IP-in-IP it is not possible.

Alex

>     [email-masked] <mailto:[email-masked]>

---

From: Tom Herbert <[email-masked]>
Date: Fri, 18 Oct 2019 07:56:32 -0700

Alex,

I guess maybe you're only considering GRE/Ethernet, but for GRE/IP I
don't believe any of these negatives are valid. In fact, an IPv6
packet that contains next header 47, a 4 byte GRE header with first 16
bits set to zero and Protocol type set to 0x86dd, followed by an IPv6
packet-- is functionally equivalent to ip6ip6 encapsulation. Also, if
you want to increase the probability of successful traversal through
the Internet then GRE/UDP can be used (RFC8086).

> bandwidth by aggregating, whereas with IP-in-IP it is not possible.
Yes an advantage of GRE over just ipip encapsulation is that it's
extensible, albeit limited in its extensibility which is why we
developed GUE.

Tom

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 21 Oct 2019 10:34:42 +0200

> the Internet then GRE/UDP can be used (RFC8086).

One may wonder whether IP/GRE/Ethernet, or GRE/UDP/IP, represents 
encapsulation that avoids the necessity of EH insertion, or does not 
represent such.

> extensible, albeit limited in its extensibility which is why we

I meant an advantage more issued from implementation, not from 
specification.

The implementation of ip-in-ip tunnelling in linux is with virtual 
interfaces.  These interfaces have only two parameters: local and remote 
address.  The GRE implementation uses a  key behind the scenes, in 
addition to these same two parameters.  That key is what helps a 
bandwidth augmenting implementation to keep up  two tunnels at the same 
time (same 'remote' addresses, but different 'local' addresses), to 
distinguish between them, and to distribute IP packets between the two 
(round-robin is one such fashion).  The ip-in-ip tunnel implementations 
do not allow such distribution, because when you put the same 'remote' 
address on two ip-in-ip interfaces it will use just one such interface.

In such a context, one could imagine using EH insertion with IP-in-IP 
tunnelling: insert a key (in an EH) dynamically, by the endpoints.  This 
could help IP-in-IP classic tunnelling to act like GRE tunnelling, with 
respect to the apps that need to maintain two tunnels at the same time.

Alex

---

From: Tom Herbert <[email-masked]>
Date: Mon, 21 Oct 2019 07:03:58 -0700

Alex,

You're conflating protocol specification with protocol implementation. It's
much better to change the implementation to leverage the protocols, rather
than to change the protocols to suit the implementation.

Tom

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 23 Oct 2019 00:18:42 -0400

In-line  

Sent from my iPhone

> On Oct 18, 2019, at 12:22 AM, Mark Smith <[email-masked]> wrote:
> 
> 
> 
> The IETF isn't about what's available today, is about what will be available in the future.
> 
> We need to consider problems that both exist today and that may exist in the future, so that if and when a problem exists in the future, we already have an engineered solution, hopefully with implementations already available to deploy.
> 
> [Gyan] Mark I read through your 6in6 skinny draft again.  So this new 6in6 skinny GRE tunnel is different from standard GRE is that it now has its own EH header type and also shrinks the inner payload IPv6 down by mapping the source and destination IID of inner header to the outer header Source and Destination IID and do the endpoints of the tunnel have to be /64 but other then that this new 6in6 tunnel can be used for any 6in6 use case I imagine.  So now with the new skinny EH header with a single lookup you can determine that skinny payload is present.  So how does this new skinny 6in6 feature with the new EH header for skinny allow you to stack tunnels and have multiple 6in6in6 etc encapsulations.  Normally with 6in6 or 4in4 you have your underlay Routing which is your outer header routing to tunnel destination and then your inner header is overlay private tunneled routed single hop.  So what’s confusing to me is how you can add another overlay another GRE/IPv6 encapsulation so essentially having two IPv6 payloads encapsulated.  You would definitely need a higher Path MTU to avoid fragmentation which is a given.  

> So in the SRv6 scenario at that IP FRR node backup path for link and node protection occurring at the PLR(point of local repair) you would be adding another in flight EH insertion routing type 4 for SRH and that would now be done via another IPv6 encapsulation header tacked on which has the EH SRH header inserted for SRv6 Ti-LFA. So the inner most header would now be the 6in6 using skinny let’s say and so has the Skinny EH header tacked on as well so now when you get the the PQ node LFA node you pop do a single lookup see the skinny 6in6 header pop the inner most last 6in6 encapsulation that was the skinny encapsulation and now when the packet hits the END SID SID length 0 the egress P or PE node respectively does the PSP or USP pop and removes the EH insertion of the SRH header done by the originator ingress PE SRv6 domain source node and now the Native IPv6 packet is forwarded on the PE-CE link to the customer VRF.  Thinking it through it sounds like this will work with 6in6 skinny feature that you can stack tunnels and this would be a use case that would benefit significantly from your draft.