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

["Yegenoglu, Ferit" <ferit.yegenoglu at lmco.com>]

Thanks - see inline.
Ferit




>> 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).
[FY2>] OK - In the intra-AS case the ingress PE is sending the Path
message directly to the egress PE, but this is OK since the VRF is
checked every time to determine the correct egress PE. In the inter-AS
option B case even though the ingress PE has a label to the egress PE
(VPN IPv4 PHOP) it has no means to verify that it is still the correct
PE, therefore the Path message must be forwarded ingress PE - ASBR -
ASBR - egress PE. It may be useful to add this clarification.