Subject: [Gen-art] Gen-ART review of draft-ietf-ccamp-gmpls-mln-extensions-11

From: <[email-masked]>
Date: Fri, 12 Feb 2010 21:11:08 -0500

I have been selected as the General Area Review Team (Gen-ART) 
reviewer for this draft (for background on Gen-ART, please see 
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please resolve these comments along with any other Last Call
comments you may receive.

Document: draft-ietf-ccamp-gmpls-mln-extensions-11
Reviewer: David L. Black
Review Date: February 12, 2010
IETF LC End Date: February 16, 2010

Summary:
This draft is basically ready for publication, but has nits
that should be fixed before publication.

Comments:
This draft extends GMPLS routing and signaling to support the
operation of GMPLS Multi-Layer/Multi-Region Networks.  One needs to be
a GMPLS expert to fully understand this draft - although, I'm not a
GMPLS expert, the draft reads reasonably well.  All of these comments
are minor.

The IACD sub-TLV formats for OSPF and IS-IS appear to be identical.  If
they are in fact identical, a single ASCII text diagram should be used
for both.

The description of the IACD sub-TLV format does not describe the
Max LSP Bandwidth fields.  At a minimum the units and/or encoding of
these fields should be described here, even thought the full
specification may be elsewhere.

Please add the values for Type and Length for the XRO SC subobject
into the ASCII figure in Section 4.1.1 .

Section 4.1.2 defines a new subobject by making minor changes to an
existing one in another RFC; a complete ASCII diagram of the new
subobject would be helpful - please add one.

Sections 5.1.4, 5.2.1 and 8 have me confused about the Attributes Flags TLV:
- Section 5.1.4 defines an Attributes Flags TLV here
- Section 5.2.1 points to RFC 5420 for what's apparently a different
	Attributes Flags TLV and defines a Pre-Planned LSP flag in
	that TLV.
- Section 8 then apparently instructs IANA to put that bit into the
	Attributes Flags TLV defined in Section 5.1.4 .
Something appears to be wrong with this combination - what was
the intent?  If these two TLVs are the same, or share a common bit
assignment registry, that should be stated.

idnits 2.12.00 found three nits:

  == The page length should not exceed 58 lines per page, but there was 1
     longer page, the longest (page 1) being 62 lines

  ** There are 144 instances of too long lines in the document, the longest
     one being 1 character in excess of 72.

  == Line 781 has weird spacing: '...ndwidth  is st...'

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Sat, 13 Feb 2010 13:42:02 +0100

Hi,

I will address the points listed here below. Thanks for the review. 

> - Section 5.1.4 defines an Attributes Flags TLV here

for Virtual TE links: the CALL ATTRIBUTE is defined in this document 

> 	Attributes Flags TLV and defines a Pre-Planned LSP flag in

for Soft FA's: the LSP ATTRIBUTE defined in RFC 5420 is used to introduced a new flag

> assignment registry, that should be stated.

I will clarify this because as they both refer to "attributes" precision of the terms used is indeed critical

Thanks,
-dimitri.
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Saturday, February 13, 2010 3:11 AM
> To: PAPADIMITRIOU Dimitri; VIGOUREUX MARTIN; 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Subject: Gen-ART review of draft-ietf-ccamp-gmpls-mln-extensions-11
>

---

From: Adrian Farrel <[email-masked]>
Date: Sun, 21 Feb 2010 11:28:44 +0000

Hi Dimitri,

Looking at your response to David Black's review, I think an update to the 
draft is needed. I'd like to get it onto an IESG agenda before Anaheim as it 
has several Ethernet drafts backed up behind it.

> I will clarify this because as they both refer to "attributes" precision 
> of the terms
> used is indeed critical

I think David is quite right that there is confusion. My understanding is as 
follows...

There are two separate objects: the Call_Attribute object and the 
LSP_Attribute object.

Both of these objects can carry a TLV called the "Attributes Flags TLV". But 
this is a DIFFERENT TLV for the two objects. In the first case, it is for 
use in the Call_Attribute object and is defined in this document. In the 
second case it is for use on the LSP_Attribute object and is defined in RFC 
4020 with this document only defining a new flag.

My suggestion to make this crystal clear is to change the name of the 
Attributes Flags TLV carried in the Call_Attribute object to be the "Call 
Attibutes Flags TLV". I think this is a really easy search and replace, and 
fixes this issue.

David also said...

>> The IACD sub-TLV formats for OSPF and IS-IS appear to be
>> identical.  If they are in fact identical, a single ASCII text diagram
>> should be used for both.

They are identical, but that is only good fortune. There is no requirement 
that they be the same, and there is no required mapping between the two. 
Furthermore, a future revision might need to change the format or content 
for one protocol, but not for the other, etc. Thus, we prefer to keep the 
definitions distinct.

>> specification may be elsewhere.

David is correct that the fields should be mentioned, but I think it would 
be OK to include a reference to RFC4203 and RFC5307.

>> Please add the values for Type and Length for the XRO SC
>> subobject into the ASCII figure in Section 4.1.1 .

The convention in RSVP-TE is to not include the Type and Length (most 
relevantly, see RFC 4874). It would be inappropriate to change that 
convention here.

>> subobject would be helpful - please add one.

There is absolutely no change in the format of the subobject. The only 
difference is the interpretation of the L bit. In order to keep the 
subobjects in lock-step, it is preferable to not include a further ASCII 
diagram.

>>   == The page length should not exceed 58 lines per page, but
>>         there was 1 longer page, the longest (page 1) being 62 lines

This is the first page caused by leading several CRLF

>>   ** There are 144 instances of too long lines in the
>>        document, the longest one being 1 character in
>>        excess of 72.

Seems to be a product of MS Word.
I think the whole thing needs to be left-shifted by 7 spaces.

>>   == Line 781 has weird spacing: '...ndwidth  is st...'

Yup. Section 5.2.2 para 2 has a double space.

Finally, could you or Lou please confirm the IANA actions in the email from 
Amanda on the 16th.

Many thanks,
Adrian

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Sun, 21 Feb 2010 13:34:24 +0100

Hi Adrian,

> From: Adrian Farrel [mailto:[email-masked]] 
> Sent: Sunday, February 21, 2010 12:29 PM
> To: PAPADIMITRIOU Dimitri; [email-masked]
> Cc: [email-masked]; 
> [email-masked]; [email-masked]
> Subject: Next steps with draft-ietf-ccamp-gmpls-mln-extensions
> 
> Hi Dimitri,
> 
> I think David is quite right that there is confusion. My 
> understanding is as follows...
> 

I have re-submitted a v12 with the following changes

. Attributes TLV -> Call Attributes TLV

. Attributes Flag TLV -> Call Attributes Flags TLV

and revisited corresponding text.

> for one protocol, but not for the other, etc. Thus, we prefer 
> to keep the definitions distinct.

I refer to the OSPF format for v12 (I can re-include in the next
revision). 

> relevantly, see RFC 4874). It would be inappropriate to change that 

