Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering
draft-ietf-tewg-diff-te-proto-08

[Ballot comment]
The note which makes clear that this is not DiffServ awareness but something different
has cleared my Discuss.  Transport needs to continue to pay attention to this protocol.

[Ballot discuss]
I'd like this note to be added to Introduction:

There are differences between the quality of service expressed and obtained
with Diffserv PHB/PDBs and that with DS-TE.  DS-TE has capabilities for
traffic that Diffserv does not:  Diffserv does not
indicate preemption, by intent, whereas DS-TE describes multiple
levels of preemption for its Class Types.  Diffserv does not support
any means of intentionally overbooking a class and then using an
underlying mechanism to compensate.    When considering a complete
quality of service environment, with Diffserv routers and DS-TE, it
is important to review these differences carefully.

[Ballot comment]
Reviewed by Lucy Lynch, Gen-ART

Her review indicated a number of places in proto-07 where it was unclear whether the authors were intending 2119 keyword meaning (MUST) where the text said "must". Review forwarded to authors and AD.

HTA: Within my limited time and understanding, this seems sensible.

Philosophical sigh:
I distrust all numbers except 1, 2 and "many".
This document sanctifies the number 8.
I hope they know what they're doing.

[Ballot comment]
Reviewed by Lucy Lynch, Gen-ART

Within my limited time and understanding, this seems sensible.

Philosophical sigh:
I distrust all numbers except 1, 2 and "many".
This document sanctifies the number 8.
I hope they know what they're doing.

[Note]: 'Back on Agenda as a forcing tool to make sure we have ALL DISCUSS comments collected before I go back to authors/wg' added by Bert Wijnen

[Ballot discuss]
This isn't diffserv-aware TE, it's TE managing MPLS using MPLS's differentiated
service.  It's very important to make this distinction, because diffserv doesn't provide
preemption classes.  I want to have either me or someone else go through this and
comb this out.  Please ping me Tuesday if I haven't given you a specific reviewer.
(It would be unreasonable to expect me to have had this reviewer for you in one week),
so it was do this Discuss or a Defer).

[Ballot discuss]
>    extensions address the Requirements for DS-TE spelt out in RFC3564.

s/spelt/spelled/

>    o values in the range 128-239 are not to be assigned at this
>    time. Before any assignments can be made in this range, there MUST be
>    a Standards Track RFC that specifies IANA Considerations that cover
>    assignment within that range.

This doesn't make sense, given the other ranges are easily useable. Is
there a _technical_ difference between this range and the other ones?


>          o values in the range 240-255 are for experimental use; these
>    will not be registered with IANA, and MUST NOT be mentioned by RFCs.

refer to RFC 3692 here?

[Ballot comment]
Within my limited time and understanding, this seems sensible.

Philosophical sigh:
I distrust all numbers except 1, 2 and "many".
This document sanctifies the number 8.
I hope they know what they're doing.

[Ballot comment]
Many of the  sections are actually requests to the RFC editor to update
values upon assignment.  I don't think this requires any change to the document,
but I thought I'd note it so that the purpose was clear to our RFC Editor liaison.

[Ballot comment]
-diff-te-mam-03 and -diff-te-mar-04 and -diff-te-russian-06 say that
  security considerations related to the use of DS-TE are discussed in
  draft-ietf-tewg-diff-te-proto-07.  However, the security considerations
  in this document points to RFC 2475, without adding much additional
  insight.  Please remove the additional level of indirection.

[Ballot discuss]
-diff-te-mam-03 and -diff-te-mar-04 and -diff-te-russian-06 say that
  security considerations related to the use of DS-TE are discussed in
  draft-ietf-tewg-diff-te-proto-07.  However, the security considerations
  in this document points to RFC 2475, without adding much additional
  insight.  Please remove the additional level of indirection.

[Ballot discuss]
Section 14.1 of draft-ietf-tewg-diff-te-proto-07 describes IANA allocation requirements for a "Bandwidth Constraints Model Id" field.  I don't completely understand the difference in the criteria used to distinguish the value ranges.  The first range is set aside for use according to the "Specification Required" policy defined in RFC 2434, which says:

"Values and their meaning must be documented in an RFC or other permanent and readily available reference"

OK, all we need is a specification for a value from the first range.  The second range is set aside for "later" assignment: "there MUST be a Standards Track RFC that specifies IANA Considerations that cover assignment within that range".

