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

From: Jim Guichard <[email-masked]>
Date: Tue, 15 Mar 2011 11:03:56 -0400

Authors,

Some comments on this draft as follows that I would like to have discussed on this alias:

 *   The draft is currently specific to point-to-point tunnels but I believe this needs to be extended to cover bi-directional tunnels and possibly point-to-multipoint tunnels also.
 *   IP-in-MPLS tunneling is not covered in the draft and this is clearly necessary so that PW and RSVP-TE tunnels can be used.
 *   The CID needs to be extended to allow for 20-bit transport label and the ability to stack labels below that (such as a VPN label).
 *   The draft should allow for the CID to be signaled between the gateways and whatever software terminating device holds a specific service function.
 *   Section 6 of the draft needs to define MPLS LSP so that PW and RSVP-TE are possible.

---

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Thu, 17 Mar 2011 18:23:13 +0100

Jim,

to kick-start the discussion, could you outline the usage scenarios that
would drive the requirements you mention below?

Thanks, Frank

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of Jim Guichard
> Sent: Tuesday, March 15, 2011 4:04 PM
> To: [email-masked]
> Subject: [Softwires] draft-ietf-softwire-gateway-init-ds-list-02
> 
> Authors,
> 
>  *   The draft is currently specific to point-to-point tunnels but I
> believe this needs to be extended to cover bi-directional tunnels and
> possibly point-to-multipoint tunnels also.
>  *   IP-in-MPLS tunneling is not covered in the draft and this is
> clearly necessary so that PW and RSVP-TE tunnels can be used.
>  *   The CID needs to be extended to allow for 20-bit transport label
> and the ability to stack labels below that (such as a VPN label).
>  *   The draft should allow for the CID to be signaled between the
> gateways and whatever software terminating device holds a specific
> service function.
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires

---

From: Jim Guichard <[email-masked]>
Date: Thu, 24 Mar 2011 16:42:30 -0400

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?

---

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Fri, 25 Mar 2011 10:16:55 +0100

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

> From: Jim Guichard [mailto:[email-masked]]
> Sent: Thursday, March 24, 2011 9:43 PM
> 
> Hi Frank,
>

---

From: "Lee, Yiu" <[email-masked]>
Date: Fri, 25 Mar 2011 14:16:05 +0000

Hi Jim,

>transport between Gateway and AFTR using MPLS VPNs.

For the simple MPLS case w/o VPN, it will limit the GW not to be able to
serve overlapped address space.

>draft-brockners-softwire-mcast-gi-ds-lite-00) so far assume that this

I agree with Frank. Multicast in gi-ds-lite should be simple and not tied
to p2mp mpls. Our proposal is very simple. Our assumption is that the
operator should have far fewer gateways than customer devices, so the GW
can create an IPv4 over ANY tunnel and run multicast on it. From the GW,
it could do RFC 4541.

/Yiu

---

From: Jim Guichard <[email-masked]>
Date: Fri, 25 Mar 2011 15:02:54 -0400

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

---

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Sun, 27 Mar 2011 13:53:18 +0200

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

> Sent: Friday, March 25, 2011 8:03 PM
> To: Frank Brockners (fbrockne)
> Cc: [email-masked]
> Subject: Re: [Softwires] draft-ietf-softwire-gateway-init-ds-list-02
> 
> >> 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
> >> 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

---

From: Jim Guichard <[email-masked]>
Date: Mon, 28 Mar 2011 13:17:31 -0400

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 ..

---

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Mon, 28 Mar 2011 20:28:26 +0200

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.

Thanks, Frank

