Subject: Re: [spring] WG Adoption Call for draft-martin-spring-segment-routing-ipv6-use-cases

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Mon, 2 Jun 2014 19:36:47 +0000

On May 30, 2014, at 9:54 PM, Hannes Gredler wrote:

> eric,
> 
> <devils advocate>
> if *just* loose source routing is required, then the same can get achieved using
> nested IP tunnels. no need for new architecture, no need for new signaling protocol extensions,
> perhaps some re-spin of forwarding hardware in order to push the large tunnel strings.
> </devils advocate>.

maybe but I don't see the advantage while SRH gives you way more 
capabilities that, at some point, may be requested as well (TE, 
LFA, EPE, ...).

> point is that you can't get away with loose source routing semantics for supporting
> all the SR use-cases. thus the current 6man draft needs rework in order
> to be somewhat feature congruent to the mpls-dataplane, which stefano
> has agreed to post _soon_.

that is correct. According to the comments received on version -00 
(among which, yours) a new version is going to be released as soon 
as the co-authors completed the internal review.

If it doesn't go fast enough for you, well, you'll have to live with 
that feeling.

>  i hope it does not take another 12 months
> (e.g. like the last time when we have asked for the data ipv6-sr plane specification
>  presented at mplswc2013 - actual publication data was feb 2014 ...) -

Indeed, SR-IPv6 was initially presented at mplswc2013, then it 
triggered interest and collaboration from many parties. Note that 
we met during a couple of hours in Paris at that time and we gave 
you all the details of what we had in mind, including the ipv6 
part. 

Then, at some point in the cycle, we published a draft describing 
what the authors worked out in terms of architecture and SRH details. 
I don't think I have to come with a justification about the amount 
of time it took.

Anyway, in the mean time, implementation work from multiple parties 
started (for both mpls and v6 dataplanes). Now that we have multiple 
implementations, we are working on interoperability and we will, 
probably, again update some of the details but don't take this as a 
commitment from my side to publish anything in a delay that suits 
your time perception. 

s.

> tx,
> 
> /hannes
> 
> On May 27, 2014, at 8:36 PM, Eric Vyncke (evyncke) wrote:
> 
>> Late reply to Hannes point:
>> 
>> On 28/03/14 22:23, "Hannes Gredler" <[email-masked]> wrote:
>>> 
>>> the real question is what percentage of public Internet routers
>>> 
>>> 1) does have MPLS hardware forwarding support
>>> 2) does have IPv6-SR hardware forwarding support.
>>> 
>>> And
>> 
>> Regarding the IPv6-SR compatibility, as SRH is basically 'loose source
>> routing', it only requires:
>> - SRH processing by all SR-enabled router whose segment id is in the SRH,
>> typically some PE routers. Those will need to be modified indeed but those
>> will be minority
>> - SRH forwarding (i.e. Not parsing or acting upon the SRH) for all
>> remaining routers. Those will be the majority
>> 
>> The latter is currently OK, I wrote a small script
>> https://www.vyncke.org/sr.php which basically sends a dummy SRH to your
>> browser (requirement is that your browser/clients supports IPv6) and after
>> a dozen of tests, all were successful. While this is not a mathematical
>> proof, this is good enough from my engineer's point of view
>> 
>> Hope this helps
>> 
>> -éric
>> 
>

---

From: Hannes Gredler <[email-masked]>
Date: Fri, 6 Jun 2014 11:17:54 +0200

stefano, et al,

my read of SR and IPv6-SR in the past year is:

  1. that in 2013 you have started out with a *unified* control-plane
     based on stacked-tunnels technology which supports more than
     one data-plane.

  2. because it supports 'more than' dataplane and there is
     a high congruency between dataplane forwarding semantics you need an
     overarching, common 'architecture' with new terminology etc.

