Subject: [mpls-tp] wg last call on draft-ietf-mpls-tp-survive-fwk-04.txt

From: "Loa Andersson" <[email-masked]>
Date: Thu, 11 Mar 2010 06:44:21 +0100

All,

this is to start an MPLS  working group last call on
draft-ietf-mpls-tp-survive-fwk-04.txt.

Please send your comments to the [email-masked] mailing
list.

The working group last call ends eob April 2nd, 2010.

/Loa

--

Loa Andersson

Sr Strategy and Standards Manager
Ericsson ///
   phone:  +46 10 717 52 13
           +46 767 72 92 13

   email:  [email-masked]
           [email-masked]

---

From: [email-masked]
Date: Fri, 12 Mar 2010 15:46:57 +0800

Hi Loa and all,

I have read this framework carefully, and found some typo:

(1) section 5: End-to-end PW recovery can be applied to survive any node 
(including S-PE) or  link failure except for the failure of the ingress 
egress T-PE
  "ingress egress T-PE"→"ingress or egress T-PE"

(2)section 6.4.3: MPLS-TP provides OAM tools to isolate a fault and 
determining exactly where a fault has occurred.
  "determining" → "determine "

(3)section 6.4.4:  The endpoints of a recovery domain should be able fault 
conditions detected in the recovery domain to the management plane.
  this senence is not complete, is there some words missed?

（4）section 6.4.5: The protocol is also used to signal administrative 
requests (e.g., manual switch, etc.) when these are provisioned only at on 
edge of the recovery domain.
     "on“ → "one"

Besides the above, I also have some quetions :

(1)section 6.2: In 1+1 protection, the selector (at the receiving end) may 
simply be configured to choose the better signal, thus it does not detect 
a fault or degradation per se, but simply identifies which path is better 
delivering data
 what does "per se" mean here? since I can't find the definition of "se"

(2)section 6.1:  Recovery LSPs (and in particular Restoration LSPs) may be 
provisioned through the management plane.

I think "restoration LSPs" are estiblished by the control plane after 
detecting a fault.  here,  is this should be" protection LSPs"?  Is my 
understanding right?

BR.

Xuehui Dai

Best Regards.
===========================================
祝您新春愉快，工作顺利，身体健康，阖家欢乐！

"Loa Andersson" <[email-masked]> 
发件人:  [email-masked]
2010-03-11 13:44

收件人
[email-masked], [email-masked], [email-masked], [email-masked]
抄送

主题
[mpls-tp] wg last call on draft-ietf-mpls-tp-survive-fwk-04.txt

All,

/Loa

--

Loa Andersson

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

---

From: Adrian Farrel <[email-masked]>
Date: Sat, 13 Mar 2010 11:35:41 +0000

Hello Xuehui,

Thanks for your review.

> I have read this framework carefully, and found some typo:

Thanks. We will pick these up in a revised version after Last Call.

> (1)section 6.2: In 1+1 protection, the selector (at
>  the receiving end) may simply be configured to
>  choose the better signal, thus it does not detect
>  a fault or degradation per se, but simply identifies
>  which path is better delivering data what does
>  "per se" mean here? since I can't find the definition
>  of "se"

"per se" is a Latin phrase often used in English.
It means "by itself" or "of itself".

> (2)section 6.1:  Recovery LSPs (and in particular
>  Restoration LSPs) may be provisioned through the
>  management plane.
>
> I think "restoration LSPs" are established by the
> control plane after detecting a fault.  Here, is
> this should be" protection LSPs"?  Is my
> understanding right?

The authors *did* intend to write "restoration LSPs".

There is nothing that prevents restoration LSPs being set up using the 
management plane. In fact, when there is no control plane, there is no 
alternative.

You may observe that using the management plane in this way is not optimal, 
and it would be better to have a control plane.

Regards,
Adrian