[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [tsvwg] draft-polk-tsvwg-intserv-multiple-tspec-01.txt

Ken

comments in-line

At 10:16 AM 10/23/2009, ken carlberg wrote:

- I may have missed it, but while your document makes a strict
requirement in maintaining the exact order of the multiple TSPECs and
FLOWSPECs (outside of those FLOWSPECs that have been discarded),
there
didn't seem to be any mention of the *basis* for the establishing the
original order of the TSPECs.  One would assume that the order is
from
the highest set of resources to the lowest.  And if this is the case,
it needs to be explicitly stated.


This is a dilemma, as there is no ability to signal the order, other
than to maintain the order in the PATH.  Now, if you get merging,
and happen to keep the relative orders within each FLOWSPEC (which
we RECOMMEND in -02), how does the merging node know which is more
important of two lists (1,2,3) and (a,b,c)?  I think you have to go
with r for Controlled load and R for Guaranteed Service.  Got any
other suggestions?


well, Control Load and Guaranteed Service are kind of like oranges and
grapefruit -- both part of the citrus family, but not things you'll
merge with each other.


I'm sorry I confused you. I never meant to imply CL and GS would ever merge.
I was giving the limitation of merging FLOWSPEC-A of 1,2,3 and FLOWSPEC-B of a,b,c the limitation of just how to you merge the two in the right order? I can't think of a solution now, but I believe we need to maintain the relative preference order within any one FLOWSPEC intact (for either all CL or all GS), agreed? 


instead, unless I missed something, you'll
only end up merging different Control Load *or* different Guaranteed
Service TSPECs.  Or does Cisco have a value added policy service that
can merge the two different service classes. (my apologies, I'm going
by my ancient memory from the original discussions on the topic)


- For section 3, I don't see the need to restate the original TSPEC
and FLOWSPEC.  Just show the new MULTI_TSPEC and MULTI_FLOWSPEC.


are you sure?


yes :-)


it's showing the contrast from how it is today with how we're
changing it...


understood, and actually I did something similar ages ago, and was
asked to remove it.  Initially, I wasn't thrilled, but in the end you
need to ask yourself what exactly is gained by showing the what has
changed in the same document.
well, it's not "...in the same document." but contrasting what's changed " ...by this document verses what's in RFCs previous to this document." 

Does that make more sense?


It doesn't change the new
specification, and if the implementor/designer/architect needs a
refresher of the original TSPEC/FLOWSPEC format, he or she can simply
bring up a new window or be non-eco-friendly and print out the old
specs.
if they can find the old spec. I'm the not the first to admit RFCs 2205-15 weren't the best arranged grouping of RFCs (even within any one of them (with the possible exception of 2205)). 


So, I'd prefer to default to the conservative position of just
presenting the minimum.
if need be, I can try and find the exact figure in the exact RFC number for someone who needs this refresher to go and look at (to prevent further laziness ;-) 



2) its probably best to stay with the naming convention of rfc-2205
and just use the terms sender and receiver.  Calling and Called node
has too much of a telephony connotation, and I think it would be
better to be application neutral in this document.


sender and receiver from the perspective of the PATH or RESV?

each are opposite, so I though Calling Node and Called node would be
easier to understand.


different, but there is consistency.  Senders always send the PATH
message downstream, and the receiver always sends the RESV upstream.
This isn't so understood by the community, and if it was, I'd have gone with that in the first place. 



5) section 1, paragraph 5.  You need to reword the last sentence of
the following paragraph

  "Thus the current mechanism of the Integrated Services, and
therefore
  RSVP, allowing the PATH generator to only provide one traffic
  specification and for the resulting RESV generator to only include
  one bandwidth request is limiting. "


rewrote to

 "It is therefore limiting to have a single bandwidth request in
 Integrated Services, and by extension, RSVP."

how's this?


ok.  Another suggestion is to say, "It is therefore limiting in terms
of the potential inefficiency of multiple RTT to have a single request
for resources in Integrated Services, and by extension, RSVP."


ok

twist my arm

;-)

Thanks

James



-ken