[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: AD review of: draft-ietf-tewg-diff-te-proto-05.txt
Inline
> -----Original Message-----
> From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com]
> Sent: woensdag 17 december 2003 19:17
> To: Wijnen, Bert (Bert)
> Cc: Tewg (E-mail); flefauch@cisco.com
> Subject: 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.
>
I am getting nore confused by your answer.
Does everyone else understand what is meant?
> >> 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.
>
Thanks
> >> > >> 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:
in the above I am sure you mean 3620 instead of 3036
in the following you have it correct
> "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."
>
I can live with it. If other IESG members push back later, so be it.
> >
> >> 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).
>
Then probably C_Type is fine. Seems that IANA web site is not in sync
with the RFC then. Maybe we should point that out.
I checked 3209. It uses both C_Type and C-type. Mmmm... pretty inconsistent.
So who am I to tell you to do better.
> >>
> >> 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
> "
and then the figure/diagram I assume
> >> >
> >> > 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.
>
OK, sounds good.
So we are in sync that the various BC Models (MAM, MAR, RDM) should request
the assigments for the specific BC Model ID ??
I think the other editors (Jerry) need to know so all 4 docs can get
updates and be in sync.
Bert