Subject: Liaison received from ITU-T on T-MPLS ring protection

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 17 Dec 2007 16:18:45 -0000

Hi,

We received a liaison from the ITU-T that reads as follows...

   SG15 Q9 has nearly completed its work on a recommendation for
   T-MPLS Ring Protection - G.8132. It is targeted to consent this
   new recommendation in the next SG15 plenary meeting scheduled
   for Feb., 2008.

   We have attached the latest draft for your information and
   comments.

We are requested to comment by 11th February 2008.

At first glance, this work appears to concentrate on the data plane only and 
so is not within our scope. The MPLS working group was also copied and can 
handle any issues concerning the MPLS data plane.

As always, you can see all incoming and outgoing communications for CCAMP at 
www.olddog.co.uk/ccamp.htm

Thanks,
Adrian

---

From: Greg Bernstein <[email-masked]>
Date: Thu, 20 Dec 2007 09:32:01 -0800

Hi all, it seems to me there maybe some implications for GMPLS based on 
previous experience with "software based 4F-BLSRs", that is rings that 
are setup on portions of a mesh network to provide fast redundant 
protection using SDH like ring switching mechanisms.
These types of rings which are applicable to a number of layers 
(optical, SDH, whatever) have traditionally had interoperability 
problems across vendors.  This has typically involved how to share the 
"ring map" information (see section 17.1 of the liaison attachment). In 
addition "nodes" need information on connections added and dropped so 
they can prevent mis-connection (the "squelching" process).

Obviously one way to keep track of a ring map is to "mark" a link as 
belonging to a particular ring and distribute this info via GMPLS routing.

Regards

Greg B.

Adrian Farrel wrote:
> At first glance, this work appears to concentrate on the data plane 
> only and so is not within our scope. The MPLS working group was also 
> copied and can handle any issues concerning the MPLS data plane.
>
> As always, you can see all incoming and outgoing communications for 
> CCAMP at www.olddog.co.uk/ccamp.htm
>
> Thanks,
> Adrian
>
>
>

-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 21 Dec 2007 20:19:13 -0000

Hi Greg,

I see what you are saying.

At the moment, however, there seems to have been no decision about a 
specific control plane for T-MPLS.

There are a couple of ways this could be relevant to us, however...

- Ring protection techniques could be used in a PSC network under the
  control of GMPLS. That is, GMPLS could be used to set up ring
  protection in a PSC network. I would want to see the requirements
  for this, however, since GMPLS appears to provide plenty of
  alternatives for protection and restoration it may be an uphill struggle
  to demonstrate why ring protection is beneficial in a PSC that is
  more like a mesh.

- A GMPLS network may operate over rings that have underlying
  ring protection. In this case the ring protection provides link-level
  protection, and we know how to handle that.

I am a little sceptical about the idea of mixing ring protection with 
end-to-end provisioning. Since MPLS gives us an easy mechanism for 
hierarchy, I don't see why we wouldn't traverse an MPLS protected ring as a 
single hop in an end-to-end LSP.

Anyway...
I think that the current work in the ITU-T for T-MPLS ring protection still 
only refers to the data plane.

Cheers,
Adrian

----- Original Message ----- 
From: "Greg Bernstein" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, December 20, 2007 5:32 PM
Subject: Re: Liaison received from ITU-T on T-MPLS ring protection

> previous experience with "software based 4F-BLSRs", that is rings that are 
> setup on portions of a mesh network to provide fast redundant protection 
> using SDH like ring switching mechanisms.
> These types of rings which are applicable to a number of layers (optical, 
> SDH, whatever) have traditionally had interoperability problems across 
> vendors.  This has typically involved how to share the "ring map" 
> information (see section 17.1 of the liaison attachment). In addition 
> "nodes" need information on connections added and dropped so they can 
> prevent mis-connection (the "squelching" process).
>
>> At first glance, this work appears to concentrate on the data plane only 
>> and so is not within our scope. The MPLS working group was also copied 
>> and can handle any issues concerning the MPLS data plane.
>>
>> As always, you can see all incoming and outgoing communications for CCAMP 
>> at www.olddog.co.uk/ccamp.htm
>>
>> Thanks,
>> Adrian
>>
>>
>>
>
> --