Subject: [Status] Charter security text

From: Stewart Bryant <[email-masked]>
Date: Thu, 10 Oct 2013 12:37:13 +0100

SPRINGers

In response to a number of IESG blocking comments I have updated
the security text in the charter to say:

"There is an assumed trust model such that any node
imposing an explicit route on a packet is assumed to
be allowed to do so, however administrative and trust
boundaries may strip explicit routes from a packet.
For each data plane technology that SPRING specifies,
a security analysis must be provided showing how protection
is provided against an attacker disrupting the network by
maliciously injecting SPRING packets."

I do not know yet whether this has been accepted.

Stewart

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 10 Oct 2013 17:53:37 +0200

All,

On the topic of MPLS vs IPv6 - one being L2 hence more secure then the
other (L3) I would like to observe that any decently managed network
would already today prohibit to accept any external packets which have
as destination an infrastructure address of such network. That is the
basic protection scheme against DOS/DDOS attacks to the
infrastructure.

When such packet is detected it should be dropped - not "stripped from
explicit routes" like the above charter update would tend to suggest.

As some may recall in the past we have been working on automating such
ACLs installation based in internal IGP addresses on all border
routers under same administrative domain within single AS or number of
ASes to ease operational burden. Not sure if all vendors support such
automation today.

I think what needs to be understood that segment routing is not
internet wide source routing technology. It is carefully crafted path
engineering and packet encapsulation technique within controlled set
of domains which really do not compare to the original issues and
security concerns of source routing.

Best,
R.

On Thu, Oct 10, 2013 at 1:37 PM, Stewart Bryant <[email-masked]> wrote:
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 10 Oct 2013 19:52:29 +0100

The SPRING charter was discussed on the telechat today. We have
a small issue with the OAM and management deliverable text that
I am working with Benoit.

The largest sticking point is the IPv6 text, where a number of
ADs are concerned that given the previous security issues with
source routing, they are concerned at the difficulty we face
significant difficulty designing a satisfactory IPv6 solution.
There was some discussion on the call about limited network
scope, but concern was expressed that once the feature was
in the wild, the scope would be difficult to control.

Jari who is the main discuss holder will work with us over
the next couple of days to try to get some text that will allow
us to go forward. The goal is to get the charter into external
review by Monday night so it can go to external review
on Tuesday and be on the following telechat for approval
by Vancouver.

Currently SPRING is of course a BOF and I have asked Alvaro
Retana, and John Scudder to chair the BOF in Vanouver.

If the charter text still has unresolved issues by the time
we meet in Vancouver, then they should be the first
priority on the agenda.

- Stewart

---

From: AshwoodsmithPeter <[email-masked]>
Date: Thu, 10 Oct 2013 19:31:12 +0000

I can understand the concern. Making a new option for V6 exposes it to misuse by the endpoints as was previously the case for v4.

What is wrong with an approach that is MPLS first and then an evolution of MPLS? That would work for IPV6/V4 or whatever else goes on top.

I mean is it heresy to suggest that we should evolve MPLS in the future? 

Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stewart Bryant
Sent: Thursday, October 10, 2013 2:52 PM
To: Adrian Farrel; [email-masked]
Cc: Joel Jaeggli; Benoit Claise; Jari Arkko; John G. Scudder; Alvaro Retana
Subject: [Status] Status of Spring

- Stewart

---

From: John E Drake <[email-masked]>
Date: Thu, 10 Oct 2013 19:41:54 +0000

Peter,

I completely agree that we should simply focus on MPLS because, as you note, it will support IPv6 as well as IPv4.

However, it is not clear that MPLS will need to be evolved in order to support Spring.  See, for example, http://tools.ietf.org/html/draft-gredler-spring-mpls-00

Yours Irrespectively,

