Re: [16NG] IESG Comments on draft-ietf-16ng-ip-over-ethernet-over-802-dot-16

[Jari Arkko <[e-mail]>]

Please submit the draft and I'll check if there's anything that remains. 
But this sounds good in general.

Jari

Riegel, Maximilian (NSN - DE/Munich) wrote:
> 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
>
>