Re: [CCAMP] Discussions about draft-dong-ccamp-rsvp-te-mpls-tp-li-lb

Jie

See my2cents lined with <fei></fei>

Best 

Fei

Jie Dong <jie.dong@huawei.com> 
发件人:  ccamp-bounces@ietf.org
2012-04-18 09:47

收件人
Lou Berger <lberger@labn.net>
抄送
"ccamp@ietf.org" <ccamp@ietf.org>
主题
Re: [CCAMP] Discussions about draft-dong-ccamp-rsvp-te-mpls-tp-li-lb

Lou, 

Thanks for your prompt reply. Please see inline.

> I think you may have missed my reference.  Take a look at section 13 of
> RFC 4872.  I suspect you'll find the flags defined there to be a better
> match.

Thanks for pointing to this. Actually I looked at RFC 4872 first. While I 
agree lockout in RFC 4872 and lock instruct look similar, IMO there are 
still some differences. 

Section 13 of RFC 4872 talks about commands to influence recovery 
operations. The lockout command is used to force the recovery LSP 
unavailable to transport traffic (either normal or extra-traffic). It is 
only applicable to the recovery LSP with particular protection type. While 
IMO Lock Instruct is a general operation to an LSP, which can be either a 
working LSP or a recovery LSP, and with no constraint on the protection 
type. 

<fei> 
According to my understanding, the function of lock is to put the 
transport path into temporal unavialable state, which SHOULD be applicable 
to either recovery or working transport paths. Although the usage of  "L" 
bit in RFC4872 is just like what you said, which can be updated to cover 
more scenarios.
</fei> 

> >
> > This capability of sending notification to a targeted node is what
> > Loopback needs. And then we followed the mechanism defined in RFC4974
> > for calls. The extension needed is a new flag in ADMIN_STATUS
> > object.
> >
> > In my understanding, ERO/SERO could achieve identification and
> > configuration of a targeted node, by defining new ERO subobjects. For
> > Loopback such extension may be more significant than just defining a
> > new flag in an existing object. But if a new subobject is to be
> > defined for several related functions, this may be an interesting
> > topic to have further discussions.
> 
> I believe that Cyril said he'd take a pass at such a document (somewhat
> based on/similar to draft-kern-ccamp-rsvpte-hop-attributes-00).  Why
> don't we wait and see what comes of that before discussing this further.

Sounds good. Would like to see discussions and progress on that.

Many thanks,
Jie

_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
https://www.ietf.org/mailman/listinfo/ccamp