RE: AD evaluation: draft-ietf-tewg-diff-te-mar-02.txt

Inline

> -----Original Message-----
> From: Ina Minei [mailto:[email protected]]
> 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:[email protected]]
> > > 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:[email protected]]
> > > > > 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
> > > >
> > >
> >
>