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] >> 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
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
