Hi Adrian, > -----Original Message----- > From: Adrian Farrel [mailto:[email protected]] > Sent: Sunday, February 21, 2010 12:29 PM > To: PAPADIMITRIOU Dimitri; [email protected] > Cc: [email protected]; > [email protected]; [email protected] > Subject: Next steps with draft-ietf-ccamp-gmpls-mln-extensions > > 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. > > >> 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 > > > > for Virtual TE links: the CALL ATTRIBUTE is defined in this document > > > >> - 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. > > > > for Soft FA's: the LSP ATTRIBUTE defined in RFC 5420 is used to > > introduced a new flag > > > >> - 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. > > > > 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.
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. > 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. I refer to the OSPF format for v12 (I can re-include in the next revision). > >> 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. > > 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. I made these clarifications in the re-submitted document v12. If not required I will change back. > >> 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. > > 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. Same here. > >> 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 > > 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. Right, the "shift" is resulting from the Word template. > >> == 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. Done. I've sent a revision e-mail yesterday Thanks, -dimitri. > Many thanks, > Adrian > > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
