[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: AD review of: draft-ietf-tewg-diff-te-proto-05.txt
Bert,
Focusing on the few remaining ones.
>> > There is text to that effect already:
>> > " Where the configured TE-class mapping and the
>> > Bandwidth Constraints model in use are such that BCh+1,
>> > BCh+2, ...and BC7 are not relevant to any of the
>> Class-Types
>> > associated with a configured TE-class, it is
>> recommended that
>> > only the Bandwidth Constraints from BC0 to BCh
>> be advertised,
>> > in order to minimize the impact on IGP scalability. "
>> > Not good enough?
>> >
>> So what happens if people do add the BCh+1 through 7 ??
It just means that "h" is getting bigger, so you advertise a higher
number of values. Don't think there is any issue here.
>> should the "recommended" be changed in "RECOMMENDED", or "MUST" ??
OK for RECOMMENDED.
>> > Clearly, all the
>> padding/length-encoding/IEEE-floating-point rules of
>> > RFC3630 and draft-ietf-isis-traffic apply.
>> > Rather than try restate all of those, I would propose we
>> add a statement
>> > to the effect that "all relevant generic TLV encoding
>> rules define in
>> > RFC3630 and draft-ietf-isis-traffic are applicable to this
>> > new sub-TLV."
>> >
>> Well, from all that I tried to visualize how this works. You have a
>> 1 octet BC Model ID and a set of 4-octet Floats. Does that then
>> get transmitted as follows:
>>
>>
>> 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
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | ModelId | padding |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | BC0 value |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> // BC. value //
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | BCh value |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>> I think so, but am not sure.
The padding rules of RFC3036 only apply at the TLV level. Here we are
talking about alignment inside the Value field of the sub-TLV itself, so
we do need to be more explicit.
I will:
- add an explicit 3 byte "reserved" field (after Model ID) and
before BC values.
- add a figure like yours above.
>> > >> I suggest to make citation/reference to IEEE floating
>> point spec
>> > >>
>> >
>> > This should be captured by the new sentence discussed above:
>> > "all relevant generic TLV encoding rules define in RFC3630 and
>> > draft-ietf-isis-traffic are applicable to this new sub-TLV." (these
>> > documents do define the floating point format).
>> >
>> I know that various IESG members were objecting not having proper
>> references. I'd siggest to add one, just for expediency and extra
>> clarity. The less deeper the nesting of ptrs the easier for the
>> readoer, no?
>>
But, to me, pointing to RFC3036 is a proper refernce since it does
include text defining the IEEE floating point format. Really, -proto- is
a delta over RFC3036. It is fine to assume complete understanding of
RFC3036. Also, there are many many generic rules of RFC3036 which apply
to that particular sub-TLV. I don't think we should try restate them.
I can make the reference to RFC3036 a little more specific if that
helps:
"all relevant generic TLV encoding rules defined in RFC3630 and
draft-ietf-isis-traffic (including TLV structure, encoding, padding and
alignment, IEEE floating point format encoding,...) are applicable to
this new sub-TLV."
>
>> It currently saus:
>> 6.2.1. CLASSTYPE object
>>
>> class = TBD, C_Type = 1 (need to get an official class
>> num from the
>> IANA with the form 0bbbbbbb). See IANA Considerations
>> section below.
>>
>> 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
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | Reserved | CT |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>>
>> Reserved : 29 bits
>> This field is reserved. It must be set to zero on transmission
>> and must be ignored on receipt.
>>
>> CT : 3 bits
>> Indicates the Class-Type. Values currently allowed are
>> 1, 2, ... , 7.
>>
>> So you want the IANA staff (and the generic reader of the spec) to
>> understand that you mean that you want to define a new "Class Name"
>> with the name being "CLASSTYPE" ???
>> And that the Class Bumber is TBD.
>> Now read again that para above! Specifically, cause you also use
>> CT to mean Class-Type. ANd then you talk about C_Type (with
>> underscore)
>> while the IANA registry uses C-Type (with hyphen).
Interesting. I inherited the "C_Type" spelling from the RSVP-TE spec
(RFC3209).
>>
>> WHen you read it, try to read it as if you are IANA personell, you
>> know something about registrations, but you do not know details about
>> RSVP, or about which exact registry/name-space you are talking about.
>> Do not assume people know as many details about this RFC-to-be as you
>> do, please.
>>
I'll be as explicit as I can then. Here's what I will update to:
"
6.2. CLASSTYPE Object
The CLASSTYPE object Class Name is CLASSTYPE. Its Class Number is TBD
(to be assigned by IANA with the form 0bbbbbbb - See IANA Considerations
section below). Currently, there is only one possible C_Type which is
C_Type 1. The CLASSTYPE object format is shown below.
6.2.1. CLASSTYPE object
Class Number = TBD (the number discussed in 6.2 above to be assigned by
IANA to the CLASSTYPE object Class)
Class Type = 1
"
>> >
>> > I don't think we need that last sentence, since once the number is
>> > actually allocated by IANA it will be specified in section
>> 5.1 above and
>> > that part of the IANA Considerations section will just disappear.
>> >
>> I think (and I believe IANA wants that too) that it helps if
>> you summarize
>> in the IANA COnsiderations section which assignments have
>> been requested
>> and which ones have been made.
>> Maybe not si much for when a reader is trying to implement this spec,
>> cause he/she will be reading the details.
>> But for people who need to check and manage/administer the IANA
>> maitained namespaces this is very helpfull.
I didn't realise they wanted the list of numbers allocated to remain in
the spec.
I looked at RSVP-TE (RFC3209) and ,like you said, I see that every
number allocated there is listed again in the IANA section.
Will do that as well then.