[Status] 答复: 答复: Status of Spring

[Xuxiaohu <[e-mail]>]

> -----邮件原件-----
> 发件人: [e-mail] [mailto:[e-mail]] 代表 Robert Raszuk
> 发送时间: 2013年10月11日 15:26
> 收件人: Xuxiaohu
> 抄送: AshwoodsmithPeter; [e-mail]
> 主题: Re: 答复: [Status] Status of Spring
> 
> 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.

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

> Best,
> R.
> 
> 
> On Fri, Oct 11, 2013 at 3:50 AM, Xuxiaohu <[e-mail]> wrote:
> > Robert,
> >
> >> -----邮件原件-----
> >> 发件人: [e-mail] [mailto:[e-mail]] 代表
> >> Robert Raszuk
> >> 发送时间: 2013年10月11日 4:58
> >> 收件人: AshwoodsmithPeter
> >> 抄送: [e-mail]
> >> 主题: Re: [Status] Status of Spring
> >>
> >> 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.
> >
> > 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
> >
> >> 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.
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> 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