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

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 ;-) )

Regards,
/Yiu

From: Mark Townsley <mark@townsley.net<mailto:mark@townsley.net>>
Date: Mon, 28 Mar 2011 23:24:57 +0200
To: Frank Brockners <fbrockne@cisco.com<mailto:fbrockne@cisco.com>>
Cc: <softwires@ietf.org<mailto:softwires@ietf.org>>
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:jguichard@juniper.net]
Sent: Monday, March 28, 2011 7:18 PM
To: Frank Brockners (fbrockne)
Cc: softwires@ietf.org<mailto:softwires@ietf.org>
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)" <fbrockne@cisco.com<mailto:fbrockne@cisco.com>>
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:jguichard@juniper.net]
Sent: Friday, March 25, 2011 8:03 PM
To: Frank Brockners (fbrockne)
Cc: softwires@ietf.org<mailto:softwires@ietf.org>
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)"
<fbrockne@cisco.com<mailto:fbrockne@cisco.com>> 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:jguichard@juniper.net]
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
Softwires@ietf.org<mailto:Softwires@ietf.org>
https://www.ietf.org/mailman/listinfo/softwires

_______________________________________________ Softwires mailing list Softwires@ietf.org<mailto:Softwires@ietf.org> https://www.ietf.org/mailman/listinfo/softwires