Hi Julien,
is always a pleasure to discuss this
topics with you.
You are right and a clarification is definitely
needed here.
Basically Ring ID parameter is a common identifier
for all the TE links
belonging to the same ring.
In such a way, in a no-control plane/pre-GMPLS
scenario, from a management
plane point of view it is possible to
discern if a given node belongs to a given ring by
checking its Ring ID.
In an advanced scenario, where a control plane
(GMPLS based) is in place
"between" data and management plane, the Ring ID
parameter keeps on
doing the same function of making possible the
association of a given TE
link with the ring it belongs to.
Why is this information needed at control plane
level? Think of a routing
protocol deployed over control plane, say GOSPF-TE.
When we come at dealing
with MSSPRING inherent requirements that control
plane has to be compliant
with, there are spring related informations that a
routing protocol has to
flood over the network (as opaque) to make possible
correct operation.
Among them there could be (depending on the strategy
that'll be followed)
the information about a TE link as belonging or not
to a ring and, if yes,
to which ring. In this case Ring ID serves the
purpose.
For a ingress node running Path Computation Engine
it is important to know
this attribute of a TE link to take special routing
decisions or to try to
satisfy given requirements involving MSSPRING
traversing.
In addition, ring ID information could be used if
some information
interests only the TNE's belonging to a given ring
and has to be flooded
only to the TNEs in that ring. In this case Ring ID
could be used by a TNE
belonging to a ring to check if its OSPF neighbor
belongs tho the same ring
and hence if a given LSA has to be sent to it or
not.
These are examples of possible usage of Ring ID
within control plane. Apart
from these specifc uses, there could be other cases
to be defined where a
similar identifier is needed. Of course it depends
on which strategy is
chosen to handle MSSPRING management and
requirements from control plane.
Hope this clarify.
Best Regards
Diego
"MEURIC Julien RD-CORE-LAN"
<julien.meuric@francetelecom.com>@ops.ietf.org
on 14/10/2005 13.58.16
Sent by: owner-ccamp@ops.ietf.org
To: "Diego Caviglia" <Diego.Caviglia@marconi.com>
cc: "ccamp" <ccamp@ops.ietf.org>
Subject: GMPLS for MS-SPRing
Hello Diego.
I have just read your
draft-caviglia-ccamp-gmpls-msspring-req-00.txt about
GMPLS requirements for MS-SPRing. I am glad to see
you have again a
pragmatic approach to ease operators' migration from
legacy SDH to GMPLS.
In paragraph "2.1 LSP Set-Up", you mention a
"RingId" required by the
management plane and useless for the data plane
itself. I am not
questionning this necessity (I am not a management
expert), but I do not
really understand why it should be handled by the
control plane. I imagine
this is related to communication between control and
management, but a
clarification may be required here.
Thanks
Julien