[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: AD evaluation: draft-ietf-tewg-diff-te-mar-02.txt
Bert,
I agree with you that setting aside half the number space seems
unnecessary at the moment.
However, regarding private numbers, one should have at least the
same number of experimental models as the models defined today. There is a
good reason for this: since we have little experience with models, vendors
may choose to extend/change a particular model in a proprietary way. That
being said, today we would need 3 vendor-specific numbers. If we only
allocate 3, as was proposed on this list, then we will have no room for
growth.
How about we agree on 32 experimental numbers, at the end of the
number space, 255 and down? Please let me know what you think, and let's
carry this work forward. Francois is open to this proposal as well.
Thank you,
Ina
On Thu, 18 Dec 2003, Wijnen, Bert (Bert) wrote:
> 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
> > >
> >
>