Subject: [mpls] draft-ietf-mpls-tp-ring-protection

From: Lingaraj Mishra <[email-masked]>
Date: Tue, 15 May 2012 23:31:52 -0700 (PDT)

Hello MPLS-TP Protection Authors,
 
I have been following RFC6378 and draft-ietf-mpls-tp-ring-protection for some time.
 
I have some questions regarding same:
 
1 - The RFC6378 does not discuss anything about topology of LINEAR protection i.e 1:n. It does not have clear topological diagrams which it should inherit from SDH protection or T-MPLS protection. If we follow T-MPLS which is REJECTED now, it should discuss SNC and Trail protection mechanisms. The packet networks are not really contained inside LINEAR topology. The most common topology, I would recon is mesh or MESS e.g not sure. The TRANSPORT workd protection linear mechanisms really fall back to 1:n in realistic scenarios for bandwidth contingency. 
 
2 - What are the values of WTR and hold-off timer? This values are normally constant in TRANSPORT world. The hold-on and hold-off values are are defined by G.707 or GR-253 for same. Are there any standard values for MPLS based defects?
3 - Why value of PT(Protection Type) is already fixed(RFC6378) ? Are we planning again new format for RING topology? The RING topology in TRANSPORT world is always 1+1 and Bi-directional.
4 - There is no such provision for ET(Extra Traffic) in case of 1:1 scenario. I think we can include same here not to under-utilize protection PATH.

5  - MPLS-TP slide package published by JWT in June,2008 recommends to use native MPLS protection mechanisms i.e. facility-bypass and de-tour till MPLS-TP ring protection is ready. Is it fine?

I also have some comment on name "Applicability of LINEAR protection in RING topologies".

6 - In steering protection, are end points pre-provisioned?

Please let me know your opinion on above.
We are kind of planning to implement MPLS-TP v1.0 and above will improvise our design.

Regards,
Lingaraj

---

From: Yaacov Weingarten <[email-masked]>
Date: Wed, 16 May 2012 12:16:55 +0300

Lingaraj, hi

Thank you for your comments.  I will try to address some of the issues that
you raise, and will try (with your assistance) to clarify some of your
other points.  See below.

Best regards,
yaacov

On Wed, May 16, 2012 at 9:31 AM, Lingaraj Mishra <[email-masked]>wrote:

> 1 - The RFC6378 does not discuss anything about topology of LINEAR
> protection i.e 1:n. It does not have clear topological diagrams which it
> should inherit from SDH protection or T-MPLS protection. If we follow
> T-MPLS which is REJECTED now, it should discuss SNC and Trail protection
> mechanisms. The packet networks are not really contained inside LINEAR
> topology. The most common topology, I would recon is mesh or MESS e.g not
> sure. The TRANSPORT workd protection linear mechanisms really fall back to
> 1:n in realistic scenarios for bandwidth contingency.
>

yw> Not sure that I fully understand what you are saying here - what
topology are you looking for beyond that given in Figure 3 and the
explanation given in the Survivability Framework (RFC6372)  and section 1.1
of the document.  Regarding mesh protection and 1:n protection there are
additional drafts that address these and propose extensions or
modifications of the basic PSC protocol.

> 2 - What are the values of WTR and hold-off timer? This values are
> normally constant in TRANSPORT world. The hold-on and hold-off values are
> are defined by G.707 or GR-253 for same. Are there any standard values for
> MPLS based defects?
>

yw> The protocol definition does not provide values for the timers, as a
result of discussions that we had in the WG.  These should either appear in
the MIB definition or possibly in an ITU document that references the RFC.

>  3 - Why value of PT(Protection Type) is already fixed(RFC6378) ? Are we
> planning again new format for RING topology? The RING topology in TRANSPORT
> world is always 1+1 and Bi-directional.
>

yw>Do not understand the connection between the PT field (that just
identifies the difference between 1:1/1+1 or uni|bi directional) and the
different topologies.  As to your generalization of rings "always being
1+1" in the transport world, I can attest that G.8032 (ERP) is not 1+1
protection in a transport environment.

>  4 - There is no such provision for ET(Extra Traffic) in case of 1:1
> scenario. I think we can include same here not to under-utilize protection
> PATH.
>

yw> According to RFC5654 (TP Reqs) - extra traffic is frowned upon in
transport networks, and therefore it is not explicitly addressed, however,
the understanding is that this would be pre-empted whenever the protection
path is trigerred for a switch.

>
> 5  - MPLS-TP slide package published by JWT in June,2008 recommends to use
> native MPLS protection mechanisms i.e. facility-bypass and de-tour till
> MPLS-TP ring protection is ready. Is it fine?
>