John

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> AshwoodsmithPeter
> Sent: Thursday, October 10, 2013 12:31 PM
> To: [email-masked]; Adrian Farrel; [email-masked]
> Cc: EXT - [email-masked]; Benoit Claise; Jari Arkko; John G. Scudder; Alvaro
> Retana
> Subject: Re: [Status] Status of Spring
> 
> I can understand the concern. Making a new option for V6 exposes it to misuse
> by the endpoints as was previously the case for v4.
> 
> What is wrong with an approach that is MPLS first and then an evolution of
> MPLS? That would work for IPV6/V4 or whatever else goes on top.
> 
> The SPRING charter was discussed on the telechat today. We have a small
> issue with the OAM and management deliverable text that I am working with
> Benoit.
> 
> The largest sticking point is the IPv6 text, where a number of ADs are
> concerned that given the previous security issues with source routing, they are
> concerned at the difficulty we face significant difficulty designing a satisfactory
> IPv6 solution.
> There was some discussion on the call about limited network scope, but
> concern was expressed that once the feature was in the wild, the scope would
> be difficult to control.
> 
> Jari who is the main discuss holder will work with us over the next couple of
> days to try to get some text that will allow us to go forward. The goal is to get
> the charter into external review by Monday night so it can go to external
> review on Tuesday and be on the following telechat for approval by Vancouver.
> 
> Currently SPRING is of course a BOF and I have asked Alvaro Retana, and John
> Scudder to chair the BOF in Vanouver.
> 
> If the charter text still has unresolved issues by the time we meet in
> Vancouver, then they should be the first priority on the agenda.
> 
> - Stewart
> 
> 
> 
>

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 10 Oct 2013 22:04:38 +0200

Hi John,

Simple question ...

If I have no MPLS in any of the data center how can I use segment
routing in those environments ?

Is your answer to deploy MPLS for transport in all data centers or
just not use segment routing there at all ?

Many thx,
R.

On Thu, Oct 10, 2013 at 9:41 PM, John E Drake <[email-masked]> wrote:
>> Stewart Bryant

---

From: AshwoodsmithPeter <[email-masked]>
Date: Thu, 10 Oct 2013 20:48:53 +0000

Robert,

Most of the TOR's and core DC switches have MPLS data planes already built into the ASICs, it's just turned off. It would not be terribly difficult actually to have a Hypervisor attach an n hop or so label stack and have the TOR and Spine switches do pop and forward without having to enable all the MPLS control planes. In my lab for example I could easily do that with most of my 20 odd  switches of different flavors and I'm sure that's true of most of the other vendor's DC gear/switches too. Of course you'd want a new form of control (SDN comes to mind), but that's true if you use V6 options, MPLS, ACL 'games' or whatever. The other advantage of MPLS in that context is that when the frame finally arrives at a VRF it can use MPLS IPVPN (or L2VPN) data plane semantics instead of something new that needs new hardware. The main constraint as far as I am aware is the limited stack depth available on initial push by some ASICs. Of course that's not a problem for the Hypervisor to VRF direction, or Hypervisor to Hypervisor but it is a problem for a VRF to Hypervisor (origin is often an ASIC). Of course in the DC you are going limited hops anyway so that may not be a concern.

However an area that does concern me is mobile backhaul. In that case an MPLS label stack is potentially a significant overhead and we may want to address it in some future version. I have a bit of real SP data (PDU size distributions) that shows it compared to other types of SP links which I can show in Vancouver if there is interest.

Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Thursday, October 10, 2013 4:05 PM
To: John E Drake
Cc: AshwoodsmithPeter; [email-masked]; Adrian Farrel; [email-masked]; EXT - [email-masked]; Benoit Claise; Jari Arkko; John G. Scudder; Alvaro Retana
Subject: Re: [Status] Status of Spring

Hi John,

Simple question ...

Many thx,
R.

---

From: AshwoodsmithPeter <[email-masked]>
Date: Thu, 10 Oct 2013 20:51:30 +0000

Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Thursday, October 10, 2013 4:05 PM
To: John E Drake
Cc: AshwoodsmithPeter; [email-masked]; Adrian Farrel; [email-masked]; EXT - [email-masked]; Benoit Claise; Jari Arkko; John G. Scudder; Alvaro Retana
Subject: Re: [Status] Status of Spring

Hi John,

Simple question ...

Many thx,
R.

---

From: "John G. Scudder" <[email-masked]>
Date: Thu, 10 Oct 2013 16:53:55 -0400

Folks, 

Please refrain from cc'ing the entire universe on your messages to [email-masked]. If your recipient list is too long, your message gets held for administrative approval, slowing its delivery and mildly annoying the mailing list administrator. I'm not sure what the magic number is, but clearly ten recipients is enough to put you in the doghouse.

Thanks,

--John

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 10 Oct 2013 22:58:14 +0200

Peter,

I admire your optimism stating that it will not be terribly difficult
to enable linux kernel support for MPLS encapsulation as well as build
IGP or LDP signalling into stock hypervisors. I think we could
continue this topic when linux supports all of the above.

However the issue is not with MPLS in the hypervisor or not. The issue
is with lack of summarization and enforcement of exact FEC match which
MPLS architecture mandates. With IP transport and subnet lookup all
works just fine without any exact match needed of FEC to next hop.