now lets have a closer look after more than one-year of 'SR-promised-land':

  1. There is little to no SP traction on IPv6-SR.
     those SPs who have voiced support in all reality
     can be served well with nested IP tunnels based on
     exisiting protocols (GRE, IPIP, L2TPv3 )

  2. For certain usecases (e.g. protection, OAM, controller-based TE, etc)
     there is SP traction in SR-over-MPLS.

  3. There is little to no congruency in terms of forwarding-semantics
     between the IPv6-SR dataplane and the MPLS data-plane.

     a) MPLS forwarding
        = loose and strict forwarding based on local assigned tags

     b) IPv6-SR forwarding
        = best-matching prefix forwarding based on global assigned adresses

  4. the cost of adding explicit routing forwarding capabilities
     to IPv6 forwarding hardware is now visible (and guess what - its expensive
     to implement on high speed (100GBIT/s lookup engines -
     (parsing IPv6-extensions headers does require a lot of memory references)

  5. IOW the need to support for 'more-than-one dataplane' has just shrunk down
     to 'one dataplane' of practical relevance (which is MPLS).

  6. for *one* practical dataplane we do not need new architecture, nor new terminology.
     all what is required is some further clarification to rfc3031, which
     'draft-gredler-spring-mpls' really is all about.

what really irritates me is your repeated delay tactics around publication
of 'IPv6-SR' in sufficient details, such that one can see the clear need for a
*common* architecture. my trust that this will happen has gotten down to almost zero.

before asking the WG to adopt a common SR architecture and terminology
i'd rather ask you to *proof* the need for it. right now there
is *zero* evidence on the table that we need a 'common, dataplane neutral
SR architecture' at all, for supporting the practical relevant use-cases.

/hannes

On Mon, Jun 02, 2014 at 07:36:47PM +0000, Stefano Previdi (sprevidi) wrote:
[ ... ]

| >  i hope it does not take another 12 months
| > (e.g. like the last time when we have asked for the data ipv6-sr plane specification
| >  presented at mplswc2013 - actual publication data was feb 2014 ...) -
| 
| 
| Indeed, SR-IPv6 was initially presented at mplswc2013, then it 
| triggered interest and collaboration from many parties. Note that 
| we met during a couple of hours in Paris at that time and we gave 
| you all the details of what we had in mind, including the ipv6 
| part. 
| 
| Then, at some point in the cycle, we published a draft describing 
| what the authors worked out in terms of architecture and SRH details. 
| I don't think I have to come with a justification about the amount 
| of time it took.
| 
| Anyway, in the mean time, implementation work from multiple parties 
| started (for both mpls and v6 dataplanes). Now that we have multiple 
| implementations, we are working on interoperability and we will, 
| probably, again update some of the details but don't take this as a 
| commitment from my side to publish anything in a delay that suits 
| your time perception. 
| 
| 
| s.

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Fri, 6 Jun 2014 09:31:21 +0000

>  1. There is little to no SP traction on IPv6-SR.

the above statement reflects a lack of understanding of what's going on 
at that particular side. I'd suggest you to have a better look. I think
even on this list, operators expressed their interest in SR architecture 
for v6 dataplane.

Very recently we had an interesting presentation at NANOG. Maybe you 
should have a look.

>     exisiting protocols (GRE, IPIP, L2TPv3 )

This is what you keep publicly claiming... without really believing on it.

>     'draft-gredler-spring-mpls' really is all about.

draft-gredler-spring-mpls is the most complex solution to a very simple 
requirement. I believe your draft is a very nice exercise so to prove 
you can do source routing with something that was clearly not designed 
to do so. With a very high price in terms of complexity (architectural 
and operational) you mimic what SR does with much more simplicity.

Your draft explains in more than 10 pages what SRs explains in 10 lines 
and nobody changes anything in the mpls dataplane.

Well, you know that, we've talked about it already, right ?

> what really irritates me

relax, enjoy the summer that's coming...

> is your repeated delay tactics around publication

on this mailing you already told me I'm a liar, now you state I'm doing 
tactics... should I keep a counter ?

> *common* architecture. my trust that this will happen has gotten down to almost zero.

why are you so stressed ? The change that needs to be made in the 6man 
draft is only about the adj-sid. a minor detail.

Since you seem very stressed and obsessed about it, let me promise you 
I will submit the draft today so you can have a more relax week-end.

Obviously, only if this makes you feel better.

s.

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Fri, 6 Jun 2014 09:48:12 +0000

Hannes,

I am following this thread from far away but I wonder about:

>     exisiting protocols (GRE, IPIP, L2TPv3 )

Tunnels are also expensive (cfr point below) but if you want to enforce a
specific route for TE, then, I am afraid that this will be a lot of
specific configuration (or states if dynamic) in a lot of nodes... As well
as a lot of specific routes towards those tunnels. So, kind of heavy.

Not to mention that with SRH you could have different paths among two
end-points based on the application (web vs video) identified by some
means (such as layer-4 information), way more complex to do it with
tunnels and 'plain' routing.

>     (parsing IPv6-extensions headers does require a lot of memory

I am sure that you know how source routing works, only the router in the
destination address main IPv6 header field needs to inspect the SR header,
all others routers can safely act only on the DA and ignoring the
extension header chain (of course, if ACL are applied on layer-4 you need
to parse the extension header chain but this is the same with or without
SR).

Hope that my comment helps clarifying the context

-éric

---

From: Hannes Gredler <[email-masked]>
Date: Fri, 6 Jun 2014 13:31:51 +0200

hi eric,

see answers inline.

On Fri, Jun 06, 2014 at 09:48:12AM +0000, Eric Vyncke (evyncke) wrote:
| Hannes,
| 
| I am following this thread from far away but I wonder about:
| 
| On 6/06/14 11:17, "Hannes Gredler" <[email-masked]> wrote:
| >
| >  1. There is little to no SP traction on IPv6-SR.
| >     those SPs who have voiced support in all reality
| >     can be served well with nested IP tunnels based on
| >     exisiting protocols (GRE, IPIP, L2TPv3 )
| 
| Tunnels are also expensive (cfr point below) but if you want to enforce a
| specific route for TE, then, I am afraid that this will be a lot of
| specific configuration (or states if dynamic) in a lot of nodes... As well
| as a lot of specific routes towards those tunnels. So, kind of heavy.
                                                         ^^^^^^^^^^^^^

depends a whole lot how you implement IP tunnels.
  if you follow the prevailing model that an IP tunnel is implemented as a logical-interface,
  (and hence needs to be explicitly configured) then you're right its heavy weight and
  expensive.

however, it does not have to be like that:
  one could have e.g. an implementation where all inbound tunneled traffic is routed
  towards a decapulator-interface (where you do all the key validation, ACL etc.)
  which POPs of the outer tunnel header and
  does an IP lookup on the next-tunnel-header.

so assuming this 'IP-tunnel-decapsulator' in core-nodes then any ingress node
could describe an explicit path by pushing N nested IP tunnels.

| Not to mention that with SRH you could have different paths among two
| end-points based on the application (web vs video) identified by some
| means (such as layer-4 information), way more complex to do it with
| tunnels and 'plain' routing.

see above: applications actually could do the nested-tunnel-pushing,
using exisiting OS kernels.

| >  4. the cost of adding explicit routing forwarding capabilities
| >     to IPv6 forwarding hardware is now visible (and guess what - its
| >expensive
| >     to implement on high speed (100GBIT/s lookup engines -
| >     (parsing IPv6-extensions headers does require a lot of memory
| >references)
| 
| I am sure that you know how source routing works, only the router in the
| destination address main IPv6 header field needs to inspect the SR header,
| all others routers can safely act only on the DA and ignoring the
| extension header chain (of course, if ACL are applied on layer-4 you need
| to parse the extension header chain but this is the same with or without
| SR).

see and that is the problem here ...

http://tools.ietf.org/html/draft-previdi-6man-segment-routing-header-00

   "Each segment endpoint inspects the SRH, updates the DA (with the next
   segment) and forwards the packet towards the next segment."

this adds the requirement to rewrite the IPv6-DA.
i'd estimate that the majority of IP6 hardware forwarding implementations
does not have the ability to *rewrite* IPv6 DAs (perhaps on the edge
thatre are some CG-NAT chipsets which can do this).

/hannes

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Fri, 6 Jun 2014 13:17:55 +0000

> | as a lot of specific routes towards those tunnels. So, kind of heavy.

I'd leave you with your estimation however I'd like to point out 
that the behavior consisting of rewriting the DA at a segment endpoint 
has not been defined by Segment Routing but rather by IPv6 architecture 
(rfc2460). Segment Routing just leverages an architectural component 
defined a few years back.

s.

---

From: Xuxiaohu <[email-masked]>
Date: Mon, 9 Jun 2014 08:07:48 +0000

> -----Original Message-----
> From: spring [mailto:[email-masked]] On Behalf Of Eric Vyncke
> (evyncke)
> Sent: Friday, June 06, 2014 5:48 PM
> To: Hannes Gredler; Stefano Previdi (sprevidi)
> Cc: Yakov Rekhter; <[email-masked]>; John G. Scudder; Alvaro Retana (aretana)
> Subject: Re: [spring] WG Adoption Call for
> draft-martin-spring-segment-routing-ipv6-use-cases
> 
> Hannes,
> 
> Tunnels are also expensive (cfr point below) but if you want to enforce a specific
> route for TE, then, I am afraid that this will be a lot of specific configuration (or
> states if dynamic) in a lot of nodes... As well as a lot of specific routes towards
> those tunnels. So, kind of heavy.

Agree that nested IP tunnels are expensive. However, the SRH which contains an ordered list of IPv6 addresses seems a bit heavy as well (e.g., the MTU issue), especially when the number of specified hops along the explicit path is very large. Why not use an ordered list of short ids, instead of an ordered list of IPv6 addresses to represent an explicit path while still allowing the underlay is IPv6 network? IMHO, the MPLS label stack seems like an ideal candidate for that ordered list of short ids. To some extent, the MPLS layer is now an overlay as opposed to the IPv6 underlay (see http://tools.ietf.org/html/draft-xu-spring-islands-connection-over-ip-00). Or do you believe the MTU issue is not a problem anymore in practice?

> end-points based on the application (web vs video) identified by some means
> (such as layer-4 information), way more complex to do it with tunnels and 'plain'
> routing.
> 
> destination address main IPv6 header field needs to inspect the SR header, all
> others routers can safely act only on the DA and ignoring the extension header
> chain (of course, if ACL are applied on layer-4 you need to parse the extension
> header chain but this is the same with or without SR).

In the approach as I mentioned above, it only requires those specified hops along the explicit path to be upgraded as well (i.e., interpret the top label of the MPLS packet into the IPv6 address of the next specified hop and then forward the packet to that hop via an IPv6 tunnel instead of an MPLS LSP tunnel). In other words, its deployment cost is much similar with that of the SRH-based approach.

Best regards,
Xiaohu

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