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

[Jean Philippe Vasseur <jvasseur@cisco.com>]

Hi Jean-Louis,

Thanks for your comments, see bellow,

At 21:14 25/02/2003 +0100, LE ROUX Jean-Louis FTRD/DAC/LAN wrote:

> 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.
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
> the RSP PE ?
Correct (again, in the context of MPLS VPN).

Just remember that the CE is a generic term here.

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


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

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

> -6.2 Scalability
>
> -"RSVP-TE"
> -"RSVP message flooding"
>
> Why such distinction? IMHO these two points can be grouped together.
Agree

> Finally, note that we find a real interest in this document, as it
> adresses our deployment cases.
That's an important feed-back, thanks.

JP.

> Regards,
>
> JL