The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] [mpls] draft-ietf-mpls-rsvpte-attributes-05.txt
Hi, I have submitted a new revision of this draft. The following changes were made to address specific comments made during IESG review and during discussions with the IESG. Thanks, Adrian Mike Shand commented... > > 1) In section 3, under length, it says that the padding > > to take the value field up to a 4 byte boundary is NOT > > included in the length. > > However in section 3.1 para 3 it says that the length > > field is always a multiple of 4 bytes regardless of the > > number of bits set. > > > > I'm having difficulty reconciling those two statements. After discussion, Mike suggested... > "The Attribute Flags TLV value field is an array of a > multiple of 32 flags numbered from the MSB as bit zero. > The length field for this TLV is therefore always a > multiple of 4 bytes, regardless of the number of bits > carried and no padding is required." We have added this text to section 3.1. > > 2) The TLV defined above in section 3 is of the normal > > design in that the length is the length of the value > > field only and does not include the type and length > > fields. However, the TLV defined 7.2 has a different > > form where the length includes the type and length > > fields. > > > > Is there some rationale why the same protocol uses both > > types of encoding? After discussion, we agreed to make no changes because the TLV definition in section 3 is "normal" and it is the prefered way to define TLVs for the new object. The "TLV" in section 7.2 is not actually a TLV but is a sub-object according to the definitions and format in RFC3209. We have no scope to play with this definition. > > And one final question. In section 9 it says in paras > > 5 and 7 that LSRs SHOULD be prepared to receive this > > object in any order.... > > > > should that be a MUST, or is SHOULD acceptable? It would > > appear to be non-optional. This is correct, and the text has been changed to 'MUST'. Mike also pointed out a couple of typos which have been fixed. Joel Halpern raised the following points. > > IANA Considerations: > > The document identifies two new spaces for the IANA to > > manage. It lists the properties of relevance to values > > in these spaces. However, it does not indicate what > > procedure is to be followed for assigning values in > > these registries. Are they to be assigned only by > > IETF Standards Track RFCs? Are they assigned simply > > on a first-come, first-served basis with sufficient > > documentation? We have added to section 11.3 "New bit numbers may be allocated only by an IETF Consensus action." And to section 11.4 "It is suggested that new SESSION_ATTRIBUTE Flags be allocated only by an IETF Consensus action." > > The document talks about several degrees or kinds of > > mandatory / optional information, ranging from > > information that must be examined at every node to > > information that only needs to be examined at the > > end-points. The specific example is given of information > > that needs to be examined at ABR/ASBRs, but should be > > deployable without upgrading all routers in the path. > > It is not clear that this stated goal is met by the > > solution provided. Some text on how the various cases > > listed are met by the documented method would be > > helpful. After refining the requirements with Joel, we have added section 10 and its subsections. > > In section 7.3.1, there are two lines which confused me: > > The Attributes subobject is pushed onto the > > RECORD_ROUTE object immediately prior to pushing the > > node's IP address or link > > ... > > This means that an Attributes subobject is bound to > > the LSR identified by the subobject found in the RRO > > immediately before the Attributes subobject. > > > > The first sentence seems to say that when I parse the > > message I will find the Attributes subobject followed > > by the ID of the node which put it there. The later > > sentence seems to say that the Attributes subobject is > > bound to the ID which precedes it, rather than the ID > > which follows it? We discussed this point and agreed that the RRO is described as a stack. So, that which you push first, you pop last. You receive an RRO and you add your sub-objects to the front. You add the Attributes sub-object first, then you add your node/link. We clarified the text in 7.3.1 by replacing < The Attributes subobject is pushed onto the RECORD_ROUTE < object immediately prior to pushing the node's IP address < or link identifier. Thus, if label recording is being used, < the Attributes subobject SHOULD be pushed onto the < RECORD_ROUTE object after the Record Label subobject(s). with > As will be clear from [RFC3209], the RECORD_ROUTE object > is managed as a "stack" with each LSR adding sub-objects > to the start of the object. The Attributes subobject is > pushed onto the RECORD_ROUTE object immediately prior to > pushing the node's IP address or link identifier. Thus, > if label recording is being used, the Attributes subobject > SHOULD be pushed onto the RECORD_ROUTE object after the > Record Label subobject(s). Mark Townsley made a series of useful editorial comments. At the send of section 1 it says... >> This document distinguishes between options and attributes >> that are only required at key LSRs along the path of the >> LSP, and those that must be acted on by every LSR along >> the LSP. Two LSP Attributes objects are defined in this >> document: the first may be passed transparently by LSRs >> that do not recognize it, the second must cause LSP setup >> failure with the generation of a PathErr message with an >> appropriate Error Code if an LSR does not recognize it. > > "must" cause or "will" cause. Must (even without capital > letters) implies that this is new functionality, > though I think this is a statement about existing > functionality. Mark is quite right, this is existing functionality. In order to clarify this, the text is changed to read... This document distinguishes between options and attributes that are only required at key LSRs along the path of the LSP, and those that must be acted on by every LSR along the LSP. Two LSP Attributes objects are defined in this document: using the C-Num definition rules inherrited from [RFC2205], the first is passed transparently by LSRs that do not recognize it, and the second causes LSP setup failure with the generation of a PathErr message with an appropriate Error Code if an LSR does not recognize it. >> 1.1 Applicability to Generalized MPLS >> >> The RSVP-TE signaling protocol also forms the basis of a >> signaling protocol for Generalized MPLS (GMPLS) as >> described in [RFC3471] and [RFC3473]. The extensions >> described in this document are intended to be equally >> applicable to MPLS and GMPLS. > > Are they "intended" to be applicable to both, or is this > document actually defining them to be applicable to both? >> 3. Attributes TLVs >> >> [snip] >> >> Length >> >> The length of the value field in bytes. Thus if no value >> field is present the length field contains the value zero. >> Each value field must be zero padded at the end to take it >> up to a four byte boundary - the padding is not included in >> the length so that a one byte value would be encoded in an >> eight byte TLV with length field set to one. > > The padding here seems unnecessarily complex. I am left to > wonder whether a 4 byte Value field should have a Length of > 1, 2, 3 or 4 (or any of the above). Personally, I think any > word-alignment gains achieved by forcing the Value to be > divisible by 4 here are outweighed by the interoperability > overhead necessary to ensure that this is interpreted > correctly by all parties. These padding rules are not uncommon in RSVP, and there seems no reason not to continue to use them. The authors feel that the descriptive text and the example make the meaning quite clear. >> 3.1 Attributes Flags TLV >> >> This document defines only one TLV type value. Type 1 >> indicates the Attributes Flags TLV. Other TLV types may >> be defined in future with type values assigned by IANA. > > A direct reference to the IANA consideration section that > deals with this would be nice here. A reference has been added. >> [snip] >> >> Unassigned bits are considered as reserved and MUST be >> set to zero on transmission by the originator of the >> object. Bits not contained in the TLV MUST be assumed >> to be set to zero. If the TLV is absent either because >> it is not contained in the LSP_ATTRIBUTES or >> LSP_REQUIRED_ATTRIBUTES object, or because those objects >> are themselves absent, all processing MUST be performed >> as though the bits were present and set to zero. > > Would it be simpler and sufficient just to say that > unassigned bits are set to zero on transmission and > ignored upon receipt? This comment has missed the point. It is true that unassigned bits MUST be set to zero on transmission as the text says. However, the text continues to describe *assigned* bits that are not present either because the TLV is deliberatley forshortened, or because the TLV is not included. In these cases the receiver MUST act (as described by the text) as though the assigned bits are set to zero. The text has been clarified further. >> [snip] >> >> No bits are defined in this document. The assignment >> of bits is managed by IANA. > > Again, a direct reference to IANA would be nice. Reference added. >> 5. LSP_REQUIRED_ATTRIBUTES Object >> >> The LSP_REQUIRED_ATTRIBUTES object is used to signal >> attributes required in support of an LSP, or to >> indicate the nature or use of an LSP where that >> information MUST be inspected at each transit LSR. >> Specifically, each transit LSR MUST examine the >> attributes in the LSP_REQUIRED_ATTRIBUTES object and >> MUST NOT forward the object transparently. > > If, after examination of the attribute at the LSR, it is > determined that the object should be forwarded > transparently, is that a protocol violation? Probably not, > though the text above might spark such a debate. We had a jolly time debating the meaning of the word 'transparent'. In order to spare us another such discussion the text has been modified to read as follows... The LSP_REQUIRED_ATTRIBUTES object is used to signal attributes required in support of an LSP, or to indicate the nature or use of an LSP where that information MUST be inspected at each transit LSR. Specifically, each transit LSR MUST examine the attributes in the LSP_REQUIRED_ATTRIBUTES object and MUST NOT forward the object without acting on its contents. >>[snip] >> >> There is a one-to-one correspondence between bits in the >> Attributes Flags TLV and the RRO Attributes Subobject. If >> a bit is only required in one of the two places, it is >> reserved in the other place. See the procedures sections, >> below, for more information. >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Type | Length | Reserved | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | | >> // Attribute Flags // >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > I don't understand the advantage of creating a subobject TLV > format with one-byte Type and Length here, particularly given > that the Value is the same number-space as the Main TLV. Why > not just use the same TLV format and rules that have already > been defined? Is there some intended used of the Reserved field > or desire to keep the Type field small? After some discussion, we agreed that keeping the same subobject format as all of the other subobjects in the RRO was likely to increase the chance of the RRO being successfully parsed and would probably be beneficial for backwards compatibility. >> 7.3.1 Subobject Presence Rules >> >> [snip] >> >> If the new subobject causes the RRO to be too big to >> fit in a Path (or Resv) message, the processing MUST >> be as described in [RFC3209]. > > A quick summary of what this means, or section within 3209 > would be a nice gesture for the reader. The authors are always happy to gesture to the reader, and have added a reference to section 4.4.3 of RFC 3209. >>7.3.2 Reporting Compliance with LSP Attributes >> >> To report compliance with an attribute requested in the >> Attributes Flags TLV, an LSR MAY set the corresponding >> bit (see Section 8) in the Attributes subobject. To >> report non-compliance, an LSR MAY clear the corresponding >> bit in the Attributes subobject. >> >> The requirement to report compliance MUST be specified in >> the document that defines the usage of any bit. This will >> reduce to a statement of whether hop-by-hop acknowledgement >> is required. > > So, each implementation will have to keep a list of which bits > it should react to, and which it shouldn't? This seems to be > rife with interop headaches. Why not just mandate the MUST here > and force the follow-on documents to inherit this? Or, split > the bits into different attributes (hop-by-hop or not > hop-by-hop)? Since each implementation will have to keep a list of what it has to do for each bit, this is nothing special. No change is made to the document. >> 11.3 Attributes Flags >> >> [snip] >> >> IANA is requested to manage the space of attributes bit flags >> numbering them in the usual IETF notation starting at zero and >> continuing through 2039. > > So, there are up to 2039 individual bits allowed? Isn't that a bit > of overkill? No, that would be 2040 bits. But the text should read 31. John Loughney added some further review comments >> Major comment is that I find the IANA section inadequate. >> It seems to be introducing a new namespace for IANA to take >> care of, but no rules on how new values are allocated. It >> seems to indicate that an RFC number is needed in section >> 10.3, but I think this needs to be more specific. The text >> in other places of the document are not so clear at what >> constitues a reason for allocating new bit flags, etc., >> so in the IANA section, I think there needs to be explicit >> text on the the mechanisms for specifying and definting them. We believe that this issue is addressed by the changes to the IANA sections already discussed. > 1) Way too much acronyms in the abstract ... Well, there are five. Each is expanded on first usage. This doesn't seem unreasonable to us. > 2) Took me several reads to be able to parse the following > text: > >> .... Because of the nature of the TLV >> construction the object is flexible and allows the future >> definition of: >> - further bit flags if further, distinct uses are discovered >> - arbitrary options and attributes parameters carried as >> individual TLVs. > >suggest: > > The new RSVP-TE message object is quite flexible, due to > the use of the TLV format and allows: > - future specification of bit flags > - additional options and atttribute paramerters carried > in TLV format. New text used. > 3) This text was confusing: > >>4.2 Generic Processing Rules for Path Messages >> >> An LSR that does not support this object will pass it on >> unaltered because of the C-Num. > >suggest: > >4.2 Generic Processing Rules for Path Messages > > An LSR that does not support this object is required to pass > it on unaltered, as the C-Num indicates that the LSR should > pass the object on transparently. In order not to get into another discussion of the meaning of the word 'transparent' we have settled on the following text.. An LSR that does not support this object is required to pass it on unaltered as indicated by the C-Num and the rules defined in [RFC2205]. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls |
|