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

From: Yakov Rekhter <[email-masked]>
Date: Wed, 26 Mar 2014 10:39:04 -0700

Alvaro,

> Hi!
> 
> This message officially starts the call for adoption for 
> draft-martin-spring-segment-routing-ipv6-use-cases.
> 
> Please indicate your position about adopting this use cases 
> draft by end-of-day on March 27, 2014.
> 
> http://tools.ietf.org/html/draft-martin-spring-segment-routing-ipv6-use-ca
ses
> Thanks!

>From section 2:

   However, there are other cases and/or specific network environments
   where MPLS may not be available or deployable for lack of support on
   network elements or for an operator's design choice.  In such
   scenarios a non-MPLS based solution would be required.

The above assumes that the already available technology, MPLS, "may
not be available or deployable for lack of support on network
elements", yet a brand new technology, a new IPv6 Segment Routing
header, will be available, deployable, and supported on network
elements. The authors should elaborate on what makes them think so.

Wrt "for an operator's design choice", the draft should present a
rational explanation for such choice. Otherwise, the draft should
just say that its use cases are the folks who go into anaphylactic
shock at the mention of MPLS.

More from section 2:

   4.  There is a need to connect millions of addressable segment
       endpoints, thus high routing scalability is a requirement.  IPv6
       addresses are inherently summarizable: a very large operator
       could scale by summarizing IPv6 subnets at various internal
       boundaries.  This is very simple and is a basic property of IP
       routing.  MPLS node segments are not summarizable. 

Where is the use case that illustrates application of summarizable
Node-SIDs ?

                                                     To reach the
       same scale, an operator would need to introduce additional
       complexity, such as mechanisms described in
       [I-D.ietf-mpls-seamless-mpls]

Perhaps before claiming "additional complexity" in 
[I-D.ietf-mpls-seamless-mpls] the authors of the draft should
count the number of times the word "simple" or "simplicity"
occurs in [I-D.ietf-mpls-seamless-mpls] (which btw has one
of its authors the same as one of the authors of 
draft-martin-spring-segment-routing-ipv6-use-cases).

Yakov.

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Wed, 26 Mar 2014 17:59:46 +0000

Hi Yakov,

thanks for your comments. See below.

> elements. The authors should elaborate on what makes them think so.

we can reword the statement so to explain that there are places 
where mpls is not planned to be deployed while ipv6 is and it is 
preferred (by the network operators of such infrastructures) to 
extend ipv6 with sr rather than changing dataplane.

> rational explanation for such choice.

I don't think so. It's a reality we have to cope with.

> Otherwise, the draft should

or maybe just mention that mpls, being a great technology, is 
not deployed everywhere.

I'd skip the "anaphylactic shock" part of your comment which, btw 
can apply to both mpls-haters and mpls-addicted. They usually 
share the same symptoms.

At the end, I believe the vast majority (if not all) of the people 
who adopted mpls did so because of good and practical reasons. 

The same applies to the ones who deployed ipv6, don't you think 
so ?

The reality of the industry is that we have both dataplanes so 
it's obvious that we may want to provide similar functionalities 
for both without claiming one technology is the solution for 
everything.

> Where is the use case that illustrates application of summarizable

I think it's explained in the text but we can add more details if
necessary.

> draft-martin-spring-segment-routing-ipv6-use-cases).

a co-author on both drafts is a good thing as it demonstrate 
we have different solutions for different (dataplanes) use cases 
and this doesn't mean one prevails over the other.

I don't find anything wrong with this.

Thanks.
s.

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

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 26 Mar 2014 19:05:21 +0100

Hi Yakov,

> elements. The authors should elaborate on what makes them think so.

Let's observe that in order to encapsulate traffic in MPLS in 1000
node network and steer it north and south 1000 nodes need to be able
to support MPLS (or for that matter RSVP-TE and IGP extensions - let's
leave aside inter-area problems).

Contrary if the desire is to steer traffic via north and south nodes
from given ingress node to egress node only those 4 out of those 1000
nodes need to support segment routing. Non of the transit nodes needs
to be SR aware.

I think this makes the deployment and operational difference very clear.

r.

---

From: Yakov Rekhter <[email-masked]>
Date: Thu, 27 Mar 2014 08:26:28 -0700

Robert,

> nodes need to support segment routing. Non of the transit nodes needs

