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

[Adrian Farrel <[e-mail]>]

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"

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

---

>> Section 5.2
>>
>> Given that "Number of Members" is a two octet integer, you need
>> to mention the byte order on the wire.
>
> Hmm, RFC 4606 didn't specify the byte order of any of its 16 bit quantities.
> Doesn't this flow from RSVP?  If not please suggest a reference for
> appropriate wording.

Good point.
Inheritance from RSVP covers this.

---

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