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

[Lou Berger <[e-mail]>]

Jie,
	Please see below.

On 4/17/2012 8:05 AM, Jie Dong wrote:
> Hi Lou, 
> 
> Thanks a lot for your helpful comments during the ccamp session in
> Paris. I've checked the existing mechanisms you mentioned, and would
> like to have some discussion about them.
> 
> 1. Testing mode and Lock Instruct
> 
> The testing (T) bit in ADMIN_STATUS object is defined in RFC3471. At
> a glance this may provide the similar function as Lock Instruction
> (LI) required, though I did not find specific description about the
> use of test mode. Thus I'm not quite sure whether there are some
> differences between test mode and lock instruct, could you shed some
> light on this? If they are the same, we could revise the draft to say
> that LI could be provided by the existing T bit, and focus on the
> extensions for loopback.

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.

> 
> 2. Notify message or ERO/SERO for sending request to target node
> 
> Section 4.3 of RFC3473 says: " The Notify message differs from the
> currently defined error messages (i.e., PathErr and ResvErr messages)
> in that it can be "targeted" to a node other than the immediate
> upstream or downstream neighbor and that it is a generalized
> notification mechanism ... The Notify message may be sent either (a)
> normally, where non-target nodes just forward the Notify message to
> the target node, similar to ResvConf processing in [RFC2205]; or (b)
> encapsulated in a new IP header whose destination is equal to the
> target IP address."
> 
> 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.

Lou

> 
> Best regards, 
> Jie