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

From: Yakov Rekhter <[email-masked]>
Date: Mon, 17 Nov 2003 13:17:16 -0800

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.

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.

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. 

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

Ditto for the reference to Forwarding Adjacencies in 5.1.8.

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

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.

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.

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.

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.

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

Yakov.

---

From: raymond zhang <[email-masked]>
Date: Thu, 20 Nov 2003 14:24:07 -0800

Hi Yakov,

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

>      requirements listed in this document.

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

>    It MUST document whether it meets each requirement described

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"

>existing MPLS/DiffServ TE mechanisms, the document should not presume

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.

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

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

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

>on scalability and extensibility, and therefore should be moved

Will do.. Thanks.

>scalability in the forwarding plane.

Good point, thanks.

>    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

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 24 Nov 2003 08:40:59 -0800

Raymond,

> requirements specified with "SHOULDs" in section 5...

Perhaps I missed it, but the -02 version still does not include
this "good point".

> then the solution MUST meet the requirement ?

Unless there is an existence proof that it is possible to have a
practical solution that meets all the requirements in section 5
that are "MUST", saying that a solution "MUST meet all the requirements
described in section 5 each time a MUST is specified" is nothing
but a wishful thinking.

> requirements in path computation...

Sorry, but the -02 version of the document still talks "... require
a discovery mechanism of some PCS using IGP extensions".

Also, may I suggest that the requirements document should focus on the
requirements and not on the specific examples of how to meet the
requirements.

> or not. Note that this is a requirement from various SPs on this draft and 

Let's not confuse requirements with the mechanisms to support the
requirements.

The requirement here is for the Head-end LSR under control of local
configuration to be able to reoptimize the path, if and when a "better"
path becomes available.

Requiring intermediate nodes to provide the information about
a more optimal path over a transit AS to the Head-end LSR is *one 
possible mechanim* to support the requirement.

> "shortest path").  Note this is a requirement listed as a "SHOULD".

If the requirement here is to compute an optimal path end to end
just for the sake of computation, then what are the practical
benefits of such a requirement ?

And if the requirement here is to compute an optimal path end to
end for the sake of using it (means establishing an LSP along such
a path), then the requirement has to be very explicit with respect
to whether it expects path optimality to be maintained all the time
or not, and if not then what percentage of the time.

> >on scalability and extensibility, and therefore should be moved

-02 version still doesn't reflect this.

> >scalability in the forwarding plane.

Ditto.

> Right.  Will incorporate, thanks...

Ditto.

> Thanks for pointing this out.  Will update...

Ditto.

Yakov.

---

From: raymond zhang <[email-masked]>
Date: Tue, 25 Nov 2003 11:31:34 -0800

Hi Yakov,
Thanks for the response...

[snip...]

>Perhaps I missed it, but the -02 version still does not include

Sorry...  -02 was posted right before your email to list showed up. I'll 
make sure this point is well reflected in the text (in section 6.1)

>described in section 5 each time a MUST is specified" is nothing

There are only a few "MUST" in section 5 of -02 now:
1. Section 5.1.1. " ..the derived solution MUST be such that it will 
interoperate seamlessly with current intra-AS MPLS TE mechanism..."
2. Section 5.1.1. "The proposed solution MUST allow to provision at the 
Head/Tail end with end-to-end RSVP signaling (eventually with loose paths)
    traversing across the interconnected ASBRs, without further 
provisioning required along the transit path."
3. Section 5.1.5. "...the solution MUST be able to re-optimize the LSP 
accordingly and non-disruptively, either upon expiration of a configurable 
timer or
    triggered by a network event or a manual request at the TE tunnel 
Head-end."
4. Section 5.1.10.1 "This new MIB MUST extend (and not reinvent) the 
existing MIBs to accommodate this new functionality."

5. Section 5.2.2.1 "The signaling of a non policy compliant request MUST 
trigger the generation of a RSVP Path Error message by the policy enforcing
    node towards the Head-end LSR, indicating the cause."
6. Section 5.2.2.2. "the re-writing node MUST generate a RSVP Path Error 
Message towards the Head-end LSR indicating the cause in terms
    of types of changes made so as to maintain the end-to-end integrity of 
inter-AS TE LSP."

In -03, we will change "MUST" to "SHOULD" for item 5 and 6 above.

As for 1, 2, 3 and 4, they constitute, in our thinking, a basic set of 
requirements for the deployments of inter-AS TE.  It would be great if you 
could clarify further of each of item 1, 2, 3 and 4 on any technical 
limitations or impracticality such that these "MUST" requirement can not 
all be met in a solution ?

>requirements and not on the specific examples of how to meet the

Right.  To this point, I will simplify the wording of the examples in this 
section
(tho I don't want to remove the example entirely since I feel it does help in
further illustrating the stated requirement).   How about the following 
wording ?

Section 5.1.2
"...
For example, one may provide a manual description of all or some of the 
hops (loose routing) the TE LSP must traverse, allowing to keep the 
information related to the intra-AS resources confidential while still 
leaving intra-AS routing decisions to local operators.  Another example is 
an automated way of setting up the TE LSP without any static configuration 
on the Head-End LSR by ways of requesting the computation of an inter-AS TE 
LSP to some path computation elements..."

>Let's not confuse requirements with the mechanisms to support the

Right...  I would also like to further clarify that the requirement calls 
for the HE LSR of the inter-AS TE LSP to have control of re-optimization 
not only for the AS segment in its own AS, but also for transit AS segments 
as well.

>possible mechanim* to support the requirement.

Yakov, I do see your point regarding "mechanism".  But we'd still like to 
keep the requirement in our response above.  Can I then propose the 
following wording to replace this paragraph ?

"The solution SHOULD provide an option for the Head-End LSRs to control if 
re-optimizing or not should there exist a more optimal path in one of the 
transit ASes along the inter-AS TE LSP path."

>or not, and if not then what percentage of the time.

This requirement is indeed for the ability to establish an optimal path e2e 
for the inter-AS TE LSP
("using it").  For example, this ability may be required for a SP with 
multiple ASes to be able to deploy
a set of meshed TE LSPs optimally across their own AS boundaries and once 
established, it should be
maintained at all times.  However, in some cases it is also a matter of 
tuning, trade-off between optimality
and network stability, ... on whether path optimality should be 
maintained  "all the time"  or triggered
after some timer has elapsed.  At the end, what we are actually after in 
the req's draft is that a solution
should offer this capability of computing an optimal inter-AS TE LSP path 
("shortest") end to end.

Will have some additional wordings then to reflect what we corresponded 
above. Your thoughts ?

>-02 version still doesn't reflect this.

It will be in -03, thanks.

Regards,
Raymond