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

[Ashok Narayanan <[e-mail]>]

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.

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

-Ashok

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