yw> Yes, most certainly.  The ring protection draft is wirtten for
operators that prefer to use a data-plane protocol for performing
protection and demonstrates how PSC could be used to perform this
switchover.

> I also have some comment on name "Applicability of LINEAR protection in

yw> what is your comment?

> 6 - In steering protection, are end points pre-provisioned?

yw> could you be specific about what provisioning you are referring to

> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>
>

---

From: Lingaraj Mishra <[email-masked]>
Date: Wed, 16 May 2012 09:50:05 -0700 (PDT)

Hi,
 
Thank you for answers below.
Please find my gratitude and some extended questions inline.
 
Regards,
Lingaraj

________________________________
 From: Yaacov Weingarten <[email-masked]>
To: Lingaraj Mishra <[email-masked]> 
Cc: "[email-masked]" <[email-masked]> 
Sent: Wednesday, May 16, 2012 2:46:55 PM
Subject: Re: [mpls] draft-ietf-mpls-tp-ring-protection

Lingaraj, hi

Thank you for your comments.  I will try to address some of the issues that you raise, and will try (with your assistance) to clarify some of your other points.  See below. 

Best regards,
yaacov

On Wed, May 16, 2012 at 9:31 AM, Lingaraj Mishra <[email-masked]> wrote:

>1 - The RFC6378 does not discuss anything about topology of LINEAR protection i.e 1:n. It does not have clear topological diagrams which it should inherit from SDH protection or T-MPLS protection. I…

yw> Not sure that I fully understand what you are saying here - what topology are you looking for beyond that given in Figure 3 and the explanation given in the Survivability Framework (RFC6372)  and section 1.1 of the document.  Regarding mesh protection and 1:n protection there are additional drafts that address these and propose extensions or modifications of the basic PSC protocol. 

[lmishra] In general, I was referring to diagram showing "how n working paths are protected by 1 protection path". As I read RFC6372 in context of 1:n protection, found below:
Section 4.7.1:
In the general case of 1:n linear protection, one protection entity is allocated to protect n working entities. "Here a diagram will be nice."

Section 4.7.2:
A 1:n protection scheme for P2MP transport paths is also required by  [RFC5654].  Such a mechanism is for future study.

Also I understand that SONET/SDH based networks always have fixed relationship like: 1:n (revertive) and 1+1(non-revertive). Here in RFC6372, we are picking on bridging and switching mechanisms differently. 

yw> The protocol definition does not provide values for the timers, as a result of discussions that we had in the WG.  These should either appear in the MIB definition or possibly in an ITU document that references the RFC. 

[lmishra] Thank you for an exact answer. 
3 - Why value of PT(Protection Type) is already fixed(RFC6378) ? Are we planning again new format for RING topology? The RING topology in TRANSPORT world is always 1+1 and Bi-directional. 

yw>Do not understand the connection between the PT field (that just identifies the difference between 1:1/1+1 or uni|bi directional) and the different topologies.  As to your generalization of rings "always being 1+1" in the transport world, I can attest that G.8032 (ERP) is not 1+1 protection in a transport environment. 

[lmishra] I meant that "We have 2 bits and 3 values already allocated". But, PSC channel type is going to serve to LINEAR, RING and MESH protection. Only one is done and two to go. What willl we do for any new PT needed for those topologies?
 
>4 - There is no such provision for ET(Extra Traffic) in case of 1:1 scenario. I think we can include same here not to under-utilize protection PATH.

yw> According to RFC5654 (TP Reqs) - extra traffic is frowned upon in transport networks, and therefore it is not explicitly addressed, however, the understanding is that this would be pre-empted whenever the protection path is trigerred for a switch. 

[lmishra] Thank you. I got ref. section 4.3.3 RFC6372.

>5  - MPLS-TP slide package published by JWT in June,2008 recommends to use native MPLS protection mechanisms i.e. facility-bypass and de-tour till MPLS-TP ring protection is ready. Is it fine? 

yw> Yes, most certainly.  The ring protection draft is wirtten for operators that prefer to use a data-plane protocol for performing protection and demonstrates how PSC could be used to perform this switchover. 

[lmishra] Why are we naming it as LINEAR protection mechanisms are applied in RING topologies. These are not exactly suitable. Even though they sound same as 1:1 or 1+1, it is completely different. The most fundamental part is that every node in RING topology is topology aware and maintain node database as oppose to LINEAR topology. This is how it is done in optical networks i.e SONET/SDH.

[lmishra] How do you maintain information at ingress node where steering is done irrespective of any segment failure among any intermediate adjacent nodes between ingress-to-egress ?