Subject: [spring] The rationale of draft-xu-spring-islands-connection-over-ip

From: Xuxiaohu <[email-masked]>
Date: Fri, 4 Jul 2014 03:12:06 +0000

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

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 4 Jul 2014 11:28:41 +0200

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-masked]> wrote:
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 4 Jul 2014 09:47:14 +0000

Hi Robert,

Your suggestion looks good to me. In fact, the encapsulation capability advertisement part (i.e., using a new sub-TLV of the ISIS capability TLV ) was previously contained in the original draft but has been removed before submitting it to the IETF as an informational draft. I had planned to submit another draft talking about the encapsulation capability advertisement once this use case draft is accepted. If the WG consensus is to cover these two parts in one doc, it's fine to me.

Best regards,
Xiaohu

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Friday, July 04, 2014 5:29 PM
To: Xuxiaohu
Cc: <[email-masked]>
Subject: Re: [spring] The rationale of draft-xu-spring-islands-connection-over-ip

Hi Xu,

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.