Re: FW: IPoRPR Core Standard Draft

Peter, 
thanks for the comments. see my responses in line.

Frank

>> 4.2 - missed 0x0806 for ARP
Ok

>> 4.3 Payload - Why would IP over RPR pad to 48 bytes to support Ethernet 64 bytes frame size? This doesn't provide any benefit when running over POS/GFP phys. This should be an issue for RPR and it's Gige adaptation layer. I'd say that the RPR interface will provide the MTU size to the network layer as per normal, and the link/MAC layer should be responsible for any minimum frame size padding required.  From memory, IP Over PPP doesn't pad.

It is not prohibited from padding.
My goal was to make a simple protocol that has the least amount
of variability. If IP needs to know whether 802.17 is running over
GigE vs Sonet, then it is that much more complex. However, if either
1. 802.17 will add the padding if needed or 
2. 802.17 can provide to IP some indication of whether padding is
   necessary or not
then I'd consider removing the requirement to always pad.
However, regardless of that, I'd keep a requirement that all IPoRPR
implementations be able to deal with receiving padded packets, even
if they came in over Sonet (this is the robustness principle in action).


>> 4.6 MTU The real RPR default MTU will probably not end up being 1500. It's about 9216 frame size for jumbo, and I suspect will be in the order of 1550 for non-jumbo to accommodate MPLS tags, VLAN tags, etc. But regardless, isn't this a property of the link rather than something to be specified by the IP Over RPR encapsulation? As John says, this may change over time for a given link.

Yeah. I guess that this belongs in section 3 -- the general overview
of 802.17

>> 
>> 5.1 I agree with John's comment about the address space hardware type. We may need this for the later version of the spec to when we want store the ringlet ID that a ARP response was seen on.

Good point. I'll change this.


>>       3: The 802.17 frame format will almost for sure change next week at the next 802.17 plenary meeting.

Grumble. I was under the impression that the 802.17 spec is more or less
done. Do you have any indications of what will/may change?



>>       4.1: ringletID may be selected by the client. But I assume you are stating it this way since this is simple version that doesn't try to do anything fancy. If so, you may want to clarify this statement.

Ok, will try to find better words.

>>       4.3: Do you think it would be useful to have a method of indicating this? If so, do you think we should do so via the MIB, or what?

Indicating what?


>>       8.3: Only partially true. Service could be denied only to other classC (BE) traffic, and only to a limited extent. The fairness algorithm keeps any one station from using more than its fair share of BE bandwidth availability. (And more limitations caused by allocations for classB (AF) and classA (EF) that I'd be happy to explain.)

Ok. Will revise the text accordingly.

All the editorial comments cheerfully accepted :-)

Frank Kastenholz