Said this one needs to clearly decouple MPLS use for application demux
(L2VPN or L3VPN) from MPLS use for transport. The latter is pretty
much dead end as far as I can see while the former works very well and
it would be a mistake to propose to change or replace it.

Best regards,
R.

---

From: Jari Arkko <[email-masked]>
Date: Fri, 11 Oct 2013 00:03:45 +0300

Thanks Stewart and others.

I wanted to add one clarification and some more technical discussion.

> us to go forward. 

I would really like to work with you to get this resolved. I see the issue, as I think do others, but I need your help in the WG to figure out what to do about it. I do not currently have a good idea, but I am sure we'll resolve it somehow. Some of you have already offered help - thanks. 

To provide a bit more context why just saying that we'll use it in closed networks is unlikely to work:

The MPLS case was easy because these networks are naturally restricted to specific areas, and there is no way for a random person in some other part of the Internet to send you packets with MPLS labels.

The basic problem with IP is that when someone defines a new source-routing header solution and applies it in network X, it does not affect just X. The code will be on various devices - with RH0 we had it on BSD, Linux, various brands of routers, maybe even on hosts, etc. Often turned on by default, leaving vulnerabilities open in many networks.

We could say that the feature MUST be by default off and can only be enabled upon explicit request from the network manager. However, if I have a thousand devices in my network I start to worry that at least one of them has accidentally enabled the feature. So now that device could potentially reflect traffic sent to it from the outside to an internal destination. This could be used to subvert firewall policies, DoS attacks on nodes not visible from the Internet, etc. As a result of this worry I now have to turn on filtering on the border of my network for the new routing header. Is there a way around this?

Also, the charter is clear that you are wishing for at least an eventual inter-AS solution. That raises the bar.

In any case, I could completely off base with the above - I have not read your proposed solutions and maybe you are thinking of something completely different, or have already found the clever solutions to the problem. I'm happy to learn more :-)

Jari

---

From: "John G. Scudder" <[email-masked]>
Date: Thu, 10 Oct 2013 17:14:54 -0400

> Also, the charter is clear that you are wishing for at least an eventual inter-AS solution. That raises the bar.

The charter is also clear [*] that the trust model presumes a single administration, so the inter-AS solution applies to multiple ASes under a single administration. This was already covered in the exchange between Joel and Stewart earlier today.

I do agree that IPv6 is less likely to fail safe if this assumption is violated, though.

--John

[*] Well, clearish -- I thought it was more explicit in earlier iterations. But still clear enough.

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 10 Oct 2013 23:17:32 +0200

Hi Jari,

> As a result of this worry I now have to turn on filtering on the border of my
> network for the new routing header. Is there a way around this?

Let me clarify my previous message reg such filtering ...

The filtering to your infrastructure addresses should be applied for
both IPv4 and IPv6 packets. SR v6 header would be a regular v6 header
(not new routing header) with perhaps few additional extension headers
embedded to indicate the strict or loose transit nodes.

So filtering applied on the edge of the network (which should be there
regardless of SR or not) would be identical to normal case and would
in fact effectively filter out any external attempt to insert SR
routed packet into your network just based on the standard v6 header
destination IP address.

The only price to pay for this is to set bgp next hop to self if you
want segment route the transit traffic, but this for one is pretty
common today and also same would be required for MPLS encapsulation
anyway.

Best regards,
R.

---

From: joel jaeggli <[email-masked]>
Date: Thu, 10 Oct 2013 15:58:10 -0700

> I can understand the concern. Making a new option for V6 exposes it to misuse by the endpoints as was previously the case for v4.

as was previously the case for ipv6 as well.

sleeping dragons aren't safe dragons.

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 11 Oct 2013 01:50:39 +0000

Robert,

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表
> Robert Raszuk
> 发送时间: 2013年10月11日 4:58
> 收件人: AshwoodsmithPeter
> 抄送: [email-masked]
> 主题: Re: [Status] Status of Spring
> 
> Peter,
> 

Unless you want to specify an explicit path by using a list of IPv6 addresses in a source routed packet, rather than a list of short segment IDs, you would face almost the same issue with MPLS. In other words, you would have to allow each hop along the explicit path to know which IPv6 address a given segment ID stands for. Remember that these segment IDs are non-aggregatable as well.

Best regards,
Xiaohu

