Subject: [spring] Question about IPv6 EH-insertion in draft-ietf-spring-srv6-network-programming

From: Fernando Gont <[email-masked]>
Date: Sat, 7 Sep 2019 06:08:43 +0300

Folks,

I have one specific question regarding this I-D:
What is the motivation for doing EH-insertion, instead of creating a new
packet with the necessary EHs, and include the original packet in the
payload?

Thanks!

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

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Sat, 7 Sep 2019 05:14:54 +0000

< An engineer comes out from the trenches/ >

Hi Fernando,

I will attempt to answer and but also setup the context first.

The context:
1) SRv6 is trying to enhance certain capabilities in IPv6 for specific deployments (2). The idea is to use IPv6 pervasively for various current features in those specific deployments (2) but also open the door for future innovation that some feel will simplify the myriad existing alternative encapsulations and techniques in those specific deployments (2). Thereby improve the attractiveness and adoption of IPv6.
2) The specific deployment that is referenced in SR architecture (RFC8402) is called a SR domain. This is a single administrative domain - e.g. belonging to a Service Provider. Kind of the domain within which an operator may use private IPv4 addresses (e.g. 10/8) for their internal infrastructure today when they don't have enough IPv4.
3) In this deployment (2), the provider gets a customer packet at their network edge which is encapsulated (e.g. normally in MPLS but in our case within an IPv6 header) and routed through to the remote network edge where it is de-encapsulated and the inner customer packet handed over to the customer. All the SRv6 and SRH aspects being discussed are for this outer IPv6 encap header that is added by the SP. The inner payload may be IPv4, IPv6 (with all it's security and other options) or any L2.
4) This is not about the IPv6 Internet. All of SR is about within a SR domain and as an extension so is SRv6 and SRH.

There are exactly two "features" (at least AFAIK) of a large set where we encounter scenarios where SRH insertion/removal for this outer IPv6 header when the customer packet transits the SR domain:
a) BSID (End.B6.Insert) : this is a SR Policy anywhere in the transit path for TE and/or Service Chaining purposes
b) TI-LFA/Microloop Avoidance (T.insert) : These are protection techniques for sub-50msec fast-reroute and repair for failures in this transit network

You can get more details/references on them on this thread : https://mailarchive.ietf.org/arch/msg/spring/Jtg9YPxEjes4Bm-1ngwXmJfeybs 

SRH that is inserted in transit is "popped" on reaching another node in the SR domain once it's purpose is served.

Some more details on these :
- In the case of (a), the SR domain ingress router has actually included an SRH with the End.B6.Insert SID in it. We can look at this as if it has "delegated"/"instructed" a downstream transit router to do SRH insertion with its own SID list corresponding to the SR Policy indicated by that BSID.
- In the case of (b), the insertion of SRH is done upon failure by a point-of-local-repair (PLR) router in the domain to take it through and "release" it at another router in the domain to circumvent this failure. In that sense, it is dynamic and mostly last for a few seconds until the network converges.

These features exist and are widely deployed today with SR-MPLS and work similarly - difference is working with stacks of label instead of SRH.

Now, it is most important to understand that the encap variants of these features (End.B6.Encap & T.encap) are already defined in the SRv6 spec.

So then we come to your Q - why the insert flavors? The motivation is to reduce the overhead of *yet another* IPv6 header and encap when doing these features. You will also realize by now that this aspect is not specific to SRv6/SRH but in general to any solution based on IPv6. Anyone having some decent experience with SR will vouch for the importance of these two features.

Since MTU overhead was one of (if not the biggest) point for this whole debate, IMHO we (IETF) owe it to the industry to find out a workable solution for SRH insertion. I accept there are challenges and we need to try and find solutions around them for successful deployments of IPv6 in these networks. 

With this context, I hope at least some more folks can engage constructively on finding a solution. I am not discounting or discrediting the past debates on this. In shrill debates, people sometimes tune off - so apologies if all of the above was already explained and covered in pieces in the past. If this is new context, I hope, perhaps things will look different from the above perspectives ...

When I hear anyone claiming to be an SR expert and evangelizing SR for IPv6 saying that either these features are not necessary, or that they are doing encap instead of insert in their solution/approach for addressing them - I am at a loss and rather choose to keep my thoughts about it private 😊

I wonder if these and few other folks seem to have taken this insertion aspect of IPv6 rather dogmatically that they are not willing to help on a solution and that they would rather not be concerned about reducing this additional IPv6 encap overhead (irrespective of whether it is SRH or CRH or xRH). 

