Subject: Re: GMPLS for MS-SPRing

From: "Diego Caviglia" <[email-masked]>
Date: Fri, 14 Oct 2005 16:46:21 +0200

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.

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
>
>
>
>
>
>
>
>

__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com

---

From: "Igor Bryskin" <[email-masked]>
Date: Fri, 14 Oct 2005 11:11:18 -0400

Sure,

Would be happy to work on this together.

Igor

----- Original Message ----- 
From: "Diego Caviglia" <[email-masked]>
To: "Igor Bryskin <i_bryskin" <[email-masked]>
Cc: "julien.meuric" <[email-masked]>; "ccamp"
<[email-masked]>
Sent: Friday, October 14, 2005 10:46 AM
Subject: Re: GMPLS for MS-SPRing

---

From: George Swallow <[email-masked]>
Date: Fri, 14 Oct 2005 14:38:39 -0400

Diego -

Is there anything that's General about this?  All that I can think of
off the top of my head is MPLS specific.  If this is the case, then the
draft belongs in MPLS.

...George

========================================================================
George Swallow             Cisco Systems                  (978) 936-1398
                           1414 Massachusetts Avenue
                           Boxborough, MA 01719

---

From: George Swallow <[email-masked]>
Date: Fri, 14 Oct 2005 14:51:05 -0400

Ignore my last post!  Acronym dyslexia on my part.  Looked at SPRing and
thought I saw SRPring...

...George

---

From: Greg Bernstein <[email-masked]>
Date: Fri, 14 Oct 2005 17:32:29 -0700

George, I believe that the LSPs discussed are indeed General LSPs, i.e., 
SDH VC-4, or MPLS LSP.
Note that I'm all for lots of topology info about the rings via routing 
protocols. 
I'd like to see what links are involved with what rings, so if there is 
a ring switch on a particular ring  we can see where we stand as far as 
what traffic maybe currently more vulnerable (e.g. if we get multiple 
faults on the same ring). One could also then see what the current ring 
"covering" on your network looks like.

However, this draft is starting with basic requirements.  Whether GMPLS 
can ever help us get around the lack of interoperability of MS-SPRing 
from multiple vendors may be a bit much to take on...

Greg B.