1 Nov 2009 17:28
Re: draft-ietf-ccamp-gmpls-g-694-lambda-labels and unique resource identification
Greg Bernstein <gregb <at> grotto-networking.com>
2009-11-01 16:28:46 GMT
2009-11-01 16:28:46 GMT
Hi Lou and Richard,
I think a related example that came up in a discussion at a previous CCAMP was of identifying a specific regenerator or wavelength converter used at a particular node. I would think that there could be a "tight binding" between a regenerator or wavelength converter and the laser.
In the latest "compatibility draft" and updated "signaling draft" we start to identify extensions for specifying regeneration at a particular node via additional signaling attributes.
We initially kept this stuff separate from the label, but that was mainly to preserve the notion of wavelengths as labels.
Best Regards
Greg
Lou Berger wrote:
-- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237
I think a related example that came up in a discussion at a previous CCAMP was of identifying a specific regenerator or wavelength converter used at a particular node. I would think that there could be a "tight binding" between a regenerator or wavelength converter and the laser.
In the latest "compatibility draft" and updated "signaling draft" we start to identify extensions for specifying regeneration at a particular node via additional signaling attributes.
We initially kept this stuff separate from the label, but that was mainly to preserve the notion of wavelengths as labels.
Best Regards
Greg
Lou Berger wrote:
Richard, Okay let me try again with a specific case. If I have an rro or ero that identifies the label (lambda) per your document, how does a node know which laser the label corresponds to when all lasers in the system are tunable? Thanks, Lou On 10/29/2009 2:22 PM, Richard Rabbat wrote:sorry for the lag. do you want to describe your use-case further in terms of what you can't do and your proposed change? thanks, Richard. On Thu, Oct 15, 2009 at 8:53 AM, Lou Berger <lberger <at> labn.net <mailto:lberger <at> labn.net>> wrote: Authors, Have you given any additional thought on the repesentation of tunable lasers (and unique resource identification) beyond what is currently in the draft? The current text is: If the node has a tunable wavelength transponder, the tuning wavelength is considered as a part of wavelength switching operation. In the past, labels used for TE LSPs always represented a specific resource that is uniquely identifiable by the node that allocates the label and resource. Such unique identification is important/required for certan restart and other corner cases. Your current definition works fine for fixed lasers that can only be mapped to a single fiber. But, the defined global label will not uniquely identify a resource on a node when (a) tunable lasers are used, or (b) when a node supports multiple fixed lasers that can be (optically) switched to a particular output interface. What are your thoughts on how to provide such link-scoped unique resource identification in the context of your draft? I don't think it'll be too difficult to address this critical point, and see a couple of straightforward solutions if you'd like to discuss off-line. Much thanks, Lou _______________________________________________ CCAMP mailing list CCAMP <at> ietf.org <mailto:CCAMP <at> ietf.org> https://www.ietf.org/mailman/listinfo/ccamp_______________________________________________ CCAMP mailing list CCAMP <at> ietf.org https://www.ietf.org/mailman/listinfo/ccamp
-- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237
_______________________________________________ CCAMP mailing list CCAMP <at> ietf.org https://www.ietf.org/mailman/listinfo/ccamp
~~~
If the issue is:
> In short: either _all_ parts of the RFC should use plural for
> TRACE object(s) in a TraceMonitor Message, or _none_.
>
I would advocate *all singular*, i.e., there's exactly one TRACE object in a
TraceMonitor Message and not multiple.
Thanks,
Dieter
ah <at> TR-Sys.de wrote:
> Dieter,
>
> Your message almost has been scrubbed as spam at our provider,
> because of the lack of 'normal' content. ("HTML-only" is one
> of the most efficient criteria in spam filtering today!)
> However, I have managed to 'de-HTLMize' the message ... 
RSS Feed