Hi Mark, I interpreted it differently, I think we are talking about IPv4 (not IPv6) over MPLS and the CGN will use the MPLS label for the NAT binding. For the comment about IPvX over IPvY in softwire, GI-DS-lite is more than IPvX over IPvY, but it got advanced (by mistake ;-) )
Regards, /Yiu From: Mark Townsley <[email protected]<mailto:[email protected]>> Date: Mon, 28 Mar 2011 23:24:57 +0200 To: Frank Brockners <[email protected]<mailto:[email protected]>> Cc: <[email protected]<mailto:[email protected]>> Subject: Re: [Softwires] draft-ietf-softwire-gateway-init-ds-list-02 On Mar 28, 2011, at 8:28 PM, Frank Brockners (fbrockne) wrote: Hi Jim, ok - we can also get some additional feedback from the WG meeting (I've added a bullet asking for a discussion on "plain" IP-over-MPLS encapsulation support to the update on draft-ietf-softwire-gateway-init-ds-lite). BTW/ - it would help the discussion if you could provide the paragraph you're thinking of to the alias. It sounds like you are talking about an IPv6 over MPLS tunnel plugged into the NAT binding of a CGN. More generally, I think this looks like what is described in these documents: http://tools.ietf.org/html/draft-miles-behave-l2nat-00 http://tools.ietf.org/html/draft-arkko-dual-stack-extra-lite-05 Softwires has generally been about IPvX over IPvY, which is at least one reason why neither of these documents have been advanced here in the past. - Mark Thanks, Frank -----Original Message----- From: Jim Guichard [mailto:[email protected]] Sent: Monday, March 28, 2011 7:18 PM To: Frank Brockners (fbrockne) Cc: [email protected]<mailto:[email protected]> Subject: Re: [Softwires] draft-ietf-softwire-gateway-init-ds-list-02 Hi Frank, What I would like to see is the ability to use TE without VPN's. I do not want to be forced to deploy VPN infrastructure in this case. RSVP-TE is an important piece of the puzzle as it provides the ability to steer traffic based upon policy that I may wish to enforce. I would be happy to supply text for the draft but would like to agree on this alias before doing so .. On 3/27/11 7:53 AM, "Frank Brockners (fbrockne)" <[email protected]<mailto:[email protected]>> wrote: Jim, why is VPN "overkill" (kind of delicate wording these days...)? TE could also be combined with MPLS VPNs. Would also be interested in other folks' thoughts on the need for "plain" IP-over-MPLS tunnels. Thanks, Frank -----Original Message----- From: Jim Guichard [mailto:[email protected]] Sent: Friday, March 25, 2011 8:03 PM To: Frank Brockners (fbrockne) Cc: [email protected]<mailto:[email protected]> Subject: Re: [Softwires] draft-ietf-softwire-gateway-init-ds-list-02 VPN is overkill imho plus i want the ability to engineer traffic paths and for this i need TE Jim Guichard Principal Networking Architect IPG CTO Office Juniper Networks CCIE #2069 Sent from my iphone On Mar 25, 2011, at 5:17, "Frank Brockners (fbrockne)" <[email protected]<mailto:[email protected]>> wrote: Hi Jim, fully agreed that MPLS should not be absent from the draft, and it is not. The current draft-ietf-softwire-gateway-init-ds-list-03 doesn't restrict things to IP tunneling. The draft already allows for MPLS transport between Gateway and AFTR using MPLS VPNs. Hence the question: For the use cases you have in mind, couldn't we just use MPLS VPNs (possibly even point-to-point with just two PEs in a VPN - Gateway and the AFTR)? Personally I've nothing against additional encapsulations, though so far there's always been a push in the WG (and also in 3GPP SA2) to keep the number of encapsulations to a minimum (e.g. L2TPv3 was dropped from the list of encaps, because we could do the very same thing with GRE). On multicast: Don't fully follow your thought below. Do you consider running multicast over the softwire between AFTR and Gateway? The multicast considerations for GI-DS-lite (see draft-brockners-softwire-mcast-gi-ds-lite-00) so far assume that this would not be the case. Thanks, Frank -----Original Message----- From: Jim Guichard [mailto:[email protected]] Sent: Thursday, March 24, 2011 9:43 PM Hi Frank, bi-directional tunnels are necessary if you wish for traffic flows to take the same path in both directions across the network. It is possible to use point-to-point but this is cumbersome to deploy. Point-to-multipoint may be necessary for multicast. Clearly IP-in-MPLS tunneling is a fundamental requirement that should not be absent from the draft. If an operator has MPLS why restrict them to IP tunneling? to kick-start the discussion, could you outline the usage scenarios that would drive the requirements you mention below? _______________________________________________ Softwires mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/softwires _______________________________________________ Softwires mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
