Subject: [mpls] Comments on draft-pan-shared-mesh-protection-01

From: Greg Mirsky <[email-masked]>
Date: Mon, 28 Mar 2011 23:13:58 -0700

Dear Authors,
please kindly consider my comments to your proposal.

   - Section 2. I think that "make-before-break" is more often used in
   reference to tunnel recovery, re-routing rather than protection since MBB
   takes advantage of available resources already used by a tunnel. In
   protection diversity of working and protecting paths usually required.
   - Section 3. the path in the example assumed to be bi-directional. I
   think that it is important that they been assumed to be co-routed as well.
   If authors believe that protocol works equally for co-routed as well as
   associated bi-directional MPLS-TP connections, please clarify.
   - I'd suggest to enumerate figures in the text. Will make referencing
   them much easier.
   - Section 6.2 It appears that proposed solution doesn't use ACH TLVs. If
   that is the case, then there's no need to reserve ACH TLV Header
   - Presented formats of STATUS and NOTIFY messages use "Exp" instead of
   "TC" in presenting SLE format
   - Section 7. That is probably my biggest issue with the proposal.
   Effectively, the mechanism is based on MIP generating an OAM message. But
   according to draft-ietf-mpls-tp-oam-framework-11 Section 3.4 generated by
   MIP OAM packet must be sent to the MEP that originated OAM request. In
   proposed mechanism MIP generates OAM packet but it's sent in opposite
   direction.

If I may, I'd consider using Section OAM with GAL as only label and the
context provided by MPLS-TP ID, i.e.MPLS-TP LSP ID as in
draft-ietf-mpls-tp-identifiers-02. Then Activation message format will
require ACH TLV Header as in document's Section 6.2.

Regards,
Greg

---

From: Ping Pan <[email-masked]>
Date: Tue, 29 Mar 2011 09:46:42 +0200

Hi, Greg,

Thanks for the feedback.

>    associated bi-directional MPLS-TP connections, please clarify.
Yes. Will do.

>    - I'd suggest to enumerate figures in the text. Will make referencing
Yes. Will do.

>
>    - Section 6.2 It appears that proposed solution doesn't use ACH TLVs.
>    If that is the case, then there's no need to reserve ACH TLV Header
>
>
OK. Will fix.

>    proposed mechanism MIP generates OAM packet but it's sent in opposite
I don't think this is the case.

First, this is about shared mesh protection, as required in MPLS-TP
(RFC5654). Don't think this is about OAM.

The proposed operation is quite simple:

- The operators set up some protection LSP's for a working one
- The protection LSP's use the network resources shared by other LSP's

- When there is a failure, the headend sends a message to a protection LSP,
saying "activate me"

- The intermediate nodes will do the following:
   - if the resources are not taken, occupy the resources and relay the
message downstream
   - if the resources are taken by a connection with less importance, take
over the resources, relay the message but tell the preempted edge node "you
are gone"
   - else, reply a message to the headend "activation failed"

- The tailend always sends a message back to the headend with either
"success" or "failure"

This is about it!

We may optimize further for performance. However, simplicity is one of the
key design objectives. After all, we intend to process the
activation/de-activation at data-plane with special code, including hardware
assistance, so that we can satisfy TP's performance objective of 50-msec.

Many thanks!

Regards,

Ping

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