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

[Francois Le Faucheur IMAP <[e-mail]>]

Hi Yakov,

On 27 Nov 2007, at 02:28, Yakov Rekhter wrote:

> Francois,
>
>> 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:
>>
>>> Hi Bruce, Francois, and Ashok,
>>>
>>>
>>> I enjoyed reading your new draft =93draft-davie-tsvwg-rsvp-
>>> l3vpn-01.txt.=94  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 =20
>>> carrying aggregate RSVP messages. Can you confirm this? If this  
>>> is =20
>>> 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 =20
>> as RFC3175 sessions for that matter). We'll add a statement to  
>> that =20
>> 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.
>
> 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


>
> Yakov.