Subject: Re: [mpls-tp] [mpls] Last Call: draft-ietf-mpls-tp-survive-fwk (Multiprotocol Label Switching Transport Profile Survivability Framework) to Informational RFC

From: [email-masked]
Date: Fri, 23 Apr 2010 16:48:19 +0800

hi,all
I review this draft, I maybe have a few confusions  about the draft. maybe 
there is a little error editors in  this draft.
1 in section 1.3, there is a a describles for associated bidirection LSP 
recovery
 " This may also be the case for associated
   bidirectional LSPs where the two directions of the LSP follow
   different paths through the network.  This causes direct interaction
   between the recovery processes affecting the two directions of an
   LSP, so that both directions of the LSP are recovered at the same
   time (i.e., bidirectional recovery is a consequence of fate-sharing)."
IMO, this mean it should need to have fate-sharing for associated 
bidirection lsp?
if one direction working path have failure, another direction working path 
must
switch into protection path?

2 in section 2 Terminology and Reference
  there are two the same definitions for Restoration 
  maybe delete one definitions for Restortion;

3 there are MPLS-TP Section level and Link layer concept. I want to 
  know what difference between MPLS-TP Section Level and MPLS-TP Link 
layer?

4 Section 4.7.3 P2MP Linear Protection
  As there is a requirement of P2MP support 1:n protection in RFC 5654,
  so I suggest to add 1:n protection solution in this section or further
  study for 1:n protection of p2mp ;

best regards
liu

The IESG <[email-masked]> 
发件人:  [email-masked]
2010-04-23 03:03
请答复 给
[email-masked]

收件人
IETF-Announce <[email-masked]>
抄送
[email-masked]
主题
[mpls] Last Call: draft-ietf-mpls-tp-survive-fwk (Multiprotocol Label 
Switching Transport Profile Survivability Framework) to Informational RFC

The IESG has received a request from the Multiprotocol Label Switching WG 
(mpls) to consider the following document:

- 'Multiprotocol Label Switching Transport Profile Survivability 
   Framework '
   <draft-ietf-mpls-tp-survive-fwk-05.txt> as an Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
[email-masked] mailing lists by 2010-05-06. Exceptionally, 
comments may be sent to [email-masked] instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-survive-fwk-05.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=18472&rfc_flag=0

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

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 23 Apr 2010 22:21:21 +0100

Hi Liu,

Thanks for reviewing.

> must switch into protection path?

I think there is some confusion between bidirectional LSP and bidirectional 
recovery.

It is possible that this text is too dense. Can I suggest to modify it as 
follows:

OLD
   Co-routed bidirectional MPLS-TP LSPs are defined in a way that allows
   both directions of the LSP to follow the same route through the
   network. In this scenario, the operator often requires the directions
   to fate-share (that is, if one direction fails, both directions
   should cease to operate).  This may also be the case for associated
   bidirectional LSPs where the two directions of the LSP follow
   different paths through the network.  This causes direct interaction
   between the recovery processes affecting the two directions of an
   LSP, so that both directions of the LSP are recovered at the same
   time (i.e., bidirectional recovery is a consequence of fate-sharing).
NEW
   Co-routed bidirectional MPLS-TP LSPs are defined in a way that allows
   both directions of the LSP to follow the same route through the
   network. In this scenario, the operator often requires the directions
   to fate-share (that is, if one direction fails, both directions
   should cease to operate).

   Associated bidirectional MPLS-TP LSPs exist where the two directions
   of a bidirectional LSP follow different paths through the network.
   An operator may also request fate-sharing for associated
   bidirectional LSPs.

   The requirement for fate-sharing causes a direct interaction between
   the recovery processes affecting the two directions of an LSP, so
   that both directions of the bidirecitonal LSP are recovered at the
   same time. This mode of recovery  is termed bidirectional recovery
   and may be seen as a consequence of fate-sharing.
END

>  maybe delete one definitions for Restortion;

Good catch.
Thanks.

>  know what difference between MPLS-TP Section Level and MPLS-TP Link