The ability to carry MPLS over transit nodes that are not MPLS aware
is an already solved problem - it is called MPLS-over-GRE (rfc4023). 
Implemented by multiple vendors. Known to be interoperable.
  
Yakov.

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 27 Mar 2014 16:46:40 +0100

Yakov,

The topic here is traffic controll and traffic steering. In MPLS to the
best of my knowledge the only tool to accomplish that is MPLS TE.

That in turn requires RSVP-TE and pretty heavy IGP extensions.

I  am not aware of any deployments of the above MPLS control planes over
GRE nor I am aware of using those when only subset of nodes in your domain
supports required extensions.

If however you are pointing out that to replace LDP one can use GRE I
completly agree.

Thx,
R.

---

From: Ross Callon <[email-masked]>
Date: Thu, 27 Mar 2014 16:28:27 +0000

> extend ipv6 with sr rather than changing dataplane.

To me this paragraph above is the real justification for use of IPv6. (although one could debate whether forwarding based on a not-yet-standardized new extension header constitutes changing the dataplane). 

This points to my main concern with draft-martin-spring-segment-routing-ipv6-use-cases -- specifically that it confuses some perfectly reasonable use cases for SPRING (which would be equally valid with either MPLS or IPv6 implementation), with the choice of data plane. 

Looking at draft-martin-spring-segment-routing-ipv6-use-cases in detail:

Section 2.1 ("IPv6 Segment Routing in the Home Network") does not seem too bad. On the one hand as far as I know the MPLS data plane has not been deployed in home networks -- although to be fair just how my digital cable box and my digital telephone box talk with the network is a detail that I don't need to know and in my role as a homeowner I don't want to know. Also the data speeds needed in the home network might be slow enough that purely software forwarding might be appropriate (at least for now). 

Section 2.2 ("IPv6 Segment Routing in the Access Network") seems to me to be a perfectly reasonable explanation for why SPRING is useful in the access network, along with a statement along the lines of the paragraph above (that some might just not want to use an MPLS data plane). 

The same could be said for sections 2.3, 2.4 and 2.5, which contain perfectly reasonable explanations for why SPRING might be useful in Data Centers, Content Delivery Networks, and Core Networks. However, why the data centers, content delivery networks, and core networks might want to use SPRING, and whether they choose to use an MPLS forwarding plane or an IPv6 forwarding plane, seem like independent issues. Given that a SPRING control plane should be able to work just fine with either data plane, the choice of data plane might come down to issues such as what products get built and what performance can be achieved at what cost.

Ross

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 28 Mar 2014 02:08:10 +0000

Hi Robert,

I think Yakov’s point could be interpreted as “you can use MPLS-SR in conjunction with MPLS-over-GRE to realize the goal that you have mentioned, i.e., only those 4 out of those 1000 nodes need to support segment routing. None of the transit nodes needs to be SR aware”. For more details, please see http://tools.ietf.org/html/draft-xu-spring-islands-connection-over-ip and http://www.ietf.org/proceedings/89/slides/slides-89-spring-0.pptx

Best regards,
Xiaohu

发件人: spring [mailto:[email-masked]] 代表 Robert Raszuk
发送时间: 2014年3月27日 23:47
收件人: Yakov Rekhter
抄送: Alvaro Retana, (aretana); [email-masked]
主题: Re: [spring] WG Adoption Call for draft-martin-spring-segment-routing-ipv6-use-cases

Yakov,

The topic here is traffic controll and traffic steering. In MPLS to the best of my knowledge the only tool to accomplish that is MPLS TE.

I  am not aware of any deployments of the above MPLS control planes over GRE nor I am aware of using those when only subset of nodes in your domain supports required extensions.

If however you are pointing out that to replace LDP one can use GRE I completly agree.

Thx,
R.
On Mar 27, 2014 4:27 PM, "Yakov Rekhter" <[email-masked]<mailto:[email-masked]>> wrote:
Robert,

Yakov.

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

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 28 Mar 2014 09:38:08 +0100

Hi Xu,

Sure you could. You could do a lot of other things as well.

But what does this buy you if you already have dual stack network
which most operators already do for years ?

For clarity I do not consider as sufficient reason fear from one going
into anaphylactic shock at the mention of IPv6 as a valid one.

Cheers,
R.

