Hi co-chairs, The rationale of this draft is simple and clear: for a given label binding of FEC X learnt though IGPs, if the IGP next-hop for FEC X is a non-SPRING node (i.e., just a normal IGP router which supports IP forwarding), that label binding should be treated as it was remotely learnt from the originating router of that label binding, just as if it was learnt from a remote LDP peer or BGP peer. In other words, the packet with such label as the top label should be tunneled towards that remote peer via some type of IP-based tunnel.
Such procedure is very useful for incremental deployment purpose and some special use cases and therefore it should be specified somewhere. Therefore we co-authors request you to issue a WG adoption poll on this draft. Thanks. Best regards, Xiaohu (on behalf of all co-authors) -----Original Message----- From: Xuxiaohu Sent: Monday, September 01, 2014 11:12 AM To: '<[email protected]>' Subject: RE: Request WG adoption polling//FW: [spring] The rationale of draft-xu-spring-islands-connection-over-ip Hi co-chairs, We co-authors believe this revision (http://tools.ietf.org/html/draft-xu-spring-islands-connection-over-ip-02) is ready for WG adoption. Would you please start an adoption poll on this doc? Best regards, Xiaohu (on behalf of all co-authors) > -----Original Message----- > From: Xuxiaohu > Sent: Tuesday, August 05, 2014 11:59 AM > To: <[email protected]> > Subject: Request WG adoption polling//FW: [spring] The rationale of > draft-xu-spring-islands-connection-over-ip > > Hi co-chairs, > > We have addressed all comments received so far in the following > revision > (http://tools.ietf.org/html/draft-xu-spring-islands-connection-over-ip > -01). Note that how to dynamically obtain the encapsulation > capabilities is defined in separate docs (e.g., > http://tools.ietf.org/html/draft-xu-isis-encapsulation-cap-00) > > We co-authors believe the current version is ready for WG adoption. > > Best regards, > Xiaohu(on behalf of all co-authors) > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of Robert > Raszuk > Sent: Friday, July 04, 2014 5:29 PM > To: Xuxiaohu > Cc: <[email protected]> > Subject: Re: [spring] The rationale of > draft-xu-spring-islands-connection-over-ip > > Hi Xu, > > We discussed this work before, however I have a new question ... > > It is an informational draft so you relay on proper configuration of > RS nodes in the islands. > > Note that today you may have out of the box SR node supporting IPv4, > IPv6 (say without SR) + MPLS. So you must select your operational > default encapsulation and very likely such encapsulation will differ > per next SR destination ! > > I therefor find it not really practical to recommend manual/i2rs/xml > configuration and choice of encapsulation on a per SR node basis. > > I would therefor advise if there would be architectural consensus to > go forward with the proposed in the draft idea to turn it into > standards track and add a flag and encap info in SR advertisement > itself indicating that given SR node may be reachable say via GRE, > L2TPv3 or VXLAN encaps. > > That way your objective is accomplished via full protocol automation > with minimal need for any per SR src/dst node manual config. > > Best, > R. > > > > > > > > > > > > On Fri, Jul 4, 2014 at 5:12 AM, Xuxiaohu <[email protected]> wrote: > > Hi all, > > > > This draft > (http://tools.ietf.org/html/draft-xu-spring-islands-connection-over-ip > -00) describes a use case about interconnecting spring islands over IP > networks. The rationale for this draft is as follows: > > > > Suppose LSR A and LSR B are separated by an IP network. Assume LSR A > receives from LSR B a label binding L for a given FEC (e.g., one of > LSR B's loopback addresses) via T-LDP or L-BGP, when LSR A wants to > forward a MPLS packet targeted for that FEC, it could forward that > MPLS packet through an IP-based tunnel towards LSR B. In contrast, if > LSR A receives the above label binding originated by LSR B via IS-IS > or OSPF, it could be looked as if this label binding was learnt from a > remote BGP or LDP peer. As such, LSR A could forward the MPLS packet > targeted for that FEC over an IP-based tunnel towards LSR B as well. > > > > In fact, one of the claimed advantages of IPv6-SR is that it doesn't > > require to > upgrade all routers in the networks. With the above approach, we can > achieve the same effect in the MPLS-SR. > > > > Best regards, > > Xiaohu > > > > _______________________________________________ > > spring mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/spring _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
