Subject: Re: Gen-ART LC Review of draft-ietf-mpls-tp-uni-nni-02

From: "Bocci, Matthew (Matthew)" <[email-masked]>
Date: Thu, 20 Jan 2011 09:47:44 +0100

Ben,

Apologies for missing your additional questions. Please see below for a
response.

Best regards,

Matthew

From: Ben Campbell <[email-masked]>
To: "Bocci, Matthew (Matthew)" <[email-masked]>
Reply-to: [email-masked]
Subject: Re: [Gen-art] Gen-ART LC Review of draft-ietf-mpls-tp-uni-nni-02
X-RSN: 1/0/933/9723/54927
 
Thanks for the quick response. Also see below. I elided sections that I
think have been addressed.
 
On Dec 22, 2010, at 5:44 AM, Bocci, Matthew (Matthew) wrote:
 
> Ben, 
>  
> Thank you for your comments. Please see below.
>  
> Best regards 
>  
> Matthew 
>  
> On 21/12/2010 22:13, "Ben Campbell" <[email-masked]> wrote:
>  
 
[...] 
 
>>  
>> -- Section 1.1, 1st paragraph:
>>  
>> More conventional in what context? Useful for what purpose?
>  
> It is the convention to represent a UNI or NNI as a specific reference
> point between functional groups e.g. MEF E-NNI (Figure 2 of MEF26) or
>ATM 
> UNI (ITU-T I.413), rather than to represent these as a span as in the
> original diagrams in RFC5921. I propose to rephrase this sentence to:
> "However, it is convention to illustrate these interfaces as reference
> points." 
>  
> With regard to your second question, I propose to rephrase the sentence
>as 
> follows: 
> "Furthermore, in the case of a UNI, it is useful to illustrate the
> distribution of UNI functions between the Customer Edge (CE) side and
>the 
> Provider Edge (PE) side of the UNI (the UNI-C and UNI-N) in order to
>show 
> their relationship to one another."
>  
>  
 
WFM 
 
>  
>>  
>> -- Figures 1 and 2:
>>  
>> Is the meaning of the various line types described elsewhere? If so, a
>> statement to that effect with a reference would be helpful.
>  
> We have used the same convention as RFC5921. However, there is no key
> there. I am not sure that a complete key would clarify the diagram as
>the 
> same line type is used to represent multiple entities due to the limited
> umber of characters that are useful for ASCII drawing.
 
Ah, I agree it probably would be too much to add a complete key, and on
re-reading, I see most of the lines are sufficiently labeled. But I am
still confused by a few of them. For example, in under the UNI column, I
see both a single and double dashed (equal signs) line under the label of
"Client Traffic Flows". Should I assume those to just be two arbitrary
flows where the line type just helps me follow a particular flow, or are
they somehow different classes of flows? 

MB> They are just flows belonging to arbitrary transport service
instances, and helps the reader to follow the path of the flow.
 
On the right side of the same diagram, I see 3 Transport Paths with an
outer set of arrows, and the lower two having another arrow between.
Should the outer arrows be interpreted as a "channel" over which client
traffic flows? 

MB> The outer arrows are supposed to look like two sides of a tunnel (the
transport path) other which the transport service instance (TSI) is
transported. 
 
>  
>>  
>> -- Figure 2: 
>>  
>> I suggest expanding CP somewhere.
>  
> CP is expanded in the terminology section.
 
So it is, right there at the top. (I could have sworn I did a text search
for that--looks like the search option in the iPad tool I use for
reviewing drafts is not reliable :-|)

On 22/12/2010 11:44, "Bocci, Matthew (Matthew)"
<[email-masked]> wrote:

>Ben,
>
>Thank you for your comments. Please see below.
>
>Best regards
>
>Matthew
>
>On 21/12/2010 22:13, "Ben Campbell" <[email-masked]> wrote:
>
>>I am the assigned Gen-ART reviewer for this draft. For background on
>>Gen-ART, please see the FAQ at
>><http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>>
>>Please resolve these comments along with any other Last Call comments you
>>may receive.
>>
>>Document: draft-ietf-mpls-tp-uni-nni-02
>>Reviewer: Ben Campbell
>>Review Date: 2010-12-21
>>IETF LC End Date: 2010-12-23
>>IESG Telechat date: (if known)
>>
>>
>>Summary: This draft is ready for publication as in informational RFC. I
>>have a small number of editorial comments that I think could further
>>improve the draft if there is another round of editing.
>>
>>Major issues: None
>>
>>Minor issues: None
>>
>>Nits/editorial comments:
>>
>>-- Section 1, 1st paragraph:
>>
>>I suggest moving the expansion of MPLS-TP TP the first mention in the
>>body of the draft.
>
>
>OK. I have moved this to the first use of the acronym in that section.
>
>>
>>-- Section 1.1, 1st paragraph:
>>
>>More conventional in what context? Useful for what purpose?
>
>It is the convention to represent a UNI or NNI as a specific reference
>point between functional groups e.g. MEF E-NNI (Figure 2 of MEF26) or ATM
>UNI (ITU-T I.413), rather than to represent these as a span as in the
>original diagrams in RFC5921. I propose to rephrase this sentence to:
>"However, it is convention to illustrate these interfaces as reference
>points."
>
>With regard to your second question, I propose to rephrase the sentence as
>follows:
>"Furthermore, in the case of a UNI, it is useful to illustrate the
>distribution of UNI functions between the Customer Edge (CE) side and the
>Provider Edge (PE) side of the UNI (the UNI-C and UNI-N) in order to show
>their relationship to one another."
>
>
>>
>>-- Section 1.2, definition of UNI-N
>>
>>I suggest expanding PE in the definition.
>
>OK 
>
>>
>>-- Figures 1 and 2:
>>
>>Is the meaning of the various line types described elsewhere? If so, a
>>statement to that effect with a reference would be helpful.
>
>We have used the same convention as RFC5921. However, there is no key
>there. I am not sure that a complete key would clarify the diagram as the
>same line type is used to represent multiple entities due to the limited
>umber of characters that are useful for ASCII drawing.
>
>>
>>-- Figure 2:
>>
>>I suggest expanding CP somewhere.
>
>CP is expanded in the terminology section.
>
>