Subject: Fwd: AD review of: draft-ietf-tewg-interas-mpls-te-req-06.txt

From: Alex Zinin <[email-masked]>
Date: Tue, 11 May 2004 16:35:24 -0700

Loa, could you please review this document for the RTG-DIR?

Thanks.

-- 
Alex
http://www.psg.com/~zinin/

This is a forwarded message
From: Wijnen, Bert (Bert) <[email-masked]>
To: "Ed Kern (E-mail)" <[email-masked]>,   "Jim Boyle (E-mail)"  <[email-masked]>
Cc: "Alex Zinin (E-mail)" <[email-masked]>
Date: Tuesday, May 11, 2004, 6:52:23 AM
Subject: AD review of: draft-ietf-tewg-interas-mpls-te-req-06.txt

===8<==============Original message text===============
WG chairs, as you probably have seen, we are processing this
as an experiment with new process:

   Participant in PROTO Team pilot:
   Workgroup Chair Followup of AD Evaluation Comments
   http://www.ietf.org/internet-drafts/draft-ietf-proto-ad-comments-pilot-01.txt

Supposedly you had been informed/consulted about this by the proto team,
and I assume you are OK with that. If not... pls do speak up (preferably
to the message from proto-team announcing us being part of the experiment).

So here we go with an initial set of comments. I am reading more and I am
asking OPS and RTG directorates for review.

1. ID-nits check:
   $ idnits-v1.24 <drafts/draft-ietf-tewg-interas-mpls-te-req-06.txt
   idnits 1.24, 16 Apr 2004, 07:05

   Line 479 contains non-ascii character in position 29.
   -->    network.  This allows SP1Æs customers connected to SP2 PE router to
                                  ^
   Line 488 contains non-ascii character in position 41.
   -->    TE LSP tail-end router located in SP1Æs network, as shown in the
                                              ^
2. Pls remove section: draft-ietf-tewg-interas-mpls-te-req-06.txt
   This makes no sense once it gets to "Publication requested" stage.

3. The use of RFC2119 language requires a normative ref to that doc.

4. Section 5.1.10.1 seems to require a writable MIB so that inter-AS TE
   tunnels can be configured (created. modified, deleted) via SNMP.
   It is OK with me... but are you sure that that is a hard requirement
   (MUST language is used) ?

5. Sect 5.1.12 and 5.1.13 use "SHOULD not" while I think "SHOULD NOT"
   is intended?

6. Lots of acronyms are used without being expanded the first time thye
   are used. 

7. Sect 6.1 .... MMM.... what does it really mean?
   It is so flexible, that ... oh well ...

8. End of sect 6.2 says:
      Other criteria might be added as this draft will evolve.
   while this draft is now "complete", no?

9. I worry about several normative references to pretty old I-Ds.
   Any outlook that those will indeed be approved at some point in
   time. Maybe several references are pretty old and need updating?   

10. I understand that the doc is written by people for which English
    is probably a second language. But that results in it being tough
    reading. Is there a way to have someone check it for proper
    english and readable sentences?

Thanks,
Bert 

===8<===========End of original message text===========

---

From: Loa Andersson <[email-masked]>
Date: Wed, 12 May 2004 23:42:25 +0200

Alex,

the review included.

----------------- start review comments ----------------------

Summary
=======
Although one find lots of nits when reviewing, and alos
some more substantial things that nees to be addressed,
see "Not so nitty comments", especially I think that we
need to discuss the ue of normative references and the
text in the security section - this is a much needed document.

The scope and scenarions are right, what is needed is quite
a bit of cleaning up.

General
=======

One thing I would like to see the requirment stated more
stringent in a separate paragraph, and the discusion supporting
this requirement in another paragraph.

E.g.

Requirment

The box SHOULD be painted blue and have a footprint of no
less than 10 x 40 cm and not larger than 20 + 60 cm.

Discussion

There are several reasons for this .....

