Re: draft of a core protocol spec
"A.Herrera" <[email protected]> Thu, 7 Nov 2002 21:12:23 -0500
| Newsgroups | gmane.ietf.iporpr |
|---|---|
| Message-ID | <[email protected]> |
> >> 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 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