Subject: [IPORPR] draft of a core protocol spec

From: Frank Kastenholz <[email-masked]>
Date: Tue, 05 Nov 2002 10:02:42 -0500

IPoRPR-people

Yesterday I promised a draft specification for the
core IP over RPR protocol work.  Here it is.

For those that don't recall, the core protocol is the
basic protocol functions needed to carry IP and MPLS
packets over an 802.17 network. In the interests of
simplicity, speed-of-development, and time-to-market,
this specification treats the 802.17 network as if it
was a simple fat-yellow-cable-Ethernet. All the other
features of 802.17 are intentionally left out of this 
spec (again, the walk-before-we-run principle). 

A later spec will address using the advanced features 
of 802.17, should the WG decided to go down that path.

This draft has not been sent to the ID repository since
the repository is now closed, pending the IETF meeting
later this month. I'm soliciting comments and discussion
now to get a round of discussion and editing done and
then will publish the document as an ID.

Frank Kastenholz

                               o /
--------------------------------x----------------------
                               O \

     IP Over Resilient Packet Rings                        Kastenholz, Frank 
     Internet Draft                                         Juniper Networks 
     Document <>                                               November 2002 
     Category: Standards Track 

       A Core Standard For Transmission of IP Packets Over IEEE 802.17 
                      (Resilient Packet Ring) Networks 

     Status of this Memo 

        This document is an Internet-Draft and is in full conformance 
        with all provisions of Section 10 of RFC2026 [1]. 

        Internet-Drafts are working documents of the Internet 
        Engineering Task Force (IETF), its areas, and its working 
        groups.  Note that other groups may also distribute working 
        documents as Internet-Drafts. 

        Internet-Drafts are draft documents valid for a maximum of six 
        months and may be updated, replaced, or obsoleted by other 
        documents at any time.  It is inappropriate to use Internet- 
        Drafts as reference material or to cite them other than as 
        "work in progress."  

        The list of current Internet-Drafts can be accessed at 
        http://www.ietf.org/ietf/1id-abstracts.txt  

        The list of Internet-Draft Shadow Directories can be accessed 
        at http://www.ietf.org/shadow.html. 

     Kastenholz        Standards Track - Expires May 2003             1 
                         IP Over Resilient Packet Rings   November 2002 

     Table of Contents 
        1 Abstract........................................................2 
        2 Conventions used in this document...............................3 
        3 Overview of IEEE 802.17.........................................3 
        4 General.........................................................5 
         4.1  IEEE 802.17 Header.....................................6 
         4.2  Protocol Type Field....................................6 
         4.3  Payload................................................6 
         4.4  Byte Order.............................................7 
         4.5  Trailer Format.........................................7 
         4.6  MTU....................................................7 
         4.7  Ring and Direction Selection...........................7 
         4.8  Higher Layer TTL and Ring Hop Count....................7 
        5 IPv4 Specific Details...........................................8 
         5.1  Address Resolution.....................................8 
        6 IPv6 Specific Details...........................................8 
         6.1  Stateless Autoconfiguration............................8 
         6.2  Link Local Address.....................................8 
         6.3  Unicast Address Mappings...............................8 
         6.4  Multicast Address Mappings.............................9 
        7 MPLS Specific Details...........................................9 
        8 Security Considerations.........................................9 
        9 IANA Considerations.............................................9 
        10 References.....................................................9 
        11 Author's Addresses............................................10 

     1  Abstract 

        This memo specifies a standard method of encapsulating IPv4, 
        IPv6, and MPLS datagrams in IEEE 802.17 Resilient Packet Ring 
        Networks.  This method uses a minimum of IEEE 802.17 functions 
        and capabilities.  As far as IP and MPLS are concerned, the 
        802.17 network is treated as a simple, flat network, similar in 
        many ways to an Ethernet. 

        A later specification will build upon this standard.  It will 
        make more of the features and capabilities of IEEE 802.17 
        networks available to IP and MPLS and specify the techniques to 
        use those features. 

     Kastenholz        Standards Track - Expires May 2002             2 
                         IP Over Resilient Packet Rings   November 2002 

     2  Conventions used in this document 

        The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 
        NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and 
        "OPTIONAL" in this document are to be interpreted as described 
        in RFC-2119 [2]. 

        The term "Higher Layer" refers to IPv4, IPv6, and MPLS when 
        they act as clients of the IEEE 802.17 network. 

        "IP" refers to both IPv4 and IPv6.  The terms "IPv4" and "IPv6" 
        are used only when a specific version of IP is meant. 

     3  Overview of IEEE 802.17 

        This section gives a brief overview of the IEEE 802.17 
        protocol.  The intent is to provide information needed to make 
        sense of the rest of this note.  This section is NOT intended 
        to be a technically rigorous description of IEEE 802.17. 

        IEEE 802.17 is a dual, counter-rotating, ring network 
        technology with destination stripping.  In the event of a fault 
        (such as a fiber cut) the nodes on each side of the fault can 
        continue to function by wrapping the ring and/or by steering 
        away from the fault and towards the operational path.  When the 
        fault clears, the ring "unwraps" and/or the effected source 
        nodes "re-steer" their traffic. 

        The two rings are called the Inner ring and Outer ring. 

        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.  Normally, the 802.17 
        MAC layer will automatically send packets via the shortest 
        path.  Alternatively, higher layers (such as IP) may explicitly 
        specify the ring to use. 

        All nodes on the ring have 48-bit IEEE 802 addresses. 

        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. 

        There are fairness and bandwidth-management elements.  There 
        are high, medium, and low priority services.  Use of these 
        features by IP and MPLS is beyond the scope of this 
        specification.  Their use will be specified in a later 
        document. 

     Kastenholz        Standards Track - Expires May 2002             3 
                         IP Over Resilient Packet Rings   November 2002 

        The IEEE 802.17 packet is similar to an Ethernet packet.  Its 
        format is: 

                             +--------------------+ 
                             | IEEE 802.17 Header | 
                             |      (16 bits)     | 
                             +--------------------+ 
                             | Destination MAC    | 
                             |  Address (48 bits) | 
                             +--------------------+ 
                             | Source MAC Address | 
                             |  (48 bits)         | 
                             +--------------------+ 
                             | Protocol Type      | 
                             |  Field (16 bits)   | 
                             +--------------------+ 
                             | Header Checksum    | 
                             |  (16 bits)         | 
                             +--------------------+ 
                             |       Payload      | 
                             |                    | 
                             +--------------------+ 
                             |         FCS        | 
                             +--------------------+ 

        Where 

        IEEE 802.17 Header 
            Is a 16-bit IEEE 802.17 header. 

            The format of the RPR header is: 

                 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 
                 |          TTL          |RI|FE|  PT |  SC |WE|E | 
                 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 

            Where 

            TTL 
                Is the Time To Live for the packet.  It is decremented 
                by each station on the IEEE 802.17 ring.  If the TTL 
                reaches 0 it is removed from the ring.  This field is 
                set by the interface hardware. 

                NOTE WELL that this TTL is not related in any way to 
                the TTL in IPv4 and MPLS headers nor the hop-count in 
                IPv6 headers. 

            RI  Ring Identifier 
                Which the ring on which the packet was originally 
                transmitted. 

     Kastenholz        Standards Track - Expires May 2002             4 
                         IP Over Resilient Packet Rings   November 2002 

            FE  Fairness Eligible 
                Indicates whether the packet is subject to the IEEE 
                802.17 fairness algorithm or not. 

            PT  Packet Type 
                Is a type field used to discriminate various IEEE 
                802.17 management and control packets from data 
                packets. 

            SC  Service Class 

            WE  Is the Wrap Eligible bit. It indicates whether the 
                packet may be wrapped when the ring is wrapped.  

            R   Is reserved. 

        Destination MAC Address 
            Is the 48-bit MAC address of the destination node.  This 
            may be a multicast or broadcast address.  This address is 
            an IEEE 802 address. 

        Source MAC Address 
            Is the 48-bit MAC address of the source node.  This may be 
            a multicast or broadcast address.  This address is an IEEE 
            802 address. 

        Protocol Type 
            This is the 16-bit type field.  It identifies the protocol 
            of the payload 

        Header Checksum 
            Is a HEC-16 over the 802.17 header, Source and Destination 
            MAC addresses, and Protocol Type. 

        Payload 
            Is the IEEE 802.17 packet’s payload.  This is the IP or 
            MPLS packet. 

        FCS 
            Is a CRC-32 over the entire IEEE 802.17 packet. 

     4  General 

        This section covers issues that are common to IPv4, IPv6, and 
        MPLS. 

     Kastenholz        Standards Track - Expires May 2002             5 
                         IP Over Resilient Packet Rings   November 2002 

     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. 

         RING 
             The ringlet on which a packet is transmitted SHOULD be 
             selected by the IEEE 802.17 MAC layer’s Ringlet Selection 
             Process.  The higher layers SHOULD NOT select the ringlet. 

         FE  Fairness Eligible 
             No value should be specified for Fairness Eligible.  The 
             default treatment, specified in [8] is used.. 

         PT  Packet Type 
             The packet type is “data packet”. 

         SC  The Service Class SHOULD be CLASS C, which “provides a 
             best-effort traffic service with no allocated or 
             guaranteed data rate and no bounds on end-to-end delay or 
             jitter”.  Use of different service classes is left for a 
             later specification. 

     4.2 Protocol Type Field 

        The 16-bit protocol type field is set to a value to indicate 
        the payload’s protocol. The values for IPv4, IPv6, and MPLS 
        are: 
        0x0800  If the payload contains an IPv4 packet. 
        0x86DD  If the payload contains an IPv6 packet. 
        0x8847  If the payload contains a MPLS Unicast packets, or 
        0x8848  if the payload contains a MPLS Multicast packet. 

     4.3 Payload 

        The payload contains the IPv4, IPv6, or MPLS packet.  The first 
        byte of the IPv4 header, IPv6 header, or top MPLS label begins 
        immediately after the 802.17 Header Checksum. 

        The payload is padded to meet any minimum frame size 
        requirements.  Note well that IEEE 802.17 is specified to 
        operate over both SONET/SDH, which does NOT have a minimum 
        frame size requirement, and Gigabit Ethernet, which does.  This 
        specification requires that IP and MPLS be unaware of the exact 

     Kastenholz        Standards Track - Expires May 2002             6 
                         IP Over Resilient Packet Rings   November 2002 

        physical medium over which the 802.17 ring is built.  
        Therefore, IP and MPLS MUST always pad packets to the minimum 
        Ethernet frame size (46 bytes) and IP and MPLS MUST always 
        expect to receive packets with padding. 

     4.4 Byte Order 

        As described in "APPENDIX B:  Data Transmission Order" of 
        RFC791[3], IP and MPLS datagrams are transmitted over the IEEE 
        802.17 network as a series of 8-bit bytes in "big endian" 
        order. 

     4.5 Trailer Format 

        Trailer encapsulation is NOT specified for IEEE 802.17 
        networks. 

     4.6 MTU 

        The default MTU of IEEE 802.17 networks is 1500 bytes.  

        The MTU may be changed by administrative command or IPv6 Router 
        Advertisement. 

     4.7 Ring and Direction Selection 

        IEEE 802.17 allows the Higher Layer to select the direction 
        around the ring that traffic is to go.  If the Higher Layer 
        does not make the selection then the IEEE 802.17 makes the 
        decision. 

        Ring and Direction selection are left to the hardware.  The 
        advanced version of this specification may change this. 

     4.8 Higher Layer TTL and Ring Hop Count 

        The Higher Layer TTL is decremented by 1 for the entire IEEE 
        802.17 ring, NOT by 1 per station on the ring. 

        IEEE 802.17 networks consist of a number of stations.  This 
        specification treats the IEEE 802.17 network as a single "LAN".  
        Therefore, the TTL is decremented by 1, just as it would be if 
        the IEEE 802.17 network was a big Ethernet. 

     Kastenholz        Standards Track - Expires May 2002             7 
                         IP Over Resilient Packet Rings   November 2002 

     5  IPv4 Specific Details 

     5.1 Address Resolution 

        ARP[4] is used to map IPv4 addresses to the appropriate MAC 
        address. 

        The hardware addresses used in IEEE 802.17 are the same size 
        and format as Ethernet addresses.  Therefore, to minimize the 
        impact on software, the "Hardware Address Space" parameter 
        (ar$hrd) used for IEEE 802.17 networks is 1[5]. 

          Editor’s Note 
               This does overload the “Ethernet Hardware Type” value to 
               include 802.17, which is certainly undesirable from a 
               “purist’s” point of view. However, I believe that the 
               costs are minimal.  If the working group would prefer, 
               we can get a new hardware type code from IANA. 

     6  IPv6 Specific Details 

        Transport of IPv6 packets over IEEE 802.17 networks is designed 
        to be as similar to IPv6 over Ethernet as possible.  The intent 
        is to minimize time and risk in developing both the standard 
        and the implementations.  This is possible because the IEEE 
        802.17 network can appear as a simple Ethernet. 

     6.1 Stateless Autoconfiguration 

        IPv6 stateless autoconfiguration follows the rules and 
        procedures in section 4 of RFC2464[6]. 

     6.2 Link Local Address 

        IPv6 link-local addresses follow the rules and procedures in 
        section 5 of RFC2464[6]. 

     6.3 Unicast Address Mappings 

        IPv6 unicast address mappings follow the rules and procedures 
        in section 6 of RFC2464[6]. 

     Kastenholz        Standards Track - Expires May 2002             8 
                         IP Over Resilient Packet Rings   November 2002 

     6.4 Multicast Address Mappings 

        IPv6 multicast address mappings follow the rules and procedures 
        in section 7 of RFC2464[6]. 

     7  MPLS Specific Details 

        Transport of MPLS packets over IEEE 802.17 follows RFC3032[7].  
        As with IPv6, the intent is to allow the IEEE 802.17 network to 
        be treated as a simple Ethernet LAN. 

     8  Security Considerations 

        This specification provides no security measures. 

        In particular 
        1. Masquerading and spoofing are possible.  There is no strong 
           authentication. 
        2. Traffic analysis and snooping is possible since no 
           encryption is provided, either by this specification or by 
           IEEE 802.17 
        3. Denial of Service attacks are possible by, eg, flooding the 
           IEEE 802.17 network with ARP broadcasts. 
        4. Attacks against the IEEE 802.17 ring management protocols 
           are possible by nodes that are directly connected to the 
           ring. 
        We note that all of these vulnerabilities exist today for 
        transport of IP and MPLS over Ethernet networks. 

     9  IANA Considerations 

        There are no IANA considerations.  This specification does not 
        define any number or name spaces that need to be centrally 
        managed. 

     10 References 

        [1] Bradner, S., "The Internet Standards Process – Revision 3", 
            BCP9, RFC2026, October 1996 

        [2] Bradner, S., "Key words for use in RFCs to Indicate 
            Requirements Levels", BCP 14 RFC 2119, March 1997 

        [3] Postel, J., "Internet Protocol", RFC-791, USC/Information 
            Sciences Institute, September 1981. 

     Kastenholz        Standards Track - Expires May 2002             9 
                         IP Over Resilient Packet Rings   November 2002 

        [4] Plummer, D.C., "An Ethernet Address Resolution Protocol", 
            RFC826, November 1982. 

        [5] IANA, "Address Resolution Protocol Parameters, 
            http://www.iana.org/assignments/arp-parameters 5 February 
            2002. 

        [6] Crawford, M., "Transmission of IPv6 Packets over Ethernet 
            Networks", RFC2464, December 1998. 

        [7] Rosen, E., et al, "MPLS Label Stack Encoding", RFC 3032, 
            January 2001. 

        [8] IEEE Draft P802.17 “Resilient Packet Ring Access Method and 
            Physical Layer Specifications – medium access control 
            parameters, physical layer interface, and management 
            parameters”. Draft D1.0, August 12, 2002. 

        Acknowledgments 

        The authors acknowledge and appreciate the work and comments of 
        the IPoRPR working group, the IEEE 802.17 working group.  In 
        particular, the review and comments by Albert Herrera have been 
        greatly appreciated. 

     11 Author's Addresses 

        Frank Kastenholz 
        Juniper Networks 
        10 Technology Park 
        Westford, MA, 01886, USA 

        Phone: +1 978 589 0286 
        Email: [email-masked] 

     Kastenholz        Standards Track - Expires May 2002            10 
                         IP Over Resilient Packet Rings   November 2002 

     Full Copyright Statement 

        "Copyright (C) The Internet Society 2002. All Rights Reserved. 
        This document and translations of it may be copied and 
        furnished to others, and derivative works that comment on or 
        otherwise explain it or assist in its implmentation may be 
        prepared, copied, published and distributed, in whole or in 
        part, without restriction of any kind, provided that the above 
        copyright notice and this paragraph are included on all such 
        copies and derivative works. However, this document itself may 
        not be modified in any way, such as by removing the copyright 
        notice or references to the Internet Society or other Internet 
        organizations, except as needed for the purpose of developing 
        Internet standards in which case the procedures for copyrights 
        defined in the Internet Standards process must be followed, or 
        as required to translate it into 

     Kastenholz        Standards Track - Expires May 2002            11 
                         IP Over Resilient Packet Rings   November 2002 

      
     Kastenholz        Standards Track - Expires May 2002            12 
