[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: Ina Minei [mailto:ina@juniper.net]
> Sent: maandag 29 december 2003 20:39
> 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,
>
> 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.
>
I do not understand this. Experiments are experiments. They should
NOT last very long (or so I think).
So by getting many numbers in that space, it encourages vendors to use
"experimental" namespace for long term product-level assignments.
That is exactly what we want to avoid I would think.
> 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.
>
I am (personally) reluctant, see above.
Bert
> 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
> > > >
> > >
> >
>