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

[Lou Berger <[e-mail]>]

Jie,


Per RFC5860:

   2.2.6. Lock Instruct


   The MPLS-TP OAM toolset MUST provide functionality to enable an End
   Point of a PW, LSP, or Section to instruct its associated End
   Point(s) to lock the PW, LSP, or Section.  Note that lock corresponds
   to an administrative status in which it is expected that only test
   traffic, if any, and OAM (dedicated to the PW, LSP, or Section) can
   be mapped on that PW, LSP, or Section.

According to IANA there are the defined admin status bits:

Bit Number Hex Value               Name                   Reference
    0      0x80000000 Reflect (R)                     [RFC3473][RFC3471]
   1-24               Unassigned
    25     0x00000040 Handover (H)                    [RFC5852]
    26     0x00000020 Lockout (L)                     [RFC4872]
    27     0x00000010 Inhibit Alarm Communication (I) [RFC4783]
    28     0x00000008 Call control (C)                [RFC4974]
    29     0x00000004 Testing (T)                     [RFC3473][RFC3471]
    30     0x00000002 Administratively down (A)       [RFC3473][RFC3471]
    31     0x00000001 Deletion in progress (D)        [RFC3473][RFC3471]

RFC 4872 also defines  Lockout of normal traffic (via the O bit) and
Lockout of a recovery LSP (via the L bit).  I suspect there are
sufficient mechanisms that can be reused to document how Lock Instruct
can be supported without new mechanisms. (Which is a reasonable thing to
do.)

On 4/17/2012 9:47 PM, Jie Dong wrote:
> 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.
> 

So you're point is that you don't like the existing mechanisms and ae
proposing an alternate.  Is this correct?

Lou

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