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

[Mark Townsley <[e-mail]>]

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