The first range requires "an RFC or other permanent and readily available reference".  The second range requires "a Standards Track RFC that specifies IANA Considerations that cover assignment within that range".  Is the only difference that some "other permanent and readily available reference" can not be referenced for values assigned from the second range?  Which range should be used for a value associated with a standards-track RFC?

Finally, the third range is specified "for experimental use; these will not be registered with IANA, and MUST NOT be mentioned by RFCs".  What about use in an experimental RFC?  I think the intention here is for _private_ use, but I don't think the text is clear about that.

IETF Last Call comments received:

The normative references include:

  [DIFF-ARCH] Blake et al., "An Architecture for Differentiated
  Services", RFC2475.

RFC 2475 is an Informational document - the basic diffserv PS is RFC 2474.
Since the present draft cites RFC 3270, which in turn cites 2474, the chain
of normative references is in place. So 2475 should probably be informative.

-----Original Message-----
From: Wijnen, Bert (Bert)
Sent: dinsdag 16 maart 2004 23:52
To: Tewg (E-mail)
Subject: BAD non-ASCII characters in
draft-ietf-tewg-diff-te-proto-06.txt


I am just reviewing dif-te docs again.

Why do you uys keep using WORD if you do not know how to
properly convert them to ASCII.

$ /bin/checkpage.awk <drafts/draft-ietf-tewg-diff-te-proto-06.txt
-: 112 lines containing non-US-ASCII characters
-: 31 lines longer than 72 characters, max 80
-: 1 pages longer than 58 lines, max 1753 lines

Oh well.. if it were just a few lines, I would let it go and
ask RFC-Editor to fix. But 112 lines seems a bit too much.

Can you quickly respin another version (and PLEASE check
yourself before you re-submit).

And is generating a Table of Contents so difficult?

You are still not 100% consistent in using Bandwidth Constraint Model
all 3 capitalized. Oh well...

Thanks,
Bert

Reviews to the RDM, MAM and MAR documents posted to
WG list as well. They all need new revisions in sync
with the base protocol document

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
Sent: dinsdag 16 december 2003 22:27
To: Tewg (E-mail)
Subject: AD review of: draft-ietf-tewg-diff-te-proto-05.txt


Editor/authors and WG, here is my review.

Serious (in my view):
- On page 10, you say that there are 8 BCs (0-7), so that
  seems a fixed number to me. With tha in mind I read:
    As detailed above in section 4.1.1, up to 8 Bandwidth Constraints
    ( BCb, 0 <= b <= 7) are configurable on any given link.
 
  so far so good.

    With DS-TE, the existing "Maximum Reservable Bw" sub-TLV is retained

  might be good to add a citation and reference to the RFC where that
  existing "Maximum Reservable Bw" sub-TLV is defined.
  Francois told me it is RFC3630. So something aka:

    With DS-TE, the existing "Maximum Reservable Bandwidth" sub-TLV 
    (sub-TLV of the Link TLV of the TE Extensions to OSPF Version 2
    [RFC3630]) is retained

  I think it is better to expand Bw to Bandwidth in the above, cause
  that is how it is named in RFC3630.

    with a generalized semantic so that it MUST now be interpreted as the
    aggregate bandwidth constraint across all Class-Types [ i.e.
    SUM (Reserved (CTc)) <= Max Reservable Bandwidth], independently of
    the Bandwidth Constraints Model.

