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

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Wed, 17 Dec 2003 17:15:36 +0100

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.

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 exatcly 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).

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)  ??

- Your Security considerations refers to the requiremwents.
  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.

- 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.
  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).
  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

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)].

- 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?

- Can you add pagination please?

- 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.

- If the MAR BC Model ID gets requested in this document (which would be
  my preference), then we also need an IANA Considerations Section.

- Try to be consistent with the base protocol spec in that you use the
  same capitalization/spelling for "Bandwidth Contraints Model".
  There are possibly other such strings/prhases as well that could
  benefit from more consistency.

Thanks,
Bert

---

From: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>
Date: Wed, 17 Dec 2003 11:58:20 -0600

Hi Bert,

> everyone knows where you want to go.

Yes, please see my responses below.
 
> But what exactly needs to be changed and added may also depend

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.
 
>     DBW < UNRESERVED_BW (i.e., 5 < 10)  ??

Yes, correct, and should be changed.
 
> - Your Security considerations refers to the requirements.

Yes, OK.
 
>   Does it not depend on that? If so then I may not have understood

Yes, MAR does certainly depend on the PROTO document.

>   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.

>   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?

>     MAX_RESERVABLE_BWk - sum [RESERVED_BWck (0 <3D c <3D MaxCT-1)].

Yes, correct.  These 3D's should be changed to = signs.

>   while the caption of the table talks about "50% General Overload"

Yes, it should refer to 50% general overload.
 
> - Can you add pagination please?

Yes, OK.
 
>   of the BC models to stds track in the future.

OK, I'll look into that.
 
>   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?

>   same capitalization/spelling for "Bandwidth Constraints Model".
>   There are possibly other such strings/phrases as well that could

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 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?

Thanks,
Jerry

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Thu, 18 Dec 2003 10:00:30 -0000

All,
 
>> > 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).

Yes. I am fine with that.
Let's work together off-line on text for IANA that will be used
consistently across the 4 drafts.
 
Francois

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Thu, 18 Dec 2003 10:03:10 -0000

Hello,
 
>> 	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, 

I agree with Ina we should should make sure IANA retains the values we
allocated so far for RDM and MAM. We can make that happen by including a
statement to IANA on that (0=RDM, 1=MAM, 2=MAR).

Cheers

Francois

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Thu, 18 Dec 2003 13:28:39 +0100

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-masked]]
> 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,
> 
> 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-masked]]
> > > 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,
> > >
> > OK
> > OK
> > OK
> > > Right, we do need a Model ID assigned for MAR.  This was an
> > > oversight in the last call on the PROTO document.
> > >
> > Good
> >
> > > 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):
> > >
> > 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
> > > >
> > OK
> > OK
> > Thanks
> > Thanks
> > > 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)."
> > >
> > 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.
> >
> > 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]"
> > >
> > 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
> >
>