Subject: Re: [Softwires] Synchronization of work between draft-ietf-softwire-gateway-init-ds-lite and draft-zhou-softwire-ds-lite-p2p

From: "Yiu L. Lee" <[email-masked]>
Date: Tue, 14 Sep 2010 08:06:24 -0400

(Bring this discussion to the softwire mailing list)

Hi Frank,

We discussed this in the last softwire meeting. I want to make two points
here:

1. Not every DSL operator has GRE infrastructure today. Engineering GRE
tunnel sometimes could be trickier (arguably more expensive) than simple
IP-in-IP.

2. The Flow Label is used for the CPE to carry IPv4 over IPv6. This CPE’s IP
Address is often different from the PD prefix to the hosts and is used for
packets sourced from the CPE. If the network wants to apply flow policy to
the hosts (or the whole PD), the network can still do so. I don’t see why
this will cause any problem.

In the end, we want to propose an simple alternative rather than enforcing
the operators to use GRE or MPLS.

Any thought?

Thanks,
Yiu

On 9/14/10 7:50 AM, "Frank Brockners (fbrockne)" <[email-masked]> wrote:

> Hi Cathy,
>  
> per our discussion back in Maastricht, IMHO/ we should investigate the
> proposal as well as alternative options a bit more, and also get feedback from
> other groups, especially 6man.
>  
> When discussing things in Maastricht, we already agreed that the requirement
> your draft puts forward (i.e. support overlapping addresses on the CPE) can be
> supported by the current version draft-ietf-softwire-gateway-init-ds-lite
> using GRE encapsulation with GRE-key extensions (where the GRE-key is used as
> CID); this also results in a single tunnel between the Gateway and the AFTR. I
> believe the option of GRE is currently a bit mis-represented in your draft
> (i.e. in section 1 you mention that the use of GRE would require a tunnel per
> CPE, which is clearly not the case in case, if we use GRE with GRE-key
> extensions – which is what draft-ietf-softwire-gateway-init-ds-lite
> specifies). 
> Hence the simplest approach to the scenario you outline in your draft is to
> use GRE with GRE-key extensions, no new encapsulation is needed.
> (BTW/ - if you look at earlier versions of
> draft-ietf-softwire-gateway-init-ds-lite, more specifically
> draft-gundavelli-softwire-gateway-init-ds-lite-00, you’ll find a description
> of broadband environments and the use of associated encapsulation types; given
> that the WG is in favor of a short and crisp spec, all these detailed examples
> were dropped from later versions of the draft).
>  
> On the proposal for a new encapsulation type in your draft – using the IPv6
> flow label as CID:
> In case a SP decides to use the proposed encap, using the IPv6 flow label as
> CID, the flow label can no longer be used for any other application, given
> that you’re not suggesting to “steal a few bits from the flow label” (like
> many other uses do), but to use the entire flow-label. E.g. the initially
> anticipated use of the flow-label for ECMP might no longer be feasible. Given
> that the new proposal would render other uses impossible, I think this
> requires a larger discussions – so that one ensures that there would be no
> plans for a parallel use of the flow label. There are a bunch of discussions
> on the use of the flow label in 6man. Have you confirmed that 6man are really
> ok with this use (and I believe Brian Carpenter mentioned something along the
> same lines in an earlier email to the list)?
>  
> In addition, it would be great to understand the technical benefit of this
> alternate encapsulation option over GRE w/ GRE-key extensions, ‘cause with GRE
> you’d have a single tunnel (and hence would also only need to manage a single
> tunnel), whereas for your new encapsulation type, one might end up with a
> series of tunnels (given that the flow label is just 20 bits – hence
> installations with more than 1M subscribers per Gateway will require
> multiplexing across multiple tunnels). Sounds like we’re increasing the
> operational complexity to save a few bits for the encapsulation (given that we
> avoid the GRE header).
>  
> Appreciate your thoughts. I’m also cc’ing Ole Troan and Pascal Thubert who
> also looked closely into the uses of the flow label.
>  
> Regards, Frank
>  
> 
> From: Cathy ZHOU [mailto:[email-masked]]
> Sent: Tuesday, September 14, 2010 10:28 AM
> To: 'Yiu L. Lee'; Sri Gundavelli (sgundave); 'Tina TSOU';
> [email-masked];
> [email-masked]
> Cc: 'Alain Durand'
> Subject: 答复: Synchronization of work between
> draft-ietf-softwire-gateway-init-ds-lite and draft-zhou-softwire-ds-lite-p2p
>  
> Hi all,
> Hope you are back from the PTO. Any comments of incorporating
> draft-zhou-softwire-ds-lite-p2p into the next version of
> draft-ietf-softwire-gateway-init-ds-lite？
>  
> Thanks，
> Cathy
>  
> 
> 
> 发件人: Yiu L. Lee [mailto:[email-masked]]
> 发送时间: 2010年8月26日 0:36
> 收件人: Sri Gundavelli (sgundave); Tina TSOU;
> [email-masked];
> [email-masked]
> 抄送: Alain Durand
> 主题: Re: Synchronization of work between
> draft-ietf-softwire-gateway-init-ds-lite and draft-zhou-softwire-ds-lite-p2p
> Hi Sri,
> 
> How are you? I hope you have a great Summer. There is no rush. We want to work
> with you guys to see whether we can include Flow Label and MPLS Label in
> GI-DS-Lite’s CID.
> 
> Thanks,
> Yiu
> 
> 
> On 8/24/10 11:44 AM, "Sri Gundavelli (sgundave)" <[email-masked]> wrote:
> Hi Lee/Tina,
>  
> Couple of the authors are in PTO, will get back to you once they are back from
> PTO. I don’t know the context of this discussion, let me see the thread and
> the drafts.
>  
> Regards
> Sri
>  
>  
>  
>  
> 
> From: Yiu L. Lee [mailto:[email-masked]]
> Sent: Tuesday, August 24, 2010 4:30 AM
> To: Tina TSOU; [email-masked];
> [email-masked]
> Cc: Alain Durand
> Subject: Re: Synchronization of work between
> draft-ietf-softwire-gateway-init-ds-lite and draft-zhou-softwire-ds-lite-p2p
> 
> I talked to Brian Carpenter off-the-list. He said encapsulating sets of same
> flow label for every packet from a given host is a compatible with the RFC, so
> I recommend us to consider to use the flow label for the P2P link. This is
> particularly help for DSL operators who don’t use GRE today.
> 
> 
> On 8/24/10 6:13 AM, "Tina TSOU" <[email-masked]> wrote:
> As suggested by Alain, MPLS part for GI DS-Lite and
> draft-zhou-softwire-ds-lite-p2p could be incorporate into the next version of
> draft-ietf-softwire-gateway-init-ds-lite.
> The authors of draft-zhou-softwire-ds-lite-p2p are ready to help, subject to
> the possible change from the original texts.
> Comments?
> 
> B. R.
> Tina
> http://tinatsou.weebly.com/index.html
> 
> ----- Original Message -----
>  
> From:  Tina TSOU <mailto:[email-masked]>
>  
> To: [email-masked]  ;
> [email-masked]
>  
> Cc: Alain Durand <mailto:[email-masked]>
>  
> Sent: Tuesday, August 24, 2010 12:37  AM
>  
> Subject: Synchronization of work between
> draft-ietf-softwire-gateway-init-ds-lite and  draft-zhou-softwire-ds-lite-p2p
>  
> 
>  
> Hi friends,
>  
> What do you think about to synchronize the work between
> draft-ietf-softwire-gateway-init-ds-lite and  draft-zhou-softwire-ds-lite-p2p?
>  
> Look forward to your reply.
>  
> 
> 
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
> 
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
> B. R.
> 
> Tina
> 
> http://tinatsou.weebly.com/index.html
> 
>

