Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mpls-tp-uni-nni-02

From: "Bocci, Matthew (Matthew)" <[email-masked]>
Date: Tue, 4 Jan 2011 15:41:41 +0100

Julien,

Thank you very much for your review.

Please see below for some responses.

Best regards,

Matthew

On 22/12/2010 16:03, "Julien Meuric" <[email-masked]>
wrote:

>Hello,
>
>I have been selected as the Routing Directorate reviewer for this draft.
>The Routing Directorate seeks to review all routing or routing-related
>drafts as they pass through IETF last call and IESG review. The purpose
>of the review is to provide assistance to the Routing ADs. For more
>information about the Routing Directorate, please see
>http://www.ietf.org/iesg/directorate/routing.html
>
>Although these comments are primarily for the use of the Routing ADs, it
>would be helpful if you could consider them along with any other IETF
>Last Call comments that you receive, and strive to resolve them through
>discussion or by updating the draft.
>
>Document: draft-ietf-mpls-tp-uni-nni-02.txt
>Reviewer: Julien Meuric
>Review Date: 2010-12-22
>IETF LC End Date: 2010-12-23
>Intended Status: Informational
>
>*Summary:*
>I have some minor concerns about this document that I think should be
>resolved before publication.
>
>*Comments:*
>This document focuses on a specific topic within a limited scope.
>Nevertheless, it is a patch to RFC 5921 and thus requires reading some
>parts of the latter (sections 3.4.2 and 3.4.3 mainly), which is
>detrimental to its readability if considered alone.
>
>*Major Issues:*
>No major issues found.
>
>*Minor Issues:*
>- It is not obvious why P nodes are not mentioned when tackling the NNI.
>It requires to look for an answer in RFC 5921, which lies in the last
>paragraph of section 3.4.2. It may be worth considering introducing that
>paragraph in this document (in section 1 for instance).

I propose adding the following text (mostly copied from RFC5921) as a
final paragraph in Section 1.1:

"Awareness of the Transport Service layer need exist only at PE nodes, and
so only these nodes are illustrate in the figures.
   MPLS-TP Provider (P) nodes need have no awareness of this layer.
   Both PE and P nodes participate in the Transport Path layer.  A PE
   terminates (i.e., is an LER with respect to) the transport paths it
   supports, and is responsible for multiplexing and demultiplexing of
   Transport Service Instance traffic over such transport paths."

>- Linked to the above, the exact scope of the document is defined a bit
>late: the fact that UNI and NNI are "Transport Service Interfaces" is
>not stated before section 1.1, while one would expect to be aware of
>this information from the abstract and introduction.

I propose to modify the first sentence of the abstract and Section 1 as
follows:
"The framework for MPLS in transport networks (RFC 5921) provides
reference models for an MPLS Transport Profile (MPLS-TP) transport service
interfaces, which are a User-to-Network Interface (UNI), and an MPLS-TP
Network-to-Network Interface (NNI)."

>- The phrase "Transport Service Instance" is only mentioned in section
>3: defining it in section 1.2 may improve the readability; "TSI" is only
>used in drawings: is it necessary to use the acronym, especially in this
>context where the phrase "Transport Service Interface" is also used?

TSI is expanded in the terminology section (1.2). It is not expanded in
the figures because of the constraints of ASCII art.

>- The term "attachment circuit" is mentioned in section 2, but it does
>not appear on figures, nor is defined in the I-D. Definition and/or
>illustration would be welcome.

This text was added as a result of a last call comment and is copied from
RFC5921. The term is a well known term that is used in RFC5921, as well as
being extensively used in PWE3 and L2VPN, so I a not sure it needs to be
defined again here.

>- The acronyms UNI-C and UNI-N are used for the first time in section
>1.1, without expansion/definition and before the terminology section.
>They should either be removed from there, or be expanded/defined at
>first use.

I will add an expansion on first use, which I believe should actually be
'User-to-Network Interface, Client side' and 'User-to-Network Interface,
Network side'.

>- The acronym UNI-N is defined in section 1.2 but not actually expanded,
>thus leading to wonder why "-N". I agree that "PE side" is more
>meaningful than "network", but adding expansion while keeping definition
>may be considered.

I will add the expansion in the terminology and correct the expansion for
UNI-C.

>- Figure 1: it looks like "Native service control" is defined as native
>service control and/or GMPLS, where I understand that GMPLS can be an
>option even if not native. Would not it be clearer to write "Service
>control" and keep current definition (native and/or GMPLS)?

