[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GMPLS for MS-SPRing
One thing that I'd suggest adding to your draft is
ability to compute and signal LSP paths in terms of
rings rather than in terms of links, and let ring
border LSRs to expend the paths - provide paths within
the rings. This mechanism is especially handy when
there is a need for path-segment recovery on per-ring
--- Diego Caviglia <Diego.Caviglia@marconi.com> wrote:
> 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
> 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
> 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
> 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
> "MEURIC Julien RD-CORE-LAN"
> on 14/10/2005 13.58.16
> Sent by: email@example.com
> To: "Diego Caviglia" <Diego.Caviglia@marconi.com>
> cc: "ccamp" <firstname.lastname@example.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.
Yahoo! Mail - PC Magazine Editors' Choice 2005