Re: [CCAMP] AD review of draft-ietf-ccamp-gmpls-vcat-lcas-11.txt

[Greg Bernstein <[e-mail]>]

Hi Adrian and all, thanks for the helpful text see the disposition of 
comments below.
The new version is in the process of being posted, but slightly delayed 
due to a tool problem.
Cheers

Greg
On 5/3/2011 2:35 AM, Adrian Farrel wrote:
> Hi Greg,
>
> Thanks for the revision. It's looking good.
>
> I've cut down to the short list of open issues.
>
> I'll mark the I-D as "revised I-D needed" again.
>
> Thanks,
> Adrian
>
>>> Section 2.2
>>>
>>> Should you include a definition of "co-routed". This is not quite as
>>> obvious as it might seem since the meanings could be:
>>> - same routers in the same order (includes parallel links)
>>> - same logical links in the same order (includes bundles)
>>> - same data links in the same order (i.e. same physical interfaces)
>>>
>>> A bit of this comes out through careful reading of the different
>>> categories, so maybe it is not needed, but it might help.
>> Hmm, we only seem to use this term in the requirements section.  I
>> meant to use it more in the VCAT notion of signals going across the
>> same nodes and similar links, i.e., not introducing huge differential
>> delays.  The main point was to differentiate this from diversely routed
>> (or partially diversely routed VCG members).
> I *love* your "similar links"
--> Glad I could brighten your day ;-)
>>    Is there particular text you would like to see added?
> Well, it is hard for me to supply the precise text, since it is your definition.
>
> I would suggest to add a new second paragraph of 2.2 along the lines of...
>
> The scenarios listed here are dependent on the terms "co-routed" and "diversely
> routed". In the context of this document, "co-routed" refers to a set of VCAT
> signals that all traverse the same sequence of switching nodes. Furthermore, a
> co-routed set of signals between any pair of adjacent nodes utilize a set of
> links that have similar delay characteristics. Thus, "diversely routed" means a
> set of signals that are not classed as "co-routed". Note that a request for a
> set of diversely routed signals might be satisfied by a set of co-routed
> signals.
>
> ---
--> Used almost all of the above:

The scenarios listed here are dependent on the terms "co-routed" and "diversely
routed". In the context of this document, "co-routed" refers to a set of VCAT
signals that all traverse the same sequence of switching nodes. Furthermore, a
co-routed set of signals between any pair of adjacent nodes utilize a set of
links that have similar delay characteristics. Thus, "diversely routed" means a
set of signals that are not classed as "co-routed".


--snip--
>>> Section 5.2
>>>
>>> Should you also have a registry for the Elementary Signal
>>> Types listed in this section? it seems likely that there will
>>> be future additions to the list. You should say that unlisted
>>> values are reserved and you should say what the allocation
>>> policy is for future values.
>>>
>>> The same applies to "Action" since future actions might
>>> show up.
>> Sounds good.  Is there example text for this somewhere that
>> I can leverage?
> It is as simple as:
>
> 7.3 VCAT Elementary Signal Registry
>
> IANA is requested to create a registry to track elementary signal types as
> defined in Section 5.2. New allocations are by "IETF Review" [RFC5226].
>
> IANA is requested to track:
>
> - Value
> - Type (Elementary Signal)
> - RFC
>
> The available range is 0 - 65535
> The registry should be initially populated with the values shown in Section 5.2
> of this document. Value 0 should be marked as Reserved. Other values should be
> marked Unassigned.
>
> 7.4 VCAT VCG Operation Actions
>
> IANA is requested to create a registry to track VCAT VCG operation actions as
> defined in Section 5.2. New allocations are by "IETF Review" [RFC5226].
>
> IANA is requested to track:
>
> - Value
> - Meaning
> - RFC
>
> The available range is 0 - 255
> The registry should be initially populated with the values shown in Section 5.2
> of this document. Other values should be marked Unassigned.
>
> [You will need to add an informative reference to 5226]
--> Fixed using your text and adding a reference to RFC 5226.
>
>
>


-- 
===================================================
Dr Greg Bernstein, Grotto Networking [phone]