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

[Xuxiaohu <[e-mail]>]

Robert,

> -----邮件原件-----
> 发件人: [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.

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

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