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

Reply via email to