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

From: Jie Dong <[email-masked]>
Date: Tue, 17 Apr 2012 12:05:27 +0000

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.

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.

Best regards,
Jie

---

From: Lou Berger <[email-masked]>
Date: Tue, 17 Apr 2012 09:05:46 -0400

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

> 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

---

From: Jie Dong <[email-masked]>
Date: Wed, 18 Apr 2012 01:47:38 +0000

Lou, 

Thanks for your prompt reply. Please see inline.

> RFC 4872.  I suspect you'll find the flags defined there to be a better

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. 

> 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

---

From: [email-masked]
Date: Wed, 18 Apr 2012 16:03:24 +0800

Jie

See my2cents lined with <fei></fei>

Best 

Fei

Jie Dong <[email-masked]> 
发件人:  [email-masked]
2012-04-18 09:47

收件人
Lou Berger <[email-masked]>
抄送
"[email-masked]" <[email-masked]>
主题
Re: [CCAMP] Discussions about draft-dong-ccamp-rsvp-te-mpls-tp-li-lb

Lou, 

> RFC 4872.  I suspect you'll find the flags defined there to be a better

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> 

Many thanks,
Jie

_______________________________________________
CCAMP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ccamp

---

From: Lou Berger <[email-masked]>
Date: Wed, 18 Apr 2012 07:56:33 -0400

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

---

From: Jie Dong <[email-masked]>
Date: Thu, 19 Apr 2012 01:48:20 +0000

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: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, April 18, 2012 4:03 PM
To: Jie Dong; Lou Berger
Cc: [email-masked]; [email-masked]
Subject: Re: [CCAMP] Discussions about draft-dong-ccamp-rsvp-te-mpls-tp-li-lb

Jie

Best

Fei

2012-04-18 09:47

收件人

抄送

主题

Lou,

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

Many thanks,
Jie

---

From: Jie Dong <[email-masked]>
Date: Thu, 19 Apr 2012 01:54:46 +0000

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:[email-masked]]
> Sent: Wednesday, April 18, 2012 7:57 PM
> To: Jie Dong
> Cc: [email-masked]
> Subject: Re: Discussions about draft-dong-ccamp-rsvp-te-mpls-tp-li-lb
> 
> Jie,
> 
> 
> Per RFC5860:
> 
>    2.2.6. Lock Instruct
> 
>

---

From: Lou Berger <[email-masked]>
Date: Thu, 19 Apr 2012 09:02:11 -0400

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

---

From: Mach Chen <[email-masked]>
Date: Sat, 21 Apr 2012 02:08:34 +0000

Hi Lou

Snipped

> can be supported without new mechanisms. (Which is a reasonable thing

For the Lockout function, according to the Section 13 of RFC 4872, my understanding of both the O bit and L bit are only applicable to the "RECOVERY" LSP, if we want to reuse the existing bits for the Lock function of MPLS-TP, some clarification updates are necessary. For example:

OLD:
Lockout (L): 1 bit

        When set, forces the recovery LSP to be temporarily unavailable
        to transport traffic (either normal or extra traffic). 

New:
Lockout (L): 1 bit

        When set, forces the LSP to be temporarily unavailable
        to transport traffic.

My suggest is that we could extend the scope of L bit to make it applies to working LSP as well in draft-dong-ccamp-rsvp-te-mpls-tp-li-lb, does it make sense?

Best regards,
Mach

---

From: Francesco Fondelli <[email-masked]>
Date: Sat, 21 Apr 2012 21:38:53 +0200

Hi All,

the "Lock Instruct and Loopback Functions" [6435] and the lockout of the
protection path [4872, 3471, 3473] are orthogonal concepts, IMHO.

1)
Overloading O bit is problematic:

--- 4872 ---
    Operational (O): 1 bit

         When set to 1, this bit indicates that the protecting LSP is
         carrying the normal traffic after protection switching.  The O
         bit is only applicable when the P bit is set to 1, and the LSP
         Protection Type Flag is set to either 0x04 (1:N Protection with
         Extra-Traffic), or 0x08 (1+1 Unidirectional Protection) or 0x10
         (1+1 Bidirectional Protection).  The O bit MUST be set to 0 in
         any other case.
---

As far as I understand the "Lock Instruct and Loopback Functions"
[6435] apply to any LSP (protected or not), however the "O bit
MUST be set to 0 in any other case" and I read "any other case"
as unprotected/full-rerouting.  I guess "LI & LOOP func" is also
applicable in the absence of a PROTECTION obj.

