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

From: Jim Guichard <[email-masked]>
Date: Wed, 6 Jul 2011 09:23:48 -0400

Hi Frank,

Reviewing version 04 of the draft I still do not see "vanilla" MPLS
encapsulation given as an option. I would like to suggest adding something
like the following to section 6:

   o  IPv4/IPv6-in-MPLS: SWID is the outer MPLS label. Context within SWID
may be indicated by the next MPLS label in the stack.

On 3/28/11 1:17 PM, "Jim Guichard" <[email-masked]> wrote:

>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]>
>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-masked]]
>>> 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
>>>
>>> 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-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.
>>> >
>>> > 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-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?
>>> >>
>>> >>
>>> >>>
>>> >>> to kick-start the discussion, could you outline the usage
>>scenarios
>>> >> that
>>> >>> would drive the requirements you mention below?
>>> >>>
>>> >
>
>_______________________________________________
>Softwires mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/softwires

---

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Wed, 6 Jul 2011 16:59:30 +0200

Hi Jim,

... works for me (any additional opinions from others?).

In order to get a -05 version out quickly, could you detail the change -
i.e. possibly expand the bullet you propose below with some additional
explanation, like e.g. what would be used as CID for "vanilla MPLS";
propose another row for the table in section 6; etc.

Once we have this, we could quickly compile a -05.

Thanks, Frank

> Sent: Wednesday, July 06, 2011 6:24 AM
> To: Jim Guichard; Frank Brockners (fbrockne)
> Cc: [email-masked]

---

From: Jim Guichard <[email-masked]>
Date: Thu, 7 Jul 2011 08:14:05 -0400

Hi Paco,

Comments inline ..

On 7/7/11 3:39 AM, "Paco Cortes" <[email-masked]> wrote:

>Hi Jim,
>
>can you clarify with the upper case part of your proposal?
>
>  o  IPv4/IPv6-in-MPLS: SWID is the outer MPLS label. CONTEXT WITHIN swid
>MAY BE INDICATED BY THE NEXT mpls LABEL IN THE STACK.
>
>You are speaking about a fully different case than the "MPLS VPN" case
>currently in the draft, where the VPN label (i.e. the inner MPLS
>label) is the SWID.
>To me it sounds like a very significant change to gi-ds-lite, as you
>seem to be proposing that traffic inside a softwire can be further
>"split" into contexts with some meaning (differentiated handling?) by
>the AFTR.

Jim> yes, exactly this. In this case the SWID is the top label and the
next label in the stack is the CID.

>
>Regarding the overall discussion in this thread (sorry I didn't answer
>earlier), I disagree on the MPLS VPN case to be an overkill. In many
>cases, the one-label overhead in part of the path is fully justified
>by the gained operational simplicity (given by relaying on MP-BGP and
>possibly CE-PE protocol for "softwire" setup and control signalling).
>Also, as already mentioned by Yiu, it enables a very simple
>implementation of overlapping IP addresses. Although this could also
>be possible with your "vanilla MPLS" proposal, it would require some
>kind of additional (proprietary?) implementation both in Gateway and
>AFTR.

Jim> let me clarify .. I completely agree that VPN should be included. My
overkill comment was more to do with the fact that in some situations it
is not necessary to deploy the full MPLS VPN machinery.
>
>This said, I do see the point on adding "vanilla MPLS" as possible
>embodiment to the draft. There may be simple scenarios where it is
>fully sufficient.
>Maybe adding a bullet to section 6 like:
>
>  o  IPv4/IPv6-in-MPLS: SWID is the MPLS label.
>
>Would this be ok for you?

Jim> I would like to see SWID = top label, CID = next label in stack
noting that the SWID label is not PHP.
>
>br,
>  Paco
>
>
>2011/7/6 Frank Brockners (fbrockne) <[email-masked]>:
>> Hi Jim,
>>

---

From: Jim Guichard <[email-masked]>
Date: Thu, 7 Jul 2011 08:24:19 -0400

Hi Frank,

Suggested changes as follows:

Section 5:

- first bullet currently states "The softwire between the Gateway and the
AFTR is created at system startup time and stays up active all time". I
would like to allow flexibility to initiate a SW at any point in time.
Given this could this bullet be changed to the following:

"The softwire between the Gateway and the AFTR MAY be created at system
startup time OR dynamically established on-demand"

Section 6:

- add the following bullet:
   o  IPv4/IPv6-in-MPLS: SWID is the top MPLS label. CID is the next MPLS
label in the stack. The AFTR may use the CID locally to identify context
within a given inbound softwire.

---

From: Jim Guichard <[email-masked]>
Date: Thu, 7 Jul 2011 09:54:25 -0400

Yes, I agree that this change makes sense and provides more flexibility ..
thanks

On 7/7/11 9:48 AM, "Paco Cortes" <[email-masked]> wrote:

>Thanks Jim, now I get it.
>You were aiming at (outer label= SWID; inner label = CID), and I
>misunderstood it as (outer label = SWID, inner label = something_new;
>IP @ = CID).
>Speaking about "vanilla MPLS" I was actually expecting (only label =
>SWID; IP @ = CID)
>
>It sounds sensible to me.
>But do you really want to restrict the vanilla MPLS case to (outer
>label = SWID, inner label = CID)? In such case, the user IP@ is pure
>overhead.
>
>Wouldn't it be better to cover both cases in one go? This could be
>done with a change like:
>
>- SWID is the top MPLS label. CID might be the next MPLS
>label in the stack, if present, or the AD's IP address.
>
>But don't take this email as an opposition to your last proposal to
>Frank. If nobody is interested on (single label=SWID, IP@=CID), then I
>will not be the one pushing for it.
>
>br,
>  Paco
>
>
>
>
>
>2011/7/7 Jim Guichard <[email-masked]>:
>> Hi Paco,
>>
>> Comments inline ..
>>
>>>>> >What I would like to see is the ability to use TE without VPN's. I
>>>>>do
>>>>> not
>>>>> >text for the draft but would like to agree on this alias before
>>>>>doing
>>>>> so
>>>>> >..
>>>>> >
>>>>> >>> Subject: Re: [Softwires]
>>>>>draft-ietf-softwire-gateway-init-ds-list-
>>>>> 02
>>>>> >>>
>>>>> >>> > 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 -