I do hope that others do continue trying to pursue and find a solution for doing SRH insert and not get dissuaded by those doggedly opposed to it.

Thanks,
Ketan

< / the engineer who doesn't want to engage in philosophical and unconstructive debates goes back to work in the trenches >

-----Original Message-----
From: spring <[email-masked]> On Behalf Of Fernando Gont
Sent: 07 September 2019 08:39
To: [email-masked]
Cc: [email-masked]
Subject: [spring] Question about IPv6 EH-insertion in draft-ietf-spring-srv6-network-programming

Folks,

I have one specific question regarding this I-D:
What is the motivation for doing EH-insertion, instead of creating a new packet with the necessary EHs, and include the original packet in the payload?

Thanks!

Cheers,

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

---

From: "Bernier, Daniel" <[email-masked]>
Date: Sat, 7 Sep 2019 05:18:06 +0000

Hi Fernando,

Let’s say I have a native IPv6 application flow to which I want to apply a service policy (i.e. chain of functions), carry metadata through TLVs or perform a very simplistic filtering action via the tag field. All of which are real use cases by the way.
Should I not leverage insertion instead ?

Thanks,

Daniel Bernier

On 2019-09-06, 11:10 PM, "spring on behalf of Fernando Gont" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

Folks,

Thanks!

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

_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring
------------------------------------------------------------------------------
External Email: Please use caution when opening links and attachments / Courriel externe: Soyez prudent avec les liens et documents joints

---

From: Mark Smith <[email-masked]>
Date: Sat, 7 Sep 2019 16:50:19 +1000

On Sat, 7 Sep 2019, 15:18 Bernier, Daniel, <[email-masked]> wrote:

> Hi Fernando,
>
>
>
> Let’s say I have a native *IPv6 application flow* to which I want to
> apply a service policy (i.e. chain of functions), carry metadata through
> TLVs or perform a very simplistic filtering action via the tag field. All
> of which are real use cases by the way.
>

Why can't you use encapsulation?

There's a 21 year old spec on how to do that, and it doesn't violate RFC
8200.

RFC 2374, "Generic Packet Tunneling in IPv6"

See figure 3. for an example of how to add supplemental information to an
existing packet via EHs with encapsulation.

>
> Thanks,
>
>
>
> Daniel Bernier
>
>
>
> On 2019-09-06, 11:10 PM, "spring on behalf of Fernando Gont" <
> [email-masked] on behalf of [email-masked]> wrote:
>
>
>
> Folks,
>
>
>
> External Email: Please use caution when opening links and attachments /
> Courriel externe: Soyez prudent avec les liens et documents joints
>
>
>
>

---

From: Fernando Gont <[email-masked]>
Date: Sat, 7 Sep 2019 14:31:42 +0300

Hello, Ketan,

Inline...

> I will attempt to answer and but also setup the context first.

Thanks for elaborating, by the way.

> 4) This is not about the IPv6 Internet. All of SR is about within a SR domain and as an extension so is SRv6 and SRH.

At least at the time of this writing, we don't have "flavours" of
IP/IPv6. The same protocol is employed everywhere, because that's the
scope of the layer.

> You can get more details/references on them on this thread : https://mailarchive.ietf.org/arch/msg/spring/Jtg9YPxEjes4Bm-1ngwXmJfeybs 
[....]
> So then we come to your Q - why the insert flavors? The motivation is to reduce the overhead of *yet another* IPv6 header and encap when doing these features. You will also realize by now that this…

So, double-checking if I understood correctly: You are saying that the
two uses cases that you are referring to already have an alternative
specification with encap/decap, but this document proposes to use EH
insertion to avoid the extra overhead of adding an additional IPv6 header?

Thanks!

Cheers,

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 7 Sep 2019 13:43:33 +0200

> insertion to avoid the extra overhead of adding an additional IPv6 header?

That is correct.

I have been telling you this over and over again and you were choosing not
to accept it.

But please do think about real deployments which do SRH insertion with
encapsulation on ingress to their network for TE or NP reasons. Then the
same customer would like to use TI-LFA to protect data plane.

So per your and few other comments he would not be able to add another
local (to the protection zone) SRH to his already encapsulated on ingress
packet, but would have to add another IPv6 encapsulation with SRH to be in
line with RFC8200 even if the only point of the new SRH is local single dst
detour and protection of arriving dst address in the outer  most IPv6
header.

How efficient/wise that is ?

Thx,
R.

---

From: Fernando Gont <[email-masked]>
Date: Sat, 7 Sep 2019 15:15:13 +0300

