- I may have missed it, but while your document makes a strict requirement in maintaining the exact order of the multiple TSPECs andFLOWSPECs (outside of those FLOWSPECs that have been discarded), theredidn't seem to be any mention of the *basis* for the establishing theoriginal order of the TSPECs. One would assume that the order is fromthe 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. 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. 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. So, I'd prefer to default to the conservative position of just presenting the minimum.
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.
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."
-ken