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

Hi Don,

Thanks. Please see in-line.

On Fri, 21 Oct 2005 12:44:02 -0400
"Don Fedyk" <dwfedyk@nortel.com> wrote:

> Hi Tomonori
> 
> Thanks for the Comments.  
> 
> > -----Original Message-----
> > From: Tomonori TAKEDA [mailto:takeda.tomonori@lab.ntt.co.jp]
> > Sent: Thursday, October 20, 2005 9:20 AM
> > To: l1vpn@ietf.org
> > Cc: Fedyk, Don [BL60:1A00:EXCH]; yakov@juniper.net; 
> > dimitri.papadimitriou@alcatel.be; richard@us.fujitsu.com; 
> > lberger@movaz.com
> > 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.  

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

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

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

> 
> > 
> > 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
L1vpn@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/l1vpn