[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: AD evaluation: draft-ietf-tewg-diff-te-mar-02.txt
If the WG wants to use the current number 0,1,2 for
RDM, MAM, MAR respectively, then the IANA considerations
sections should contain text aka (RDM example):
IANA-Note (to be removed at RFC-Publication time):
We request IANA to assign value 0 for the RDM model.
As for the partitioning of the number space, I am not so sure I agree.
If you have used any sofar, then you did so at your own risk by
assuming that I-D level specs are stable. I think there are GOOD
reasons NOT to set asside half the number space for experiments
and code points that nobody registers in the IANA registry to be.
Thanks,
Bert
> -----Original Message-----
> From: Ina Minei [mailto:ina@juniper.net]
> Sent: donderdag 18 december 2003 0:53
> To: Wijnen, Bert (Bert)
> Cc: Ash, Gerald R (Jerry), ALABS; Tewg (E-mail)
> Subject: RE: AD evaluation: draft-ietf-tewg-diff-te-mar-02.txt
>
>
>
> Bert,
>
> If I am reading this correctly, the model-ids will be
> assigned by
> IANA. One request: when asking for these assignments, it will be very
> useful to maintain the already assigned numbers, including the
> partitioning of the number space into public and private space.
>
> Are we in agreement on that?
>
> Thank you,
>
> Ina
>
> On Thu, 18 Dec 2003, Wijnen, Bert (Bert) wrote:
>
> > 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
> >
>