Re: [Softwires] draft-ietf-softwire-gateway-init-ds-list-02

[Mark Townsley <[e-mail]>]

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 <[e-mail]>
> Date: Mon, 28 Mar 2011 23:24:57 +0200
> To: Frank Brockners <[e-mail]>
> Cc: <[e-mail]>
> 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:[e-mail]]
>>> Sent: Monday, March 28, 2011 7:18 PM
>>> To: Frank Brockners (fbrockne)
>>> Cc: [e-mail]
>>> 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)" <[e-mail]>
>>> 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:[e-mail]]
>>>>> Sent: Friday, March 25, 2011 8:03 PM
>>>>> To: Frank Brockners (fbrockne)
>>>>> Cc: [e-mail]
>>>>> 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)"
>>>>> <[e-mail]> 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:[e-mail]]
>>>>>>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/softwires
> 
> _______________________________________________ Softwires mailing list [e-mail] https://www.ietf.org/mailman/listinfo/softwires