Re: [16NG] Request for review of draft-ietf-16ng-ip-over-ethernet-over-802-dot-16 from a DSL perspective

"Riegel, Maximilian (NSN - DE/Munich)" <maximilian.riegel@nsn.com> Sun, 04 January 2009 19:34 UTC

Return-Path: <16ng-bounces@ietf.org>
X-Original-To: 16ng-archive@optimus.ietf.org
Delivered-To: ietfarch-16ng-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93C883A6934; Sun, 4 Jan 2009 11:34:24 -0800 (PST)
X-Original-To: 16ng@core3.amsl.com
Delivered-To: 16ng@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 443923A6934 for <16ng@core3.amsl.com>; Sun, 4 Jan 2009 11:34:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B4nn3nWWtbal for <16ng@core3.amsl.com>; Sun, 4 Jan 2009 11:34:22 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 039B93A689C for <16ng@ietf.org>; Sun, 4 Jan 2009 11:34:21 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n04JXJZr012075 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 4 Jan 2009 20:33:19 +0100
Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n04JXJ7a007730; Sun, 4 Jan 2009 20:33:19 +0100
Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 4 Jan 2009 20:33:19 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Sun, 04 Jan 2009 20:33:18 +0100
Message-ID: <BC27158B99D3064A955ADE084783900C0192B467@DEMUEXC014.nsn-intra.net>
In-Reply-To: <00aa01c95ae6$fb48cd00$420c7c0a@china.huawei.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [16NG] Request for review of draft-ietf-16ng-ip-over-ethernet-over-802-dot-16 from a DSL perspective
Thread-Index: Acla5v++9/CU26kmQ221SYNDwBufSgTqC14Q
References: <817000.84300.qm@web81901.mail.mud.yahoo.com> <00aa01c95ae6$fb48cd00$420c7c0a@china.huawei.com>
From: "Riegel, Maximilian (NSN - DE/Munich)" <maximilian.riegel@nsn.com>
To: ext Frank Xia <xiayangsong@huawei.com>, g_e_montenegro@yahoo.com, Mark Townsley <townsley@cisco.com>
X-OriginalArrivalTime: 04 Jan 2009 19:33:19.0088 (UTC) FILETIME=[4C04D700:01C96EA3]
Cc: draft-ietf-16ng-ip-over-ethernet-over-802-dot-16@tools.ietf.org, 16ng@ietf.org
Subject: Re: [16NG] Request for review of draft-ietf-16ng-ip-over-ethernet-over-802-dot-16 from a DSL perspective
X-BeenThere: 16ng@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: 16ng working group discussion list <16ng.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/16ng>, <mailto:16ng-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/16ng>
List-Post: <mailto:16ng@ietf.org>
List-Help: <mailto:16ng-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/16ng>, <mailto:16ng-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: 16ng-bounces@ietf.org
Errors-To: 16ng-bounces@ietf.org

Hi Frank,

Thanks for your comments. We would appreciate to get some more
information on your general comments to reach better understanding for
making appropriate modifications in the document.

1) What would be the benefits of putting the public access
recommendation part into a separate Informational RFC on 'IPoETHo802.16
access in Broadband Networks'? Common broadband access networks e.g. DSL
accesss according to TR-101 can be configured either way, in public
access configuration or for Transparent LAN Service. I have the feeling
that the document would end up quite similar to the
draft-ietf-16ng-ip-over-ethernet-over-802-dot-16 document.
Is there anything, we should add in informational annexes to adapt the
applicability better to broadband access networks?

2) We agree that distributed bridging functionality is hard to implement
when a centralized database is needed. This led to the current approach
to show the applicability of the distributed bridging architecture in
the public access scenario, when forced forwarding allows to concentrate
the data base in one particular location. It seems, more extensive
considerations on the bridging architecture may be helpful for better
understanding the issues. Would you agree that we should provide more
text on the pros and cons of centralized vs distributed bridging
architectures.

Bye
Max

-----Original Message-----
From: 16ng-bounces@ietf.org [mailto:16ng-bounces@ietf.org] On Behalf Of
ext Frank Xia
Sent: Wednesday, December 10, 2008 17:47
To: g_e_montenegro@yahoo.com; Mark Townsley
Cc: draft-ietf-16ng-ip-over-ethernet-over-802-dot-16@tools.ietf.org;
16ng@ietf.org
Subject: Re: [16NG] Request for review of
draft-ietf-16ng-ip-over-ethernet-over-802-dot-16 from a DSL perspective

Hi Folks

General comments include:
1)removing public access recommendation part.
  We can have an informational draft on
  "IPoEo802.16 access in Broadband Network".
2)re-considering distributed bridging funcionalities.
  It is hard to implement when a centralized database needed.

Please check the detailed comments:
1) Section 8
  "Therefore, the AR in the  public access link model
   SHOULD assign common IPv6 prefixes to all SSs
   served by the AR"
  IP addresing is still under discussion in Broadband Forum.
  However, IMO, these is almost a consensus that each
  SS uses a unique IPv6 prefixe.

2)Section 7.3.
 When a network-side bridge receives an ARP request
  from a host behind subsriber-side bridge, the network
  side bridge should discard the request if the destination
  host is also behind the same subscriber-side switch.

3)Appendix B.
  I propose that the edge network-side switchs
  are responsible for host database maitenance, and
  responsing ARP request as a proxy.
  No centralized database is needed.

4)Section 7.2
   It is better to remove TR101 stuff from this section.

BR
Frank


----- Original Message -----
From: <g_e_montenegro@yahoo.com>
To: "Mark Townsley" <townsley@cisco.com>; "Frank Xia" 
<xiayangsong@huawei.com>
Cc: "Jari Arkko" <jari.arkko@piuha.net>; "Soohong Daniel Park" 
<soohongp@gmail.com>;
<draft-ietf-16ng-ip-over-ethernet-over-802-dot-16@tools.ietf.org>;
<16ng@ietf.org>
Sent: Tuesday, November 18, 2008 6:01 PM
Subject: Request for review of
draft-ietf-16ng-ip-over-ethernet-over-802-dot-16 from a DSL perspective


> Hi Mark and Frank,
>
> Your names have been offered as people who are familiar with DSL 
> network deployments.
>
> We would like to request your review of a 16ng draft that may have 
> some similarities with those deployments:
>
> http://tools.ietf.org/html/draft-ietf-16ng-ip-over-ethernet-over-802-d
> ot-16-07
>
> This draft is in AD review, and Jari asked the WG to close the loop on

> this draft with DSL-savvy folks. The idea is not that they should 
> match, but that DSL deployments have some similarities, hence you 
> might have good insight and feedback on this draft.
>
> Please feel free to forward to other DSL experts you may be aware of. 
> If at all possible, we would like to get some feedback by December 12,
2008.
>
> Thanks in advance,
>
> Gabriel and Daniel, 16ng co-chairs
>
> 


_______________________________________________
16NG mailing list
16NG@ietf.org
https://www.ietf.org/mailman/listinfo/16ng
_______________________________________________
16NG mailing list
16NG@ietf.org
https://www.ietf.org/mailman/listinfo/16ng