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

["Adrian Farrel" <[e-mail]>]

Hi Liu,

Thanks for reviewing.

> 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?

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

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

Good catch.
Thanks.

> 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?

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?

> 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 ;

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