On Fri, Mar 28, 2014 at 3:08 AM, Xuxiaohu <[email-masked]> wrote:
> Hi Robert,
>
>
>
> I think Yakov’s point could be interpreted as “you can use MPLS-SR in
> conjunction with MPLS-over-GRE to realize the goal that you have mentioned,
> i.e., only those 4 out of those 1000 nodes need to support segment routing.
> None of the transit nodes needs to be SR aware”. For more details, please
> see http://tools.ietf.org/html/draft-xu-spring-islands-connection-over-ip
> and http://www.ietf.org/proceedings/89/slides/slides-89-spring-0.pptx
>
>
>
> Best regards,
>
> Xiaohu
>
>
>
> 主题: Re: [spring] WG Adoption Call for
> draft-martin-spring-segment-routing-ipv6-use-cases
>
>
>
> Yakov,
>
> The topic here is traffic controll and traffic steering. In MPLS to the best
> of my knowledge the only tool to accomplish that is MPLS TE.
>
> I  am not aware of any deployments of the above MPLS control planes over GRE
> nor I am aware of using those when only subset of nodes in your domain

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 28 Mar 2014 09:30:37 +0000

> -----邮件原件-----
> 发送时间: 2014年3月28日 16:38
> 收件人: Xuxiaohu
> 抄送: Yakov Rekhter; [email-masked]; Alvaro Retana, (aretana)
> But what does this buy you if you already have dual stack network which most
> operators already do for years ?

Even you already have a dual stack or IPv6 network, it doesn't mean you can run IPv6-SR directly on it w/o any change to the IPv6 data plane. IMHO, the IPv6-SR approach may be suitable for you to achieve the goal that you have mentioned when those 4 out of those 1000 nodes have been successfully upgraded to support IPv6-SR while the approach of combining MPLS-SR and MPLS-over-GRE could still be considered as a viable way (w/o any change to the data plane) before the above assumption becomes a reality.

Best regards,
Xiaohu

