When checking the datatracker
https://datatracker.ietf.org/idtracker/draft-ietf-16ng-ip-over-ethernet-
over-802-dot-16/ I found the following open comments from last weeks
IESG discussions.
Meanwhile we have prepared a new revision of the I-D addressing the
issues. We are ready to submit the revised I-D and would like to clarify
that we really solved the issues.
Bye
Max
pls see inline
Date: 2009-09-10, 04:24:05
Document: draft-ietf-16ng-ip-over-ethernet-over-802-dot-16
Version: 11
Commented by: Jari Arkko
Comment: [IESG Evaluation DISCUSS]
The document is now in quite good shape -- there's been progress
since the previous versions! I did have a few issues, though:
Here the conclusion is right but the rationale needs a bit work:
According to [RFC4861], a link is defined as a communication
facility
or medium over which IP devices can communicate at the link layer,
i.e. the layer immediately below IP. Ethernet fully satisfies the
definition of the link. IEEE 802.16, however, has limitations on
its
transitive connectivity, i.e. IEEE 802.16 provides point-to-point
connections between SSs and the BS but does not enable any direct SS
to SS connectivity. Hence, it is required to bridge each of the
point-to-point connections between SSs and the BS so that Ethernet
is
realized over IEEE 802.16 access network.
Here's a piece of Ethernet technology that has the same limitations as
802.16:
- it is point to point
- it doesn't do multicast
- it has limitations with regards to host - host connectivity
unless your nic supports either straight and twisted cables
http://www.ccrane.com/images/medium/cat-5e-ethernet-cable.jpg
Great! And congratulation. This is the best explanation of the IEEE
802.16 link
model which I have ever seen.
But I do agree, of course, that bridging is required. I would suggest
however that the paragraph be reworded to:
Like in today's wired Ethernet networks, bridging is required to
implement connectivity between more than two devices. In 802.16,
the
point-to-point connections between SSs and the BS can be bridged
so that Ethernet is realized over IEEE 802.16 access network.
Your proposal is much shorter and hits the point. We included the
proposed text
instead of the previous wording.
The network-side bridging function SHOULD create a new radio side
port whenever a new SS attaches to any of the BSs of the network or
SHOULD remove a radio side port when an associated SS detaches from
the BSs.
Wouldn't this be more of a case for a MUST than a SHOULD? This is
basic
functionality for 802.16 Ethernet.
Agreed. It is the essential behavior of the bridge. MUST is more
appropriate.
We changed SHOULD to MUST in the new revision of the I-D.
The generic IP over Ethernet network scenario assumes that all hosts
are residing on the same link with trust relationship between all of
them.
I'm not sure why we need to assume a trust relationship here. I would
suggest deleting everything from word "link" onwards.
We are mentioning here trust relationship, because it is the main
difference to the public access case, where direct communication on the
link layer is prevented to protect other hosts on the same link from
malicious attacks. For the plain Ethernet functionality, trust
relationship is not required. We deleted as you proposed.
All multicast and multicast control messages SHOULD be processed in
the network-side bridging function according to [RFC4541].
This is a fine requirement, except for 4541 being an informational
document and this spec being proposed standard. I would like to change
this and similar recommendations in Section 7 to a different wording.
Say, "can" instead of "SHOULD". Alternatively, we could call out this
downref in a Last Call, but AFAICT this was not done in the last call
we just had.
Same for RFC 4562 references.
We changed "SHOULD" to "can". We know about the difficulty to make
normative references to informative specifications. If "can" allows us
to point to the Informational RFCs, we are fine.
--------------------------
Date: 2009-09-08, 07:18:44
Document: draft-ietf-16ng-ip-over-ethernet-over-802-dot-16
Version: 10
Commented by: Magnus Westerlund
Comment: [IESG Evaluation COMMENT]
Section 5.2, 7.1:
I wonder why these section puts the requirement level on SHOULD and
not a MUST?
And what are the reasons/motivation for when it is allowable to not do
the
action?
For Section 5.2 (replicating broadcast messages and sending them unicast
to all hosts) we used 'SHOULD', because later in the document we
describe, when this rule should not be followed.
In section 7.1 hints are given to conserve radio resources by
selectively processing multicast and broadcast messages. The system
still works even when not all of the hints are adopted. Furthermore some
of the hints are from Informational RFCs, which makes it difficult to
use 'MUST' (see Jari's comment above).
I hope we were able to sufficiently address all the remaining issues of
the document. If yes, we will submit the revised I-D to the IETF.
Bye
Max