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

[Loa Andersson <[e-mail]>]

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

Alex Zinin wrote:

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

-- 

Loa Andersson

mobile [phone]