Subject: [mpls-tp] AD review of draft-ietf-mpls-tp-framework-11.txt

From: Adrian Farrel <[email-masked]>
Date: Sun, 04 Apr 2010 23:13:33 +0100

Don't panic!

Hi,

I have carried out my AD review slightly earlier than usual in the
process so I have probably found a number of issues that you will
be fixing as part of mark-ups after second WG last call.

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 this to be a really good document. Evidence of hard work by
the editors and great input from the whole community. Thanks!

As you'll see, most of my comments are pretty trivial nits.

Adrian

---

idnits (http://tools.ietf.org/tools/idnits/) says:

  ** There is 1 instance of too long lines in the document, the longest
     one being 1 character in excess of 72.

  -- No information found for draft-ietf-ccamp-mpls-tp-cp-framework - is
     the name correct?

Not sure about the second problem. Possibly having the I-D name span
three lines has thrown something.

---

Abstract

s/Telecommunications/Telecommunication/  x2

---

Section 1.1

Please expand "OAM" on first use (the Abstract doesn't count)

---

Section 1.1

s/Telecommunications/Telecommunication/  x2

---

Section 1.2

Although it is important to clarify the scope, this section is identical
to the first paragraph of Section 1.1 with the exception of the 
qualification "MPLS-TP" as applied to "transport paths". Since that
omission is presumable accidental, I think the section does not add
anything and can be safely deleted.

---

Section 1.3

It may be helpful to insert an informational reference to 
draft-ietf-opsawg-mpls-tp-oam-def with the definition of "OAM".

You might re-order the list to be in alphabetic order.

Can you fix the layout for the definition of "Native" so that the
word "service" does not appear to be a defined term.

S-PE
s/provider/Provider/

---

General

Please check hyphenation of such as "point to multipoint"

s/bi-directional/bidirectional/

---

Section 1.3.8

Just wanted to check that you are sure that a service LSP cannot carry
more than one service. If you're sure, that's fine.

---

Section 1.3.11

Some formatting and bracketing issues before the bullet list

---

Section 1.3.12

You might add an informational reference to 
draft-ietf-mpls-tp-rosetta-stone

---

Section 2

s/Bi-directional/bidirectional/

---

Section 3.1

   Such packet transport services
   inherit a number of characteristics, defined in [RFC5654]:

Inherit from where?

---

Section 3.1

   o  The service provided by the MPLS-TP network to the client is
      guaranteed not to fall below the agreed level regardless of other
      client activity.

I don't think this is quite accurate. I think that the criterion is that
the service will not fall below the agreed level without the client
being informed. One might hide this in the term "agreed", but (for
example) the event of a connection failure will presumably fall below
the terms of a normal service agreement.

---

Section 3.2

s/requirements/requirement's/

---

Figure 1 fails to show post-RFC5654 MPLS features that are not required
for (and so not part of) MPLS-TP.

---

Section 3.3 bullet 4

Include a reference to I-D.ietf-ccamp-mpls-tp-cp-framework?

---

Section 3.4

   An MPLS LSP Label can also be used as the adaptation

Hmmm. Isn't the encapsulation beneath a shim header the adaptation?
The adaptation rules include how the TC, S, and TTL fields are set
as well as the label itself

---

Figures 3 and 4

Excellent ascii-art, how did you manage that? :-)

---

Section 3.7

   A MEG may also include a set of Maintenance Entity Group Intermediate
   Points (MIPs).  MEPs are capable of sourcing and sinking OAM flows,
   while MIPs can both react to OAM flows received from within a MEG.

Something broken about this sentence: "...while MIPS can both..."

---

Section 3.7

   A G-ACh packet may be directed to an individual MIP along the path of
   an LSP or MS-PW by setting the appropriate TTL in the label for the
   G-ACh packet, as per the traceroute mode of LSP Ping [RFC4379] and
   the vccv-trace mode of [I-D.ietf-pwe3-segmented-pw].

Well, the TTL is in the shim header, not in the label.
May be worth checking for this issue throughout the document.

---

Figure 12 shows an arrow with "direction of packet flow". The following
text lists three packet flows all of which seem to be in the
opposite direction. Confusing?

---

Section 3.8.2

Your "definition" of inband in Section 3.8.1 is in conflict with its use
in this section for unidirectional LSPs. In this case, there is no
return path that there would be for a bidirectional LSP. Of course, you 
can use some other LSP unidirectional or bidirectional) as a return 
path, but in 3.8.1 you define this as out=of-band.