I made these clarifications in the re-submitted document v12. If not
required I will change back.

> subobjects in lock-step, it is preferable to not include a 

Same here.

> I think the whole thing needs to be left-shifted by 7 spaces.

Right, the "shift" is resulting from the Word template. 

> Finally, could you or Lou please confirm the IANA actions in 
> the email from Amanda on the 16th.

Done. I've sent a revision e-mail yesterday

Thanks,
-dimitri.

---

From: Lou Berger <[email-masked]>
Date: Sun, 21 Feb 2010 07:37:28 -0500

Adrian,
	It looks like Dimitri is one step ahead (at least for now ;-)  Take a
look at:

http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url1=draft-ietf-ccamp-gmpls-mln-extensions-11.txt&url2=http://www.ietf.org/staging/draft-ietf-ccamp-gmpls-mln-extensions-12.txt

I suspect all issues are addressed in this rev.  Once you and David
confirm, we can respond to IANA with the requisite changes.

Please confirm that there are/are not remaining open issues.

Much thanks,

Lou

---

From: Adrian Farrel <[email-masked]>
Date: Sun, 21 Feb 2010 12:46:29 +0000

Ah thanks, I had only checked the datatracker. I guess this will pop out on 
Monday when the Secretariat get to work.

It seems to address the points.

Thanks.