So does that mean that you basically UPDATE RFC3630? You change the
definition of one of the sub-TLVs in that document. If so (which I
think) then you must add to the abstract that you do update RFC3630.
 
    This document also 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)

  So should I assume that if there are only 3 bandwidth constraints, then
  N above is 3 ?? I think it can be made clearer if there always need to be
  8, or if that is not the case, what the value of N is in that case and
  how that is determined.

    Where:

          - With OSPF, the sub-TLV is a sub-TLV of the "Link TLV" and its
            sub-TLV type is TBD. See IANA Considerations section below.
 
  Would be good to describe if this needs to be a length to be padded
  to 32 bits (as also in RFC3630). I think a diagram mightbe helpfull too.

          - With ISIS, the sub-TLV is a sub-TLV of the "extended IS
            reachability TLV" and its sub-TLV type is TBD. See IANA
            Considerations section below.
 
  similarly, point to RFC describing the ISIS TLVs, so people know where
  it fits.

          - Bandwidth Constraint Model Id: 1 octet identifier for the
            Bandwidth Constraints Model currently in use by the LSR
            initiating the IGP advertisement.
              - Value 0 identifies the Russian Dolls Model specified in
            [DSTE-RDM].
              - Value 1 identifies the Maximum Allocation Model
            specified in [DSTE-MAM].

  When you do the above, it seems to me that those 2 documents become
  normative. And a stds track RFC can not make normative reference to
  experimental RFCs. See also my concerns about IANA considerations below

          - Bandwidth Constraints: contains BC0, BC1,... BC(N-1).

  explain what N is here, how is it determined?

            Each Bandwidth Constraint is encoded on 32 bits in IEEE
            floating point format. The units are bytes (not bits!) per
            second. Where the configured TE-class mapping and the
            Bandwidth Constraints model in use are such that BCh+1,
            BCh+2, ...and BC7 are not relevant to any of the Class-Types
            associated with a configured TE-class, it is recommended that
            only the Bandwidth Constraints from BC0 to BCh be advertised,
            in order to minimize the impact on IGP scalability.

  I suggest to make citation/reference to IEEE floating point spec

- Then on next page (page 11) I read:
    A DS-TE LSR receiving the "Bandwidth Constraints" sub-TLV with a
    Bandwidth Constraint Model Id which does not match the Bandwidth
    Constraint Model it currently uses, MAY generate a warning to the
    operator reporting the inconsistency between Bandwidth Constraint
    Models used on different links. Also, in that case, if the DS-TE LSR
    does not support the Bandwidth Constraint Model designated by the
    Bandwidth Constraint Model Id, or if the DS-TE LSR does not support
    operations with multiple simultaneous Bandwidth Constraint Models,
    the DS-TE LSR MAY discard the corresponding TLV. If the DS-TE LSR
    does support the Bandwidth Constraint Model designated by the
    Bandwidth Constraint Model Id and if the DS-TE LSR does support
    operations with multiple simultaneous Bandwidth Constraint Models,
    the DS-TE LSR MAY accept the corresponding TLV and allow operations
    with different Bandwidth Constraints Models used in different parts
    of the DS-TE domain.
 
  What is are all these MAY cases???  What else can a DS-TE LSR do if it
  does not recognize or support a Model Id ??

- Section 6.2.1 should be more explicit.
  I think you need to specify that you want a Class-Number of TBD,
  a Class-Name of CLASSTYPE, a C-Type of 1.
  I think value zero should be stated to be reserved.
 
- Section 6.3
  I suspect that the reason why you reserve CT=0 and do not pass it
  ever in a CLASSTYPE object sis for backward compatibility?
  It would be good to make that explicit if that is the case.
  If not, then explain why.

- section 6.3 has:

    If a path message contains multiple CLASSTYPE objects, only the first
    one is meaningful; subsequent CLASSTYPE object(s) MUST be ignored and
    MUST not be forwarded.
 
  I think you mean "MUST NOT" instead of "MUST not" ??

- In section 6.4 I see:

    In both situations, this causes the path set-up to fail. The sender
    SHOULD notify management that a LSP cannot be established and
    possibly might take action to retry reservation establishment without
    the CLASSTYPE object.

  What is "management" in this case? Is it a management system ?

- I suspect that the Security Considerations section is to weak.
  Especially, text aka
    This document does not introduce additional security threats beyond
    those inherent to Diff-Serv and MPLS Traffic Engineering and the same
    security mechanisms proposed for these technologies are applicable
    and may be used.

  So it is optional to use those mchanisms since you say "may be used"/
  Probably better to say something aka:

    This document does not introduce additional security threats beyond
    those described for Diff-Serv [add refrence] and MPLS Traffic
    Engineering [add reference] and the same security measures and
    procedures described in those documents apply here.

  Same comments on the rest of security considerations.