Probably nothing much to do, but achieve some harmonization of the term.

Your elegant solution to "how do I provide a return path?" is fine, but
I am not sure whether we now call the LSP unidirectional any more. The
service, of course, *is* still unidirectional.

---

Section 3.9

I know you don't want to go into the CP in detail, but you list three
references for GMPLS signaling, yet you don't mention routing except
as a single word in a bullet list.

An important point you could make in Section 3.11 is that an operator
might use GMPLS routing, but manual provisioning.

---

You may find RFC 4726 a better reference for inter-domain GMPLS than
RFC 4216

---

From: "Bocci, Matthew (Matthew)" <[email-masked]>
Date: Mon, 26 Apr 2010 19:56:38 +0200

Adrian,

Many thanks for your comments. Unless stated otherwise, I have included them wholesale. Please see below for a few in-line comments.

Best regards,

Matthew

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: 04 April 2010 23:14
> To: [email-masked]
> Cc: [email-masked]
> Subject: [mpls-tp] AD review of draft-ietf-mpls-tp-framework-11.txt
> 
> Don't panic!
> 
> Hi,
> 
> I have carried out my AD review slightly earlier than usual 
> in the process so I have probably found a number of issues 
> that you will be fixing as part of mark-ups after second WG last call.
> 
> 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 this to be a really good document. Evidence of hard 
> work by the editors and great input from the whole community. Thanks!
> 

OK will check again on submission.

> 
>   -- No information found for 
> draft-ietf-ccamp-mpls-tp-cp-framework - is
>      the name correct?
> 
> Not sure about the second problem. Possibly having the I-D 
> name span three lines has thrown something.

Not sure why the second one doesn't work either. xml2rfc was fine with this.

> Although it is important to clarify the scope, this section 
> is identical to the first paragraph of Section 1.1 with the 
> exception of the qualification "MPLS-TP" as applied to 
> "transport paths". Since that omission is presumable 
> accidental, I think the section does not add anything and can 
> be safely deleted.
> 
> ---
> 
> Section 1.3
> 
> Can you fix the layout for the definition of "Native" so that 
> the word "service" does not appear to be a defined term.
> 
> S-PE
> s/provider/Provider/
> 
> ---
> 
> General
> 
> Just wanted to check that you are sure that a service LSP 
> cannot carry more than one service. If you're sure, that's fine.

I think this should be one transport service instance, according to the descriptions elsewhere in the draft.

>    inherit a number of characteristics, defined in [RFC5654]:

I think 'exhibit' is a better word to use.

> I don't think this is quite accurate. I think that the 
> criterion is that the service will not fall below the agreed 
> level without the client being informed. One might hide this 
> in the term "agreed", but (for
> example) the event of a connection failure will presumably 
> fall below the terms of a normal service agreement.

I think we were trying to paraphrase the following requirement:

32  In an environment where an MPLS-TP layer network is supporting a
       client layer network, and the MPLS-TP layer network is supported
       by a server layer network, then operation of the MPLS-TP layer
       network MUST be possible without any dependencies on the server
       or client layer network.

       A.  The server layer MUST guarantee that the traffic-loading
           imposed by other clients does not cause the transport service
           provided to the MPLS-TP layer to fall below the agreed level.
           Mechanisms to achieve this are outside the scope of these
           requirements.

But I see we have not done that very well. Perhaps we could say:
"The service provided by the MPLS-TP network to a given client will not to 
fall below the agreed level as a result of the traffic-loading of other clients."