> > Most of the TOR's and core DC switches have MPLS data planes already built
> into the ASICs, it's just turned off. It would not be terribly difficult actually to
> have a Hypervisor attach an n hop or so label stack and have the TOR and Spine
> switches do pop and forward without having to enable all the MPLS control
> planes. In my lab for example I could easily do that with most of my 20 odd
> switches of different flavors and I'm sure that's true of most of the other
> vendor's DC gear/switches too. Of course you'd want a new form of control
> (SDN comes to mind), but that's true if you use V6 options, MPLS, ACL 'games'
> or whatever. The other advantage of MPLS in that context is that when the
> frame finally arrives at a VRF it can use MPLS IPVPN (or L2VPN) data plane
> semantics instead of something new that needs new hardware. The main
> constraint as far as I am aware is the limited stack depth available on initial
> push by some ASICs. Of course that's not a problem for the Hypervisor to
>   VRF direction, or Hypervisor to Hypervisor but it is a problem for a VRF to
> Hypervisor (origin is often an ASIC). Of course in the DC you are going limited
> hops anyway so that may not be a concern.
> >
> > However an area that does concern me is mobile backhaul. In that case an
> MPLS label stack is potentially a significant overhead and we may want to
> address it in some future version. I have a bit of real SP data (PDU size
> distributions) that shows it compared to other types of SP links which I can
> show in Vancouver if there is interest.
> >
> > Peter
> >
> >
> >
> > Cc: AshwoodsmithPeter; [email-masked]; Adrian Farrel; [email-masked];
> EXT - [email-masked]; Benoit Claise; Jari Arkko; John G. Scudder; Alvaro
> Retana
> >> I completely agree that we should simply focus on MPLS because, as you
> note, it will support IPv6 as well as IPv4.
> >>
> >> However, it is not clear that MPLS will need to be evolved in order to support
> Spring.  See, for example,
> http://tools.ietf.org/html/draft-gredler-spring-mpls-00
> >>
> >> Yours Irrespectively,
> >>
> >> John
> >>

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 11 Oct 2013 09:26:09 +0200

Xiaohu,

The difference is that endpoint of SR encap does not need to be a SID.
It can be normal BGP next hop fully able to be aggregated/summarized.

Few key SIDs as transit nodes or service nodes are all ok to be not
aggregatable.

If required we need to modify the SR architecture if it enforces today
that end point must be express as SID.

Best,
R.

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 11 Oct 2013 09:36:20 +0000

Robert,

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表 Robert Raszuk
> 发送时间: 2013年10月11日 15:26
> 收件人: Xuxiaohu
> 抄送: AshwoodsmithPeter; [email-masked]
> 主题: Re: 答复: [Status] Status of Spring
> 
> Xiaohu,
> 

Did you mean that the final destination address would be stored in a separate field other than the bottom of segment ID list? 

BTW, it seem that you could realize the above goal as well by using the MPLS label stack technology. For example, assume source node A wants to send a packet to destination node Z via an explicit path {X, Y, Z},  A could encapsulate the packet first with GRE encapsulation with tunnel source of A and tunnel destination of Z, and then append segment labels for Y and X in turn to the GRE encapsulated packet. Once that packet arrives at Y, Y would strip the segment label for Y and then forward the decapsualted GRE packet to Z.

Best regards,
Xiaohu

> > Unless you want to specify an explicit path by using a list of IPv6 addresses in
> a source routed packet, rather than a list of short segment IDs, you would face
> almost the same issue with MPLS. In other words, you would have to allow each
> hop along the explicit path to know which IPv6 address a given segment ID
> stands for. Remember that these segment IDs are non-aggregatable as well.
> >
> > Best regards,
> > Xiaohu
> >
> >> > From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Robert
> >> Raszuk
> >> >>> From: [email-masked] [mailto:[email-masked]] On
> Behalf
> >> Of
> >> >>> AshwoodsmithPeter
> >> >>> From: [email-masked] [mailto:[email-masked]] On
> Behalf
> >> Of
> >> >>> Stewart Bryant
> >> >>> concerned that given the previous security issues with source routing,
> they
> >> are
> >> >>> days to try to get some text that will allow us to go forward. The goal is
> to
> >> get

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 11 Oct 2013 10:15:30 +0000

Robert,

BTW, Did you refer to http://tools.ietf.org/html/draft-filsfils-rtgwg-segment-routing-00 by SR architecture?  I have not found any statement as you said in that doc. Instead, in section 3.1.  Illustration of that doc, it said the endpoint is assigned a node segment ID and that segment ID is placed at the bottom of the segment ID list.

Xiaohu

---

From: Hannes Gredler <[email-masked]>
Date: Fri, 11 Oct 2013 13:07:24 +0200

robert,

On Thu, Oct 10, 2013 at 10:58:14PM +0200, Robert Raszuk wrote:
| I admire your optimism stating that it will not be terribly difficult
| to enable linux kernel support for MPLS encapsulation as well as build
| IGP or LDP signalling into stock hypervisors. I think we could
| continue this topic when linux supports all of the above.

