On Mar 29, 2011, at 10:14 AM, Lee, Yiu wrote: > 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 ;-) )
Simple typo, I typed "IPv6" when I meant "IPv4" below, apologies. The documents a refer to clearly are for the IPv4 case though. So, the "L2-Aware" NAT, or "ds-extra-lite" in the documents below is a CGN which uses a VLAN, MPLS Label, PPP session, Ethernet MAC address, etc... I think we should continue to describe this generally rather than try and list every single possible L2 construct than can carry IPv4 and use it to plug into a NAT binding. - Mark > > Regards, > /Yiu > > From: Mark Townsley <[email protected]> > Date: Mon, 28 Mar 2011 23:24:57 +0200 > To: Frank Brockners <[email protected]> > Cc: <[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] >>> 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
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
