Subject: Comments on draft-davie-tsvwg-rsvp-l3vpn-02

From: "Yegenoglu, Ferit" <[email-masked]>
Date: Fri, 07 Mar 2008 11:03:18 -0500

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? 

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

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. 

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?

Regards,

Ferit

---

From: "Yegenoglu, Ferit" <[email-masked]>
Date: Fri, 07 Mar 2008 14:03:32 -0500

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

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

Ferit,

Please see inline for ASHOK>

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

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

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

> description of how the Path messages are processed.

ASHOK> Sure.

> 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

---

From: Ashok Narayanan <[email-masked]>
Date: Fri, 07 Mar 2008 13:41:12 -0500

Ferit,

Yegenoglu, Ferit wrote:
> 1)      Section 3.2, “The router……………determines the local VRF context by 
> advertised by this router into BGP”
> 

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

ASHOK> Sure.

> 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

---

From: "Yegenoglu, Ferit" <[email-masked]>
Date: Fri, 07 Mar 2008 17:08:36 -0500

Thanks - see inline.
Ferit

> label just like the Resv messages are sent directly to the upstream
RSVP

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.

---

From: Ashok Narayanan <[email-masked]>
Date: Fri, 07 Mar 2008 16:20:44 -0500

Inline...

> can be removed - it is referring to one way of determining the VRF

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.

> label just like the Resv messages are sent directly to the upstream RSVP

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