please have a look at
http://sourceforge.net/apps/mediawiki/mpls-linux/index.php?title=Main_Page
 
| However the issue is not with MPLS in the hypervisor or not. The issue
| is with lack of summarization and enforcement of exact FEC match which
| MPLS architecture mandates. With IP transport and subnet lookup all
| works just fine without any exact match needed of FEC to next hop.

can you point me to the text which says so.
i could not find such a claim in rfc3031 ?

/hannes

| Said this one needs to clearly decouple MPLS use for application demux
| (L2VPN or L3VPN) from MPLS use for transport. The latter is pretty
| much dead end as far as I can see while the former works very well and
| it would be a mistake to propose to change or replace it.

| On Thu, Oct 10, 2013 at 10:48 PM, AshwoodsmithPeter
| <[email-masked]> wrote:
| > Robert,
| >
| > Most of the TOR's and core DC switches have MPLS data planes already built into the ASICs, it's just turned off. It would not be terribly difficult actually to have a Hypervisor attach an n hop or so label stack and have the TOR and Spine switches do pop and forward without having to enable all the MPLS control planes. In my lab for example I could easily do that with most of my 20 odd  switches of different flavors and I'm sure that's true of most of the other vendor's DC gear/switches too. Of course you'd want a new form of control (SDN comes to mind), but that's true if you use V6 options, MPLS, ACL 'games' or whatever. The other advantage of MPLS in that context is that when the frame finally arrives at a VRF it can use MPLS IPVPN (or L2VPN) data plane semantics instead of something new that needs new hardware. The main constraint as far as I am aware is the limited stack depth available on initial push by some ASICs. Of course that's not a problem for the Hypervisor to
|   VRF direction, or Hypervisor to Hypervisor but it is a problem for a VRF to Hypervisor (origin is often an ASIC). Of course in the DC you are going limited hops anyway so that may not be a concern.
| >
| > However an area that does concern me is mobile backhaul. In that case an MPLS label stack is potentially a significant overhead and we may want to address it in some future version. I have a bit of real SP data (PDU size distributions) that shows it compared to other types of SP links which I can show in Vancouver if there is interest.
| >
| > Peter
| >
| >
| >
| > -----Original Message-----
| > From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
| > Sent: Thursday, October 10, 2013 4:05 PM
| > To: John E Drake
| > Cc: AshwoodsmithPeter; [email-masked]; Adrian Farrel; [email-masked]; EXT - [email-masked]; Benoit Claise; Jari Arkko; John G. Scudder; Alvaro Retana
| > Subject: Re: [Status] Status of Spring
| >
| > Hi John,
| >
| > Simple question ...
| >
| > If I have no MPLS in any of the data center how can I use segment
| > routing in those environments ?
| >
| > Is your answer to deploy MPLS for transport in all data centers or
| > just not use segment routing there at all ?
| >
| > Many thx,
| > R.
| >
| >
| > On Thu, Oct 10, 2013 at 9:41 PM, John E Drake <[email-masked]> wrote:
| >> Peter,
| >>
| >> I completely agree that we should simply focus on MPLS because, as you note, it will support IPv6 as well as IPv4.
| >>
| >> However, it is not clear that MPLS will need to be evolved in order to support Spring.  See, for example, http://tools.ietf.org/html/draft-gredler-spring-mpls-00
| >>
| >> Yours Irrespectively,
| >>
| >> John
| >>
| >>> -----Original Message-----
| >>> From: [email-masked] [mailto:[email-masked]] On Behalf Of
| >>> AshwoodsmithPeter
| >>> Sent: Thursday, October 10, 2013 12:31 PM
| >>> To: [email-masked]; Adrian Farrel; [email-masked]
| >>> Cc: EXT - [email-masked]; Benoit Claise; Jari Arkko; John G. Scudder; Alvaro
| >>> Retana
| >>> Subject: Re: [Status] Status of Spring
| >>>
| >>> I can understand the concern. Making a new option for V6 exposes it to misuse
| >>> by the endpoints as was previously the case for v4.
| >>>
| >>> What is wrong with an approach that is MPLS first and then an evolution of
| >>> MPLS? That would work for IPV6/V4 or whatever else goes on top.
| >>>
| >>> I mean is it heresy to suggest that we should evolve MPLS in the future?
| >>>
| >>> Peter
| >>>
| >>> -----Original Message-----
| >>> From: [email-masked] [mailto:[email-masked]] On Behalf Of
| >>> Stewart Bryant
| >>> Sent: Thursday, October 10, 2013 2:52 PM
| >>> To: Adrian Farrel; [email-masked]
| >>> Cc: Joel Jaeggli; Benoit Claise; Jari Arkko; John G. Scudder; Alvaro Retana
| >>> Subject: [Status] Status of Spring
| >>>
| >>>
| >>> The SPRING charter was discussed on the telechat today. We have a small
| >>> issue with the OAM and management deliverable text that I am working with
| >>> Benoit.
| >>>
| >>> The largest sticking point is the IPv6 text, where a number of ADs are
| >>> concerned that given the previous security issues with source routing, they are
| >>> concerned at the difficulty we face significant difficulty designing a satisfactory
| >>> IPv6 solution.
| >>> There was some discussion on the call about limited network scope, but
| >>> concern was expressed that once the feature was in the wild, the scope would
| >>> be difficult to control.
| >>>
| >>> Jari who is the main discuss holder will work with us over the next couple of
| >>> days to try to get some text that will allow us to go forward. The goal is to get
| >>> the charter into external review by Monday night so it can go to external
| >>> review on Tuesday and be on the following telechat for approval by Vancouver.
| >>>
| >>> Currently SPRING is of course a BOF and I have asked Alvaro Retana, and John
| >>> Scudder to chair the BOF in Vanouver.
| >>>
| >>> If the charter text still has unresolved issues by the time we meet in
| >>> Vancouver, then they should be the first priority on the agenda.
| >>>
| >>> - Stewart
| >>>
| >>>
| >>>
| >>>
| >>> _______________________________________________
| >>> status mailing list
| >>> [email-masked]
| >>> https://www.ietf.org/mailman/listinfo/status
| >>> _______________________________________________
| >>> status mailing list
| >>> [email-masked]
| >>> https://www.ietf.org/mailman/listinfo/status
| >>>
| >>
| >>
| >> _______________________________________________
| >> status mailing list
| >> [email-masked]
| >> https://www.ietf.org/mailman/listinfo/status
| _______________________________________________
| status mailing list
| [email-masked]
| https://www.ietf.org/mailman/listinfo/status
| 
|

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 11 Oct 2013 13:50:22 +0100

