Re: Closing the GELS Mailing List

["tom.petch" <cfinss@dial.pipex.com>]

Adrian

Just to break the pattern, I am not on the GELS list - never got round to it -
and would be very happy to see them merged.

A list should reflect a community of interest and I think that there is only one
here.  The work of CCAMP has a wider impact on other SDOs and liaisons form a
significant part of CCAMP's work.  Where GELS is different is the SDO to liaise
with, but I do not see that as justification for a separate list.

Tom Petch


----- Original Message -----
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "PAPADIMITRIOU Dimitri" <Dimitri.Papadimitriou@alcatel-lucent.be>; "Zafar
Ali (zali)" <zali@cisco.com>; "Attila Takacs (IJ/ETH)"
<Attila.Takacs@ericsson.com>; <ccamp@ops.ietf.org>; "gels" <gels@rtg.ietf.org>
Cc: "Ross Callon" <rcallon@juniper.net>
Sent: Friday, September 07, 2007 10:59 AM
Subject: Re: Closing the GELS Mailing List


> I think this thread is a representation in miniature of the issues
> involved...
>
> - All the emails in this thread have been copied to both mailing lists
> - All the participants in the thread are subscribed to both mailing lists
>
> No, it doesn't cost to have both lists active.
> No, it doesn't cost to have all of the threads on CCAMP.
>
> Please note that we should not discuss the data plane. If you don't
> understand (or don't like, or don't want to use) the data plane you should
> have your discussions in private or at the IEEE.
>
> Dimitri said...
>
> >> - Label allocation and swapping rules
> > is that not a forwarding component discussion ?
>
> It is certainly informed by the forwarding component (i.e. the definition of
> the data plane), but the rules we need to define are the rules for the
> control plane. I.e. (and for example, only) if the forwarding plane defines
> that the label allocated on the upstream interface must be numerically one
> greater than the label allocated on the downstream interface, this rule must
> be referenced in the control plane specification. This is important since it
> is a constraint placed on the normal per-interface operation of GMPLS. That
> makes it CCAMP work.
>
> > beside the fact that there is an assumption on what
> > label means and how it is represented in data plane
>
> This is also something we would expect to describe within CCAMP although
> "what is a label" would come to us from the data plane specification.
>
> Thanks,
> Adrian