> s/requirements/requirement's/

Which instance of the word 'requirements' are you referring to? There are quite a few in that paragraph :)
 
> 
> ---
> 
> Figure 1 fails to show post-RFC5654 MPLS features that are 
> not required for (and so not part of) MPLS-TP.

We propose modifying the figure as follows:

  |<============================== MPLS ==============================>|
                                                     { Post-RFC5654    }
                                                     { non-Transport   }
                                                     {   Functions     }
  |<========== Pre-RFC5654 MPLS ===========>|
  {      ECMP       }
  { LDP/non-TE LSPs }
  {     IP fwd      }  
                                    
                    |<======== MPLS-TP ============>|
                                       { Additional }
                                       {  Transport }
                                       {  Functions } 

> The adaptation rules include how the TC, S, and TTL fields 
> are set as well as the label itself

How about we change this to read?:

"An MPLS LSP can also provide the adaptation..."

But we will also have to ensure that we make the rest of the phrasing in these sections consistent.

> Excellent ascii-art, how did you manage that? :-)

We had a good artist on the staff :) Thanks!

> Something broken about this sentence: "...while MIPS can both..."

This sentence needs to be merged with the beginning of the following sentence, thus:

"MEPs are capable of sourcing and sinking OAM flows, while MIPs can both react to OAM 
flows received from within a MEG and can originate notifications to the MEPs as a
   result of specific network conditions."

> May be worth checking for this issue throughout the document.

OK. This is a turn of phase that I think has unfortunately crept into other places too. We will
fix this in this draft. I propose that we refer to this as the TTL in the label stack entry.

> 
> ---
> 
> Figure 12 shows an arrow with "direction of packet flow". The 
> following text lists three packet flows all of which seem to 
> be in the opposite direction. Confusing?

The figure refers to the direction of LSP user plane user traffic flow, while the 
bullets refer to the directio of packets on the return path. I propose that
we modify the text as follows:

                 LSP         LSP

           U ========= Y ========= D

          LER         LSR         LER

           ---------> Direction of user plane traffic flow

                  Figure 12: Return Path reference Model

The following cases are described for the various types of LSPs:

   Case 1  Return path packet transmission from D to U

   Case 2  Return path packet transmission from Y to U

   Case 3  Return path packet transmission from D to Y

> 
> ---
> 
> Section 3.8.2
> 
> Your "definition" of inband in Section 3.8.1 is in conflict 
> with its use in this section for unidirectional LSPs. In this 
> case, there is no return path that there would be for a 
> bidirectional LSP. Of course, you can use some other LSP 
> unidirectional or bidirectional) as a return path, but in 
> 3.8.1 you define this as out=of-band.
> 
> Your elegant solution to "how do I provide a return path?" is 
> fine, but I am not sure whether we now call the LSP 
> unidirectional any more. The service, of course, *is* still 
> unidirectional.

We think the text in Case 1 needs to be fixed as follows:

Case 1  If an in-band return path is required to deliver traffic from D back to U,
           it is recommended for reasons of operational simplicity that
           point-to-point unidirectional LSPs be provisioned as
           associated bidirectional LSPs (which may also be co-routed)
           whenever return traffic from D to U is required.  Note that
           the two directions of such an LSP may have differing
           bandwidth allocations and QoS characteristics.  The discussion 
           for such LSPs below applies.

        As an alternative, an out-of-band return path may be used.

> 
> ---
> 
> Section 3.9
> 
> I know you don't want to go into the CP in detail, but you 
> list three references for GMPLS signaling, yet you don't 
> mention routing except as a single word in a bullet list.
> 
> An important point you could make in Section 3.11 is that an 
> operator might use GMPLS routing, but manual provisioning.

We propose adding the following text to section 3.11:
"Note that the path of an LSP or PW may be dynamically computed, while
the LSP or PW itself is established through static configuration."

> 
> ---
> 
> You may find RFC 4726 a better reference for inter-domain 
> GMPLS than RFC 4216

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