Subject: [mpls-tp] AD Review of draft-ietf-mpls-tp-survive-fwk-04.txt

From: Stewart Bryant <[email-masked]>
Date: Thu, 01 Apr 2010 18:22:59 +0100

As requested I have carried out my AD review slightly before the end of 
WGLC completion.

The purpose of an AD review is to check that the document is ready to go 
to IETF last call and IESG review. The intention is to find most of the 
issues that might be found at those stages and so smooth  the passage of 
the I-D and reduce the load on the IESG in general.

I found the document to be well written and the issues I comment on are 
pretty minor.

- Stewart

Multiprotocol Label Switching Transport Profile Survivability Framework

                 draft-ietf-mpls-tp-survive-fwk-04.txt

1.2. Recovery Action Initiation

   The protection switching operation is basically a data-plane
   capability and in the context of MPLS-TP it needs to be ensured that
SB> Surely the "protection switching operation" is a DP "action" rather 
than "capability"
   it is possible to switch over independent of the way the network is
   configured and managed. 

1.4. Scope of this Framework

   The general description of the functional architecture is applicable
   for both LSPs and pseudowires (PWs), however, PW recovery is only
   introduced in Section 7, and the details are out of scope for this
   document.

   This framework applies to general LSP recovery schemes, but also to
   schemes that are optimized for specific topologies in order to handle
   protection switching in an efficient manner.  Recovery schemes
   for PWs are introduced in Section 7, but the details are for further
   study and will be addressed in a separate document.

SB> The above two paras repeat each other WRT PWs

2. Terminology and References

3. Requirements for Survivability

SB> Why do we need to spend so much of the document paraphrasing the 
requirements?
SB> I would have thought that it was adequate to simply point to RFC5654,
SB> and that this section could be reduced to the introductory material
SB> in the first para  see below.

   MPLS-TP requirements are presented in [RFC5654] and serve as a
   normative reference for the definition of all MPLS-TP function
   including survivability.  Survivability is presented in [RFC5654] as
   playing a critical role in the delivery of reliable services, and the
   requirements for survivability are set out using the recovery
   terminology defined in [RFC4427].

4.6.1. Mesh Networks

   Linear protection is a mechanism of protection and protection state
   coordination that provides a fast and simple protection switching
   that fits best in mesh networks since it can operate between any pair

SB> The above implicitly states that an alternate mechanism is needed in 
rings is that what we mean to say?

6.4. OAM Signaling

   MPLS-TP provides a comprehensive set of OAM tools for fault
   management and performance monitoring at different nested levels
   (end-to-end, a portion of a path (LSP or PW) and at the link level).
SB> Probably needs a cross ref to OAM Framework

    A MIP is capable of reacting to OAM messages.
SB> This is a bit of a hot topic, do we need to say this here?
SB> OAM FWK covers this topic anyway

7.1. Utilizing Underlying MPLS-TP Recovery

   MPLS-TP PWs are carried across the network inside MPLS-TP LSPs.
   Therefore, an obvious way to protect a PW is to protect the LSP that
   carries it. 
SB> This does not protect the Attachment Circuits, or T-PEs - You talk to
SB> this a little bit later.

7.2. Recovery in the Pseudowire Layer

  (for example, by running over the same LSP tunnel - compare
   with Section 4.6.2).

SB> "compare with Section" is an English fragment.

12.1. Normative References

   [MPLS-TP-FWK]
              Vigoureux, M., Ed., Ward, D., Ed., and Betts, "A Framework
              for MPLS in Transport Networks", MPLS-TP-FWK, Work in
              Progress.

SB> The above ref does not look right

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 14 Apr 2010 10:38:55 +0100

Thanks Stewart.

>   it is possible to switch over independent of the way the network is

We chose "operation".

> SB> The above two paras repeat each other WRT PWs

Good catch.

> SB> Why do we need to spend so much of the document paraphrasing the > 
> requirements?

Yes. We originally included the requirements when 5654 was an early draft. 
We then thought it might be useful to summarise and structure the 
requirements for ease of comprehension.

However, similar comments about potential confusion and duplication were 
raised by ITU-T review, so we will cut out most of this section as you 
suggest.

> rings is that what we mean to say?

Yes. Note our intent to make inferrences. We have word-smithed.

> SB> Probably needs a cross ref to OAM Framework

OK

> SB> OAM FWK covers this topic anyway

Agreed. No benefit to making this statement (even if it is true :-)

>   carries it. SB> This does not protect the Attachment Circuits, or 
> T-PEs - You talk to

Yes, as you note, this is covered in 7.2.

> SB> "compare with Section" is an English fragment.

A poll of the room in Stockholm revealed that no-one understands what you 
mean! ;-)

Changed the text to "see also Section"

> SB> The above ref does not look right

Ah yes. Thanks.

Cheers,
Adrian and Nurit