- issues with IANA Considerations.
  I bet IANA will have a HARD time to understand what they need to do.
  You must be much cleared.

  - for one thing you refer to section 5.3, which does not exist.
  - I would make separate subsections for each assignment in different
    namespaces. That makes it clearer.

  - you write:

      This document defines a number of objects with implications for IANA.

    This doc requests IANA to male assigments in a few namespaces.
    It also requests IANA to create and maintain a new namespace registry.

    The above 2 sentences would be section 14 if I had written this.

    Then I would have a subsection for each of the following

      This document defines in section 5.1 a new sub-TLV, the "Bandwidth
      Constraints" sub-TLV, for the OSPF "Link" TLV [OSPF-TE]. A sub-TLV
      Type in the range 10 to 32767 needs to be assigned by Expert Review.
      This sub-TLV Type also needs to be registered by IANA.
 
    RFC3630 states that values in 1--32767 are assigned by Standards Action
    (and not by Expert Review). So better would be:

      14.1 Bandwidth Constraints sub-TLV for OSPF version 2

      This document defines in section 5.1 a new sub-TLV, the "Bandwidth
      Constraints" sub-TLV, for the OSPF "Link" TLV [OSPF-TE]. The sub-TLV
      requested is in the range 10 to 32767 needs to be assigned by IANA.
      IANA has assigned TBD for the "Bandwidth Constraints" sub-TLV.

    Pls do a similar text for the ISIS sub-TLV assignment.

  - For:

      This document defines in section 5.3 a "Bandwidth Constraint Model
      Id" field within the "Bandwidth Constraints" sub-TLV. This document
      also defines in section 5.3 two values for this field (0 and 1).
      Future allocations of values in this space and in the range 2 to 127
      should be handled by IANA using the First Come First Served policy
      defined in [IANA]. Values in the range 128 to 255 are reserved for
      experimental use.
 
    I feel that this document should NOT make the assignments for the
    RDM/MAM and MAR models. Those are experimental RFCs and I think that if
    we make assignments here, that we cause a normative ref to experimental
    RFC and that is a nono for a stds track document.

    Each Model document can claim (in its IANA section) an assignment from

    So what we must do here is to specify the namespace, request IANA to
    create and maintain it, and specify the rules for making assignments.
    Se also my earlier comments on the ranges. I think that 128-255 for
    experimental use is far too many. I think that something aka the following
    makes much more sense:

      14.x A new namespace for Bandwidth Constraint Model Identifiers

      This document defines in section 5.1 a "Bandwidth Constraint Model
      Id" field (namespace) within the "Bandwidth Constraints" sub-TLV,
      both for OSPF and ISIS.

      IANA is requested to create and maintain this new namespace. The
      field for this namespace is 1 octet, and IANA guideliens for
      assigments for this field are as follows:

      o values in the range 0-64 are to be assigned via Standards Action
        as defined in [RFC2434]

      o values in the range 65-127 are to be assigned via Specification
        Required

      o values in the range 128-252 are not to be assigned at this
        time.  Before any assignments can be made in this range, there
        MUST be a Standards Track RFC that specifies IANA Considerations
        that covers the range being assigned.

      o values in the range 253-255 are for experimental use; these will
        not be registered with IANA, and MUST NOT be mentioned by RFCs.

    Or something like that.

  - Pls also reconsider the text for the RSVP-TE object and error codes
    in light of the above

  - If you can add the IANA web page that contains the current registry,
    then it will help IANA to more quickly understand what they need to
    do, and it will help future readers to quickly find the
    assignments repository.

Nits/admin issues