Execusted in such a way the requirment becomes clearly
verifiable (measureable), while the discussion contributes
to understanding why the requirment looks like is does. Now
those two elements are mixed and it is hard to decide what is
what.

Not so nitty comments
=====================

References
----------

There are 18 normative reference, this seems to be high for this
type of document. It is a bit unclear what "normative" is here.
Since it is a requirment doc, that won't be implemented, the
normative references should included thigs that is necessary to
understand the teechnology in this RFC. I've a feeling that this
is somewhat ambigious. The MPLS architecture is a informative
reference while the RSVP-TE BGP is normative. Why is it more
necessary to understand those than the architecture?

Note: I'm not suggesting to add to the list of normative references,
but to review the list and see if it is possible tp move
some of them to informative.

Introduction
------------

    This document doesn't make any claims with respect to whether it is
    possible to have a practical solution that meets all the
    requirements listed in this document.

I'm not clear on how to understand this, does it mean:

- that it might be not be possible to have ONE single solution
   that meet ALL the requirments

   or

- that it might not be possible to meet some of the requirments
   at all?

Section 3.3
-----------
(last paragraph)

    Please note that the inter-AS traffic engineering over an IP-only
    network is for future consideration since there is no sufficient
    interest for similar requirements to those of IP/MPLS networks
    at this time.  More specifically, this document only covers the
    inter-AS TE requirements for packet based IP/MPLS networks.

This is kind of speaking on behalf of the "IP-only opertors",
wouldn't it be enough to say that it is outside the scope of this
document?

Section 4.1.2
-------------

case 1 and 2, are these really inter-AS traffic engineering?
isn't it two stiched cases of intra-AS TE? Each AS does its TE
separately and the AS that is traversed just deleiver a SLA.

Section 5.1.8
-------------

    The proposed solution(s) MUST have minimum impact on the network
    scalability from both intra and inter-AS perspectives.

I'm of the opinion that a it should be possible to verify if a requirment
is met or not. Stating requirments as in section 5.1.8 makes this
very hard.

section 5.1.9
-------------

    There SHOULD be several possibilities to map a particular traffic
    to a particular destination onto a specific inter-AS TE LSP.

So, how many is several?

5.2.1. Confidentiality
----------------------

    Since an inter-AS TE LSP may span multiple ASes belonging to
    different SPs, the solution MIGHT allow to "hide" the set of hops
    used by the TE LSP within an AS as illustrated in the following
    example:

I'm not clear what "hide" indicates - not really hidden?

Section 5.2.2.1
---------------

    In some cases, a TE policy server could also be used for the
    enforcement of inter-AS TE policies.  This requirement could allow
    SPs to make the inter-AS TE policies scale better.

A very imprecise way of stating a requirment

    Inter-AS TE solutions SHOULD allow Inter AS TE policies
    to be enforced via servers?

7. Security considerations
--------------------------

This section is more evaluation criteria for the coming solutions, I guess
that it is worthwhile to discuss th Inter AS TE security in its own right
here.

Nit comments
============

naming references
-----------------
Why is the reference to RSVP-TE called [TE-RSVP], I guess that
the RFC-Ed will chane it to [RFC3209], but if we want to use a
text if should be [RSVP-TE]

Acronyms
--------

There are a suprisingly high number of acronyms that it not expanded
when they firt occur, some is not expanded at all, e.g. LSR and ASBR.

PE, P and PE
------------

PE is expanded as "Provider Edge Equipment", while it in other places
are said to "Provider Edge"

ASBR Router
-----------
In the definitions section there is something called a ASBR Router,
since the "R" in ASBR is "Router" this becomes a AS Border Router Router,
which seems kind of overloaded.

section 4.1.2, 6th line funny ccharacter.

network.  This allows SP1Æs customers connected to SP2 PE router to

(well same character shows up some more places)

in figure ASBR RTR again =  AS Border Router Router.

does "local loop" == "access circuit" == "local loop access circuit"?
terminology seems overloaded.

---------- end review ------------------

-- 

Loa Andersson

mobile +46 739 81 21 64