RE: AD review of: draft-ietf-tewg-diff-te-proto-05.txt

Inline

> -----Original Message-----
> From: Francois Le Faucheur (flefauch) [mailto:[email protected]]
> Sent: woensdag 17 december 2003 19:17
> To: Wijnen, Bert (Bert)
> Cc: Tewg (E-mail); [email protected]
> 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