- there is no Table of Contents (required for docs > 15 pages
  see draft-rfc-editor-rfc2223bis-07.txt
- there is no IPR section (as per RFC2026) sect 10
- there are no copy-rigth statements (RFC-editor can add those)
- pls add and note RFC-Editor to remove the summary of SUB-IP
  related drafts (or just remove it by next rev)
- do not use citation in abstract (as per RFC-Editor instructions)
  The one that you use could be replaced by "(RFC3564)"
- update references section to point to current docs, for example
  te-reqs-07 is now RFC3564
- whenever you use acronyms the first time, pls make sure to
  also use the full text. SO in abstract spell out IGP and RSVP-TE
  in a similar way you did it for DS-TE.
  But this must be done throughout document. See RFc-Editor instructions
- The use of capitals in "Bandwidth Constraints Model" is very
  inconsistent throught this document and also in the 3 experimental
  modle documents (RDM, MAM and MAR)
  Even sometimes it is "Constraints" (plural) and other times it is
  "Constraint" (singular).
- sect 4.1.2 towards the end
    The "LSP Size Overbooking" method and the "Link size overbooking"
  pls be consustent in use of capitals
- In section 4.3.1 I see
    The configured Class-Type indicates, in accordance with the supported
    Bandwidth Constraint Model, what are the Bandwidth Constraints that
    MUST be enforced for that LSP.
  s/what are// ??
  sounds better in my ears... but maybe it is just me.
- section 4.3.3
  two times I see:
          specified is section 4.2.1 above
  s/is/in/ !!
- page 10, pls add a citation and reference to the IEEE floating point
  format specification

- section 6.3
  Why do you use different editorial styles or textual formatting to
  describe how an LSR should handle the receipt of a CLASSTYPE object?

- in section 6.5
  You use Class-Type in full in the first few bullets and then switch
  to CT. Not very consistent.

- section 8, last para
  Quite a flood of terms to indicate that something is optional, no?
  Do you really think that this flood of words is very readable?
  For example, MAY means that something is optional according to RFC2119
  So why state
    "... MAY also optionally..., when used, the optional additional.."?
  It seems to repeat the "MAY" or "optional" at least 3, maybe even 4 times
  in that one sentence.

- sect 10, 4th para
  s/an a bandwidth/a bandwidth/

- check spelling in sect 11.2

- APpendix A, might want toa dd a few words why it is included.
  What is a "Head-End" ?? May want to explain that

- appendix C 2nd line
  s/LSRs and not DS-TE/LSRs are not DS-TE/ ??

Thanks,
Bert

[Note]: 'WG Last Call has been issued. End April 28th. Also notice sent to isis, ospf, mpls and ccamp WGs Responsible: WG' has been cleared by Bert Wijnen

[Note]: 'WG Last Call has been issued. End April 28th. Also notice sent to isis, ospf, mpls and ccamp WGs Responsible: WG' added by Bert Wijnen

WG Last Call has been issued. End April 28th.
Also notice sent to isis, ospf, mpls and ccamp WGs
See below

-----Original Message-----
From: Jim Boyle [mailto:jboyle@pdnets.com]
Sent: dinsdag 8 april 2003 5:56
To: te-wg@ops.ietf.org
Subject: WG last call: draft-ietf-tewg-diff-te-proto-03.txt



http://www.ietf.org/internet-drafts/draft-ietf-tewg-diff-te-proto-03.txt

This is WG last call for this draft to be advanced standards track.
Since notice was sent to other WGs for review, we will take 3 weeks.

Last call for this draft closes 4/28.

thanks,

Jim Boyle
-----Original Message-----
From: Jim Boyle [mailto:jboyle@pdnets.com]
Sent: dinsdag 8 april 2003 5:53
To: mpls@uu.net; ccamp@ops.ietf.org; ospf@discuss.microsoft.com;
isis-wg@ietf.org
Cc: te-wg@ops.ietf.org
Subject: Notice of WG last call on Diff Serv TE Protocol draft in TEWG



In May 2001 the TEWG adopted the development of the requirements and
necessary protocol extensions for Diff-Serv TE.  Upon completion, TEWG
was to notify the various protocol WGs of the proposal to allow review
of the proposed protocol changes (if any).  This note serves that purpose.

Please find the pointer for the protocol specification draft below and
review the proposed changes required in the routing and signaling
protocols. 

A WG last call on the protocol draft will start by separate email to the
TEWG.  Be sure to follow-up with any discussion to the te-wg list.

http://www.ietf.org/internet-drafts/draft-ietf-tewg-diff-te-proto-03.txt

It specifies extensions outlined as follows:
- IGP Reuse of unreserved bandwidth sub-tlv to carry
BW available per TE-Class
- IGP Optional use bandwidth constraints sub-tlv
- IGP Optional use local overbooking multiplier sub-tlv
- RSVP Class Type Object for signaling class-types other than 0.
- RSVP Diffserv TE error codes

The protocol supports the use of a variety of different bandwidth
constraint models.  The following drafts are examples listed here for
reference only.

http://www.ietf.org/internet-drafts/draft-ietf-tewg-diff-te-russian-02.txt
http://www.ietf.org/internet-drafts/draft-lefaucheur-diff-te-mam-00.txt
http://www.ietf.org/internet-drafts/draft-ash-mpls-dste-bcmodel-max-alloc-resv-01.txt

Also for reference, the requirements are developed and with RFC-ED now.

http://www.ietf.org/internet-drafts/draft-ietf-tewg-diff-te-reqts-07.txt