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

[Ashok Narayanan <[e-mail]>]

Inline...

Yegenoglu, Ferit wrote:
> 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.

ASHOK2> What I would like to say is that the local VRF is determined from the
RD and prefix advertised in BGP; this is part of the protocol. The
implementation-specific part is specifically _how_ it is determined; whether
simply using the RD is sufficient or whether a route lookup is required.
I'll try to tighten up the text a little.


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

ASHOK2> So this is not how RSVP works in general. Path messages are responsible 
for route discovery, and can only handle routing changes if they are addressed 
towards the destination. Consider the case where the destination D is connected 
to two egress PEs B and C. If the Path is established through B, but then later 
then internal route changes to C for some reason, by continuously sending the 
Path _to_ B we would never discover this. Only by sending the Path to _D_ would 
we discover the routing change (because it would be received by C instead of B).

-Ashok

> -Ashok
> 
>>  
>>
>> Regards,
>>
>> Ferit
>>
>>  
>>
>>  
>>
>