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

[Jie Dong <[e-mail]>]

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. 

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