---

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Tue, 14 Sep 2010 14:41:55 +0200

Hi Yiu,

> Sent: Tuesday, September 14, 2010 2:06 PM
> 
> We discussed this in the last softwire meeting. I want to make two
> points here:
> 
> tunnel sometimes could be trickier (arguably more expensive) than
> simple IP-in-IP.

...FB: OK. If this is a key argument for the new enap, then IMHO/ this should be eluded to in the draft in detail, 'cause in both cases ("GRE with GRE-key as CID" or "IP-in-IPv6 with flow label as CID") one needs the encapsulation supported on both ends of the tunnel, and the associated machinery to handle the CID. So at a more abstract level, this is quite similar (and many devices support GRE today, as they support IP in IP). The one difference is that with the only 20-bit wide flow label, we might end up with multiple tunnels (for large scale gateways), which might be more complicated.

> 
> 2. The Flow Label is used for the CPE to carry IPv4 over IPv6. This
> CPE’s IP Address is often different from the PD prefix to the hosts and
> is used for packets sourced from the CPE. If the network wants to apply
> flow policy to the hosts (or the whole PD), the network can still do
> so. I don’t see why this will cause any problem.

...FB: Well, the concern is a more general one. I'm not disagreeing that we might be able to have flow policies even with the new use of the flow label. The thing that I think requires more discussion is whether people see a need for using the IPv6 flow label in the core of their network, even if GI-DS-lite with this new encapsulation would be used within the very same deployment. If there is such a use, the new encap might create challenges... - which we should understand upfront. I don't know all the foreseen use-cases for the flow label, hence my earlier question on whether the question has been taken to a larger audience (especially 6man).

