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

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Tue, 27 May 2014 18:36:30 +0000

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: Yakov Rekhter <[email-masked]>
Date: Fri, 30 May 2014 19:37:45 +0000

Eric,

> -----Original Message-----
> From: Eric Vyncke (evyncke) [mailto:[email-masked]]
> Sent: Tuesday, May 27, 2014 2:37 PM
> To: Hannes Gredler; Stefano Previdi (sprevidi)
> Cc: Yakov Rekhter; <[email-masked]>; Alvaro Retana (aretana)
> Subject: Re: [spring] WG Adoption Call for draft-martin-spring-segment-
> routing-ipv6-use-cases
> 
> - 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

If indeed, as you said above, only "minory" of the routers (e.g., only PEs) 
would be able to process IPv6 SRH, then SR would *not* be able to support 
such use cases as various flavors of local protection, and traffic engineering 
(except for EPE). Conversely, support for various flavors of local 
protection and/or traffic engineering (other than EPE) would require 
all routers to support IPv6 SRH.

Yakov.

> 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: Robert Raszuk <[email-masked]>
Date: Fri, 30 May 2014 21:50:15 +0200

Hi Yakov,

I read Eric's email and included its main point a bit differently.

It is known for a fact that in large network (say 1000 routers) it is
sufficient to force traffic only via few key core boxes (perhaps 10 or
so) in order to perform good traffic engineering.

With SR it is possible while in classical RSVP-TE it is not - simply
due hop by hop signalling nature of the latter.

His reference to PE was IMHO just an example without intention to
provide exhaustive list.

For local protection with basic IPv6 network I would rather recommend
use of LFA solutions which again do not require anything to do with
SRH processing - so his SRH forwarding only case for vast majority of
routers in a given domain remains sound and valid.

Best regards,
R.

On Fri, May 30, 2014 at 9:37 PM, Yakov Rekhter <[email-masked]> wrote:
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring

---

From: Hannes Gredler <[email-masked]>
Date: Fri, 30 May 2014 21:54:28 +0200

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

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

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

tx,

/hannes

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 30 May 2014 22:04:00 +0200

Hey Hannes,

> if *just* loose source routing is required, then the same can get achieved
> using nested IP tunnels.

I would agree with above.

In fact one could state a question which encap would be more efficient
two IPv6 extension headers or 6 IPv4 headers :)

Also data plane processing wise one could perhaps observe that
flexible handling of multi level IPv4 headers is already supported
today in a lot of deployed hardware ....

> point is that you can't get away with loose source routing semantics for
> supporting all the SR use-cases.

Care to list those ? Perhaps for sake of documentation it may turn
helpful. Maybe for simplicity just limit those use cases to IP
forwarding paradigm only :)

Thx,
R.

---

From: Hannes Gredler <[email-masked]>
Date: Fri, 30 May 2014 22:08:48 +0200

robert,

> so) in order to perform good traffic engineering.

i do not share that view: 

we have heard of many customer requirements requiring to to disjoint routing
of SIGTRAN traffic down to the PE level.
IOW pretty much every router needs to have support for the new
*expensive* data plane.

> due hop by hop signalling nature of the latter.

with LSP hierarchy we can solve pretty much any scaling problem, right ?

> routers in a given domain remains sound and valid.

the trouble with LFA technology and 100% backup coverage is
a bit like star-wars … lots of episodes ;-)

Episode 1: - LFA
  is not deployable due to the algorithm not
  consider what is an operational feasible
  path (think of backup of a oc-768 with a oc-3).

  so we need:

Episode 2: - LFA + policy (manageability draft)

  trouble is now we have eliminated many paths
  due to policy reasons: so we need something
  to increase path-diversity by reusing
  existing tunnels - which gets us to

Episode 3: - R-LFA
  it is still possible to construct pathologic
  topologies which do not provide 100% coverage.

Episode 4: - R-LFA +DF
  concerns about micro-loops and desire to place SPT
  backup traffic on the post-convergence-path leads us
  to

Episode 5: - TI-LFA

now my question is: would you bet the farm on that there won't
be another episode (i.e. things we haven't considered so far).
i won't, given that track record of misguided hopes and believes.

/hannes

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 30 May 2014 22:29:16 +0200

Hi Hannes,

> we have heard of many customer requirements requiring to to disjoint

True if you are talking end to end between PEs. I have heard of those
between 2004-2006 when MTR fashion was at the peak too :)

And I must have missed that SR claims to address those without all
nodes supporting SRH processing if you are talking PE-PE.

But there are cases where to the PE level is not required for number
of applications so those can be addressed without all nodes handling
SRHs.

Again we are not here to decide I think.

If customer takes a calculator and conclude that for his need it is
better to deploy MPLS data plane he will dop that no matter for SPRING
or FALL brings to the table.

If on the other hand he will see that just he can upgrade IOS on bunch
of nodes to address his needs he will do just that.

> with LSP hierarchy we can solve pretty much any scaling problem, right ?

Yep - never claimed we can't :). But it all comes with cost and complexity.

Even if some of us can play with LSPs easy I would not state that we
should force everyone else into that art.

>   path (think of backup of a oc-768 with a oc-3).

If someone has such mix of active core links I would not worry about
LFA, but about redesign of the network first :)

>   existing tunnels - which gets us to

As you know both can be automated quite easily.

>   topologies which do not provide 100% coverage.

Is the goal to address pathological cases which probability of
happening in real life is equal to any of two of us visiting Mars any
time soon ...

> i won't, given that track record of misguided hopes and believes.

