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

Hi Fei,

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

Agreed. The existing lockout may be updated to cover both working LSP and recovery LSP.

Best regards,
Jie

From: zhang.fei3@zte.com.cn [mailto:zhang.fei3@zte.com.cn]
Sent: Wednesday, April 18, 2012 4:03 PM
To: Jie Dong; Lou Berger
Cc: ccamp@ietf.org; ccamp-bounces@ietf.org
Subject: 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