Adrian
----- Original Message ----- 
From: "Lou Berger" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: "PAPADIMITRIOU Dimitri" <[email-masked]>; 
<[email-masked]>; 
<[email-masked]>; 
<[email-masked]>; <[email-masked]>
Sent: Sunday, February 21, 2010 12:37 PM
Subject: Re: Next steps with draft-ietf-ccamp-gmpls-mln-extensions

---

From: <[email-masked]>
Date: Sun, 21 Feb 2010 21:52:14 -0500

Adrian and Dimitri,

The submitted -12 version looks good - I saw one minor nit:

- Second line of 5.1.5: "Attributes Flags" -> "Call Attributes Flags"

Thanks for clarifying the distinction between the (renamed) Call
Attributes Flags TLV vs. the Attributes Flags TLV - it's now clear
what's going on, and the revised requests to IANA should also be clear.

> for one protocol, but not for the other, etc. Thus, we prefer to keep
the

This is only about combining the text diagram, not combining the
definitions.  If/when the definitions diverge, revised ASCII text
diagrams for one or both sub-TLV formats can be included in the document
that diverges the definitions.  The definitions are distinct in -12,
they just point to the same ASCII text diagram.

> relevantly, see RFC 4874). It would be inappropriate to change that

Dimitri did something even better in -12; he documented the Type and
Length in the descriptions below the ASCII figures and included the
values in the descriptions.  Given this, the actual values for Type and
Length do not need to be inserted into the ASCII figures.  

> subobjects in lock-step, it is preferable to not include a further
ASCII

I think such a diagram would help implementers, and would force any
future modifications to consider the effects on both objects, which I
think is beneficial.  As noted in the review, this was a minor comment,
so removal of the diagram from -12 would be ok with me.

Thanks,
--David

> From: [email-masked] [mailto:[email-masked]] On
Behalf Of Lou Berger
> Sent: Sunday, February 21, 2010 7:37 AM
> To: Adrian Farrel
> Cc: [email-masked]; [email-masked];
draft-ietf-ccamp-gmpls-mln-
> [email-masked]; Black, David; PAPADIMITRIOU Dimitri
> Subject: Re: [Gen-art] Next steps with
draft-ietf-ccamp-gmpls-mln-extensions
> 	It looks like Dimitri is one step ahead (at least for now ;-)
Take a
http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url1=draft-ietf-ccamp-gm
pls-mln-extensions-
11.txt&url2=http://www.ietf.org/staging/draft-ietf-ccamp-gmpls-mln-exten
sions-12.txt
> > I think David is quite right that there is confusion. My
understanding is as
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art

---

From: <[email-masked]>
Date: Mon, 22 Feb 2010 17:12:52 -0500

The -12 version of this draft resolves all of the comments from the Gen-ART review of the -11 version with one minor exception -- the word "Call" needs to be inserted into the second line of section 5.1.5 as indicated below:

    5.1.5 Call Inheritance Flag  
            
       This document introduces a specific Call Inheritance Flag at 
       position bit 0 (most significant bit) in the Attributes Flags
                                                   ^
                                                   |
Call ----------------------------------------------/

An RFC Editor Note would be a fine way of handling this change, but it does need to be made.

Thanks,
--David

> From: Black, David
> Sent: Friday, February 12, 2010 9:11 PM
> To: [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]; 'gen-
> [email-masked]'
> Cc: Black, David; Lou Berger; Adrian Farrel; [email-masked]

---

From: Adrian Farrel <[email-masked]>
Date: Wed, 24 Feb 2010 18:12:08 +0000

Thanks for your thoroughness, David.

RFC Editor note has been created.

Cheers,
Adrian
----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>; 
<[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>; 
<[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>; 
<[email-masked]>
Sent: Monday, February 22, 2010 10:12 PM
Subject: Gen-ART review of draft-ietf-ccamp-gmpls-mln-extensions-12

The -12 version of this draft resolves all of the comments from the Gen-ART 
review of the -11 version with one minor exception -- the word "Call" needs 
to be inserted into the second line of section 5.1.5 as indicated below:

An RFC Editor Note would be a fine way of handling this change, but it does 
need to be made.

Thanks,
--David

> [email-masked]; 'gen-
> [email-masked]'