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

From: [email-masked]
Date: Thu, 7 Nov 2002 14:33:08 -0800

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

If the reason to put this off is because this first version uses only classC, then fine. But as for the reason specified above, you should have very little worry. When I was designing the service classes for RPR, I modeled them after diffserv. There is an almost perfect mapping both ways between EF and classA, AF and classB, and BE and classC.

jl
_______________________________________________
IPORPR mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/iporpr

---

From: "A.Herrera" <[email-masked]>
Date: Thu, 7 Nov 2002 21:12:23 -0500

> If the reason to put this off is because this first version uses only classC,
then fine. But as for the reason specified above, you should have very little
worry. When I was designing the service classes for RPR, I modeled them after
diffserv. There is an almost perfect mapping both ways between EF and classA, AF
and classB, and BE and classC.
> jl

John,

I have nothing against addressing simple and straightforward
things swiftly. The only reason I'd like to see diffserv mappings
separate is for clarity and consistency. I'd rather see a separate
simple two page draft that addresses PHBs and references the
appropriate architecture or framework document, which in turn can
be referenced by succeeding RPR diffserv drafts as we move forward
along other issues. It also makes it simpler if we ever have to
interact with other WG for feedback/concurrence etc. (Diffserv
within Transport). It also makes it simpler as the other
WGs move forward with issues of their own that might impact us
such as PDB's, etc.

Again, nothing prevents us from doing work now in preparation
for a re-charter. I just want to keep the core spec focused.

Albert