[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: AD review of: draft-ietf-tewg-diff-te-proto-05.txt
- To: "Tewg (E-mail)" <te-wg@ops.ietf.org>
- Subject: RE: AD review of: draft-ietf-tewg-diff-te-proto-05.txt
- From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
- Date: Wed, 17 Dec 2003 17:25:44 +0100
resend to wg list, which now seems to accept my postings again
-----Original Message-----
From: Wijnen, Bert (Bert)
Sent: woensdag 17 december 2003 16:51
To: 'Francois Le Faucheur (flefauch)'
Cc: Tewg (E-mail)
Subject: RE: AD review of: draft-ietf-tewg-diff-te-proto-05.txt
[Note: seems my other postings to TEWG are not coming through yet.
I am checking on that.]
Inline
> -----Original Message-----
> From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com]
> Sent: woensdag 17 december 2003 15:23
> To: Wijnen, Bert (Bert)
> Cc: Tewg (E-mail); flefauch@cisco.com
> Subject: RE: AD review of: draft-ietf-tewg-diff-te-proto-05.txt
>
>
> Hello Bert,
>
> Thanks for your thorough review. Please see thoughts/proposal below:
>
> >>So something aka:
> >>
> >> With DS-TE, the existing "Maximum Reservable Bandwidth" sub-TLV
> >> (sub-TLV of the Link TLV of the TE Extensions to OSPF Version 2
> >> [RFC3630]) is retained
>
> Yes, I'll add such a reference to [RFC3630] for OSPF (and to
> draft-ietf-isis-traffic-05.txt for ISIS).
>
Thanks
> >> I think it is better to expand Bw to Bandwidth in the above, cause
> >> that is how it is named in RFC3630.
>
> OK.
>
> >> with a generalized semantic so that it MUST now be interpreted as the
> >> aggregate bandwidth constraint across all Class-Types [ i.e.
> >> SUM (Reserved (CTc)) <= Max Reservable Bandwidth], independently of
> >> the Bandwidth Constraints Model.
> >>
> >> So does that mean that you basically UPDATE RFC3630? You change the
> >> definition of one of the sub-TLVs in that document.
>
> Yes, we "generalize the semnatic". Same thing applies to the
> "Unreserved Bandwidth" sub-TLV.
>
OK, I see that now. SO that also updates RFC3630 and the one for ISIS
> >>If so (which I think) then you must add to the abstract that you do
> update RFC3630.
> >>
>
> Will do.
>
Good, and please add which pieces of which RFC are being UPDATED.
> >> This document also defines the following new optional sub-TLV to
> >> advertise the eight potential Bandwidth Constraints (BC0 to BC7):
> >>
> >> "Bandwidth Constraints" sub-TLV:
> >> - Bandwidth Constraint Model Id (1 octet)
> >> - Bandwidth Constraints (Nx4 octets)
> >>
> >> So should I assume that if there are only 3 bandwidth constraints, then
> >> N above is 3 ??
> >> I think it can be made clearer if there always need to be
> >> 8, or if that is not the case, what the value of N is in
> >> that case and how that is determined.
> >>
>
> 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 ??
should the "recommended" be changed in "RECOMMENDED", or "MUST" ??
> >>
> >> Would be good to describe if this needs to be a length to be padded
> >> to 32 bits (as also in RFC3630). I think a diagram mightbe helpfull too.
> >>
>
> 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. Adding a figire would make it much clearer,
don't you think?
> >> - With ISIS, the sub-TLV is a sub-TLV of the "extended IS
> >> reachability TLV" and its sub-TLV type is TBD. See IANA
> >> Considerations section below.
> >>
> >> similarly, point to RFC describing the ISIS TLVs, so people know where
> >> it fits.
>
> OK.
>
> >> 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?
>
> >> - Then on next page (page 11) I read:
> >> A DS-TE LSR receiving the "Bandwidth Constraints" sub-TLV with a
> >> Bandwidth Constraint Model Id which does not match the Bandwidth
> >> Constraint Model it currently uses, MAY generate a warning to the
> >> operator reporting the inconsistency between Bandwidth Constraint
> >> Models used on different links. Also, in that case, if the DS-TE LSR
> >> does not support the Bandwidth Constraint Model designated by the
> >> Bandwidth Constraint Model Id, or if the DS-TE LSR does not support
> >> operations with multiple simultaneous Bandwidth Constraint Models,
> >> the DS-TE LSR MAY discard the corresponding TLV. If the DS-TE LSR
> >> does support the Bandwidth Constraint Model designated by the
> >> Bandwidth Constraint Model Id and if the DS-TE LSR does support
> >> operations with multiple simultaneous Bandwidth Constraint Models,
> >> the DS-TE LSR MAY accept the corresponding TLV and allow operations
> >> with different Bandwidth Constraints Models used in different parts
> >> of the DS-TE domain.
> >>
> >> What is are all these MAY cases??? What else can a DS-TE LSR do if it
> >> does not recognize or support a Model Id ??
>
> If it doesn't support a Model ID, the LSR can just do nothing. We are
> suggesting that it may do a few useful things (like let operator know
> there is something odd).
> I will turn the first "MAY" into a "SHOULD" because it is clearly
> "goodness" to notify operator.
> For the other MAYs, different people may want different behaviour so it
> is probably best to keep them as "MAY".
>
> Also, I will replace "to the operator" by "to the operator/management
> system".
>
I leave it up to you. It seemed to me there are too many MAYs, so that
it would be difficult to determine what actually will happen.
I thought that if one receives in unsupported/unknown Model ID, that
it would be much more detrministic to discard it, and send an error
to the sender. But if all WG memebrs think the current etxt is fine!?
Oh well.
> >>
> >> - Section 6.2.1 should be more explicit.
> >> I think you need to specify that you want a Class-Number of TBD,
> >> a Class-Name of CLASSTYPE, a C-Type of 1.
>
> Can't see what is missing:
> We have specified the Class-Name of CLASSTYPE and the C-Type of 1
> already.
> We need IANA to allocate the Class-Num (from 0bbbbbbb range). I
> understand RFC Editor will put the IANA allocated value in
> there as soon
> as it is allocated before publication.
>
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).
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 think value zero should be stated to be reserved.
> >>
>
> Agreed.
>
> >> - Section 6.3
> >> I suspect that the reason why you reserve CT=0 and do not pass it
> >> ever in a CLASSTYPE object sis for backward compatibility?
>
> Yes.
>
> >> It would be good to make that explicit if that is the case.
>
> OK. I'll add a statement on this and will point to section 10 "existing
> TE as Particular Case of DS-TE" and Appendix C "Interoperability with
> non DS-TE capable LSRs" for details on how it actually helps.
>
>
> >> - section 6.3 has:
> >>
> >> If a path message contains multiple CLASSTYPE objects, only the first
> >> one is meaningful; subsequent CLASSTYPE object(s) MUST be ignored and
> >> MUST not be forwarded.
> >>
> >> I think you mean "MUST NOT" instead of "MUST not" ??
>
> Yes.
>
> >> - In section 6.4 I see:
> >>
> >> In both situations, this causes the path set-up to fail. The sender
> >> SHOULD notify management that a LSP cannot be established and
> >> possibly might take action to retry reservation establishment without
> >> the CLASSTYPE object.
> >>
> >> What is "management" in this case? Is it a management system ?
>
> Yes. So how about I update that with "The sender SHOULD notify the
> operator/management system that ..." ?
>
Sounds better to me
> >> Probably better to say something aka:
> >>
> >> This document does not introduce additional security threats beyond
> >> those described for Diff-Serv [add refrence] and MPLS Traffic
> >> Engineering [add reference] and the same security measures and
> >> procedures described in those documents apply here.
> >>
> >> Same comments on the rest of security considerations.
>
> Works for me.
>
> >> - for one thing you refer to section 5.3, which does not exist.
>
> 5.3 --> 5.1
>
I understand. Pls fix it
> >> - I would make separate subsections for each assignment in different
> >> namespaces. That makes it clearer.
>
> OK.
>
> >> - you write:
> >>
> >> This document defines a number of objects with implications for IANA.
> >>
> >> This doc requests IANA to male assigments in a few namespaces.
> >> It also requests IANA to create and maintain a new namespace registry.
> >>
> >> The above 2 sentences would be section 14 if I had written this.
> >>
> >> Then I would have a subsection for each of the following
> >>
>
> OK.
>
> >> So better would be:
> >>
> >> 14.1 Bandwidth Constraints sub-TLV for OSPF version 2
> >>
> >> This document defines in section 5.1 a new sub-TLV, the "Bandwidth
> >> Constraints" sub-TLV, for the OSPF "Link" TLV [OSPF-TE]. The sub-TLV
> >> requested is in the range 10 to 32767 needs to be assigned by IANA.
>
> OK.
>
> >> IANA has assigned TBD for the "Bandwidth Constraints" sub-TLV.
> >>
>
> 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.
Pls think of yourself as reading this in other roles than just as
author/editor of the spec. Think how implementers read it, think
how oeprators read it, think how IANA, RFC-Editor, other people
will read it as well.
> >> Pls do a similar text for the ISIS sub-TLV assignment.
> >>
>
> OK.
>
> >> - For:
> >>
> >> This document defines in section 5.3 a "Bandwidth Constraint Model
> >> Id" field within the "Bandwidth Constraints" sub-TLV. This document
> >> also defines in section 5.3 two values for this field (0 and 1).
> >> Future allocations of values in this space and in the range 2 to 127
> >> should be handled by IANA using the First Come First Served policy
> >> defined in [IANA]. Values in the range 128 to 255 are reserved for
> >> experimental use.
> >>
> >> I feel that this document should NOT make the assignments for the
> >> RDM/MAM and MAR models. Those are experimental RFCs and I think that if
> >> we make assignments here, that we cause a normative ref to experimental
> >> RFC and that is a nono for a stds track document.
> >>
> >> Each Model document can claim (in its IANA section) an assignment from
> >>
>
> OK. I'' remove the specific numbers from proto and we'll also update
> RDM, MAM, MAR so that their ID is allocated from there.
>
Thanks. I really think this makes sense. But I hope that other WG memebrs
think so too. It is not that when an AD has comments that you juts MUST make
changes to please him/her. Only if his/her comments make sense.
I believe though that most of my IESG collegues believe the same.
> >> So what we must do here is to specify the namespace, request IANA to
> >> create and maintain it, and specify the rules for making assignments.
>
> OK.
>
> >> Se also my earlier comments on the ranges. I think that 128-255 for
> >> experimental use is far too many.
>
> Agreed.
>
> >> I think that something aka the following makes much more sense:
> >>
> >> 14.x A new namespace for Bandwidth Constraint Model Identifiers
> >>
> >> This document defines in section 5.1 a "Bandwidth Constraint Model
> >> Id" field (namespace) within the "Bandwidth Constraints" sub-TLV,
> >> both for OSPF and ISIS.
> >>
> >> IANA is requested to create and maintain this new namespace. The
> >> field for this namespace is 1 octet, and IANA guideliens for
> >> assigments for this field are as follows:
> >>
> >> o values in the range 0-64 are to be assigned via Standards Action
> >> as defined in [RFC2434]
> >>
> >> o values in the range 65-127 are to be assigned via Specification
> >> Required
> >>
> >> o values in the range 128-252 are not to be assigned at this
> >> time. Before any assignments can be made in this range, there
> >> MUST be a Standards Track RFC that specifies IANA Considerations
> >> that covers the range being assigned.
> >>
> >> o values in the range 253-255 are for experimental use; these will
> >> not be registered with IANA, and MUST NOT be mentioned by RFCs.
> >>
>
> As we started discussing privately, I recommend we do not separate the
> ranges for "Standards Action" and for other "Specification Required"
> (such as RFC in Experimental Track). It is very possible that a BC Model
> first published in Experimental Track later becomes a Standards Track
> spec, and it should keep the same ID.
I'd like to hear WG member opinions on this.
Your argument makes some sense too. So maybe just a Specification
Required is OK. Nit sure. Opinions please!?
> Also, I think it may be a little overkill to set aside a range (128-252)
> which could be used in the future for purposes which are yet to be
> defined (or do you have something specific in mind?).
>
The reason for that is (specifically if you do just Specification Required)
that if we fill up the first 128 values much faster than we currently think,
that we then have a checkpoint so to speak to see if we need to change the
rules for assigning values. If we do not set that space aprt, we may only
find out when we have only 5 or so values left at which time there is
not much we can do. RFC 3630 does similar thing by the way.
> So how about simply:
> "
> o values in the range 0-247 are to be assigned according to the
> "Specification Required" policy defined in [RFC2434].
> o values in the range 248-255 are for experimental use; those
> will not be registered with IANA and MUST NOT be mentioned
> by RFCs..
> "
>
See above
> >> - Pls also reconsider the text for the RSVP-TE object and error codes
> >> in light of the above
>
> Will make that a separate subsection.
>
> >>
> >> - If you can add the IANA web page that contains the current registry,
> >> then it will help IANA to more quickly understand what they need to
> >> do, and it will help future readers to quickly find the
> >> assignments repository.
>
> I can add pointer to "http://www.iana.org/assignments/rsvp-parameters";
> for the rsvp numbers.
That would be good I think.
> For the sub-TLV numbers, I couldn't locate specific pages on IANA.
>
Same problem for me. I have a request oustanding at IANA.
It is strange that they seem not to be on the web pages.
> >>
> >> Nits/admin issues
> >>
>
> I'll address all the nits/admin issues you listed. Comments on just a
> few of those:
>
> >> - section 6.3
> >> Why do you use different editorial styles or textual formatting to
> >> describe how an LSR should handle the receipt of a CLASSTYPE object?
>
> I didn't get the issue. Could you be more specific?
>
Look at pages 14 and 15. Page 14 every paragraph is just flowing text
and each para describes a situation and how to handle it.
On page 15, each para still describes a situation and how to handle
it, but it uses bulleted lists instead of just flowing text.
I think I like the bulleted lists better, but that is just a matter
of taste, so I leave that up to you. But I would use a single style,
certainly within one section.
> >> - APpendix A, might want to add a few words why it is included.
>
> The main reason for Appendix A is to indicate the dependencies between
> (i) doing Head-end prediction and (ii) the need to advertise something
> in IGP which is otherwise optional.
> The text lists these dependencies so it should be fairly
> clear that the appendix is here to list these dependencies.
>
As I said it is a nit. If it is clear to everyone already, then fine/
> >> What is a "Head-End" ?? May want to explain that
> It is the LSR at the "head" of the tunnel (ie from which the TE Tunnel
> originate). It is a very commonly used term in TE.
>
I see that the term occurs earlier on in the doc too.
Not sure why I only wondered when reading appendix.
I think it comes back to which people we expect to read the final RFC.
Many of the TE experts probably can deal with all this. Others may
find it more difficult. Again, it was just a nit/question.
Bert
> Thanks
>
> Francois
>