I am not sure what's the point of that list. If you are stating that
with hop by hop LSP crafting you have more control - of course you are
rigth and no one will argue.

But do you need such fine art or you are ok with lighter and less
expensive alternatives.

Frankly I like control plane based solutions vs data plane .. it is
just that perhaps we should more focus on making the former much
easier for operators then they are today.

Cheers,
R.

---

From: Hannes Gredler <[email-masked]>
Date: Fri, 30 May 2014 22:29:30 +0200

hi robert,

> forwarding paradigm only :)

just watch for use-cases which require an 'adjacency-label' -
the 'adjacency-SID' has got 'strict routing semantics' and cannot
get substituted by e.g. a node/prefix-SID which has 'loose routing semantics'

the use cases i am talking are specifically:

http://tools.ietf.org/html/draft-filsfils-spring-segment-routing-use-cases-00#section-3.2.1
http://tools.ietf.org/html/draft-filsfils-spring-segment-routing-use-cases-00#section-4.1.2
http://tools.ietf.org/html/draft-filsfils-spring-segment-routing-use-cases-00#section-4.1.3
http://tools.ietf.org/html/draft-filsfils-spring-segment-routing-use-cases-00#section-4.1.4
http://tools.ietf.org/html/draft-filsfils-spring-segment-routing-use-cases-00#section-4.1.5
http://tools.ietf.org/html/draft-filsfils-spring-segment-routing-use-cases-00#section-4.2.1
http://tools.ietf.org/html/draft-filsfils-spring-segment-routing-use-cases-00#section-4.2.2
http://tools.ietf.org/html/draft-filsfils-spring-segment-routing-use-cases-00#section-6.1
http://tools.ietf.org/html/draft-filsfils-spring-segment-routing-use-cases-00#section-6.2

HTH,

/hannes

---

From: Hannes Gredler <[email-masked]>
Date: Fri, 30 May 2014 22:42:00 +0200

On May 30, 2014, at 10:29 PM, Robert Raszuk wrote:
[ … ]

> rigth and no one will argue.

point is that LFA and opportunistic path-hunting technologies *always*
have a gap, which was silently ignored up until it comes to deployment.
boom reality check … i am having these 'episode' discussion since
4 years with some of my customers … always putting it off to the
'next release' is not something which was perceived well.

> easier for operators then they are today.

that and also striving for the right balance between control-plane
and data-plane state. e.g. using automated-RSVP for setting up
facility protection LSPs to all the next-next-hops uses the
RSVP protocol in a range which is *far* away from scaling woes.
one can then use SR label-blocks to get label bindings to
the final destination points. - two MPLS labels (read: no fwd
plane upgrade), 100% coverage. no excessive (T-LDP) sessions.
app 30-50 RSVP sessions even on large scale networks.

/hannes

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 30 May 2014 22:44:43 +0200

> http://tools.ietf.org/html/draft-filsfils-spring-segment-routing-use-cases-00#section-3.2.1

I would not say that context segment is the same as adj-SID

> http://tools.ietf.org/html/draft-filsfils-spring-segment-routing-use-cases-00#section-4.1.2

Sure if you want strict ERO granularity alternative.

> http://tools.ietf.org/html/draft-filsfils-spring-segment-routing-use-cases-00#section-4.1.3

One can easily to EPE with bunch of global SIDs pointing to different
exit interfaces or VRFs.

> http://tools.ietf.org/html/draft-filsfils-spring-segment-routing-use-cases-00#section-4.1.5

Yep.

> http://tools.ietf.org/html/draft-filsfils-spring-segment-routing-use-cases-00#section-4.2.2

On those two I could claim one can do a lot with just global SIDs.

> http://tools.ietf.org/html/draft-filsfils-spring-segment-routing-use-cases-00#section-6.2

True.

> HTH,

Partially :)

r.

---

From: "Leddy, John" <[email-masked]>
Date: Fri, 30 May 2014 23:25:51 +0000

General comments,

Given that we are talking about technology for the future of the Internet,
it would be good to consider requirements of Internet traffic.

LFA for Internet?  With smart apps, CDNs, intelligent clients?  What?

We need to move to IPV6, we are.  Are You?

We need to do it very efficiently and enable innovation and TTM with low
risk.
Scale is obviously an issue.  I want to enable more bandwith!
Raw bandwidth to someone offnet really drives the tradeoffs for an
Internet provider, move to V6 only.  Now!
Flexibility in what we can do internally is a big value add, V6 SR.
Because V6 is how we offer services to our customers, new mandate.

Commercial Intranet traffic (VPN) is high value, but really noise as far
as volume.  Do we build a future IP architecture on this?

Channeling PeterL, the cheapest way to build a SONET network is to build a
SONET network.  Or something like that, I think we can do better butŠ
Apologize for a mis quote.  Peter can address with me.

Given we build INTERNET infrastructure for <100% capacity at peak, for
single link, single site, single fiber bundle failures.  And then we pad
it for growth.
With Overcapacity of 50%ish.  You have to love 50% CAGR per year on
traffic, you are never wrong.

Some of this optimization stuff is inertsesting (sp?), that is not how we
build networks on this side.

Everything for us is IPV6, not interested in forcing us to have to tunnel
it all in MPLS.  
I¹m not even happy with Ethernet.  SONET gone, Ethernet?, Big Fat V6 Pipe
go.

John Leddy

On 5/30/14, 4:08 PM, "Hannes Gredler" <[email-masked]> wrote:

>a bit like star-wars Š lots of episodes ;-)
>
>Episode 1: - LFA