Subject: GMPLS for MS-SPRing

From: "MEURIC Julien RD-CORE-LAN" <[email-masked]>
Date: Fri, 14 Oct 2005 13:58:16 +0200

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

---

From: Huub van Helvoort <[email-masked]>
Date: Fri, 14 Oct 2005 21:05:52 +0200

Hello Diego,

You wrote:

> Hi Igor,
>        I agree with you but the ID is only a requiremet ID, we tried to
> avoid possible signalling and routing implementation that can satisfy the
> requiremnts.

I agree with you that adding more specific/implementation information
will change the scope of theis I-D.

Kind regards, Huub.
==

> If there is interest in the community about this topic we'll produce IDs to
> satisfy the requiremets.
> 
> Regards
> 
> Diego
> 
> 
> Igor Bryskin <[email-masked]> on 14/10/2005 16.39.55
> 
> To:    Diego Caviglia <[email-masked]>,
>        [email-masked]
> cc:    [email-masked]
> 
> Subject:    Re: GMPLS for MS-SPRing
> 
> Hi Diego,
> 
> 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
> basis.
> 
> Igor
> 
> --- Diego Caviglia <[email-masked]> 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
>>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"
>><[email-masked]>@ops.ietf.org
>>on 14/10/2005 13.58.16
>>
>>Sent by:    [email-masked]
>>
>>
>>To:    "Diego Caviglia" <[email-masked]>
>>cc:    "ccamp" <[email-masked]>
>>
>>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

-- 
================================================================
              http://members.chello.nl/hhelvoort/
================================================================
Always remember that you are unique...just like everyone else...