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. 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] > 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]> > 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] > >> 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
