Subject: [Tsvwg] draft-davie-tsvwg-rsvp-l3vpn-01.txt - comments

From: "Yegenoglu, Ferit" <[email-masked]>
Date: Wed, 21 Nov 2007 10:44:34 -0500

Hi Bruce, Francois, and Ashok,

I enjoyed reading your new draft "draft-davie-tsvwg-rsvp-l3vpn-01.txt."
We are working on some problems that can benefit from the solutions that
your draft is proposing. I have the following comments/questions:

1)       As far as I can tell, your draft is also applicable to the case
where the aggregation region (per RFC 4804) is outside of the provider
network, that is when the CE-PE interface is actually carrying aggregate
RSVP messages. Can you confirm this? If this is correct I would suggest
adding a note to that effect in your draft.

2)       In Section 3.1 (para. starting with "As noted above..."), you
are stating that the reason for not using the MPLS router alert label is
that not all deployed routers may support this. However, even if the
routers were to support this capability, using the MPLS router alert
label would require that P routers along the PE-PE path also process
RSVP messages, when they cannot do that because they lack VPN
information. I would suggest adding this as another reason why MPLS
router alert cannot be used.

3)       The VRF_ID identifies a VRF when sent by a PE router, a VPN
context when sent by an ASBR, and possibly something else in a different
application. It is merely a locally unique identifier, can we give it a
more general name?

4)       How does an ASBR generate the "pseudo VRF_ID"? Ideally one
would not want to generate a different pseudo VRF_ID for each RSVP
session, but use a common identifier for sessions belonging to one VPN.
One can get close to achieving this by noting that the VPN_ID carried
inside the PATH message is unique within the router interface (IF_IN)
through which the ASBR receives that PATH message. Therefore, if we use
f(VPN_ID, IF_IN) as the pseudo VRF_ID sent upstream by the ASBR (where
f() is a one-to-one function), we can at least ensure that RSVP sessions
belonging to the same VPN and arriving at the ASBR over the same
interface use the same pseudo VRF_ID.

5)       Is there a reference for the approaches summarized in Appendix
A.2 and A.3? From the brief descriptions provided in your draft I have a
feeling that they may not work for the inter-AS Option B case as it may
not be possible to uniquely identify sessions between two ASBRs. 

Regards,

Ferit

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Thu, 22 Nov 2007 13:44:04 +0100

Hi Ferit,

Thanks for your interest and comments. Thoughts on some of the points  
you bring up embedded below:

On 21 Nov 2007, at 16:44, Yegenoglu, Ferit wrote:

> I enjoyed reading your new draft “draft-davie-tsvwg-rsvp- 
> l3vpn-01.txt.”  We are working on some problems that can benefit  
> from the solutions that your draft is proposing. I have the  
> following comments/questions:
>
>
> 1)       As far as I can tell, your draft is also applicable to the  
> case where the aggregation region (per RFC 4804) is outside of the  
> provider network, that is when the CE-PE interface is actually  
> carrying aggregate RSVP messages. Can you confirm this? If this is  
> correct I would suggest adding a note to that effect in your draft.
This is correct. It is also applicable to RFC4804 sessions (as well  
as RFC3175 sessions for that matter). We'll add a statement to that  
effect.
>
> 5)       Is there a reference for the approaches summarized in  
> Appendix A.2 and A.3?
we're not aware of references documenting these other approaches in  
further details.

> From the brief descriptions provided in your draft I have a feeling  
> that they may not work for the inter-AS Option B case as it may not  
> be possible to uniquely identify sessions between two ASBRs.
Right. Or perhaps more accurately, they would require further  
extensions to operate in inter-AS Option B.

Francois

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 26 Nov 2007 17:28:13 -0800

Francois,

> > I enjoyed reading your new draft =93draft-davie-tsvwg-rsvp-
> > l3vpn-01.txt.=94  We are working on some problems that can benefit 
> > provider network, that is when the CE-PE interface is actually =20
> > carrying aggregate RSVP messages. Can you confirm this? If this is =20
> This is correct. It is also applicable to RFC4804 sessions (as well =20
> as RFC3175 sessions for that matter). We'll add a statement to that =20
> effect.
> >

> extensions to operate in inter-AS Option B.

Could you elaborate on what "further extensions" be required.

Yakov.

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Wed, 28 Nov 2007 21:01:52 +0100

Hi Yakov,

> Could you elaborate on what "further extensions" be required.

To make the approach described in Appendix A.3 work in inter-AS  
Option B, one avenue would be to get ASBR to :
	* readvertise VRF-labels (with "dummy addresses")
	* process RSVP messages and maintain RSVP states within VRF context
	* be able to do IP lookup inside VRF context in order to forward  
Path (as we discussed together) presumably maintaining VRF-like tables
	* swap dummy addresses inside Path message PHOP when forwarding them  
(for forwarding of Resv upstream)

Also, regarding Appendix A.3 approach, a method would have to be  
defined to allow the ingress-PE to pick the right VRF-label to apply  
when forwarding the Path message in the first place (eg in the  
simpler case of intra-AS: ingress-PE knows the egress-PE, but how  
exactly does ingress-PE pick the right VRF-label out of the multiple  
advertised by the egress-PE?).

Cheers

Francois