> 
> In the end, we want to propose an simple alternative rather than
> enforcing the operators to use GRE or MPLS.

...FB: IMHO this is not about enforcing, this is more about ensuring that we don't break anything. Once we're sure that we don't break anything and can also articulate the value of the new encap, I personally don't see any issues with expanding the set of encap types.

Regards, Frank

> proposal as well as alternative options a bit more, and also get
> feedback from other groups, especially 6man.
> 
> When discussing things in Maastricht, we already agreed that the
> requirement your draft puts forward (i.e. support overlapping addresses
> on the CPE) can be supported by the current version draft-ietf-
> softwire-gateway-init-ds-lite using GRE encapsulation with GRE-key
> extensions (where the GRE-key is used as CID); this also results in a
> single tunnel between the Gateway and the AFTR. I believe the option of
> GRE is currently a bit mis-represented in your draft (i.e. in section 1
> you mention that the use of GRE would require a tunnel per CPE, which
> is clearly not the case in case, if we use GRE with GRE-key extensions
> – which is what draft-ietf-softwire-gateway-init-ds-lite specifies).
> Hence the simplest approach to the scenario you outline in your draft
> is to use GRE with GRE-key extensions, no new encapsulation is needed.
> (BTW/ - if you look at earlier versions of draft-ietf-softwire-gateway-
> init-ds-lite, more specifically draft-gundavelli-softwire-gateway-init-
> ds-lite-00, you’ll find a description of broadband environments and the
> use of associated encapsulation types; given that the WG is in favor of
> a short and crisp spec, all these detailed examples were dropped from
> later versions of the draft).
> 
> On the proposal for a new encapsulation type in your draft – using the
> IPv6 flow label as CID:
> In case a SP decides to use the proposed encap, using the IPv6 flow
> label as CID, the flow label can no longer be used for any other
> application, given that you’re not suggesting to “steal a few bits from
> the flow label” (like many other uses do), but to use the entire flow-
> label. E.g. the initially anticipated use of the flow-label for ECMP
> might no longer be feasible. Given that the new proposal would render
> other uses impossible, I think this requires a larger discussions – so
> that one ensures that there would be no plans for a parallel use of the
> flow label. There are a bunch of discussions on the use of the flow
> label in 6man. Have you confirmed that 6man are really ok with this use
> (and I believe Brian Carpenter mentioned something along the same lines
> in an earlier email to the list)?
> 
> In addition, it would be great to understand the technical benefit of
> this alternate encapsulation option over GRE w/ GRE-key extensions,
> ‘cause with GRE you’d have a single tunnel (and hence would also only
> need to manage a single tunnel), whereas for your new encapsulation
> type, one might end up with a series of tunnels (given that the flow
> label is just 20 bits – hence installations with more than 1M
> subscribers per Gateway will require multiplexing across multiple
> tunnels). Sounds like we’re increasing the operational complexity to
> save a few bits for the encapsulation (given that we avoid the GRE
> header).
> 
> Appreciate your thoughts. I’m also cc’ing Ole Troan and Pascal Thubert
> who also looked closely into the uses of the flow label.
> 
> Regards, Frank
> 
> 
> To: 'Yiu L. Lee'; Sri Gundavelli (sgundave); 'Tina TSOU'; draft-zhou-
> [email-masked]; draft-ietf-softwire-gateway-init-
> [email-masked]
> Cc: 'Alain Durand'
> Subject: 答复: Synchronization of work between draft-ietf-softwire-
> gateway-init-ds-lite and draft-zhou-softwire-ds-lite-p2p
> 
> Hi all,
> Hope you are back from the PTO. Any comments of incorporating draft-
> zhou-softwire-ds-lite-p2p into the next version of draft-ietf-softwire-
> gateway-init-ds-lite？
> 
> Thanks，
> Cathy
> ________________________________________
> 
> 收件人: Sri Gundavelli (sgundave); Tina TSOU; draft-zhou-softwire-ds-
> [email-masked]; draft-ietf-softwire-gateway-init-ds-
> [email-masked]
> 抄送: Alain Durand
> 主题: Re: Synchronization of work between draft-ietf-softwire-gateway-
> init-ds-lite and draft-zhou-softwire-ds-lite-p2p
> Hi Sri,
> 
> How are you? I hope you have a great Summer. There is no rush. We want
> to work with you guys to see whether we can include Flow Label and MPLS
> Label in GI-DS-Lite’s CID.
> 
> Thanks,
> Yiu
> 
> 
> Couple of the authors are in PTO, will get back to you once they are
> back from PTO. I don’t know the context of this discussion, let me see
> the thread and the drafts.
> 
> Regards
> Sri
> 
> 
> 
> 
> 
> To: Tina TSOU; [email-masked]; draft-
> [email-masked]
> Cc: Alain Durand
> Subject: Re: Synchronization of work between draft-ietf-softwire-
> gateway-init-ds-lite and draft-zhou-softwire-ds-lite-p2p
> 
> I talked to Brian Carpenter off-the-list. He said encapsulating sets of
> same flow label for every packet from a given host is a compatible with
> the RFC, so I recommend us to consider to use the flow label for the
> P2P link. This is particularly help for DSL operators who don’t use GRE
> today.
> 
> 
> As suggested by Alain, MPLS part for GI DS-Lite and draft-zhou-
> softwire-ds-lite-p2p could be incorporate into the next version of
> The authors of draft-zhou-softwire-ds-lite-p2p are ready to help,
> subject to the possible change from the original texts.
> Comments?
> 
> B. R.
> Tina
> To: [email-masked]  ; draft-
> [email-masked]
> 
> Subject: Synchronization of work between  draft-ietf-softwire-gateway-
> init-ds-lite and  draft-zhou-softwire-ds-lite-p2p
> 
> 
> 
> Hi friends,
> 
> What do you think about to synchronize the work between  draft-ietf-
> softwire-gateway-init-ds-lite and  draft-zhou-softwire-ds-lite-p2p?
>