_______________________________________________
IPORPR mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/iporpr

---

From: [email-masked]
Date: Thu, 7 Nov 2002 10:55:32 -0800

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.

---

From: Frank Kastenholz <[email-masked]>
Date: Thu, 07 Nov 2002 14:42:25 -0500

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

Leon, thanks for reading and commenting on it.

>When the 
>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)

>lb] They are called ringlet0 (former outer) and ringlet1 (former Inner) 

Ok, thanks.

>        the shortest path to each destination.
>lb] My suggestion: "IEEE 802.17 includes MAC-level protocols to determine
>the ring topology."

Ok. 

>lb] SONET/SDH and 1 and 10 Gigabit Ethernet are specified in the draft 

Ok

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

>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

---

From: [email-masked]
Date: Thu, 7 Nov 2002 14:29:12 -0800

>is added to the ring, does the MAC update its notion of what TTL

There is *no* way to indicate TTL to the MAC. TTL is set internally by the MAC. And, yes, the MAC adjusts the TTL value as needed, including when topology changes.
_______________________________________________
IPORPR mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/iporpr

---

From: Frank Kastenholz <[email-masked]>
Date: Thu, 07 Nov 2002 17:34:43 -0500

>There is *no* way to indicate TTL to the MAC. TTL is set internally by the MAC. And, yes, the MAC adjusts the TTL value as needed, including when topology changes. 