> For clarity I do not consider as sufficient reason fear from one going into
> anaphylactic shock at the mention of IPv6 as a valid one.
> 
> Cheers,
> R.
> 
> 
> > conjunction with MPLS-over-GRE to realize the goal that you have
> > mentioned, i.e., only those 4 out of those 1000 nodes need to support
> segment routing.
> > None of the transit nodes needs to be SR aware”. For more details,
> > please see
> > http://tools.ietf.org/html/draft-xu-spring-islands-connection-over-ip
> > The topic here is traffic controll and traffic steering. In MPLS to
> > the best of my knowledge the only tool to accomplish that is MPLS TE.
> >
> > I  am not aware of any deployments of the above MPLS control planes
> > over GRE nor I am aware of using those when only subset of nodes in
> > your domain supports required extensions.
> >
> >> to support MPLS (or for that matter RSVP-TE and IGP extensions -
> >> let's leave aside inter-area problems).
> >>

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Fri, 28 Mar 2014 09:48:58 +0000

Hi Ross,

> To me this paragraph above is the real justification for use of IPv6. (although one could debate whether forwarding based on a not-yet-standardized new extension header constitutes changing the dat…

well, depends on the change...

the proposal we've made for v6 it's a minor extension of v6 dataplane:
extensions headers are there from rfc2460 (even if the behavior related 
to them has been updated by rfc7045). The SR extension consists on a new 
type of an already existing header. I believe that a v6 network operator
would find it more attractive than a radical change of it's dataplane.

Anyway, I think we are in agreement. 

> Section 2.1 ("IPv6 Segment Routing in the Home Network") does not seem too bad. On the one hand as far as I know the MPLS data plane has not been deployed in home networks -- although to be fair ju…

I don't disagree but if the reality of the infrastructure is based on v6 
dataplane, I will obviously work on a solution that preserves the dataplane.

Realistically, I will never go to a large operator running a v6 networks 
and tell him "ho, btw, just move to mpls and you'll get what you want" 
if his question was "can you make source routing available in v6". 

I'm agnostic in terms of architectures, dataplanes, protocols, etc. but I 
do care about industry reality and customer requirements.

I think you and me agree that we should not let spring become an arena 
where mpls fans and haters try to shoot down each others. 

> Section 2.2 ("IPv6 Segment Routing in the Access Network") seems to me to be a perfectly reasonable explanation for why SPRING is useful in the access network, along with a statement along the line…

yes. The initial paragraphs of section 2 give, imho, a good description of 
the context.

> The same could be said for sections 2.3, 2.4 and 2.5, which contain perfectly reasonable explanations for why SPRING might be useful in Data Centers, Content Delivery Networks, and Core Networks. H…

I fully agree. SPRING charter is about architecture that, once agreed,
is translated into the necessary protocol extensions so to apply it
on existing dataplanes.

Thanks.
s.

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 28 Mar 2014 10:49:25 +0100

Hi Xu,

Today MPLS over GRE support in most implementations I am familiar with
has been supported for applications using MPLS labels as demux to VRFs
(example L2 or L3 VPNs).

It is not directly obvious that one can claim support for transport
MPLS as SID over GRE on existing deployed hardware without requirement
to change existing data plane. I mean of course line rate support in
line cards rather then punting it to slow path.

After all the switching path needs to support following sequence of operation:

- Decapsulation of GRE header
- POP
- Lookup subsequent MPLS label as SID in global table
- Encapsulation in GRE + MAC rewrite

Clearly software upgrade is needed anyway to support SR, but I think
you are making a claim that v6 data plane support will be much harder
then the above.

I think the answer really depends on the particular hardware used.

Regards,
R.

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 28 Mar 2014 11:01:27 +0000

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表 Robert Raszuk
> 发送时间: 2014年3月28日 17:49
> 收件人: Xuxiaohu
> Today MPLS over GRE support in most implementations I am familiar with has
> been supported for applications using MPLS labels as demux to VRFs (example
> L2 or L3 VPNs).

MPLS label can also be used to indicate an outgoing interface. Here a GRE tunnel interface can be looked as an outgoing interface.

Best regards,
Xiaohu

> It is not directly obvious that one can claim support for transport MPLS as SID
> over GRE on existing deployed hardware without requirement to change existing
> data plane. I mean of course line rate support in line cards rather then punting it
> to slow path.

> Clearly software upgrade is needed anyway to support SR, but I think you are
> making a claim that v6 data plane support will be much harder then the above.
> 
> > Even you already have a dual stack or IPv6 network, it doesn't mean you can
> run IPv6-SR directly on it w/o any change to the IPv6 data plane. IMHO, the
> IPv6-SR approach may be suitable for you to achieve the goal that you have
> mentioned when those 4 out of those 1000 nodes have been successfully
> upgraded to support IPv6-SR while the approach of combining MPLS-SR and
> MPLS-over-GRE could still be considered as a viable way (w/o any change to the
> data plane) before the above assumption becomes a reality.
> >
> > Best regards,
> > Xiaohu
> >
> >> For clarity I do not consider as sufficient reason fear from one
> >> going into anaphylactic shock at the mention of IPv6 as a valid one.
> >>
> >> Cheers,
> >> R.
> >>
> >>
> >> > I think Yakov’s point could be interpreted as “you can use MPLS-SR
> >> > in conjunction with MPLS-over-GRE to realize the goal that you have
> >> > http://tools.ietf.org/html/draft-xu-spring-islands-connection-over-
> >> > ip and
> >> > http://www.ietf.org/proceedings/89/slides/slides-89-spring-0.pptx
> >> >
> >> >
> >> >
> >> > Best regards,
> >> >
> >> > Xiaohu
> >> >
> >> >
> >> >
> >> >> > The above assumes that the already available technology, MPLS,
> >> >> > "may not be available or deployable for lack of support on
> >> >> > network elements", yet a brand new technology, a new IPv6
> >> >> > Segment Routing header, will be available, deployable, and
> >> >> > supported on network elements. The authors should elaborate on what
> makes them think so.
> >> >>
> >> >> node network and steer it north and south 1000 nodes need to be
> >> >> able to support MPLS (or for that matter RSVP-TE and IGP
> >> >> extensions - let's leave aside inter-area problems).
> >> >>
> >> >> Contrary if the desire is to steer traffic via north and south
> >> >> nodes from given ingress node to egress node only those 4 out of
> >> >> those 1000 nodes need to support segment routing. Non of the
> >> >> transit nodes needs to be SR aware.
> >> >
> >> > The ability to carry MPLS over transit nodes that are not MPLS
> >> > aware is an already solved problem - it is called MPLS-over-GRE (rfc4023).

---

From: Yakov Rekhter <[email-masked]>
Date: Fri, 28 Mar 2014 10:36:58 -0700

Stefano,

> thanks for your comments. See below.

in-line...

[clipped...]

> for both without claiming one technology is the solution for 

The reality of the industry is that while we have the MPLS dataplane, 
we do *not* have the IPv6 data plane that supports IPv6 SR header.

Yakov.

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Fri, 28 Mar 2014 17:50:16 +0000

Hi Yakov,

> we do *not* have the IPv6 data plane that supports IPv6 SR header.

well (just to be picky) as a matter of fact we do ;-)

Also, introducing SRH processing in existing v6 networks is not a 
major change (nothing compared to a migration to a different 
dataplane).

s.

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 28 Mar 2014 21:42:20 +0100

Hi Yakov,

> we do *not* have the IPv6 data plane that supports IPv6 SR header.

Nor we have much of deployments of IPv6 only control + data plane
which supports MPLS. And IPv6 only networks are real not imaginary.

So there are two options:

- add minor extensions to IPv6 dataplane which can provide control and
encapsulation in a very smooth and gradual way for a number of
applications

- rework, implement and deploy entire load of MPLS control plane to
support IPv6 bearing in mind that MPLS does not have real NNI so at
best it's applicability is limited to closed domains under same
administration

At least to me the above choice is clear.

Best,
R.

---

From: Hannes Gredler <[email-masked]>
Date: Fri, 28 Mar 2014 22:23:33 +0100

hi stefano,

On Fri, Mar 28, 2014 at 05:50:16PM +0000, Stefano Previdi (sprevidi) wrote:
| Hi Yakov,
| 
| On Mar 28, 2014, at 6:36 PM, Yakov Rekhter wrote:
| > Stefano,
| > 
| >> Hi Yakov,
| >> 
| >> thanks for your comments. See below.
| > 
| > in-line...
| > 
| > [clipped...]
| > 
| >> The reality of the industry is that we have both dataplanes so 
| >> it's obvious that we may want to provide similar functionalities 
| >> for both without claiming one technology is the solution for 
| >> everything.
| > 
| > The reality of the industry is that while we have the MPLS dataplane, 
| > we do *not* have the IPv6 data plane that supports IPv6 SR header.
| 
| 
| well (just to be picky) as a matter of fact we do ;-)

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

3) what is the pricetag for the hardware upgrade.

