Re: [Status] Status of Spring

[Hannes Gredler <[e-mail]>]

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
| <[e-mail]> 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: [e-mail] [mailto:[e-mail]] On Behalf Of Robert Raszuk
| > Sent: Thursday, October 10, 2013 4:05 PM
| > To: John E Drake
| > Cc: AshwoodsmithPeter; [e-mail]; Adrian Farrel; [e-mail]; EXT - [e-mail]; 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 <[e-mail]> 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: [e-mail] [mailto:[e-mail]] On Behalf Of
| >>> AshwoodsmithPeter
| >>> Sent: Thursday, October 10, 2013 12:31 PM
| >>> To: [e-mail]; Adrian Farrel; [e-mail]
| >>> Cc: EXT - [e-mail]; 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: [e-mail] [mailto:[e-mail]] On Behalf Of
| >>> Stewart Bryant
| >>> Sent: Thursday, October 10, 2013 2:52 PM
| >>> To: Adrian Farrel; [e-mail]
| >>> 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
| >>> [e-mail]
| >>> https://www.ietf.org/mailman/listinfo/status
| >>> _______________________________________________
| >>> status mailing list
| >>> [e-mail]
| >>> https://www.ietf.org/mailman/listinfo/status
| >>>
| >>
| >>
| >> _______________________________________________
| >> status mailing list
| >> [e-mail]
| >> https://www.ietf.org/mailman/listinfo/status
| _______________________________________________
| status mailing list
| [e-mail]
| https://www.ietf.org/mailman/listinfo/status
| 
|