> Sent: Monday, March 28, 2011 7:18 PM
> want to be forced to deploy VPN infrastructure in this case. RSVP-TE
is
> an
> >> 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
> >>
> >> > fully agreed that MPLS should not be absent from the draft, and
it
> >is
> >> > 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 -
> >> > encapsulations, though so far there's always been a push in the
WG
> >> (and
> >> > (e.g. L2TPv3 was dropped from the list of encaps, because we
could
> >do

---

From: Mark Townsley <[email-masked]>
Date: Mon, 28 Mar 2011 23:24:57 +0200

> 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

---

From: "Lee, Yiu" <[email-masked]>
Date: Tue, 29 Mar 2011 08:14:10 +0000

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 <[email-masked]<mailto:[email-masked]>>
Date: Mon, 28 Mar 2011 23:24:57 +0200
To: Frank Brockners <[email-masked]<mailto:[email-masked]>>
Cc: <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Softwires] draft-ietf-softwire-gateway-init-ds-list-02

Hi Jim,

- Mark

Thanks, Frank

-----Original Message-----
From: Jim Guichard [mailto:[email-masked]]
Sent: Monday, March 28, 2011 7:18 PM
To: Frank Brockners (fbrockne)
Cc: [email-masked]<mailto:[email-masked]>
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-masked]<mailto:[email-masked]>>
wrote:

Jim,

why is VPN "overkill" (kind of delicate wording these days...)? TE
could
also be combined with MPLS VPNs.

Thanks, Frank

-----Original Message-----
From: Jim Guichard [mailto:[email-masked]]
Sent: Friday, March 25, 2011 8:03 PM
To: Frank Brockners (fbrockne)
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Softwires]

Jim Guichard

CCIE #2069

Sent from my iphone

On Mar 25, 2011, at 5:17, "Frank Brockners (fbrockne)"
<[email-masked]<mailto:[email-masked]>> 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.

also in 3GPP SA2) to keep the number of encapsulations to a
minimum

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-masked]]
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?

_______________________________________________
Softwires mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/softwires

_______________________________________________ Softwires mailing list [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/softwires

---

From: Mark Townsley <[email-masked]>
Date: Tue, 29 Mar 2011 10:52:55 +0200

> 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…

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-masked]>
> To: Frank Brockners <[email-masked]>
> Cc: <[email-masked]>
>>>>> <[email-masked]> wrote:
>>>>> 
>>>>>> Hi Jim,
>>>>>> 
> _______________________________________________ Softwires mailing list [email-masked] https://www.ietf.org/mailman/listinfo/softwires

---

From: "Lee, Yiu" <[email-masked]>
Date: Tue, 29 Mar 2011 08:59:22 +0000

Hi Mark,

I fully agree with your comment about the L2 encap. However, gi-ds-lite somehow allows gre and mpls-vpn label for the NAT binding. I guess the WG should decide what to include and what not in this draft. For example: Jim suggested to include the plain mpls label.

/Yiu

From: Mark Townsley <[email-masked]<mailto:[email-masked]>>
Date: Tue, 29 Mar 2011 10:52:55 +0200
To: Microsoft Office User <[email-masked]<mailto:[email-masked]>>
Cc: Frank Brockners <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Softwires] draft-ietf-softwire-gateway-init-ds-list-02

---

From: Mark Townsley <[email-masked]>
Date: Tue, 29 Mar 2011 11:31:15 +0200

> I fully agree with your comment about the L2 encap. However, gi-ds-lite somehow allows gre and mpls-vpn label for the NAT binding. I guess the WG should decide what to include and what not in this…

Ultimately, you can use anything that correlates directly back to the other side of the tunnel where addresses are being assigned. TE Tunnel makes perfect sense, as does a VPN label, VLAN, or anything else at your disposal.

This begs the question though, if you aren't using IPv4 and IPv6 at the same time, where is the "dual-stack" part of "dual-stack-lite" in it?

The heart of the "lite" part of "dual-stack-lite" is capitalizing on traffic separation that the NAT is cognizant of, allowing overlapping of the private IPv4 space and potentially eliminating the NAT on the other side of the tunnel. That doesn't require IPv6, and is perfectly fine to define, but if we're going to do that I think we need to consider it more generally and it may end up as part of Behave as much as it would Softwires. 

- Mark

> To: Microsoft Office User <[email-masked]>
> Cc: Frank Brockners <[email-masked]>, "[email-masked]" <[email-masked]>