Hmmm.
In fact, we only mention "section level" once in the whole document.
Section 4.4.1 has:
   A protection mechanism may be provided at the MPLS-TP link layer
   (which connects two MPLS-TP nodes).  Such a mechanism can make use of
   the procedures defined in [RFC5586] to set up in-band communication
   channels at the MPLS-TP section level, to use these channels to
   monitor the health of the MPLS-TP link, and to coordinate the
   protection states between the ends of the MPLS-TP link.
If I recall right, this text was gifted to us by the latest ITU-T liaison.

Anyway, I think the point is that the section level OAM operates on a single 
link between a pair of MPLS-TP routers. The protection, of course, requires 
the use of multiple "parallel" links. So "section level" applies to a single 
link, and "link level" applies to a set of links.

If this distinction continues to worry you, maybe the best approach would be 
to remove this reference to "section level". What do you think?

>  study for 1:n protection of p2mp ;

You're right. R67B of RFC5654.

I propose to add a new final paragraph to section 4.7.3. as follows.

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

OK?

Many thanks,
Adrian

---

From: [email-masked]
Date: Mon, 26 Apr 2010 15:13:17 +0800

Adrian
thank you for replying , I think it maybe more clear to change it 
according to your opinions for everyone.

best regards
liu

"Adrian Farrel" <[email-masked]> 
2010-04-24 05:21
请答复 给
"Adrian Farrel" <[email-masked]>

收件人
<[email-masked]>
抄送
<[email-masked]>, <[email-masked]>
主题
Re: [mpls] Last Call: draft-ietf-mpls-tp-survive-fwk (Multiprotocol Label 
Switching Transport Profile Survivability Framework) to Informational RFC

Hi Liu,

Thanks for reviewing.

> must switch into protection path?

I think there is some confusion between bidirectional LSP and 
bidirectional 
recovery.

OLD

Good catch.
Thanks.

Hmmm.

Anyway, I think the point is that the section level OAM operates on a 
single 
link between a pair of MPLS-TP routers. The protection, of course, 
requires 
the use of multiple "parallel" links. So "section level" applies to a 
single 
link, and "link level" applies to a set of links.

If this distinction continues to worry you, maybe the best approach would 
be 
to remove this reference to "section level". What do you think?

OK?

Many thanks,
Adrian

---

From: "Shahram Davari" <[email-masked]>
Date: Mon, 26 Apr 2010 10:35:32 -0700

Hi,

I have a comment regarding this draft.

This draft states that an MPLS-TP tunnel can be protected in one of its segments without use of a PST. This I assume is something similar to FRR detour protection. What is not clear in the draft is how is OAM (and not control plane) used to detect failure so that an intermediate node can perform protection. As we know an intermediate node can't initiate BFD.

Thanks,
Shahram

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Mon, 26 Apr 2010 20:04:38 +0200

Hi Shaharm,

I cannot recall that we used the statement exactly as appears below, but
in principle this is correct.  RFC 4873
<http://datatracker.ietf.org/doc/rfc4873/>  provides a solution for
segment protection, without using a PST. 

The draft is a framework and it introduces various elements of control
to trigger the recovery action (e.g. OAM signaling, network failure
detection, control-plane signaling, administrative commands, etc.),
different levels of recovery, different mechanisms, etc. 

It is correct that in order to monitor a segment of a path using OAM we
need a PST, because OAM messages may be initiated only by MEPs which
reside at the endpoints of a path. But there other elements of controls
that can be used as well and the framework introduce them as well. RFC
4873 for example makes use of the control-plane signaling to trigger a
recovery. 

Best regards,

Nurit

P.S. please note that FRR is limited in its applicability as it handles
uni-directional protection switching only!

From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext Shahram Davari
Sent: Monday, April 26, 2010 8:36 PM
To: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] Last Call: draft-ietf-mpls-tp-survive-fwk
(Multiprotocol Label Switching Transport Profile Survivability
Framework) to Informational RFC

Hi,

This draft states that an MPLS-TP tunnel can be protected in one of its
segments without use of a PST. This I assume is something similar to FRR
detour protection. What is not clear in the draft is how is OAM (and not
control plane) used to detect failure so that an intermediate node can
perform protection. As we know an intermediate node can't initiate BFD.

Thanks,

Shahram