[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: AD evaluation: draft-ietf-tewg-diff-te-mar-02.txt
Inline
> -----Original Message-----
> From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com]
> Sent: woensdag 17 december 2003 18:58
> To: Wijnen, Bert (Bert); Tewg (E-mail)
> Cc: Ash, Gerald R (Jerry), ALABS
> Subject: RE: AD evaluation: draft-ietf-tewg-diff-te-mar-02.txt
>
>
> Hi Bert,
>
> > I have already received answers from Jerry when I brought
> > the below to his attention.
> > Jerry, feel free to post them to the list too, so that
> > everyone knows where you want to go.
>
> Yes, please see my responses below.
>
> > I do want the WG members to be aware of the status, thus
> > this posting.
> >
> > I believe Jerry is getting ready to post a new revision.
> > But what exactly needs to be changed and added may also depend
> > a bit on what fixes we will agree to for the base protocol spec
> > (see my review comments for that posted yesterday).
>
> Agreed. Please see my proposal below concerning the
> Bandwidth Constraint Model Id. I think we should be uniform
> in assignment, either all done in Model ID's, or all done in
> the PROTO ID. I agree that proposing assignments in the
> Model ID's is preferable.
>
I think Francois is in agreement now too, but he did not yet
explicitly say so (I believe).
> > Jerry, there are some more/new comments under nits/admin below.
> > Pls take a look.
> >
> > More or less serious:
> >
> > - In sect 6 I see:
> >
> > Now let's say an LSP arrives for CT2 needing 5 units of bandwidth (i.e.,
> > DBW = 5). We need to decide based on Table 1 whether to admit this
> > LSP or not. Since for CT2
> >
> > RESERVED_BW2 < BC2 (10 < 20), and
> > DBW < UNRESERVED_BW (i.e., 10 - 10 < 5)
> >
> > Table 1 says to admit the LSP.
> >
> > Should that be
> > DBW < UNRESERVED_BW (i.e., 5 < 10) ??
>
> Yes, correct, and should be changed.
>
OK
> > - Your Security considerations refers to the requirements.
> > It probably would be better to refer to the PROTO doc, like
> > the RDM and MAM doc do? I know that the PROTO doc needs
> > to be improved for the security considerations.
>
> Yes, OK.
>
OK
> > - I do not see that you state that your model requires/depends on
> > the protocol extensions as described in the PROTO document.
> > Does it not depend on that? If so then I may not have understood
> > it yet.
>
> Yes, MAR does certainly depend on the PROTO document.
>
OK
> > If it does depend, then I wonder if you do not need to get a
> > Model ID assigned (as in sect 5.1 of PROTO document, where it
> > does assign 0 for RDM and 1 for MAM).
>
> Right, we do need a Model ID assigned for MAR. This was an
> oversight in the last call on the PROTO document.
>
Good
> > I think that such assignments should not be done in the PROTO
> > doc itself but in each model-specific document. But in any
> > event, I see none for MAR and wonder if that is correct
>
> Yes, assuming that we use the same approach in the other
> Model IDs, text needs to be added to the MAR ID. According
> to your suggestion, perhaps something like this needs to be
> included in the MAR ID:
>
> "[DSTE-PROTO] 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)
>
> Where:
>
> - Bandwidth Constraint Model Id: 1 octet identifier for the
> Bandwidth Constraints Model currently in use by the LSR
> initiating the IGP advertisement.
> - Value 2 identifies the Maximum Allocation with
> Reservation Model specified in this document."
>
> Would that suffice as a new Section in the MAR ID?
>
I think I would not be as specific. But in any event, I propose that the
authors of the 3 BC Model Docs get together and use a common way to
specify this and to request assignment. I think I would say something aka
(but this is just my personal opinion):
"[DSTE-PROTO] defines the optional "Bandwith Constraints" sub-TLV to
advertise the eight potential Bandwidth Constraints (BC0 to BC7).
It contains a field for the Bandwidth Constraint Model Id.
This document specifies the Maximum Allocation with Reservation (MAR)
Bandwidth Constraint Model and it used value TBD in the Model
Bandwidth Constraint Model Id field.
>
> > Nits/admin
> >
> > - in sect 2 I see a couple of "3D" strings, which I suspect
> > need to be "=" signs, correct? This is the text:
> >
> > RESERVED_BWck: reserved bandwidth-in-progress on CTc on link k (0 <3D c
> > <3D MaxCT-1), RESERVED_BWck 3D total amount of the bandwidth reserved
> > by all the established LSPs which belong to CTc.
> >
> > UNRESERVED_BWck: unreserved link bandwidth on CTc on link k specifies
> > the amount of bandwidth not yet reserved for CTc, UNRESERVED_BWck 3D
> > MAX_RESERVABLE_BWk - sum [RESERVED_BWck (0 <3D c <3D MaxCT-1)].
>
> Yes, correct. These 3D's should be changed to = signs.
>
OK
> > - Table 4 in appendix A.2
> > The text just before the table talks about "30% general overload"
> > while the caption of the table talks about "50% General Overload"
> > Should they be in sync?
>
> Yes, it should refer to 50% general overload.
>
OK
> > - Can you add pagination please?
>
> Yes, OK.
>
Thanks
> > - Although an IPR statement (RFC2026, sect 10) is not mandatory, it would
> > be good to add one. Certainly if we plan to move one or more
> > of the BC models to stds track in the future.
>
> OK, I'll look into that.
>
Thanks
> > - If the MAR BC Model ID gets requested in this document (which would be
> > my preference), then we also need an IANA Considerations Section.
>
> OK. Here is a possible text:
>
> "IANA Considerations
>
> This document defines in Section xx a "Bandwidth Constraint
> Model Id" field within the "Bandwidth Constraints" sub-TLV.
> This document also defines in Section xx a value for this field (2)."
>
> Would that suffice as a new Section in the MAR ID?
>
I think (based on my otehr text above), I would do something aka:
IANA Considerations
This document defines in Section xx a value to be used in the "Bandwidth
Constraint Model Id" field within the "Bandwidth Constraints" sub-TLV.
According to the guidelines specified in [DSTE-PROTO], IANA has assigned
value TBD to identify the Maximum Allocation with Reservation (MAR)
Bandwidth Constraint Model.
> > - Try to be consistent with the base protocol spec in that you use the
> > same capitalization/spelling for "Bandwidth Constraints Model".
> > There are possibly other such strings/phrases as well that could
> > benefit from more consistency.
>
> Fine by me. In looking at the PROTO draft, I see these
> different versions of this:
> Bandwidth Constraints Model
> Bandwidth Constraint Model
> Bandwidth Constraints model
>
> Which one do we want to use?
>
I propose that the various editors/authors of the documents get together
to agree on a common notation.
> I also noted that the RFC Editor commented on a related nit
> in the review of Wai Sum's submission, as follows:
>
> "you use the term "bandwidth constraints models"; we suggest
> that this would be much less awkward if it were "bandwidth
> constraint models". RFC 3564 actually has both forms, which
> we should have caught when it was published; however, that
> ambiguity allows you to choose the less awkward form for your
> document. There are of course many occurrences of this.
>
> [BTW, better English usage would be "bandwidth-constraint
> models" -- the stacked adjectives should really be hyphenated
> -- but we do not insist on this, since RFC 3564 did not
> hyphenate the term]"
>
> Maybe we should use, since we are changing all the Model IDs
> and the PROTO ID:
>
> Bandwidth-Constraint Model
> or
> Bandwidth-Constraint Models
>
> (as the case may be).
>
> Is this OK?
>
As I said above. I prefer us to be consistent over the 4 documents at
least. Maybe Wai Sum can still make his doc consistent as well.
I proposed above that the editors/authors get together to agree on
a common notation.
> Thanks,
> Jerry
>
Bert