furthermore

4) what is the cost increase for future hardware to support
   a redundant dataplane which does more or less the same thing
   than exisiting hardware.

| Also, introducing SRH processing in existing v6 networks is not a 
| major change (nothing compared to a migration to a different 
| dataplane).

since most v6 hardware implementations i am familiar with, do not have
support for parsing SRH processing, what you are suggesting here
*is* a migration to a different dataplane. (and i am pretty sure you did not
want to tell the list that introducing support for dataplane #4 on the internet
is free of charge for all your employers' v6 products).

/hannes

---

From: Hannes Gredler <[email-masked]>
Date: Fri, 28 Mar 2014 22:45:58 +0100

On Fri, Mar 28, 2014 at 09:42:20PM +0100, Robert Raszuk wrote:
| [ ... ]
| So there are two options:
| 
| - add minor extensions to IPv6 dataplane which can provide control and
| encapsulation in a very smooth and gradual way for a number of
| applications

those are by no means "minor extensions" - those are "major, intrusive
changes which often require hardware re-spins and expensive upgrade cycles"

| - rework, implement and deploy entire load of MPLS control plane to
| support IPv6 bearing in mind that MPLS does not have real NNI so at
| best it's applicability is limited to closed domains under same
| administration

just curious - whats wrong with BGP-LU, BGP-LS as a NNI protocol ?

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 28 Mar 2014 22:48:55 +0100

Hi Hannes,

> *is* a migration to a different dataplane.
+
> changes which often require hardware re-spins and expensive upgrade

I do not think this is a question of build in support for parsing in
hardware SRH.

I am of the opinion that this is a question of having hardware
complaint to RFC6564 recommendation of IPv6 Extension Header Format
which has been around for few years as IETF standards track document.

Clearly if your hardware is not complaint with recommended format of
any new EH your claim is true.

However it seems to me (no matter how great IPv4+MPLS data plane
feature richness is today) that freezing support for current and
future enhancements in IPv6 is a dead end street for both vendors and
operators.

I guess it is ok for market to decide, but it does not seems to be ok
for IETF politics to make such call.

> just curious - whats wrong with BGP-LU, BGP-LS as a NNI protocol ?

Nothing wrong, but those are limited to a same trust domain. While BGP
SAFI 2/1 is a bit of much wider deployment scope.

Cheers,
R.

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Fri, 28 Mar 2014 21:50:19 +0000

Hi Hannes,

> 2) does have IPv6-SR hardware forwarding support.

