Hi Yiu,

> From: Yiu L. Lee [mailto:[email protected]]
> Sent: Tuesday, September 14, 2010 2:06 PM
> 
> (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.

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

> 
> Any thought?
> 
> Thanks,
> Yiu
> 
> 
> On 9/14/10 7:50 AM, "Frank Brockners (fbrockne)" <[email protected]>
> 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 protected]]
> Sent: Tuesday, September 14, 2010 10:28 AM
> To: 'Yiu L. Lee'; Sri Gundavelli (sgundave); 'Tina TSOU'; draft-zhou-
> [email protected]; draft-ietf-softwire-gateway-init-
> [email protected]
> 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 protected]]
> 发送时间: 2010年8月26日 0:36
> 收件人: Sri Gundavelli (sgundave); Tina TSOU; draft-zhou-softwire-ds-
> [email protected]; draft-ietf-softwire-gateway-init-ds-
> [email protected]
> 抄送: 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 protected]>
> 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 protected]]
> Sent: Tuesday, August 24, 2010 4:30 AM
> To: Tina TSOU; [email protected]; draft-
> [email protected]
> 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 protected]> 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 protected]>
> 
> To: [email protected]  ; draft-
> [email protected]
> 
> Cc: Alain Durand <mailto:[email protected]>
> 
> 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

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

Reply via email to