I just looked. I'd have sworn that there was a TTL field
in the MA_DATA.request. I just looked. I'm wrong. I'll remove
all the TTL goop.

Sorry

Frank

---

From: "Glenn Parsons" <[email-masked]>
Date: Sun, 17 Nov 2002 14:20:14 -0500

Frank,

You have confirmed my concern.

In my short experience (~10 yrs) I notice that designers read the least
number of docs before implementing.  That is, if there any description of
RPR in this document (beyond a short abstract), I submit that it would be
taken by some to be the 'de facto' definition of RPR.

I would prefer to avoid that situation.

As you may be aware, IEEE 802.17 will be forwarding a copy of the WG ballot
version of RPR (similar to an ID in IETF WG last call) to the IESG (for MIB
review) and will also copy this WG.  As a result, I do not see any issue
with not being able to access the document.

As a result, my comment stands that this document should contain no RPR
descriptive text beyond a simple abstract.

Cheers,
Glenn.

> ----------
> From: 	Frank Kastenholz
> Sent: 	Monday, November 11, 2002 3:59 PM
> To: 	Parsons, Glenn [CAR:6L81:EXCH]; [email-masked]
> Subject: 	RE: [IPORPR] draft of a core protocol spec
> 
> At 05:36 PM 11/10/2002 -0500, Glenn Parsons wrote:
> 
> >Frank, 
> >
> >You have noted the various minor corrections to the details on RPR that
> you have included in this draft.  However, I have a more fundamental
> concern.  As we are doing for the RPR MIB, I believe that the
> specification for RPR should be definitively in IEEE 802.17.  That is,
> your proposed document (or any IETF document) should not include any
> details of RPR that could be construed as being a definition.  Even if a
> subset of the RPR definition looks the same, I would suggest that it may
> be interpreted differently.  That is something we want to avoid.  This
> document should only describe the payload format when it is IP, the
> details of RPR are irrelevant (since it is a broadcast media).
> >
> >As such, I would recommend that all of the RPR pedagogy (all of section 3
> and most of 4) be deleted. 
> 
> Glenn
> Thanks for your comments
> 
> In no way should this draft be considered to attempt to replace
> or supplant the 802.17 work. Section 3 is meant to be just enough
> of an overview of the technology so that people reading the spec
> by itself (such as the IESG will be doing when they review it) will
> be able to understand the rest of it. I would be more than happy
> to put some stronger text at the front saying that the section is
> just a brief, highlevel, description of the aspects of 802.17 that
> are relevant to the work that IPoRPR is doing, and/or move it to
> an appendix. But I do feel that having some "RPR pedagogy" is
> both useful and necessary.
> 
> As to section 4 -- that section's goal is to describe various 
> common things that one needs to do to do IP/MPLS over 802.17.
> Things like what values to put in the Ether-type field, where
> the payload is to begin, and so on. Some of the things in 
> here that I thought were 'adjustable' (like the TTL) turn out
> not to be and those would get moved into section 3. Also,
> some things may seem to be too obvious (e.g. that the
> IP header immediately follows the 802.17 header, or that the
> packet type is "data") but one thing that I've learned
> over the last 20+ years of doing TCP/IP development is that
> more often than we would like, the engineers writing the
> code need to be told these simple things.
> 
> Again, thanks for taking the time and brain-cycles to read
> and comment on the document.
> 
> Frank Kastenholz
> 
>

