Subject: [L1vpn] RE: I-D ACTION:draft-fedyk-l1vpn-basic-mode-00.txt

From: "Don Fedyk" <[email-masked]>
Date: Fri, 21 Oct 2005 12:44:02 -0400

Hi Tomonori

Thanks for the Comments.  

> -----Original Message-----
> From: Tomonori TAKEDA [mailto:[email-masked]]
> Sent: Thursday, October 20, 2005 9:20 AM
> To: [email-masked]
> Cc: Fedyk, Don [BL60:1A00:EXCH]; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]
> Subject: Fwd: I-D ACTION:draft-fedyk-l1vpn-basic-mode-00.txt 
> 
> 
> Hi Don, Yakov,
> 
> Nice to see the draft.
> 
> With chair hat off, please see my comments below.
> 
> 1)  I am expecting that this draft specifies signaling
> mechanisms for L1VPN 
> BM, and  auto-discovery/reachability exchange mechanisms will 
> follow. It 
> may depend on how discussion will go, but if this document 
> specifies only 
> signaling, we may want to consider to change the draft title.
> 
Well there is routing as well in the backbone but the discussion seemed
split on the auto-discovery mechansims.  

> 2) I think this draft elaborates (or precisely specifies) signaling
> procedures based on GMPLS UNI. In GMPLS UNI, nesting is 
> recommended to be 
> used if VPN addressing realm is used, or contiguous may be 
> used if the same 
> addressing realm is used.
> 
> One comment is that stitching is developed in CCAMP since
> that time, and I 
> believe stitching can be used in L1VPN BM as well. It would 
> be nice to 
> catch this point in the document.

Yes good point. 

> 
> Another comment is that in nesting or stitching applications,
> it is not 
> always necessary to establish FA LSP or LSP segment 
> dynamically. It would 
> be possible to pre-configure FA LSP or LSP segment. Does this 
> also apply to 
> L1VPN BM?
Preconfigure would take some of the control away form the L1VPN user. My
tendency would be to say no.  However there may be some preconfiguring
to reserve resources for L1VPN customers so I think we need to discuss.

> 
> 3) It would be good to see that recovery aspects are covered
> in future revisions.
> - PE-PE recovery: Is this more like segment recovery or link 
> protection?
> - CE-CE recovery: I guess how to calculate CE-CE disjoint 
> paths is for 
> further study. (beyond basic mode?)

Yes we should add a section. 

> 
> 4) Section 2,
> 
>        "(2) GMPLS RSVP-TE is used not just as a signaling
> mechanism, but 
> also as a routing mechanism
>          within the provider network."

s/GMPLS RSVP-TE/GMPLS/ a typo.           
> 
>    I guess you don't mean RSVP-TE is used as a routing mechanism?
> 
> 
> Thanks,
> Tomonori
> 

_______________________________________________
L1vpn mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/l1vpn

---

From: Tomonori TAKEDA <[email-masked]>
Date: Sun, 23 Oct 2005 16:59:22 +0900

Hi Don,

Thanks. Please see in-line.

On Fri, 21 Oct 2005 12:44:02 -0400

> split on the auto-discovery mechansims.  

OK. I have seen the relevant I-D on this topic.

http://www.ietf.org/internet-drafts/draft-ouldbrahim-l1vpn-bgp-auto-discovery-00.txt

> to reserve resources for L1VPN customers so I think we need to discuss.

Agreed.

I am thinking there are several scenarios that preconfiguration may help.
- Resource reservation for L1VPN customers, as you pointed out
- Migration from today's operation

Something to discuss.

Best regards,
Tomonori