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

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

This should be of interest to L3VPN WG since this draft will be  
presented in L3VPN in Vancouver.
Francois

Begin forwarded message:

> From: "Yegenoglu, Ferit" <[email-masked]>
> Date: 21 November 2007 16:44:34 GMT+01:00
> To: [email-masked]
> Subject: [Tsvwg] draft-davie-tsvwg-rsvp-l3vpn-01.txt - comments
>
> 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:

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