On 7/9/19 14:43, Robert Raszuk wrote:
> I have been telling you this over and over again and you were choosing
> not to accept it. 

Then you have answered my previous question. This EH-insertion thing is
not solving any problem that cannot be solved with the standard that we
have, and instead introduces potential problems.

You shouldn't be surprised if, modulo social engineering, the proposal
for EH insertion doesn't fly in 6man.

That said, I think EH insertion should be removed from this document, on
the basis that:

* It breaks an existing standard (RFC8200) that explicitly banned it for
technical concerns.

* It doesn't solve a problem that cannot be solved with encap/decap, and
in fact introduces potential problems.

> local (to the protection zone) SRH to his already encapsulated on
> ingress packet, but would have to add another IPv6 encapsulation with
> SRH to be in line with RFC8200 even if the only point of the new SRH is
> local single dst detour and protection of arriving dst address in the
> outer  most IPv6 header. 
> 

That's certainly, at least, a cleaner design than inserting EHs in the
network (and there's no such a thing as a free lunch). Inserting EHs is,
if anything, a hack.

As a side comment, if you have concerns wasted bits (and since you
stress all the time that SR operates in a "limited domain") a quick
comment would be: why do you use IPv6 addresses (IDs of global scope) to
identify the SR nodes?

Thanks,

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 7 Sep 2019 14:53:29 +0200

Hi,

why do you use IPv6 addresses (IDs of global scope) to
> identify the SR nodes?

Well one valid reason would be to avoid need for yet another mapping table
like LDP or SR-MPLS requires.

Sure TI-LFA works fine with SR-MPLS no problem. It also works fine with
uSID.

It may work with new EH encapsulation proposal with IPv4 too.

Please keep in mind that for vast majority of TI-LFA you do not need any
SID at all. ZERO SID covers most of real topologies !!!

SRC slide 19 from :
https://www.segment-routing.net/tutorials/2016-09-27-topology-independent-lfa-ti-lfa/

All you require SRH for is preservation of original destination IPv6
address in the packet during detour. It is IPv6 packet which you are
protecting so where do you put those 128 bits ?

You can not map it to anything and ship in the control plane as you would
drop a lot till such pigeon would rich the PQ node. That would defeat the
entire purpose of LFA.

Best,
Robert.

---

From: Xiejingrong <[email-masked]>
Date: Sat, 7 Sep 2019 13:06:34 +0000

I am happy to see the converging, and I agree with both Robert and Gernando.

The problem that an EH-insertion want to solve can also be solved by using an extra encap/decap, which is obviously compliant. 
The more bytes used by extra encap/decap may be the tax we have to pay for using IPv6!

The problem that CRH want to solve can also be solved easily by using the SRH, just use 6-10 SIDS in SRH directly.
The tax is the use of IPv6 addresses (IDs of global scope) to identify the SR nodes, for the benefits that IPv6 brings!

Why not ?

Jingrong

-----Original Message-----
From: spring [mailto:[email-masked]] On Behalf Of Fernando Gont
Sent: Saturday, September 07, 2019 8:15 PM
To: Robert Raszuk <[email-masked]>
Cc: [email-masked]; Ketan Talaulikar (ketant) <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [spring] Question about IPv6 EH-insertion in draft-ietf-spring-srv6-network-programming

> I have been telling you this over and over again and you were choosing 

Then you have answered my previous question. This EH-insertion thing is not solving any problem that cannot be solved with the standard that we have, and instead introduces potential problems.

You shouldn't be surprised if, modulo social engineering, the proposal for EH insertion doesn't fly in 6man.

That said, I think EH insertion should be removed from this document, on the basis that:

* It breaks an existing standard (RFC8200) that explicitly banned it for technical concerns.

* It doesn't solve a problem that cannot be solved with encap/decap, and in fact introduces potential problems.

> SRH to be in line with RFC8200 even if the only point of the new SRH 
> is local single dst detour and protection of arriving dst address in 
> the outer  most IPv6 header.
> 

That's certainly, at least, a cleaner design than inserting EHs in the network (and there's no such a thing as a free lunch). Inserting EHs is, if anything, a hack.

As a side comment, if you have concerns wasted bits (and since you stress all the time that SR operates in a "limited domain") a quick comment would be: why do you use IPv6 addresses (IDs of global scope) to identify the SR nodes?

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Sat, 7 Sep 2019 23:47:33 +0300

On 7/9/19 15:53, Robert Raszuk wrote:
> Well one valid reason would be to avoid need for yet another mapping
> table like LDP or SR-MPLS requires. 

If you care about overhead, that's an area that I would explore.