On 10/10/2013 22:03, Jari Arkko wrote:
> We could say that the feature MUST be by default off and can only be enabled upon explicit request from the network manager.
> However, if I have a thousand devices in my network I start to worry that at least one of them has accidentally enabled the feature.
Are we talking routers or devices here?

In the routing world many bad things can happen if a router is 
misconfigured,
so I am not sure how this is special?

>   So now that device could potentially reflect traffic sent to it from the outside to an internal destination.
>   This could be used to subvert firewall policies, DoS attacks on nodes not visible from the Internet, etc. As a result of this worry I now have to turn on filtering on the border of my network for the new routing header. Is there a way around this?
I doubt it, although presumably you will not have enabled forwarding
on the new header unless you intended to forward on it.

Off by default is a good starting position, but is not charter text.
> Also, the charter is clear that you are wishing for at least an eventual inter-AS solution. That raises the bar.
The interest here is that people run multiple AS in a DC. We are not 
talking about this being
run on the Internet core.
> In any case, I could completely off base with the above - I have not read your proposed solutions and maybe you are thinking of something completely different, or have already found the clever solu…

I am unaware of a solution sitting on the table, but the discussion is 
about the charter
text describing what people are going to work on. It is not a detailed 
evaluation of
a solution.

So what we are looking for here is charter text that provides the 
critical success factors that
determine whether a solution can be sent for publication.

Stewart

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 11 Oct 2013 15:00:02 +0200

Hannes,

> http://sourceforge.net/apps/mediawiki/mpls-linux/index.php?title=Main_Page

Are we talking lab/experiments or production ? Please point me to any
linux distribution which officially supports this. Also please point
me to the official linux kernel which supports mpls kernel project.

> i could not find such a claim in rfc3031 ?

Not in rfc3031 but in rfc5036 .. pretty much the only practical
signalling protocol for mpls transport (not an overlay mpls
signalling):

   "Prefix SHOULD NOT use the label for forwarding unless its routing
    table contains an entry that exactly matches the FEC Element."

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
r.

---

From: Hannes Gredler <[email-masked]>
Date: Fri, 11 Oct 2013 16:11:23 +0200

