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

[Lou Berger <[e-mail]>]

sigh.

On 4/18/2012 9:54 PM, Jie Dong wrote:
> Hi Lou, 
> 
> Totally agree that it would be good if existing mechanism can be
> reused to support lock instruct. This discussion is just to make sure
> whether existing mechanisms can meet the requirement well, or some
> updates to them are needed (as Fei said).
> 
> Section 13 of RFC 4872 says: 
> 
> B. Lockout of normal traffic:
> The O bit of the PROTECTION object is set to 1 to force the recovery
> LSP to be temporarily unavailable to transport normal traffic.
> 
> So the O bit is also defined for lockout of the recovery LSP. For
> Lock Instruct we may need to update this to make it applicable to
> both working LSP and recovery LSP.
> 

did you read "A. Lockout of recovery LSP:"?  Is this not sufficient?

Lou

> Best regards,
> Jie
> 
> 
>> -----Original Message-----
>> From: Lou Berger [mailto:[e-mail]]
>> Sent: Wednesday, April 18, 2012 7:57 PM
>> To: Jie Dong
>> Cc: [e-mail]
>> Subject: Re: Discussions about draft-dong-ccamp-rsvp-te-mpls-tp-li-lb
>>
>> 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
>>>
>>>
>>>
>>>
>>>
> 
> 
> 
>