Subject: [IPORPR] FW: IPoRPR Core Standard Draft

From: [email-masked]
Date: Thu, 7 Nov 2002 09:35:33 -0800

Forgot to send to the list

>  -----Original Message-----
> From: 	Peter Jones  
> Sent:	Wednesday, November 06, 2002 7:03 PM
> To:	[email-masked]
> Cc:	John Lemon; Raj Sharma; Jason Fan; Vinay Bannai
> Subject:	RE: IPoRPR Core Standard Draft
> 
> Frank,
> 
> Some follow up comments to John's.
> 
> 4.2 - missed 0x0806 for ARP
> 
> 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.
> 
> 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.
> 
> 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.
> 
> Regards
> Peter
> 
> 	 -----Original Message-----
> 	From: 	John Lemon  
> 	Sent:	Wednesday, November 06, 2002 6:31 PM
> 	To:	[email-masked]'
> 	Subject:	IPoRPR Core Standard Draft
> 
> 	Frank,
> 
> 	I just read your draft that you posted to the IPoRPR list this week. I have a few comments.
> 
> 	jl
> 
> 	Technical:
> 	3: 802.17 does not determine and default to the shortest path. The standard is purposely silent on this. Instead, 802.17 rings determine the topology of the ring, allowing a choice of shortest path, or some other algorithms to be employed.
> 	3: The 802.17 frame format will almost for sure change next week at the next 802.17 plenary meeting.
> 	4.1: The client (host or router) does not set the TTL or frame type. The MAC sets these values.
> 	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.
> 	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?
> 	4.6: The MTU can be changed from the default only via 802.17 negotiation (via the topology discovery protocol). While this could be triggered by an administrative command or by a router advertisement, these are just possibilities, and still just triggers.
> 	5.1: I certainly would prefer a new type code.
> 	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.)
> 	9: See my comment on 5.1.
> 	10.8: Please update to reference D1.1, October 25.
> 
> 	Editorial:
> 
> 	1: Starting on page 2, the footer lists an expiration date of May 2002 instead of May 2003.
> 	3: Starting in this section, you use "node" and "nodes" whereas 802.17 uses "station" and "stations".
> 	3: Starting in this section, you use "ring" for the purpose that 802.17 uses "ringlet". Note that 802.17 distinguishes between a ring and a ringlet. A ring is comprised of 2 counter rotating ringlets.
> 	3: 802.17 now refers to the ringlets as ringlet0 and ringlet1. Inner and outer are used only in diagrams where ringlet0 is shown as the outer ringlet, transmitting clockwise, and ringlet1 is shown as the inner ringlet, transmitting counterclockwise.> 
> 	3: Starting in this section, you use "packet" for the purpose that 802.17 uses "frame". Note that 802.17 distinguishes between a packet and a frame. Packet is used for the SDU of higher layers, such as IP, whereas frame is used for the PDU used by 802.17.
> 	3: As of draft 1.1, Packet Type (PT) has changed to Frame Type (FT), and the reserved bit (R) has changed to the parity bit (P), which is used only for fairness frames and reserved for all other frames.
> 	3: RI stands for ringlet identifier.
> 	3: Change "Which the ring" to "Which ringlet".
> 	4.4: Since this always confuses people, you might say in addition or instead that it is the same order as used by Ethernet.
_______________________________________________
IPORPR mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/iporpr

---

From: Frank Kastenholz <[email-masked]>
Date: Thu, 07 Nov 2002 15:03:57 -0500

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…

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…

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…

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…

Ok. Will revise the text accordingly.

All the editorial comments cheerfully accepted :-)

Frank Kastenholz

---

From: [email-masked]
Date: Thu, 7 Nov 2002 14:39:49 -0800

>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?

Definitely, but I don't think it is useful to prognosticate in this
very contentious area. :-) I believe that the outcome of next week's
meeting should be very stable, and a basis for working from. It will
likely be labeled Draft 2.0.

>>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?

I was referring to indicating the PHY type (and/or padding requirements)
to the client. But, after reading Peter's comments, I retract this. I agree
with Peter that the upper layers should not have to worry about this and
that we should handle this in 802.17. It's too late to comment on this for
next week, but I'll try to remember to get this comment in for next time.
(Or maybe Peter should since he originated the idea.)

jl