Subject: RE: [IPORPR] draft of a core protocol spec

From: Frank Kastenholz <[email-masked]>
Date: Mon, 11 Nov 2002 15:59:15 -0500

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
_______________________________________________
IPORPR mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/iporpr

---

From: nitin panjwani <[email-masked]>
Date: Mon, 11 Nov 2002 14:24:54 -0800 (PST)

Hi All,

I am new to RPR world and probably have not great
undrstanding of it yet.
I was thinking how the network will work when there is
mpls protection working over RPR network. Wouldn't
this double protection delay the traffic and probably
affect the throughput and speed. Is there any document
available which talks about this and what are the
thoughts of RPR gurus about it.

Regards,
Nitin 

__________________________________________________
Do you Yahoo!?
U2 on LAUNCH - Exclusive greatest hits videos
http://launch.yahoo.com/u2
_______________________________________________
IPORPR mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/iporpr

---

From: "A.Herrera" <[email-masked]>
Date: Mon, 11 Nov 2002 19:29:28 -0500

RPR protection switching provides a mechanism
similar to MPLS's FastReRoute detour paths
for failure recovery.

There's no reason to enable this on RPR rings
since RPR protection will steer/wrap away from
faults at L2 within 50ms.

Now, in terms of MPLS end-to-end path re-optimization
during fault detection, the ring will remain a
viable path regardless of any faults that occur
within the ring.

Albert

----- Original Message -----
From: "nitin panjwani" <[email-masked]>
To: "Frank Kastenholz" <[email-masked]>; "Glenn Parsons"
<[email-masked]>; <[email-masked]>
Sent: Monday, November 11, 2002 5:24 PM
Subject: [IPORPR] RPR protection with MPLS