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] > 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]> 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] https://www.ietf.org/mailman/listinfo/softwires