no, I don't think it's the right question (btw, with such 
kind of questions e would still have an atm internet).

The real question is what is are there operators (service provider 
or enterprise networks) using ipv6 dataplane and for which an 
extension to the ipv6 dataplane brings more benefits than 
constraints.

> 3) what is the pricetag for the hardware upgrade.

if hardware upgrade is needed. Keep in mind that in many cases 
it's not required. First because some vendors already support EHs
and second because SR does not mandate that all routers are upgrade 
but rather only the ones that would process the SRH.

>   a redundant dataplane which does more or less the same thing

cost is an important factor that operators ALREADY takes into 
account.

> support for parsing SRH processing,

we're probably not familiar with the same implementations... 
Again, keep in mind that SRH processing is not required in all
nodes of the network... think about it.

> what you are suggesting here

not really.

s.

> (and i am pretty sure you did not

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Fri, 28 Mar 2014 21:53:18 +0000

> changes which often require hardware re-spins and expensive upgrade cycles"

I don't think the above statement reflects the entire HW industry.

s.

---

From: Hannes Gredler <[email-masked]>
Date: Sat, 29 Mar 2014 01:43:07 +0100

On Fri, Mar 28, 2014 at 10:48:55PM +0100, Robert Raszuk wrote:
| Hi Hannes,
| 
| > since most v6 hardware implementations i am familiar with, do not have
| > support for parsing SRH processing, what you are suggesting here
| > *is* a migration to a different dataplane.
| +
| > those are by no means "minor extensions" - those are "major, intrusive
| > changes which often require hardware re-spins and expensive upgrade
| > cycles"
| 
| I do not think this is a question of build in support for parsing in
| hardware SRH.
| 
| I am of the opinion that this is a question of having hardware
| complaint to RFC6564 recommendation of IPv6 Extension Header Format
| which has been around for few years as IETF standards track document.
| 
| Clearly if your hardware is not complaint with recommended format of
| any new EH your claim is true.
| 
| However it seems to me (no matter how great IPv4+MPLS data plane
| feature richness is today) that freezing support for current and
| future enhancements in IPv6 is a dead end street for both vendors and
| operators.

i am certainly interested in *new, non-redundant* functionality. however not leveraging
technology which has "multi protocol" in its name and as such serves v6 perfectly
well, just for the sake of inventing something "new" does not seem prudent to me.

| I guess it is ok for market to decide, but it does not seems to be ok
| for IETF politics to make such call.

agreed that customers buying kit are making a call on this, not IETF -
however IETF should keep honesty in the discussion.
unfortunately the current way of promoting v6-sr is an 'oversell'.

  "look we have this new dataplane, it comes at (almost) zero cost,
   and is going to be the 'holy-grail of networking'
   (one protocol, one dataplane which does it all)"

so a bit more honesty on the one-off and perpetual cost of adding dataplane #4
on the internet would be appreciated.

| > just curious - whats wrong with BGP-LU, BGP-LS as a NNI protocol ?
| 
| Nothing wrong, but those are limited to a same trust domain. While BGP
| SAFI 2/1 is a bit of much wider deployment scope.

not sure i understand - why is 3107 limited to the same trust domain ?

/hannes

---

From: Hannes Gredler <[email-masked]>
Date: Sat, 29 Mar 2014 01:58:30 +0100

On Fri, Mar 28, 2014 at 09:53:18PM +0000, Stefano Previdi (sprevidi) wrote:
| 
| On Mar 28, 2014, at 10:45 PM, Hannes Gredler wrote:
| 
| > On Fri, Mar 28, 2014 at 09:42:20PM +0100, Robert Raszuk wrote:
| > | [ ... ]
| > | So there are two options:
| > | 
| > | - add minor extensions to IPv6 dataplane which can provide control and
| > | encapsulation in a very smooth and gradual way for a number of
| > | applications
| > 
| > those are by no means "minor extensions" - those are "major, intrusive
| > changes which often require hardware re-spins and expensive upgrade cycles"
| 
| 
| I don't think the above statement reflects the entire HW industry.

again, honesty in the discussion, please.

cherry-picking a particular HW chipset that you may have
which may provides the necessary ucode budget for a few segments
and then declaring victory is insufficient.

just watch your installed base in your co-authoring SP networks (core, edge, DC)
and ask yourself if the hardware upgrade in support of v6-sr is
zero cost or > zero-cost and then look how big the upgrade cost is
and then it becomes obvious that this cannot be glossed over.

/hannes

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Sat, 29 Mar 2014 09:25:51 +0000

> | > On Fri, Mar 28, 2014 at 09:42:20PM +0100, Robert Raszuk wrote:

really, I'm liar now ?

in general I don't reply to people pretending I'm not honest, because
it looks more like an insult.

Nevertheless, it's probably not what you intended but you got thoughts 
confused and the result is a misplaced sentence. It may happen to all 
of us...

> and then declaring victory is insufficient.

I really don't know why you pretend that. It is not the case but since
you seems so convinced, I'm not sure it's worth trying to convince 
you that it's not the case.

> and then it becomes obvious that this cannot be glossed over.

do you really think we didn't do the exercise ? Also, do you really 
think we are planning to do a forklift upgrade of all network 
elements because of SR-IPv6 ? I think I explained multiple times but
just in case: SR-IPv6 requires the node processing the SRH to be 
capable of so, not the entire network.

Bottom line, we do have HW that does not incur a substantial (nor 
significant) penalty because of EHs. We have this in multiple vendor 
contexts and it matches the requirements of the use cases we're 
addressing. 

s.

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 29 Mar 2014 11:35:55 +0100

Hi Hannes,

> on the internet would be appreciated.

Well looking from the side at this I think perhaps both parties are a
bit too far.

As example one side is defending LDP unicast like it's of any
practical value, while the other side dismisses use of simple GRE
encapsulation and proposes in place SR.

Looking at the bigger picture it needs to be observed that networks
are becoming simpler and are moving to carry less state while more and
more services are becoming overlays. With that in mind keeping use of
entire load of MPLS control plane state is not aligned with network
re-architecture trend.

Example: Peter's TeraStream ... look how much MPLS control plane state
he is carrying in the Croatia network and draw your own conclusions ;)

