[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [16NG] Request for review of draft-ietf-16ng-ip-over-ethernet-over-802-dot-16 from a DSL perspective
Hi Max
Happy new year!
Please see my in-line reply...
BR
Frank
----- Original Message -----
From: "Riegel, Maximilian (NSN - DE/Munich)" <maximilian.riegel at nsn.com>
To: "ext Frank Xia" <xiayangsong at huawei.com>; <g_e_montenegro at yahoo.com>;
"Mark Townsley" <townsley at cisco.com>
Cc: <draft-ietf-16ng-ip-over-ethernet-over-802-dot-16 at tools.ietf.org>;
<16ng at ietf.org>
Sent: Sunday, January 04, 2009 1:33 PM
Subject: RE: [16NG] Request for review of
draft-ietf-16ng-ip-over-ethernet-over-802-dot-16 from a DSL perspective
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?
Frank=>You have constructive recommendation to Broadband Network,
however, I don't see the consistence with on-going technical choice
in Broadband network. Just I highlighted in my email, you recommends
different users SHARE a IPv6 prefix, IMHO, it is not the case in Broadband
Network.
Even in IPoETHo802.16 access scenario, user isolation principle is
also supposed to be observed. That is , different subscriber
is supposed to have different VLAN (or other mechanims, such
as MAC force forwarding..) .
I am not clear how to implement these in BRAS/DSLAM/SWITCH
after my reading this document.
is BRAS needed to extend to support PKM authentication?
is any GRE tunnel required for traffic between DSLAM and BRAS?
is any extra interface needed such as R6 in WiMAX ?
However, these clarificiations are not very related to this document,
while they are helpful when applying IPoETHo802.16 to Broadband Network.
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.
Frank=>I dont know if it is proper when we design a STANDARD
while leaving some important issues for implementer.
I prefer to having a choice based on the WG talents.
Bye
Max
-----Original Message-----
From: 16ng-bounces at ietf.org [mailto:16ng-bounces at ietf.org] On Behalf Of
ext Frank Xia
Sent: Wednesday, December 10, 2008 17:47
To: g_e_montenegro at yahoo.com; Mark Townsley
Cc: draft-ietf-16ng-ip-over-ethernet-over-802-dot-16 at tools.ietf.org;
16ng at 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 at yahoo.com>
To: "Mark Townsley" <townsley at cisco.com>; "Frank Xia"
<xiayangsong at huawei.com>
Cc: "Jari Arkko" <jari.arkko at piuha.net>; "Soohong Daniel Park"
<soohongp at gmail.com>;
<draft-ietf-16ng-ip-over-ethernet-over-802-dot-16 at tools.ietf.org>;
<16ng at 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 at ietf.org
https://www.ietf.org/mailman/listinfo/16ng
_______________________________________________
16NG mailing list
16NG at ietf.org
https://www.ietf.org/mailman/listinfo/16ng