Subject: Question 6man SRH encaps only

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Tue, 6 Nov 2018 08:08:09 +0000

Hi Joel,

Regarding your question on 6man about the SRH and allowing only encapsulation:
There are two open-source host implementations of the SRH (Linux Kernel, FD.io VPP). I wrote the code for SRH in the latter.

A---1---2---B
(A and B are hosts)

In one of the use-cases host A has awareness of the transport network.
Host A generates and sends a packet of the form IP(SRH(TCP(...))) where the SRH contains segments <1,2,B>.
Note that B is an interface address on host B.

Do you believe that in this case the host should send IP(SRH(IP(TCP(...))))? If yes, why?
I think this is a relevant use-case -e.g. PANRG-, and don’t see why we would enforce encapsulation.

Thanks,
Pablo.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 6 Nov 2018 15:14:08 +0700

Yes, I am saying that we should always use IP(SRH(IP(...))).
The reason is simplicity and robustness.
As we have already discussed, the host has to be prepared to generate 
that form and process that form whenever it is talking to someone 
outside the SR Domain.
Having two ways of encoding the same thing, and two processing paths for 
generating / handling the same thing, introduces complexity.

If there is a strong benefit (beyond the number of bits in the packet), 
I would like to hear about that benefit.  I can easily believe I missed 
something.

In the absence of a benefit, choices are in and of themselves harmful.

Yours,
Joel

On 11/6/18 3:08 PM, Pablo Camarillo (pcamaril) wrote:
> There are two open-source host implementations of the SRH (Linux Kernel, 
> FD.io VPP). I wrote the code for SRH in the latter.
> 
> A---1---2---B
> 
> (A and B are hosts)
>

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Tue, 6 Nov 2018 08:56:32 +0000

