(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 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';
> [email protected];
> [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;
> [email protected];
> [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];
> [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]  ;
> [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