2)
L bit in ADMIN_STATUS is problematic too (basically, because what Mach
said).  It would be difficult to disambiguate "I want to lock
this recovery LSP out of the protection domain" (legacy behavior)
and "I want to lock this (w or p or whatever) LSP out of normal
service (in order to eventually make a loop-back test)".

3)
T bit is... I've always wondered how people use the T bit... :-)

For the sake of clarity I think a new bit in the ADMIN_STATUS is
preferable.  Just my opinion.

I do have a question about draft-dong-ccamp-rsvp-te-mpls-tp-li-lb-02...
... do the concepts of "lock a LSP out of normal service" and "perform a
data-plane loop-back test" belongs only to MPLS-TP ?  What about other
GMPLS controlled technologies ?

thanks
Ciao
FF

---

From: Lou Berger <[email-masked]>
Date: Sun, 22 Apr 2012 12:31:57 -0400

So I think there's multiple ways to reuse the existing bits.  We just
have to agree on which bits have applicability to TP's Lock Instruct.
Looking back at the TP requirement we have:

   2.2.6. Lock Instruct

So we have:
1) lock corresponds to an administrative status

-- Great, seems to map to setting the ADMIN_STATUS object A bid
      Administratively down (A): 1 bit

         When set, indicates that the local actions related to the
         "administratively down" state should be taken.

2)  only test traffic, if any,

-- Great, seems to map to setting the ADMIN_STATUS T bit when testing
traffic is present
      Testing (T): 1 bit

         When set, indicates that the local actions related to the
         "testing" mode should be taken.

3) The above seems to cover the unprotected case, now we also have the
existing O and L bits for the protection cases.

-- When LI is on a working path, the traffic needs to be switched to a
recovery lsp, as is already described in 4872 (the RFC even tells you
when to set the A bit!), and then to also follow the "Lockout of normal
traffic" procedure.

-- When LI is on a recovery LSP, the traffic may need to be switched
back to the working LSP, as is already described in 4872, and then to
also follow the "Lockout of recovery LSP" procedure.

So if we have a document that says that all TP implementations will use
the above to support TP LI, are there any TP LI requirements that are
not met?

Lou

---

From: Mach Chen <[email-masked]>
Date: Mon, 23 Apr 2012 02:19:09 +0000

Hi Lou, FF and others,

I agree the principle that we should try to reuse the existing bits when possible, but we also need to avoid overuse that may cause potential confusion or conflicts with the existing usage.  

Please see my reply inline...

> Sent: Monday, April 23, 2012 12:32 AM
> To: Francesco Fondelli; Mach Chen; Jie Dong
> Cc: [email-masked]

I am not sure whether this mode allows the test and OAM traffic be mapped on the LSP, seems not (my reading of it), so it seems that it cannot satisfy the requirement. 

>          "testing" mode should be taken.

T bit seems better than A bit, but there is only few description about what's the "testing" mode, if it was chosen, some clarifications are needed. For example, "In testing mode, only the test traffic, if any, and OAM (dedicated to the LSP) can be mapped on that LSP". 

> also follow the "Lockout of recovery LSP" procedure.

The LI function does not differ the normal and extra traffic, at first glance, we had thought we could reuse these bits for LI. But when deep in more, we found that they are not suitable at least as it current definition. As FF said, we also wondered how people will use the T bit:-), it defines as:

Lockout (L): 1 bit

It intends to lock out EITHER the normal OR extra traffic, my reading of this is that the L bit cannot be used alone, it must be used with other bits(e.g., the O bit) hence to make sure whether the normal or extra traffic should be locked out. So I think the L and O bit are not suitable for the TI function.

And if the T bit can be updated as above, it could apply to both working and recovery LSP, so there is no need to give more meanings to the L and O bits.. 

> the above to support TP LI, are there any TP LI requirements that are

IMHO, we should avoid using the combination of the above bits to support TP LI, it's a bit complicate, especially from the view of implementation. I am open to reuse the existing bit or define new bit, if the WG have the consensus to reuse the existing bits(e.g., the T bit), we could update the draft to reflect that. 

Many thanks,
Mach
> >>> can be supported without new mechanisms. (Which is a reasonable
> thing
> >>> to
> >>> do.)
> >>
> >> For the Lockout function, according to the Section 13 of RFC 4872, my
> understanding of both the O bit and L bit are only applicable to the
> "RECOVERY" LSP, if we want to reuse the existing bits for the Lock function
> of MPLS-TP, some clarification updates are necessary. For example:
> >>
> >> OLD:
> >> Lockout (L): 1 bit
> >>
> >> My suggest is that we could extend the scope of L bit to make it applies
> to working LSP as well in draft-dong-ccamp-rsvp-te-mpls-tp-li-lb, does it
> make sense?
> >>
> >> Best regards,
> >> Mach