On Fri, Oct 11, 2013 at 03:00:02PM +0200, Robert Raszuk wrote:
| > please have a look at
| > http://sourceforge.net/apps/mediawiki/mpls-linux/index.php?title=Main_Page
| 
| [ ... ] Please point me to any
| linux distribution which officially supports this. Also please point
| me to the official linux kernel which supports mpls kernel project.

i am not sure if there is such a thing as an "official linux kernel"
  of course there is linus' and his lieutenants git trees - however
  every major linux distribution pulls from there and adds a ton
  of patches to it. - the linux MPLS extensions are basically
  kernel patches plus userspace utilizities - nothing more.
  so if you want to get it to work - get your favourite
  (linux from scratch) distro and apply the patches ...
  i did it with 'gentoo' linux and as far as i can tell it works fine
  even with l2vpn services on top of the transport LSPs.
    note that there are also pre-cooked debian ISO images with everything
    applied if you do not want to compile your kernel by yourself.

| > can you point me to the text which says so.
| > i could not find such a claim in rfc3031 ?
| 
| Not in rfc3031 but in rfc5036 .. pretty much the only practical
| signalling protocol for mpls transport (not an overlay mpls
| signalling):
| 
|    "Prefix SHOULD NOT use the label for forwarding unless its routing
|     table contains an entry that exactly matches the FEC Element."

oh yes, and this is indeed problematic ... and its fixed here:
http://www.ietf.org/rfc/rfc5283.txt

---

From: Xuxiaohu <[email-masked]>
Date: Sat, 12 Oct 2013 03:05:33 +0000

> Hannes Gredler
> 发送时间: 2013年10月11日 22:11
> 收件人: Robert Raszuk
> 抄送: [email-masked]; AshwoodsmithPeter

Great that LDP has removed that limitation. When using ISIS or OSPF for label distribution purpose, we should follow the same principle. In this way, the scalability of IGP would not be impacted by the SPRING architecture.

Best regards,
Xiaohu

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 12 Oct 2013 09:35:09 +0200

LDP has not removed any limitation. If you use MPLS you still need to
send all host FECs in LDP. There is no magic transit nodes are not
aware about your overlay application .. they can not demux on their
own. Label must be specific to the transport endpoint.

RFC5283 just reduces IGP and RIB size - not LDP:

   "Note that LDP re-advertises to its peers the specific FEC element
   FEC1, and not the aggregated prefix found in the IP RIB during the
   longest-match search."

If you use IP encapsulation you don't need any additional signalling
to send your overlay application between any two end points in the
network yet benefit from natural aggregation of IP subnets at any
point.

Likewise when SR SIDs are MPLS labels they can not be aggregated. When
SR SIDs are IP addresses they can be nicely aggregated for example at
the IGP or AS area boundaries.

r.

---

From: Xuxiaohu <[email-masked]>
Date: Sat, 12 Oct 2013 08:25:40 +0000

> 发送时间: 2013年10月12日 15:35
> 抄送: Hannes Gredler; [email-masked]; AshwoodsmithPeter

I meant "...Prefix SHOULD NOT use the label for forwarding unless its routing table contains an entry that exactly matches the FEC Element." by "limitation".

> own. Label must be specific to the transport endpoint.

Exactly. FECs can't be aggregated and therefore the MPLS forwarding table size is not reduced.

> network yet benefit from natural aggregation of IP subnets at any

The concern is whether a list of IPv6 addresses or a list of short IDs is used in a packet to represent an explicit source path. If the former is the case, I agree with you. However, it seem that is not the recommended option. On the contrary, the latter is. See the following statement quoted from http://datatracker.ietf.org/doc/draft-filsfils-rtgwg-segment-routing:

" ...The main differences from the IPv6 source route model are:  The source route is encoded as an ordered list of segments instead of IP addresses. "

> the IGP or AS area boundaries.

As I had illustrated in a previous email with an example, if you want to reduce the MPLS forwarding table size, you could replace the innermost LSP towards the final tunnel destination (i.e., the last hop of the explicit path) with an IP-based tunnel while still using LSPs to represent the paths to the remaining hops of the explicit path. In this way, there is no need to create label bindings for those large amount of final tunnel endpoints.

For example, in the following topology where the metrics of all links are the same, assume A want to send a packet X to Z via a explicit route {C, E}, the packet sent from A would look as: |MPLS label for C|GRE tunnel to E|packet X|.

A-----B-------D-----E
     \   /
       C

Best regards,
Xiaohu

> > Great that LDP has removed that limitation. When using ISIS or OSPF for label
> distribution purpose, we should follow the same principle. In this way, the
> scalability of IGP would not be impacted by the SPRING architecture.
> >
> > Best regards,
> > Xiaohu
> >