---

From: "Yiu L. Lee" <[email-masked]>
Date: Tue, 14 Sep 2010 09:45:41 -0400

Hi Frank,

> ...FB: Well, the concern is a more general one. I'm not disagreeing that we
> might be able to have flow policies even with the new use of the flow label.
> The thing that I think requires more discussion is whether people see a need
> for using the IPv6 flow label in the core of their network, even if GI-DS-lite
> with this new encapsulation would be used within the very same deployment. If
> there is such a use, the new encap might create challenges... - which we
> should understand upfront. I don't know all the foreseen use-cases for the
> flow label, hence my earlier question on whether the question has been taken
> to a larger audience (especially 6man).
> 
I don't disagree, but the ip address used by the CPE is only used by the CPE
sourced traffic, this is why I think it is safe to be used. One can consider
all the IPv4 traffic of a household is a flow (for encap). In this setup,
this is rather true and should not affect other flow label for native v6
traffic. 

I also want to hear more inputs. This is why I moved this discussion to the
mailing list. We will also post this question to 6man.

> ...FB: IMHO this is not about enforcing, this is more about ensuring that we
> don't break anything. Once we're sure that we don't break anything and can
> also articulate the value of the new encap, I personally don't see any issues
> with expanding the set of encap types.
> 
Yes, this is my belief too.

Thanks,
Yiu

---

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Tue, 14 Sep 2010 19:41:26 +0200

Hi Yiu,

> > might be able to have flow policies even with the new use of the
flow
> label.
> > The thing that I think requires more discussion is whether people
see
> a need
> > there is such a use, the new encap might create challenges... -
which
> we
> I also want to hear more inputs. This is why I moved this discussion
to
> the

... FB: Great, and thanks for widening the audience. BTW/ - one could
construct (theoretical) use cases, where the use of the flow label as
CID would at least change network behavior, e.g. imagine that a provider
would use ECMP and the hash would include the flow label (as initially
anticipated when the flow label was introduced). With the assumption of
SA and DA (Gateway and AFTR) being the same for all flows, the hash of
the flow label would determine ECMP behavior - desirable or not, it
would have an impact. So am curious to see whether there are real use
cases out there.

Thanks, Frank

---

From: "Yiu L. Lee" <[email-masked]>
Date: Thu, 23 Sep 2010 17:42:47 -0400

I am ready to send the question to 6man. Before doing this, I got a question
for GI-DS-lite. The spec assumes that there is a single pt-to-pt tunnel from
the GW to AFTR. If we use Flow Label, the BRAS will have a pt-to-mp tunnel
from BRAS to AFTR (each CPE will have a dedicated IP-in-IPv6 tunnel). Will
this violate the spec?

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 24 Sep 2010 11:15:29 +1200

> from BRAS to AFTR (each CPE will have a dedicated IP-in-IPv6 tunnel). Will

Isn't the real question whether this will add an unreasonable amount
of state to the AFTR?

   Brian

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

---

From: "Yiu L. Lee" <[email-masked]>
Date: Thu, 23 Sep 2010 19:51:55 -0400

No, I mean "Does this violate the gi-ds-lite spec which assumes one tunnel
between GW and AFTR?"

---

From: "Yiu L. Lee" <[email-masked]>
Date: Fri, 24 Sep 2010 08:15:21 -0400

Actually, it is still a pt-to-pt. The flow label will be used in the BRAS
only, so my question is irrelevant. Thanks for taking the time to read it.