Of course in the case of SR shifting the state to centralized
controllers responsible for inserting proper headers in the packets
does not come for free and there is still a lot to be done on the
management, monitoring and troubleshooting side, but if we rather then
working on this will continue to argue about MPLS and it's signalling
being the only multi-protocol data plane forever we may not get far I
am afraid - but maybe that's the point .....

> | Nothing wrong, but those are limited to the same trust domain. While BGP

In theory it is not, however in practice it is sufficient to observe
how many tier1s, tier2s or even tier3s ISPs and IX-es run 3107 peering
sessions today to answer your dilemma.

Cheers,
R.

---

From: Hannes Gredler <[email-masked]>
Date: Mon, 31 Mar 2014 15:28:57 +0200

hi stefano,

On Sat, Mar 29, 2014 at 09:25:51AM +0000, Stefano Previdi (sprevidi) wrote:
| 
| On Mar 29, 2014, at 1:58 AM, Hannes Gredler wrote:
| 
| > On Fri, Mar 28, 2014 at 09:53:18PM +0000, Stefano Previdi (sprevidi) wrote:
| > | 
| > | On Mar 28, 2014, at 10:45 PM, Hannes Gredler wrote:
| > | 
| > | > On Fri, Mar 28, 2014 at 09:42:20PM +0100, Robert Raszuk wrote:
| > | > | [ ... ]
| > | > | So there are two options:
| > | > | 
| > | > | - add minor extensions to IPv6 dataplane which can provide control and
| > | > | encapsulation in a very smooth and gradual way for a number of
| > | > | applications
| > | > 
| > | > those are by no means "minor extensions" - those are "major, intrusive
| > | > changes which often require hardware re-spins and expensive upgrade cycles"
| > | 
| > | 
| > | I don't think the above statement reflects the entire HW industry.
| > 
| > again, honesty in the discussion, please.
| 
| 
| really, I'm liar now ?

i did not say that; - let me relate a story:

in my "networking childhood" i was in a sales organization
and during teh years there i have got to understand the difference between
"lying" and "not saying the (full) truth".
most often when people try to *sell* something the
use a concious or unconcious form of the latter.

| in general I don't reply to people pretending I'm not honest, because
| it looks more like an insult.
| 
| Nevertheless, it's probably not what you intended but you got thoughts 
| confused and the result is a misplaced sentence. It may happen to all 
| of us...

its a friendly reminder to check the facts again :-)
fact is that thare are performance/cost differences between
a lookup engine which

a) does fixed sized lookups at a fixed offset (MPLS)
b) does best-matching prefix, recursive lookups at variable offsets.
   (IP6-SR)

| 
| > cherry-picking a particular HW chipset that you may have
| > which may provides the necessary ucode budget for a few segments
| > and then declaring victory is insufficient.
| 
| 
| I really don't know why you pretend that. It is not the case but since
| you seems so convinced, I'm not sure it's worth trying to convince 
| you that it's not the case.
 
the cost of processing an additional routing header is not just the
routing header itself. because the routing header is between the IPv6
header and e.g. the TCP header you are also increasing the cost
of accessing TCP header fields for e.g. matching port # inside a firewall filter.

As you know the IP6 header chaining has not been designed for making hardware lookups efficient.
it may well be that because of the potential 100s of additional routing header bytes
the firewall relevant data cannot be accessed hy the lookup engine,
which typically has got a limited view on the header bytes.

this is a example of "not telling the full truth" ... (again no insult)
it may be that you can do the routing lookups, but can you do all together at *scale* ?

1) processing large routing headers
2) firewall lookups
3) at line rate
4) more than one chipset family 
5) differwnt chipset generations

| > just watch your installed base in your co-authoring SP networks (core, edge, DC)
| > and ask yourself if the hardware upgrade in support of v6-sr is
| > zero cost or > zero-cost and then look how big the upgrade cost is
| > and then it becomes obvious that this cannot be glossed over.
| 
| 
| do you really think we didn't do the exercise ? 

i don't know - if i just look at the cost of supporting this on a installed base
e.g. two different ASIC families and two different generations thereof, plus
teh full feature matrix and senior testers which will squeeze the product
i'll get very fast at discomfort.

| Also, do you really think we are planning to do a forklift upgrade of all network 
| elements because of SR-IPv6 ? 

no usually it works such that you:

1. try to insert this at the edge first (this adds value for an immediate customer requirement) and
   therbet carefully hiding the future cost of this (at high speed) in the core.
2. when SPs want to enable it at the core / higher speeds / other platforms
   the true cost unveils.

| I think I explained multiple times but
| just in case: SR-IPv6 requires the node processing the SRH to be 
| capable of so, not the entire network.

understood, arguable the same (loose source routing) can be achieved e.g.
with nested GRE tunnels ... there is no need to add an entirely new dataplane.

| Bottom line, we do have HW that does not incur a substantial (nor 
| significant) penalty because of EHs. We have this in multiple vendor 
| contexts and it matches the requirements of the use cases we're 
| addressing. 

you're saying essentially that additional complexity comes at no cost -
and according to my past experience this is often an indication
that not all facts are on the table. again, no insult, not calling
anybody anything, just an invitation to poke and drill a bit into the
hardware implications of this.

adding dataplanes #4 to the internet is something which is going to be
expensive, and therefore needs to be carefully examined from
different angles.

/hannes

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Mon, 31 Mar 2014 13:48:17 +0000

> | > | > On Fri, Mar 28, 2014 at 09:42:20PM +0100, Robert Raszuk wrote:

I understand your experience... but maybe avoid to generalize it.

> i'll get very fast at discomfort.

since you don't need to support it on all platforms (only on platforms 
where you expect the SRH being processed) the scope is reduced and the
platforms are usually not core devices.

It won't come for free for sure but I know MANY platforms where the hit
is far more than just acceptable.

> 2. when SPs want to enable it at the core / higher speeds / other platforms

but by then, you will probably find more HW being capable of switching 
v6 packets with EHs.

> with nested GRE tunnels ... there is no need to add an entirely new dataplane.

sure, you can also do it by stacking mpls-te-rsvp tunnels after all...

> you're saying essentially that additional complexity comes at no cost -

no. I says that additional complexity comes at acceptable cost for many 
platforms, especially for the use cases currently worked out.

s.