---

From: Paco Cortes <[email-masked]>
Date: Thu, 7 Jul 2011 09:39:55 +0200

Hi Jim,

br,
  Paco

---

From: Paco Cortes <[email-masked]>
Date: Thu, 7 Jul 2011 15:48:44 +0200

br,
  Paco

---

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Thu, 7 Jul 2011 23:52:40 +0200

Works for me (and thanks for the suggested text). If I don't hear
otherwise, I'll post an -05 version by tomorrow including Jim's
suggestions.

Thanks, Frank

> Sent: Thursday, July 07, 2011 6:54 AM
> To: Paco Cortes
> Cc: [email-masked]; Frank Brockners (fbrockne)
> Yes, I agree that this change makes sense and provides more
flexibility
> >>>  o  IPv4/IPv6-in-MPLS: SWID is the outer MPLS label. CONTEXT
WITHIN
> >>>swid
> >> Jim> let me clarify .. I completely agree that VPN should be
> included.
> >>My
> >>>>>    o  IPv4/IPv6-in-MPLS: SWID is the outer MPLS label. Context
> within
> >>>>> SWID
> >>>>> >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
> >>>>> >>why is VPN "overkill" (kind of delicate wording these
days...)?
> TE
> >>>>> could
> >>>>> >>> 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
> >>>>> >>> > not. The current draft-ietf-softwire-gateway-init-ds-list-
> 03
> >>>>> doesn't
> >>>>> >>> > restrict things to IP tunneling. The draft already allows
> for
> >>>>> MPLS
> >>>>> >>> > 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
> >>>>> >>> > On multicast: Don't fully follow your thought below. Do
you
> >>>>> consider
> >>>>> >>> > running multicast over the softwire between AFTR and
> Gateway?
> >>>> The
> >>>>> >>> > draft-brockners-softwire-mcast-gi-ds-lite-00) so far
assume
> >>>>> >>> >> 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
> >>>>> >>> >> be absent from the draft. If an operator has MPLS why
> restrict
> >>>>> them
> >>>>> >>> to
> >>>>> >>> >> IP
> >>>>> >>> >> tunneling?
> >>>>> >>> >>
> >>>>> >>> >>
> >>>>> >>> >>>

---

From: "Lee, Yiu" <[email-masked]>
Date: Thu, 7 Jul 2011 21:59:05 +0000

Hi Frank,

Did Jim and Paco metnion to also allow IP for the CID? So, I suggest to
modify Section 6:

Section 6:

- add the following bullet:
   o  IPv4/IPv6-in-MPLS: SWID is the top MPLS label. CID is the next MPLS
label in the stack or IPv4 address if the AFTR is the last hop of the LSP.
The AFTR may use the CID locally to identify context within a given
inbound softwire.

---

From: Paco Cortes <[email-masked]>
Date: Fri, 8 Jul 2011 10:49:19 +0200

Hi Yiu,

I believe that the conclusion of the discussion between Jim and me is
that the following bullet should be added to section 6:

 o  IPv4/IPv6-in-MPLS: SWID is the top MPLS label. CID might be the next MPLS
label in the stack, if present, or the AD's IP address.

What do you think of it?
In your suggested text, I find the usage of the term "context"
confusing. It is already well defined in the draft what a CID is.
And the text "if the AFTR is the last hop of the LSP" is redundant, isn't it?

br,
  Paco

---

From: Jim Guichard <[email-masked]>
Date: Fri, 8 Jul 2011 08:12:37 -0400

I think the other necessary change is for section 5. Could you agree to change the 1st bullet to allow for dynamic establishment of softwires? It seems restrictive to mandate that they be pre-established.

Jim Guichard

CCIE #2069

Sent from my iphone

---

From: "Lee, Yiu" <[email-masked]>
Date: Fri, 8 Jul 2011 12:37:10 +0000

Hi Paco,

I am good this is cleaner.

Thanks,
Yiu

---

From: "Lee, Yiu" <[email-masked]>
Date: Fri, 8 Jul 2011 12:38:03 +0000

I support that. I am sorry if I get you misunderstood I didn't support
Section 5.

On 7/8/11 8:12 AM, "Jim Guichard" <[email-masked]> wrote:

>I think the other necessary change is for section 5. Could you agree to
>change the 1st bullet to allow for dynamic establishment of softwires? It
>seems restrictive to mandate that they be pre-established.

---

From: Paco Cortes <[email-masked]>
Date: Fri, 8 Jul 2011 15:04:39 +0200

I also support Jim's proposed change to section 5

---

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Sat, 9 Jul 2011 00:51:28 +0200

FYI. I just posted draft-ietf-softwire-gateway-init-ds-lite-05
reflecting the discussion (including the two requested changes).

Regards, Frank

> From: Paco Cortes [mailto:[email-masked]]
> Sent: Friday, July 08, 2011 6:05 AM
> To: Lee, Yiu
> Cc: Jim Guichard; Frank Brockners (fbrockne); [email-masked]