I think we have to be careful not to confuse the control plane of the
client service for establishing and maintaining client connections across
the UNI with the control plane of the transport service, which is why we
use the term Native Service Control. So this may be either a control plane
belonging to the client service, or it may be GMPLS since this can be used
as an alternative in some instances. The term Native Service is in common
usage as per RFC3985, but I appreciate that the usage here is a little
unclear. How about: "Native service control = Control plane defined as
belonging to the native service, and/or GMPLS" ?

>*Nits:*
>Abstract
>s/subjet/subject/

OK

>-----
>Section 1.2
>s/PE Side/PE side/

OK

>-----
>Section 2 & 3
>- either:
>     s/User-Network/User-to-Network/ in section 2
>     + s/NNI is illustrated/Network-to-Network Interface (NNI) is
>illustrated/ in section 3
>- or: s/User-Network Interface (UNI)/UNI/ in section 2
>-----
>
>
>Regards and merry Christmas,
>
>Julien
>

---

From: Julien Meuric <[email-masked]>
Date: Fri, 07 Jan 2011 10:38:57 +0100

Hi Matthew (and happy new year everyone).

See my answers in line.

Cheers,

Julien

Le 04/01/2011 15:41, Bocci, Matthew (Matthew) a écrit :
> On 22/12/2010 16:03, "Julien Meuric"<[email-masked]>
> wrote:
>
>> Hello,
>>
[JM] OK

> Network-to-Network Interface (NNI)."
[JM] OK

> the figures because of the constraints of ASCII art.
[JM] It is expanded but not actually defined/explained; adding a sentence in the terminology section would be helpful.

> being extensively used in PWE3 and L2VPN, so I a not sure it needs to be
[JM] That is a typical example of the main shortcoming of this document. Anyway, it is up to you.

> 'User-to-Network Interface, Client side' and 'User-to-Network Interface,
[JM] OK

> I will add the expansion in the terminology and correct the expansion for
[JM] OK

> belonging to the native service, and/or GMPLS" ?
[JM] Not sure about that one. I completely agree with the intent, my concern is about the "patch-like" wording because it feels like writing "x = x + y" [while y (GMPLS) is not zero]... "x + y" should remain, but I would feel more comfortable with a more generic phrase [than RFC 3985] for the "left x": if "service control" is excluded, how about something like "service layer control"?

>> Section 2&  3

---

From: "Bocci, Matthew (Matthew)" <[email-masked]>
Date: Fri, 7 Jan 2011 13:33:47 +0100

Hi Julien,

Happy New Year. Please see below.

Thanks.
Matthew

On 07/01/2011 09:38, "Julien Meuric" <[email-masked]>
wrote:

>[JM] It is expanded but not actually defined/explained; adding a sentence
>in the terminology section would be helpful.

MB> It is defined in RFC5921, section 3.4.2. I propose to add the
following modified snippet from that paragraph to the terminology section:
"a single logical point-to-point connection at the Transport Service layer
between the ingress PE providing a packet transport service to a CE, and
the corresponding egress PE to which the peer CE is attached."
 
>[JM] Not sure about that one. I completely agree with the intent, my
>concern is about the "patch-like" wording because it feels like writing
>"x = x + y" [while y (GMPLS) is not zero]... "x + y" should remain, but I
>would feel more comfortable with a more generic phrase [than RFC 3985]
>for the "left x": if "service control" is excluded, how about something
>like "service layer control"?

MB> Service Layer Control could be confused with transport Service layer
control. Also, mentioning GMPLS was a specific request from the ITU-T here
and they have already reviewed the document as a part of the joint MPLS-TP
process, and this somewhat constrains us to only making changes that are
really necessary. So, how about we delete the note from the figure, change
the name in the figure to Client Service Control, and then add the
following sentence to the text below the figure:
"Note that the client service control plane may be a control protocol
belonging to the native service, or GMPLS."

---

From: Julien Meuric <[email-masked]>
Date: Fri, 07 Jan 2011 15:06:32 +0100

Hi again Matthew.

The definition you propose for TSI is fine with me.

The phrase "Client service control" addresses my comment. I do not care 
if you use a note with "=" or a full sentence, but the one you suggest 
for the latter reads clear (to me at least).

Enjoy the week-end,

Julien