RE: [Tsvwg] Comments on draft-davie-tsvwg-rsvp-l3vpn-02

["Yegenoglu, Ferit" <[e-mail]>]

Thanks Ashok - Please see inline for [FY] for a comment and a question.
Ferit

-----Original Message-----
From: Ashok Narayanan [mailto:[e-mail]] 
Sent: Friday, March 07, 2008 1:41 PM
To: Yegenoglu, Ferit
Cc: [e-mail]; [e-mail]
Subject: Re: [Tsvwg] Comments on draft-davie-tsvwg-rsvp-l3vpn-02

Ferit,

Please see inline for ASHOK>

Yegenoglu, Ferit wrote:
> Hi Bruce, Francois, and Ashok,
> 
>  
> 
> I have a few comments on your draft:
> 
>  
> 
> 1)      Section 3.2, "The router...............determines the local
VRF context by 
> finding a matching VPN-IPv4 prefix with the specified RD that has been

> advertised by this router into BGP"
> 
> - Can you clarify how the local VRF context is determined? Can the VRF

> context be determined directly from the RD or does the router search 
> through advertised routes as described in the above sentence?

ASHOK> That is an implementation-specific question. Most implementations
will 
allocate a separate RD for each VRF for which routes are being
advertised into 
BGP; so, any such implementation can just look up the VRF from the RD.
However, 
since RFC2547 does not _impose_ this semantic on the RD, depending on
the 
implementation it may have to look up the entire route.
[FY>] OK - If this is implementation dependent maybe the above sentence
can be removed - it is referring to one way of determining the VRF
context.

> 
> 2)      Section 3.3, "The Resv message is sent to the IP address 
> contained within the RSVP_HOP object in the Path message."
> 
> - I believe you mean the RSVP_HOP object in the Path state (not 
> message). Note that you can actually delete this sentence (it is a
repeat).

ASHOK> Sure; but I didn't understand the difference between "the
RSVP_HOP object 
in the Path message" and "the RSVP_HOP object in the Path state".

> 
> 3)      Section 5.2.2, paragraph starting with "When the upstream RSVP

> hop sends a Path message....."
> 
> a.       It is worth clarifying that just as there are upstream and 
> downstream RSVP hops, there are upstream and downstream ASBRs in the 
> description of how the Path messages are processed.

ASHOK> Sure.

> 
> b.       The first Path message is processed by the ASBRs thus
creating 
> Path state; Resv messages and all subsequent Path messages are only 
> processed by the upstream and downstream RSVP hops, causing eventually

> the ASBR Path state to expire. It may help to clearly state this in
the 
> paragraph. Also, are there any issues with this, i.e. the processing
of 
> the first Path message of all end-to-end reservations at the ASBRs?

ASHOK> So, in respect to Section 5.2.2, it is not expected that the ASBR
will 
ever create any Path state. Its role is simply to receive and forward
the Path 
message based on the VPN-IPv4 address in the SESSION object. Also, I
should 
point out that the ASBR will have to do this for *every* Path message in
the 
flow, not just the first one. Only if summary refresh (RFC2961) is used,
will 
the ASBR not have to process subsequent refreshes for a flow. I'll add a

clarification for this.
[FY>] After the upstream RSVP hop receives the Resv message, it will
have a VPN-IPv4 address for the downstream RSVP hop. Why wouldn't any
future Path messages be sent directly to the downstream RSVP hop with a
label just like the Resv messages are sent directly to the upstream RSVP
hop with a label.

-Ashok

>  
> 
> Regards,
> 
> Ferit
> 
>  
> 
>  
>