I fail to see how this option is simpler. 
Note that as opposed to what you stated, hosts A and B generate the packet and are inside the SR domain.
A Linux host B will receive IP(SRH(IP(TCP(...))). What is the purpose of the inner IP header? 

On top of that, you can link a TCP/UDP socket with a given segment routing header [1]. Why would I insert here an IP header?
If you have the time [2] is an interesting read. In there you have a good list of benefits.

I believe that if hosts A and B are within the SR domain -which is the case when hosts A and B generate the SR header-, then there is no benefit to introduce an inner IP header before the L4 payload.

Thanks,
Pablo.

[1]. https://tools.ietf.org/html/draft-duchene-spring-srv6-socket-00
[2]. David Lebrun, Mathieu Jadin, François Clad, Clarence Filsfils,
and Olivier Bonaventure. 2018. Software Resolved Networks: Rethinking
Enterprise Networks with IPv6 Segment Routing. In SOSR
’18: SOSR ’18: Symposium on SDN Research, March 26–27, 2018,
Los Angeles, CA, USA. ACM, New York, NY, USA, 14 pages.
https://doi.org/10.1145/3185467.3185471

On 06/11/2018, 15:14, "Joel M. Halpern" <[email-masked]> wrote:

    

    Yours,
    Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 6 Nov 2018 16:44:35 +0700

The point is that a host inside the SR domain, when processing an SR 
policy, has to be prepared, for reasons we discussed on the list before 
the meeting, to generate the full IP(SR(IP(...))) packet format.  Having 
an option to generate two different SR formats does not add value and 
does inherently add complexity.

On the receive side, the host must also be prepared to receive both 
formats.  One can argue that this is less of a burden, but it is still 
complexity.  And we have already determined that it needs to be able to 
handle the encapsulated case.

Yours,
Joel

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Tue, 6 Nov 2018 10:28:20 +0000

I think it depend on your view of simplicity.  Simple to implement for a broad set of solutions or simple to specify?

It is simple to specify a host must only encapsulate, or other restrictions but that doesn’t necessarily give us a strong base to build other specification.

I prefer that we make sure the SRH draft define a good base on which other documents can be based to solve real problems beyond the very limited use cases we have defined.

BTW It is simple to implement the socket based approach to apply an SR policy to a socket within an SR Domain - It is implemented, and it works.

Darren

> On Nov 6, 2018, at 4:44 AM, Joel M. Halpern <[email-masked]> wrote:
> 
> The point is that a host inside the SR domain, when processing an SR policy, has to be prepared, for reasons we discussed on the list before the meeting, to generate the full IP(SR(IP(...))) packet format.  Having an option to generate two different SR formats does not add value and does inherently add complexity.
> 
> On the receive side, the host must also be prepared to receive both formats.  One can argue that this is less of a burden, but it is still complexity.  And we have already determined that it needs to be able to handle the encapsulated case.
> 
> Yours,
> Joel
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 6 Nov 2018 17:53:25 +0700

I do not understand your argument about a good base for future use.

All the cases I know of can be handled with just the encapsulation mode. 
  If there are issues that it can not handle, details on that would be 
good to hear them.  Conversely, I don't see how the working group can 
decide that it needs a feature because some folks say that they think 
there is a use for it in the future.

Yours,
Joel

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Tue, 6 Nov 2018 11:44:54 +0000

Joel, forcing every host to place an outer encapsulation on a packet ‘because there is no reason it won’t work’ is not justification.  It’s like forcing every host to use IPSec because there is no reason it won’t work.

There are use cases for intra-domain communication in the draft. 
There is no justification for an additional outer IP encapsulation in that case. 
It is implemented and works.

Darren

> On Nov 6, 2018, at 5:53 AM, Joel M. Halpern <[email-masked]> wrote:
> 
> All the cases I know of can be handled with just the encapsulation mode.  If there are issues that it can not handle, details on that would be good to hear them.  Conversely, I don't see how the working group can decide that it needs a feature because some folks say that they think there is a use for it in the future.
> 
> Yours,
> Joel
>

---

From: Joel Halpern Direct <[email-masked]>
Date: Tue, 6 Nov 2018 22:08:01 +0700

Darren, as I understand it, we have already agreed that hosts have to 
have the capability to generate and process encapsulated messages.

With two representations, we have to have capabilities in the 
configuration and the SR Policy to indicate which one is to be used 
when.  As far as I know, there is no simple rule the hosts can follow, 
as there is no obvious way a priori to know that a destination is in the 
same SR domain.

Across our protocols, we have found that having multiple ways of doing 
the same thing generally makes life harder.  So I am asking taht we 
either articulate a significant benefit from having such duplication, or 
we not duplicate capability.

Yours,
Joel

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 7 Nov 2018 08:41:57 +1300

> we not duplicate capability.

Put it this way: to allow the non-encapsulated mode, we need a watertight
way of ensuring that it is only used within a limited domain where we
are certain that both hosts know what they're doing and trust each other.

That's a lot of complexity, quite in addition to the intrinsic complexity
of having both an encapsulated and non-encapsulated mode.

Well, there's a draft for that:
https://tools.ietf.org/html/draft-carpenter-limited-domains

That draft expresses the opinion that there *will* be many such domains
in future, but there's no disguising that this creates complexity. As
things stand today, except for hand-crafted configurations, we have no
way to support this that I am aware of.

    Brian

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

---

From: Tom Herbert <[email-masked]>
Date: Tue, 6 Nov 2018 14:32:01 -0800

> way to support this that I am aware of.
I am not sure that the use case for hosts speaking SR would ever be
prevalent. I suspect the vast majority of deployments will be to apply
SR in the network in which case encapsulation is always used. There's
a couple of reasons for this. In anything that resembles a public
network (like in mobile where SRv6 is proposed as replacement for GTP)
end hosts are not trusted and couldn't be part of the  domain. Even if
the hosts are trusted, say in a compartmentalized data center it's
still less likely hosts would participate. It is not common for hosts
to implement any sophisticated routing, and it's often the case that
servers and networks are managed very differently by different
internal organizations.

An alternative to hosts participating directly in SR (or other complex
routing) is described in draft-herbert-route-fast-00. The idea is that
the network gives a host an ticket that encodes routing. When a
network nodes sees the ticket it can apply the routing, for instance
the ticket may indicate a SR list to use.

Tom