---

From: Mach Chen <[email-masked]>
Date: Mon, 23 Apr 2012 03:12:27 +0000

Hi FF,

I agree that the L and O bit are not suitable for TP LI (because: only apply to recovery LSP, differ normal and extra traffic, ...). That's why we choose to define a new bit for the purpose(easy and safe). If we really want to reuse an existing bit, as Lou suggested, the T bit may be an alternative. 

> GMPLS controlled technologies ?

The LI and LB should not only belong to MPLS-TP, they are typical functions in transport network, IMHO, they could apply to other GMPLS controlled technologies as well. 

Best regards,
Mach
> From: Francesco Fondelli [mailto:[email-masked]]
> Sent: Sunday, April 22, 2012 3:39 AM
> To: Mach Chen
> Cc: Lou Berger; Jie Dong; [email-masked]

---

From: Jie Dong <[email-masked]>
Date: Mon, 23 Apr 2012 06:28:46 +0000

Hi FF and others,

> protection path [4872, 3471, 3473] are orthogonal concepts, IMHO.

Agreed, according to current specifications of Lockout. 

> Overloading O bit is problematic:

Agreed. And since "the O bit is only applicable when the P bit is set to 1", in my understanding it can only be set in signaling of the recovery LSP. 

> service (in order to eventually make a loop-back test)".

Yes, this is also what I mentioned during ccamp session: LI has nothing to do with protection, while L (lockout) bit is to make the recovery LSP unavailable for protection. 

> T bit is... I've always wondered how people use the T bit... :-)

Yes, probably we need more descriptions about the T bit.

> preferable.  Just my opinion.

That's also the reason we defined the new "Lock Instruct" bit in the draft. 

> GMPLS controlled technologies ?

IMO it is not only for MPLS-TP. As Lou said, TP is often used as a motivator for new functions, and such functions would also be applicable to other GMPLS controlled networks.

And we are still open to feedbacks whether a new bit is better, or some existing bit can be easily updated to cover the lock instruct requirement. Comments are welcome.

Many thanks,
Jie

> "RECOVERY" LSP, if we want to reuse the existing bits for the Lock function of
> MPLS-TP, some clarification updates are necessary. For example:
> >
> > OLD:
> > Lockout (L): 1 bit
> >
> > My suggest is that we could extend the scope of L bit to make it applies to
> working LSP as well in draft-dong-ccamp-rsvp-te-mpls-tp-li-lb, does it make
> sense?
> >
> > Best regards,
> > Mach

---

From: Lou Berger <[email-masked]>
Date: Mon, 23 Apr 2012 10:02:17 -0400

Mach,

See below.

> I am not sure whether this mode allows the test and OAM traffic be mapped on the LSP, seems not (my reading of it), so it seems that it cannot satisfy the requirement. 

Why not?

> T bit seems better than A bit, but there is only few description about what's the "testing" mode, if it was chosen, some clarifications are needed. For example, "In testing mode, only the test traf…

Right, the A and T bits were always intended to have technology specific
meanings.

So, just define how you want to have the A and T bits to be
interpreted/used for TP, once the WG agrees, the work is done.  No new
bits or really even new mechanisms, just agreement on usage for TP.

> The LI function does not differ the normal and extra traffic, 

Sure.  But RFC4872 does, so the 1 requirement (prevent usage by user
traffic) can use the ADMIN_STATUS A bit defined in 3471/3 and 2
mechanism already defined in 4872.

> at first glance, we had thought we could reuse these bits for LI. But when deep in more, we found that they are not suitable at least as it current definition. As FF said, we also wondered how people will use the T bit:-), it defines as:
> 
> Lockout (L): 1 bit
> 