---

From: [email-masked]
Date: Mon, 18 Nov 2002 10:39:15 -0800

I completely agree with Glenn (on this topic :-).
 
jl
-----Original Message-----
From: Glenn Parsons [mailto:[email-masked]]
Sent: Sunday, November 17, 2002 11:20 AM
To: [email-masked]
Cc: 'Frank Kastenholz'
Subject: RE: [IPORPR] draft of a core protocol spec

Frank, 

In my short experience (~10 yrs) I notice that designers read the least number of docs before implementing.  That is, if there any description of RPR in this document (beyond a short abstract), I submit that it would be taken by some to be the 'de facto' definition of RPR.

As you may be aware, IEEE 802.17 will be forwarding a copy of the WG ballot version of RPR (similar to an ID in IETF WG last call) to the IESG (for MIB review) and will also copy this WG.  As a result, I do not see any issue with not being able to access the document.

As a result, my comment stands that this document should contain no RPR descriptive text beyond a simple abstract. 

Cheers, 
Glenn. 

	---------- 
From:   Frank Kastenholz 

	At 05:36 PM 11/10/2002 -0500, Glenn Parsons wrote: 

	>Frank, 
> 
>You have noted the various minor corrections to the details on RPR that you have included in this draft.  However, I have a more fundamental concern.  As we are doing for the RPR MIB, I believe that the specification for RPR should be definitively in IEEE 802.17.  That is, your proposed document (or any IETF document) should not include any details of RPR that could be construed as being a definition.  Even if a subset of the RPR definition looks the same, I would suggest that it may be interpreted differently.  That is something we want to avoid.  This document should only describe the payload format when it is IP, the details of RPR are irrelevant (since it is a broadcast media).

	> 
>As such, I would recommend that all of the RPR pedagogy (all of section 3 and most of 4) be deleted. 

	Glenn 
Thanks for your comments 

	Frank Kastenholz