Subject: Comments on draft-zhang-mpls-interas-te-req

From: "LE ROUX Jean-Louis FTRD/DAC/LAN" <[email-masked]>
Date: Tue, 25 Feb 2003 21:14:24 +0100

Hi folks,

I have several comments regarding draft-zhang-mpls-interas-te-req-01:

-4.2 Scenario II
Does the final comments "please note that the inter-AS MPLS TE..."
refers only to case 2.
If yes does it mean that, in case 1, the VRF functionality is located on
the RSP PE ? 
This section could require several clarifications...

-4.4 Scenario IV
It could be relevant to illustrate this scenario with severals
application cases, including for instance the following case : A PE-PE
tunnel crossing two ASs of the same SP, for a L2VPN service (ie with
high QoS requirements)

Paragraph 2 : section 3.2 instead of "section 2.2"

-5.9 
"Application scenario II presented in section 3.2 above requires
multiple TE tunnels...". 
This is true only for scenario II case 2. 
(minor :  Section 4.2 instead of 3.2).

-5.10 Confidentiality 
"Optionally the TE LSP path cost within AS2 could be provided to A".
Do you mean that this cost could be provided "a posteriori" within the
Resv message, or "a priori" via PCC-PCS signaling. In the first case
this would require an RSVP extension, that could consist in adding a RRO
Cost subobject.

-6.2 Scalability

-"RSVP-TE"
-"RSVP message flooding"

Why such distinction? IMHO these two points can be grouped together.

Finally, note that we find a real interest in this document, as it
adresses our deployment cases.

Regards,

JL

---

From: Jean Philippe Vasseur <[email-masked]>
Date: Tue, 25 Feb 2003 15:45:47 -0500

Hi Jean-Louis,

Thanks for your comments, see bellow,

>Does the final comments "please note that the inter-AS MPLS TE..."

Yes indeed as the CE is the inter-AS TE LSP Head-end so the TE LSP 
terminates within a VRF (if the CE is connected to a VRF in the context of 
MPLS VPN) or in the global routing table otherwise.

>If yes does it mean that, in case 1, the VRF functionality is located on

Correct (again, in the context of MPLS VPN).

Just remember that the CE is a generic term here.

>tunnel crossing two ASs of the same SP, for a L2VPN service (ie with

Right, I agree, we'll illustrate this in the next rev (02) that will be 
published this week.

>Paragraph 2 : section 3.2 instead of "section 2.2"

thanks

>(minor :  Section 4.2 instead of 3.2).

Right

>this would require an RSVP extension, that could consist in adding a RRO

We mean "a priori". The point here is to be able, when sending a request to 
another AS, to get a response (positive or negative) with potentially the 
path cost even if the computed path is not provided (for confidentiality 
reasons). This way, the requesting LSR (PCC) could use this information to 
compute an optimal path (see the definition of "optimal" provided in this 
draft as well as the associated limitations). For instance [PATH-COMP] 
proposed such a mechanism where the Path computation request specifies that 
the path cost should be provided in the reply and the Path Computation 
reply contains an object (PATH-COST) specifying the path cost.

We'll clarify this in rev -02, thanks.

>Why such distinction? IMHO these two points can be grouped together.

Agree

>adresses our deployment cases.

That's an important feed-back, thanks.

JP.