[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: few comments on draft-ietf-tewg-interas-mpls-te-req-01.txt

Hi Yakov,

Sorry for the delayed response and many thanks for the comments. Please see the responses in lines below...

At 01:17 PM 11/17/2003 -0800, Yakov Rekhter wrote:
Folks,

Here are few comments on draft-ietf-tewg-interas-mpls-te-req-01.txt.

1. The document should state up front the following:

     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.

Good point, although this point may have been largely reflected in requirements specified with "SHOULDs" in section 5...

With this in mind the following in 6.1 should be removed:

   It MUST meet all the requirements described in section 5 each
   time a MUST is specified.

and be replaced with the following:

   It MUST document whether it meets each requirement described
   in section 5.

Well in a requirements doc, is it not the case that when there is a MUST, then the solution MUST meet the requirement ?

But to the merit of your first point, maybe we can propose to add this in section 6.1 : "if a solution can fulfill just a subset of those requirements in section 5, then it MUST be explicitly documented"

2. Since this is a *requirements* document, other than relying on the
existing MPLS/DiffServ TE mechanisms, the document should not presume
a particular solution.

Indeed. This point was mentioned before. As a result, references as such in the latest revision of the document have been reworded as examples, merely to illustrate or help in understanding the corresponding requirements.

Therefore references to such specific solutions like PCS (e.g., in
section 5.1.2) should be removed from the document.

Similarly, the mention of this is merely an example to illustrate the requirements in path computation...

Ditto for the reference to Forwarding Adjacencies in 5.1.8.

Already got that one. Thanks.

Likewise, the following in 5.1.5 has to be removed:

   The solution SHOULD support the ability for intermediate nodes to
   signal the respective Head-End LSRs of the existence of a more
   optimal path.

(as it presuppose a particular way of establishing an optimal path).

This is actually one of our requirements that a SP with inter-AS TE HE would like to be notified if there is a more optimal path opening up over a transiting AS. This way the HE SP can 1). LSR can have a configurable choice to optimize or not depending upon the available capacity in its own AS should the ASBR exist point change for the re-opt path. 2). in case the more optimal path yields for example, a worse delay (over a longer path due to some mis-configured TE metrics, e.g.), the notification would provide additional clue for HE SP to determine the cause of problem

Also in some cases, the Head-end LSR may want to control the reoptimization process, especially when carrying sensitive traffic (because reoptimization, although not traffic disruptive (thanks to make before break), does generate jitter and potentially packet reordering, something not desirable for some TE LSPs. In that case, the solution SHOULD provide a mode whereby intermediate nodes can signal the existence of a better path and then the head-end LSR will decide whether to perform a reoptimization or not. Note that this is a requirement from various SPs on this draft and is listed as a SHOULD.

3. In Section 5.1.3 the document needs to explicitly state whether
it is a requirement to maintain optimal path all the time, and if
not then what percentage of overall path life time.

Well, for some LSPs (not all, but some LSPs) it is desirable to have a solution being able to compute an optimal end to end path (a requirement for SPs on the draft). The question of whether the TE LSPs should always be on the optimal is a question of implementation agreement and parameter setting. The requirement here is just that the solution must offer the possibility on compute an optimal path end to end (again by optimal we man "shortest path"). Note this is a requirement listed as a "SHOULD".

4. Sections 6.2 ("Scalability and Extensibility"), 6.3 ("Complexity
and Risks"), and 6.5 ("Backward Compatibility") talk about requirements
on scalability and extensibility, and therefore should be moved
into Section 5.

Will do.. Thanks.

5. I would suggest to include 5.1.8 into 6.2, as 6.2 talks about
scalability, and 5.1.8 talks about one particular aspect of scalability -
scalability in the forwarding plane.

Good point, thanks.

6. In 5.1.5 replace:

   Furthermore the solution SHOULD provide the ability of manually
   rejecting re-optimization at AS boundaries.

with the following:

   Furthermore, the solution MUST provide the ability to reject
   re-optimizatization at AS boundaries.

Right. Will incorporate, thanks...

7. In 6.2 replace "SPF" with "Constrained SPF" or "CSPF".

Thanks for pointing this out. Will update...

Regards,
Raymond


Yakov.