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

[Adrian Farrel <[e-mail]>]

Sounds good, thanks.

I'll look to see the new version and then move it forwards.

Adrian

> -----Original Message-----
> From: Greg Bernstein [mailto:[e-mail]]
> Sent: 04 May 2011 17:08
> To: [e-mail]
> Cc: [e-mail];
[e-mail];
> 'CCAMP'; [e-mail]
> Subject: Re: AD review of draft-ietf-ccamp-gmpls-vcat-lcas-11.txt
> 
> 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]