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