I understand the desire for a simple, single bit, solution, but GMPLS is
an existing protocol that predates TP by a long time.  We should reuse
the existing mechanisms to meet TP's specific (but not unique)
requirements.  You mention that you're worried about "confusion or
conflicts" with exiting implementations, I'm not sure there are any in
this case as we are simply talking about using the bits as intended, i.e.:
  A bit = Administratively down (i.e., don't use it for user traffic)
  T bit = Testing (i.e., LSP is carrying test traffic)
  O/L bits =  Lockout of normal/recovery LSP (i.e., don't use
              working/protection LSP for user traffic)

and adding some specific TP usage, e.g., something along the lines of:
  TP Rule 1: To set TP LI on an unprotected LSP, set the A-bit on
             the LSP being locked. (as defined in rfc 3473/1)
  TP Rule 2: To set TP LI on an protected working path LSP,
             move the user traffic to a protection LSP, set the
             O-bit on the protection LSP, then set the A-bit on the
             the LSP being locked. (as defined in rfc 4872)
  TP Rule 3: To set TP LI on an protection path LSP, if not already
             done move the user traffic to the working (or another
             protection) LSP, set the L-bit on the protection LSP,
             set the A-bit on the LSP being locked. (all as defined in
             rfc 4872).
  TP Rule 4: Before sending test traffic on a locked LSP, set the T-bit.
  TP Rule 5: When no longer sending test traffic on a locked LSP, clear
             the T-bit.
  TP Rule 6: To remove TP LI, clear the A bit and, if set above, the
             L-bit.  When the O-bit is set, revert according to working
             LSP status/settings following procedures in RFC4872.

Other than it being "a bit complicated", is there a TP requirement that
can't be met by the existing mechanisms and usage rules?

If not, then general approach of the WG (and GMPLS) is to (re)use common
mechanisms wherever possible even when a new mechanisms could be "more
optimal" or "simpler"...

Lou

---

From: Mach Chen <[email-masked]>
Date: Tue, 24 Apr 2012 03:30:24 +0000

Lou,

See my reply inline...

Snipped.

>               working/protection LSP for user traffic)

O bit is not for locking out NORMAL(working) LSP, both O/L bits are only applicable to RECOVERY LSP. 

>              the LSP being locked. (as defined in rfc 3473/1)
OK. 
>              the LSP being locked. (as defined in rfc 4872)
OK.
>              set the A-bit on the LSP being locked. (all as defined in

Since the A bit is used for lock instruct, why do we need to set the L bit? 

>   TP Rule 4: Before sending test traffic on a locked LSP, set the T-bit.
OK.

>   TP Rule 5: When no longer sending test traffic on a locked LSP, clear
OK.

>              LSP status/settings following procedures in RFC4872.

As said above, the L bit is redundant for TP LI. If does not set L bit in Rule 3, no need to clear it. Fine with rest part. 

Summary: I agree with most the above suggestions, except for the usage of L bit. If these is no objection on this, we will update the draft accordingly. 

Many thanks,
Mach

---

From: Lou Berger <[email-masked]>
Date: Tue, 24 Apr 2012 07:43:15 -0400

Mach,
	Glad we're down to one open point.

> Since the A bit is used for lock instruct, why do we need to set the L bit? 

Because that's what the RFC says to do.

Is there an issue with using the L bit, or do you just think it's
unnecessary?

Lou

---

From: Mach Chen <[email-masked]>
Date: Wed, 25 Apr 2012 01:55:10 +0000

Lou,

> Sent: Tuesday, April 24, 2012 7:43 PM
> To: Mach Chen
> Cc: Francesco Fondelli; Jie Dong; [email-masked]

Yes, I think it's unnecessary, the A bit should take precedence when both A and L bit are set.

In addition, the L bit is designed to lock out either the normal or extra traffic: 
Lockout (L): 1 bit

But TP TI requires to lock out both normal and extra traffic.

Best regards,
Mach

---

From: Lou Berger <[email-masked]>
Date: Wed, 25 Apr 2012 07:37:09 -0400

Mach,
	The two sentences/statements you reference are equivalent.  I
understand that the text in the first sentence (RFC4872) is open to
misinterpretation.  If you'd like, you can open an editorial errata on
RFC4872 that states "unavailable to transport traffic (either normal or
extra traffic)" should read "unavailable to transport traffic (both
normal and extra traffic)" to avoid such misunderstanding of the
parenthetical in the future.

Lou

---

From: Mach Chen <[email-masked]>
Date: Thu, 26 Apr 2012 06:05:33 +0000

Lou,

Sure, will do that soon.

Many thanks,
Mach

> Sent: Wednesday, April 25, 2012 7:37 PM
> To: Mach Chen

---

From: Jie Dong <[email-masked]>
Date: Thu, 26 Apr 2012 08:21:27 +0000

Hi Lou,

Agree that we could reuse the A bit for lock instruct. 

Another confusing part in RFC 4872 is about the O bit in PROTECTION Object. 

In section 13.B, the O bit "is set to 1 to force the recovery LSP to be temporarily unavailable to transport normal traffic". 

But in section 14 it says "when set to 1, this bit indicates that the protecting LSP is carrying the normal traffic after protection switching." 

So two totally different operations with the same bit. My understanding is the operation in 13.B can be achieved by setting both the L bit and the O bit. We may need an errata to reflect this.

Best regards,
Jie