---

From: Xuxiaohu <[email-masked]>
Date: Sat, 12 Oct 2013 08:32:29 +0000

> 发件人: Xuxiaohu
> 发送时间: 2013年10月12日 16:26
> 收件人: 'Robert Raszuk'
> 主题: re: [Status] Status of Spring
> 
> 
> 
> > -----邮件原件-----
> I meant "...Prefix SHOULD NOT use the label for forwarding unless its routing
> table contains an entry that exactly matches the FEC Element." by "limitation".
> 
> The concern is whether a list of IPv6 addresses or a list of short IDs is used in a
> packet to represent an explicit source path. If the former is the case, I agree with
> you. However, it seem that is not the recommended option. On the contrary,
> the latter is. See the following statement quoted from
> http://datatracker.ietf.org/doc/draft-filsfils-rtgwg-segment-routing:
> 
> " ...The main differences from the IPv6 source route model are:  The source
> route is encoded as an ordered list of segments instead of IP addresses. "
> 
> As I had illustrated in a previous email with an example, if you want to reduce
> the MPLS forwarding table size, you could replace the innermost LSP towards
> the final tunnel destination (i.e., the last hop of the explicit path) with an
> IP-based tunnel while still using LSPs to represent the paths to the remaining
> hops of the explicit path. In this way, there is no need to create label bindings
> for those large amount of final tunnel endpoints.
> 
> For example, in the following topology where the metrics of all links are the
> same, assume A want to send a packet X to Z via a explicit route {C, E}, the
> packet sent from A would look as: |MPLS label for C|GRE tunnel to E|packet X|.

s/Z/E

---

From: Xuxiaohu <[email-masked]>
Date: Sat, 12 Oct 2013 10:01:28 +0000

In fact, the idea as mentioned before (i.e., replacing the innermost LSP of a stacked LSP tunnel with an IP-based tunnel) is not only suitable for SPRING, but also useful for the traditional MPLS paradigm in multi-area/level or even multi-domain scenarios.

For example, as stated in section 5.1.6. Inter-Area Routing of the seamless MPLS draft (http://datatracker.ietf.org/doc/draft-ietf-mpls-seamless-mpls/?include_text=1),

   "This architecture results in carrying all loopbacks of all nodes
   except pure P nodes (AN, AGN, ABR and core PE) in labeled BGP, e.g.
   there will be in the order of 100.000 routes in labeled BGP when
   approaching the stated scalability goal."

with the above idea, there is no need to advertise such a large amount of labeled BGP host routes across area/level boundaries anymore. Instead, it only requires to advertise aggregated BGP routes (w/o label) across area/level boundaries. 

Best regards,
Xiaohu

> -----邮件原件-----
> 发件人: Xuxiaohu
> 发送时间: 2013年10月12日 16:32
> 收件人: Xuxiaohu; Robert Raszuk
> 主题: 答复: [Status] Status of Spring
> 
> 
> 
> > -----邮件原件-----
> > 发件人: Xuxiaohu
> > 发送时间: 2013年10月12日 16:26
> > 收件人: 'Robert Raszuk'
> > Exactly. FECs can't be aggregated and therefore the MPLS forwarding table
> size
> > is not reduced.
> >

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 12 Oct 2013 18:30:48 +0200

Hi Xuxiahou,

> As I had illustrated in a previous email with an example, if you want to
> reduce the MPLS forwarding table size, you could replace the innermost
> LSP towards the final tunnel destination (i.e., the last hop of the explicit
> path) with an IP-based tunnel while still using LSPs to represent the paths
> to the remaining hops of the explicit path. In this way, there is no need to
> create label bindings for those large amount of final tunnel endpoints.

And my observation is that if you already remove inner most LSP and
replace it with IP encapsulation there is no need to add any
subsequent LSPs as well .. just in the case of need for steering or
service chaining add few extension headers.

Why would I run LDP if I IP encapsulation provides me with the
functional alternative and less control plane state ?

All compatible with each other, no need for extra heavy weight
signalling like you would need with RSVP-TE for path engineering.

Cheers,
R.

---

From: Xuxiaohu <[email-masked]>
Date: Mon, 14 Oct 2013 01:42:47 +0000

Robert,

> 发送时间: 2013年10月13日 0:31

Are you suggesting containing an ordered list of IPv6 addresses, rather than short segment IDs in a packet to indicate an explicit path? 

> functional alternative and less control plane state ?

Outer LSPs could be RSVP-TE LSPs or SPRING-based LSPs as well which provide you more features in addition to path connectivity.

Best regards,
Xiaohu