RE: draft of a core protocol spec

At 01:56 PM 11/7/2002 +0200, Leon Bruckman wrote:
>Frank,
>My comments below.

Leon, thanks for reading and commenting on it.


>When the 
>        fault clears, the ring "unwraps" and/or the effected source 
>        nodes "re-steer" their traffic.
>lb] In steer protection the client in a node may select not to steer back,
>thus avoiding a second hit. I would recommend to remove this sentence 

As this section of the document is meant to be a high-level,
not-very-technical, description of 802.17, is it necessary?
All I want to say is that once the fault clears, the ring
reverts to normal operation (hmm, maybe I should just say that)


>       The two rings are called the Inner ring and Outer ring.
>lb] They are called ringlet0 (former outer) and ringlet1 (former Inner) 

Ok, thanks.

>       A node may transmit a packet in either direction around the 
>        ring.  IEEE 802.17 includes MAC-level protocols to determine 
>        the shortest path to each destination.
>lb] My suggestion: "IEEE 802.17 includes MAC-level protocols to determine
>the ring topology."

Ok. 

>       IEEE 802.17 is a media-independent network protocol that is 
>        layered over several different physical media.  SONET and 
>        Gigabit Ethernet are currently specified; others may be 
>        specified in the future.  The higher layers are shielded from 
>        any media dependencies.
>lb] SONET/SDH and 1 and 10 Gigabit Ethernet are specified in the draft 

Ok

>       There are fairness and bandwidth-management elements.  There 
>        are high, medium, and low priority services.  
>lb] My suggestion: "There are 3 service classes: Class A that provides low
>delay and delay variation, class B that includes a committed and a excess
>component, and class C a best effort class.

Ok

>Use of these 
>        features by IP and MPLS is beyond the scope of this 
>        specification.  Their use will be specified in a later 
>        document.
>lb] We could at least define the mapping of DiffServe to the RPR service
>classes 

I imagine that this could lead to a long discussion (having watched 
how long it took Diffserv to do something that was supposed to be 
"simple"...). The purpose of this note is to define the basic, no 
bells, no whistles, version of IPoRPR. The idea is that these are
things that we can easily get consensus on. This would allow
implementation and experimentation work to begin. Using the
"advanced" features of 802.17 is something we intentionally put
off until we recharter the working group to go into those areas
(which should happen Q1 or Q2 of next year). It's been my experience
in the IETF that keeping a very constrained charter keeps the 
working group tightly focussed on the issues at hand and that
means that the working group actually gets things done in a timely
manner. 

>lb] RPR also defines a echo frame to verify connectivity between any two
>stations on the ring at the RPR layer, and a flush frame that can be used to
>avoid misorder when steering flows

Yup. But I don't see them as relevant to the basic encapsulation,
etc, of IP and MPLS over RPR. 

>    4.1 IEEE 802.17 Header 
>
>        When transmitting an IP or MPLS packet, a host or router 
>        indicates various parameters to the IEEE 802.17 MAC layer (see 
>        section 5.3.1.1 of [8].  This section specifies how those 
>        parameters are to be used: 
>
>         TTL In the absence of any recommended value in IEEE 802.17, 
>             the TTL SHOULD be set to 255. 
>lb] There is no need (nor a standard way) to indicate TTL to the MAC. The
>MAC can calculate it based on the DA

There does not need to be a standard way of indicating the TTL to
the MAC. That's an implementation issue.  However, that's irrelevant.
If the MAC can insert the "correct" TTL, that's _probably_ all we
need and I'll revise the spec to say that. One question, when a node
is added to the ring, does the MAC update its notion of what TTL
to use "quickly"?


Frank Kastenholz