Subject: [CCAMP] Thoughts on updating the OAM Configuration fwk and the MPLS-TP OAM configuration drafts

From: "Attila Takacs" <[email-masked]>
Date: Tue, 1 Dec 2009 11:48:44 +0100

Hi all,

Some thoughts on updating the OAM Configuration fwk and the MPLS-TP OAM
configuration drafts.

I think we need to extend the OAM Function flags (described in
draft-ietf-ccamp-oam-configuration-fwk-02) to five flags:

-CC
-CV
-PM Loss
-PM Delay
-Fault Management signals

With regards to BFD I see three operation vs. configuration modes:

1) Set CC in the flags and only bootstrap the BFD session, by sending
the local discriminator values in RSVP-TE and leave timer negotiation to
BFD control messages. This is similar to LSP Ping based bootstrapping
described in draft-ietf-bfd-mpls-07.txt.

2) Set CC in the flags but configure the timers via the control plane,
this should correspond to "CC mode" in draft-asm-mpls-tp-bfd-cc-cv-01.
We may include the min/max intervals and by doing so support initial
timer negotiation in control plane. However, we may need a flag in CC
configuration sub-TLV (now in
draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-03 called "Suggested TX
Interval sub-TLV") to indicate whether data plane timer renegotiation is
enabled or disabled (i.e., subsequently via BFD control messages). This,
as described in draft-asm-mpls-tp-bfd-cc-cv-01, should be disabled for
TP LSPs by default.

3) In case of "full" MPLS-TP OAM support any of the flags could be set
as needed, reflecting "CV/CC mode" described in
draft-asm-mpls-tp-bfd-cc-cv-01, delay and loss measurement as described
in draft-frost-mpls-tp-loss-delay-00 and management signals as given in
draft-sfv-mpls-tp-fault-00.

To configure CC we will need to add
-enable/disable DP timer re-negotiation
-PHB to identify priority and drop precedence of CC packets

When it comes to CV, it would be interesting to discuss whether only the
OAM identifiers described in draft-ietf-mpls-tp-identifiers-00 are ought
to be supported. If so, those could be derived from RSVP-TE signaling
without the need to carry them explicitly in MPLS-TP OAM Configuration
sub-TLVs (now called Source unique MEP_ID sub-TLV in
draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-03). 

For Performance Monitoring Loss/Delay we need to add new TLVs, carrying
-measurement interval
-possibly loss/delay bound thresholds (given we what these for MPLS-TP)
that could be used to assess the quality of the connection and may
eventually trigger protection
-PHB of control packets if we want to set it differently from CC packets
or from data traffic.

For the Fault Management Signals, I would add a new "Fault Management
Signals sub-TLV" carrying:
-Enabled signals flags: AIS, LDI, LKR, CFS (which, except CFS, are
specified in draft-sfv-mpls-tp-fault-00)
-refresh timer of fault indication messages
-flag to enable/disable explicitly clear of faults
-PHB of fault management packets 

Another thing we may want to consider is adding a sub-TLV to set
consequent actions that are configurable. This is described to some
extent in the MPLS-TP OAM Framework. The defects identified include:
Loss Of Continuity defect, Mis-connectivity defect, MEP misconfiguration
defect, Period Misconfiguration defect.

An operator may want to configure if the consequence of LOC should be
the blocking or non-blocking of outgoing data traffic. Similarly it may
be useful to configure whether the "Period Misconfiguration defect"
should result in a signal fail condition or not.

I plan to send detailed text to the editors of
draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-03 along the lines
described above. Please comment!
Thanks,
Attila

---

From: Loa Andersson <[email-masked]>
Date: Wed, 02 Dec 2009 15:58:34 +0100

Attila,

thanks - I think things are converging quite a bit now.

May the OAM Configuration TLV specified in the OAM Configuration
Framweork only be present in the PATH message?

/Loa

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

-- 

Loa Andersson                         email: [email-masked]
Sr Strategy and Standards Manager            [email-masked]
Ericsson Inc                          phone: +46 10 717 52 13
                                              +46 767 72 92 13

---

From: Attila Takacs <[email-masked]>
Date: Thu, 3 Dec 2009 14:13:58 +0100

Hi Loa,

It can be carried in the LSP_ATTRIBUTES Object in the Resv message; so it can be used for timer negotiation and discriminator synchronization if needed.

Attila

> -----Original Message-----
> From: Loa Andersson [mailto:[email-masked]] 
> Sent: Wednesday, December 02, 2009 3:59 PM
> To: Attila Takacs
> Cc: [email-masked]; [email-masked]
> Subject: Re: [CCAMP] Thoughts on updating the OAM 
> Configuration fwk and the MPLS-TP OAM configuration drafts
> 
> Attila,
> 
> May the OAM Configuration TLV specified in the OAM 
> Configuration Framweork only be present in the PATH message?
> 
> /Loa
> 
> Attila Takacs wrote:
> > Hi all,
> > 
> > Some thoughts on updating the OAM Configuration fwk and the MPLS-TP 
> > OAM configuration drafts.
> > 
> > the local discriminator values in RSVP-TE and leave timer 
> negotiation 
> > to BFD control messages. This is similar to LSP Ping based 
> > bootstrapping described in draft-ietf-bfd-mpls-07.txt.
> > 
> > Interval sub-TLV") to indicate whether data plane timer 
> renegotiation 
> > is enabled or disabled (i.e., subsequently via BFD control 
> messages). 
> > This, as described in draft-asm-mpls-tp-bfd-cc-cv-01, should be 
> > disabled for TP LSPs by default.
> > 
> > draft-asm-mpls-tp-bfd-cc-cv-01, delay and loss measurement as 
> > described in draft-frost-mpls-tp-loss-delay-00 and 
> management signals 
> > as given in draft-sfv-mpls-tp-fault-00.
> > 
> > 
> > 
> > -enable/disable DP timer re-negotiation -PHB to identify 
> priority and 
> > drop precedence of CC packets
> > 
> > When it comes to CV, it would be interesting to discuss 
> whether only 
> > the OAM identifiers described in 
> draft-ietf-mpls-tp-identifiers-00 are 
> > ought to be supported. If so, those could be derived from RSVP-TE 
> > signaling without the need to carry them explicitly in MPLS-TP OAM 
> > Configuration sub-TLVs (now called Source unique MEP_ID sub-TLV in 
> > For Performance Monitoring Loss/Delay we need to add new TLVs, 
> > carrying -measurement interval -possibly loss/delay bound 
> thresholds 
> > (given we what these for MPLS-TP) that could be used to assess the 
> > quality of the connection and may eventually trigger 
> protection -PHB 
> > of control packets if we want to set it differently from CC 
> packets or 
> > from data traffic.
> > 
> > specified in draft-sfv-mpls-tp-fault-00) -refresh timer of fault 
> > indication messages -flag to enable/disable explicitly 
> clear of faults 
> > Loss Of Continuity defect, Mis-connectivity defect, MEP 
> > misconfiguration defect, Period Misconfiguration defect.
> > 
> > the blocking or non-blocking of outgoing data traffic. Similarly it 
> > may be useful to configure whether the "Period 
> Misconfiguration defect"

---

From: Loa Andersson <[email-masked]>
Date: Thu, 03 Dec 2009 15:04:43 +0100

Attila,

OK great, then we need to update that in the framework.

I also have a question on the relationship between flags and
the sub-tlvs.

I think there are four possibilities:

1. A flag is set, but there is no sub-tlv
    - the action here should be to turn on the function the
      flag indicates using default values
      I also think that if a function indicated by flag is
      running, it should be left unchanged, even if it is not
      running on default values

2. A flag is set, and there is a sub-tlv
    - the action here would be to turn on the function indicated by
      the flag, using the parameters found in sub-tlv

3. A flag is not set, and there is no sub-tlv
    - the action here would be to turn off any function that has
      been configured earlier

4. A flag is not set, but there is sub-tlv
      - this should be treated as an error conditions and an
        error message should be returned, no changes to the configured
        OAM should be made.

Is this correctly understood?

/Loa

--

---

From: Attila Takacs <[email-masked]>
Date: Thu, 3 Dec 2009 15:17:25 +0100

Hi Loa, 

> OK great, then we need to update that in the framework.
Ok, I will do so.

> Is this correctly understood?
Yes. I will check is this need clarification in the fwk.

Attila

> 
> /Loa
> 
> Attila Takacs wrote:
> > Hi Loa,
> > 
> > It can be carried in the LSP_ATTRIBUTES Object in the Resv 
> message; so it can be used for timer negotiation and 
> discriminator synchronization if needed.
> > 
> > Attila
> > 
>                                               +46 767 72 92 
> 13 _______________________________________________
> CCAMP mailing list
> [email-masked]

---

From: Loa Andersson <[email-masked]>
Date: Thu, 03 Dec 2009 18:20:42 +0100

Attila,

if we agree on this the we also have a method to easily reconfigure
OAM on already set up LSPs, simple send a refresh PATH or RESV.

What do people think is this a good idea?

/Loa

--

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 3 Dec 2009 18:28:57 +0100

+1

Cheers,
Andy

On Thu, Dec 3, 2009 at 6:20 PM, Loa Andersson <[email-masked]> wrote:
>>> I also have a question on the relationship between flags and the
>>> sub-tlvs.
>>>
>>> message; so it can be used for timer negotiation and discriminator
>>> synchronization if needed.
>>>>
>>>> Attila
>>>>
>>> Configuration fwk
>>>>> and the MPLS-TP OAM configuration drafts
>>>>>
>>>>> Attila,
>>>>>
>>>>>> Some thoughts on updating the OAM Configuration fwk and
>>>
>>> the MPLS-TP
>>>>>>
>>>>>> 1) Set CC in the flags and only bootstrap the BFD session,
>>>>>
>>>>> by sending
>>>>>>
>>>>>> 2) Set CC in the flags but configure the timers via the
>>>>>
>>>>> control plane,
>>>>>>
>>>>>> this should correspond to "CC mode" in
>>>>>
>>>>> draft-asm-mpls-tp-bfd-cc-cv-01.
>>>>>>
>>>>>> We may include the min/max intervals and by doing so
>>>>>
>>>>> support initial
>>>>>>
>>>>>> timer negotiation in control plane. However, we may need a
>>>>>
>>>>> flag in CC
>>>>>>
>>>>>> draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-03 called
>>>>>
>>>>> "Suggested TX
>>>>>>
>>>>>> 3) In case of "full" MPLS-TP OAM support any of the flags
>>>>>
>>>>> could be set
>>>>>>
>>>>>> draft-asm-mpls-tp-bfd-cc-cv-01, delay and loss measurement as described in
>>>>>> draft-frost-mpls-tp-loss-delay-00 and
>>>>>
>>>>> management signals
>>>>>>
>>>>>> signaling without the need to carry them explicitly in
>>>
>>> MPLS-TP OAM
>>>>>>
>>>>>> Configuration sub-TLVs (now called Source unique MEP_ID
>>>
>>> sub-TLV in
>>>>>>
>>>>>> (given we what these for MPLS-TP) that could be used to
>>>
>>> assess the
>>>>>>
>>>>>> For the Fault Management Signals, I would add a new "Fault
>>>>>
>>>>> Management
>>>>>>
>>>>>> -Enabled signals flags: AIS, LDI, LKR, CFS (which, except
>>>
>>> CFS, are
>>>>>>
>>>>>> consequent actions that are configurable. This is
>>>
>>> described to some
>>>>>>
>>>>>> extent in the MPLS-TP OAM Framework. The defects
>>>
>>> identified include:
>>>>>>
>>>>>> An operator may want to configure if the consequence of LOC
>>>>>
>>>>> should be
>>>>>>
>>>>>> the blocking or non-blocking of outgoing data traffic.
>>>
>>> Similarly it
>>>>>>

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 3 Dec 2009 09:34:45 -0800

Yes, indeed

Regards,
Greg

---

From: <[email-masked]>
Date: Thu, 3 Dec 2009 17:41:17 -0000

It sounds like a sensible idea to me Loa.  Indeed, I have always been of
the view that in co mode networks using a CP the signalling protocol has
a very important role to play wrt telling trail termination points what
SA to expect in CV OAM DP packets, and also activating/deactivating the
(CV) defect detection/handling in sync with set-up/tear-down of the
connection.
 
regards, Neil

________________________________

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Greg Mirsky
	Sent: 03 December 2009 17:35
	To: Loa Andersson
	Cc: [email-masked]; Attila Takacs; [email-masked]
	Subject: Re: [CCAMP] Thoughts on updating the OAM Configuration
fwk and theMPLS-TP OAM configuration drafts

	Yes, indeed
	
	Regards,
	Greg

		Attila,
		
		if we agree on this the we also have a method to easily
reconfigure
		OAM on already set up LSPs, simple send a refresh PATH
or RESV.

		/Loa
		
		Attila Takacs wrote:

			Hi Loa, 

				OK great, then we need to update that in
the framework.

			Ok, I will do so.

				I also have a question on the
relationship between flags and the sub-tlvs.

				1. A flag is set, but there is no
sub-tlv
				   - the action here should be to turn
on the function the
				     flag indicates using default values
				     I also think that if a function
indicated by flag is
				     running, it should be left
unchanged, even if it is not
				     running on default values
				
				2. A flag is set, and there is a sub-tlv
				   - the action here would be to turn on
the function indicated by
				     the flag, using the parameters
found in sub-tlv
				
				3. A flag is not set, and there is no
sub-tlv
				   - the action here would be to turn
off any function that has
				     been configured earlier
				
				4. A flag is not set, but there is
sub-tlv
				     - this should be treated as an
error conditions and an
				       error message should be returned,
no changes to the configured
				       OAM should be made.

			Yes. I will check is this need clarification in
the fwk.
			
			Attila

				/Loa
				
				Attila Takacs wrote:

				Hi Loa,
				
				It can be carried in the LSP_ATTRIBUTES
Object in the Resv 

				message; so it can be used for timer
negotiation and discriminator synchronization if needed.

				Attila

				-----Original Message-----
				From: Loa Andersson [mailto:[email-masked]]
				Sent: Wednesday, December 02, 2009 3:59
PM
				To: Attila Takacs
				Cc: [email-masked]; [email-masked]
				Subject: Re: [CCAMP] Thoughts on
updating the OAM 

				Configuration fwk 

				Attila,
				
				thanks - I think things are converging
quite a bit now.
				
				May the OAM Configuration TLV specified
in the OAM Configuration Framweork only be present in the PATH message?
				
				/Loa
				
				Attila Takacs wrote:

				Hi all,
				
				Some thoughts on updating the OAM
Configuration fwk and 

				the MPLS-TP 

				I think we need to extend the OAM
Function flags (described in

				-CC
				-CV
				-PM Loss
				-PM Delay

				With regards to BFD I see three
operation vs. configuration modes:
				
				1) Set CC in the flags and only
bootstrap the BFD session,

				by sending

				the local discriminator values in
RSVP-TE and leave timer

				negotiation

				to BFD control messages. This is similar
to LSP Ping based bootstrapping described in draft-ietf-bfd-mpls-07.txt.
				
				2) Set CC in the flags but configure the
timers via the

				control plane,

				We may include the min/max intervals and
by doing so

				support initial

				timer negotiation in control plane.
However, we may need a

				flag in CC

				"Suggested TX

				Interval sub-TLV") to indicate whether
data plane timer

				renegotiation

				is enabled or disabled (i.e.,
subsequently via BFD control

				messages). 

				This, as described in
draft-asm-mpls-tp-bfd-cc-cv-01, should be disabled for TP LSPs by
default.
				
				3) In case of "full" MPLS-TP OAM support
any of the flags

				could be set

				as needed, reflecting "CV/CC mode"
described in draft-asm-mpls-tp-bfd-cc-cv-01, delay and loss measurement
as described in draft-frost-mpls-tp-loss-delay-00 and

				management signals

				
-PHB to identify

				priority and

				When it comes to CV, it would be
interesting to discuss

				whether only

				ought to be supported. If so, those
could be derived from RSVP-TE signaling without the need to carry them
explicitly in 

				MPLS-TP OAM 

				Configuration sub-TLVs (now called
Source unique MEP_ID 

				sub-TLV in 

				
				For Performance Monitoring Loss/Delay we
need to add new TLVs, carrying -measurement interval -possibly
loss/delay bound

				thresholds

				(given we what these for MPLS-TP) that
could be used to 

				assess the 

				quality of the connection and may
eventually trigger

				protection -PHB

				of control packets if we want to set it
differently from CC

				packets or

				from data traffic.
				
				For the Fault Management Signals, I
would add a new "Fault

				Management

				Signals sub-TLV" carrying:
				-Enabled signals flags: AIS, LDI, LKR,
CFS (which, except 

				CFS, are 

				specified in draft-sfv-mpls-tp-fault-00)
-refresh timer of fault indication messages -flag to enable/disable
explicitly

				clear of faults

				Another thing we may want to consider is
adding a sub-TLV to set consequent actions that are configurable. This
is 

				described to some 

				extent in the MPLS-TP OAM Framework. The
defects 

				identified include:

				Loss Of Continuity defect,
Mis-connectivity defect, MEP misconfiguration defect, Period
Misconfiguration defect.
				
				An operator may want to configure if the
consequence of LOC

				should be

				the blocking or non-blocking of outgoing
data traffic. 

				Similarly it 

				may be useful to configure whether the
"Period

				Misconfiguration defect"

				should result in a signal fail condition
or not.

				I plan to send detailed text to the
editors of

				

				--

				Loa Andersson
email: [email-masked]
				Sr Strategy and Standards Manager
[email-masked]
				Ericsson Inc
phone: +46 10 717 52 13
	
+46 767 72 92 13

				-- 

				Loa Andersson
email: [email-masked]
				Sr Strategy and Standards Manager
[email-masked]
				Ericsson Inc
phone: +46 10 717 52 13
	
+46 767 72 92 13 _______________________________________________
				CCAMP mailing list
				[email-masked]

		-- 

		Loa Andersson                         email:
[email-masked]
		Sr Strategy and Standards Manager            [email-masked]
		Ericsson Inc                          phone: +46 10 717
52 13
		                                            +46 767 72
92 13
		_______________________________________________
		CCAMP mailing list
		[email-masked]
		https://www.ietf.org/mailman/listinfo/ccamp

---

From: Thomas Nadeau <[email-masked]>
Date: Thu, 3 Dec 2009 13:13:44 -0500

Has anyone thought about security ramifications of allowing this?

On Dec 3, 2009, at 12:28 PM, "Andrew G. Malis" <[email-masked]>  
wrote:

> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp
>

---

From: <[email-masked]>
Date: Thu, 3 Dec 2009 19:10:13 -0000

Hi Tom....this is why it is always a good idea for a co mode network to
take its CP/MP logically OOB wrt to the traffic DP....a forced action
for the co-cs mode, but requires a conscious design decision in the
co-ps mode.

regards, Neil   
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Thomas Nadeau
> Sent: 03 December 2009 18:14
> To: Andrew G. Malis
> Subject: Re: [mpls-tp] [CCAMP] Thoughts on updating the OAM 
> Configurationfwk and the MPLS-TP OAM configuration drafts
> 
> Configuration 
> >>>>>>> To configure CC we will need to add -enable/disable DP timer 
> >>>>>>> re-negotiation -PHB to identify
> >>>>>>
> >>>>>> priority and
> >>>>>>>
> >>>>>>> ought to be supported. If so, those could be derived 
> from RSVP- 
> >>>>>>> TE signaling without the need to carry them explicitly in
> >>>>
> >>>> MPLS-TP OAM
> >>>>>>>
> >>>>>>> draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-03 along the 
> >>>>>>> lines described above. Please comment!
> >>>>>>> Thanks,
> >>>>>>> Attila
> >>>>>>>
> >>>>>>>
> >>>>>>>

---

From: Thomas Nadeau <[email-masked]>
Date: Thu, 3 Dec 2009 14:47:25 -0500

That still doesn't answer my question. *)  Has anyone thought about unapproved RSVP messages being send to modify/deactivate/activate LSPs in this model described here?  

	--Tom

---

From: <[email-masked]>
Date: Fri, 4 Dec 2009 10:02:41 -0000

Thanks Tom....but won't the CP signalling/routing protocols for MPLS-TP
(if one is used) sit under a reserved label that should not appear in
the traffic DP (except for OAM messages themselves, which is arch wrong
IMO since OAM is in the same DP as the traffic).  So I am not clear how
external parties could access the CP. Sorry I am not getting your point,
can you please expand on your specific concerns, eg with some exmaples?

Thanks.....regards, Neil

> From: Thomas Nadeau [mailto:[email-masked]] 
> Sent: 03 December 2009 19:47
> To: Harrison,N,Neil,DPF2 R
> Cc: [email-masked]; [email-masked]; [email-masked]
> 	That still doesn't answer my question. *)  Has anyone 
> thought about unapproved RSVP messages being send to 
> modify/deactivate/activate LSPs in this model described here?  
> 
> 	--Tom
> 
> 
> 
> > Hi Tom....this is why it is always a good idea for a co 
> mode network 
> > to take its CP/MP logically OOB wrt to the traffic DP....a forced 
> > action for the co-cs mode, but requires a conscious design 
> decision in 
> > the co-ps mode.
> > 
> > regards, Neil

---

From: <[email-masked]>
Date: Fri, 4 Dec 2009 11:38:48 +0000

Tom,

Can you be more specific? I don't see any greater security ramifications
resulting from unapproved RSVP messages being sent to
modify/deactivate/activate LSPs in this model than the current usages of
RSVP-TE.

Although for a slightly different context in Section 4.4.3.3 of
draft-jenkins-mpls-tp-bt-requirements-00.txt I have the following note:

   [Editor's note: Need to insert some text requiring a mechanism to
   limit the chance of fat fingers running inappropriate tests, e.g. on
   a per PW basis the ability to run a throughput test (and the maximum
   rate) needs to be pre-authorised via some mechanism e.g. within the
   PW interface configuration]

When writing the draft I had quite a lengthy discussion with Simon (the
draft's co-author) about suitable mechanisms but I timed out on constructing
some suitable text (and still haven't got around to it).

Maybe something similar would be needed for being able to reconfigure the
OAM on already setup LSPs. What I was thinking about for draft-jenkins was
something like being able to specify in the interface configuration a
requirement for explicit authentication/authorisation (possibly limited to
specific account roles) before performing the Throughput test so (1)
operations folks might think twice before continuing and (2) AAA can
specifically record who performed the action so if things do go wrong the
guilty operations person can be tracked down and "re-educated".

Ben

---

From: Loa Andersson <[email-masked]>
Date: Fri, 04 Dec 2009 13:57:55 +0100

Tom,

> modify/deactivate/activate LSPs in this model than the current usages of

I agree with Ben, I don't see any additional security issues as
compared to how RSVP-TE is used today.

/Loa

--

---

From: Thomas Nadeau <[email-masked]>
Date: Fri, 4 Dec 2009 08:26:15 -0500

I guess my point is to ask whether or not we've thought through the architectural and security implications of allowing changes to configurations via a signaling protocol.  More specially, are we targeting OAM configuration to be contained to just RSVP-related configuration, or are we going to allow it to go beyond that?  If its the former, I'd agree, the security implications are similar to those of the base protocol; however, when we go beyond that such as the discussion of enabling/disabling existing LSPs or such things, I see potential issues there.

	--Tom

---

From: Chris Benson <[email-masked]>
Date: Mon, 7 Dec 2009 17:32:08 -0800 (PST)

Loa and Attila,

When viewing the four possibilities as enumerated by
Loa, I wonder if the fourth might be better thus:

4. A flag is not set, but there is sub-tlv
     - this will result in the function being TURNED OFF,
       AND is treated as an error condition: an error message
       should be returned (indicating incompatible sub-tlv).

My reason for suggesting this is in case there is any
misidentification of whether a sub-tlv is associated
with the flag being considered or not.  In all the other
three cases, the value of the flag is sufficient to
determine the resultant state of the function. Perhaps
it would be "cleaner" if that were so in this fourth case
as well.

If a peer were using some unrelated experimental extension,
but accidentally re-used a sub-tlv tag associated with the
flag under examination, then it would be unable to turn
off the flag's feature.

This is an error case that "shouldn't" happen, but it seems
cleaner to me if the flag alone can tell us the eventual
state of the function, without also needing the ability to
associate a sub-tlv (or set of sub-tlvs) with the cleared
flag, to identify Loa's case 4.

Just a thought. With thanks, from Chris Benson.

On Thu, 3 Dec 2009, Loa Andersson wrote:

>>  Date: Thu, 03 Dec 2009 15:04:43 +0100
>>  From: Loa Andersson <[email-masked]>
>>  To: Attila Takacs <[email-masked]>
>>  Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
>>  Subject: Re: [mpls-tp] [CCAMP] Thoughts on updating the OAM Configuration
>>      fwk and the MPLS-TP OAM configuration drafts
>>  
>>  Attila,
>>  
>>  > It can be carried in the LSP_ATTRIBUTES Object in the Resv message; so it
>>  > can be used for timer negotiation and discriminator synchronization if
>>  > needed.
>>  > 
>>  > Attila
>>  > 
>>  > > From: Loa Andersson [mailto:[email-masked]] Sent: Wednesday, December 02,
>>  > > 2009 3:59 PM
>>  > > To: Attila Takacs
>>  > > Subject: Re: [CCAMP] Thoughts on updating the OAM Configuration fwk and
>>  > > the MPLS-TP OAM configuration drafts
>>  > >
>>  > > Attila,
>>  > >

---

From: [email-masked]
Date: Tue, 8 Dec 2009 11:27:22 +0800

Hi attila

If we want to configure PW oam using the same procedure, for the setting 
up of PW 
in two directions is independent (not like RSVP-TE, path and resv message 
are dependent),
we had better put the timer negotiation in the BFD session itself.
And in this way, it will be easier to renegotiate the timer if the two 
ends want to change
it.

I agree with you, this should be updated in the furture version.

B.R.

:)

Fei

"Attila Takacs" <[email-masked]> 
发件人:  [email-masked]
2009-12-01 18:48

收件人
<[email-masked]>, <[email-masked]>
抄送

主题
[CCAMP] Thoughts on updating the OAM Configuration fwk and the  MPLS-TP 
OAM configuration drafts

Hi all,

-CC
-CV
-PM Loss
-PM Delay

---

From: Loa Andersson <[email-masked]>
Date: Tue, 08 Dec 2009 13:13:15 +0100

Tom,

all the four drafts we've discussed are extensions to RSVP-TE, so
the same considerations that apply to other RSVP-TE applications
applies here.

/Loa

--

---

From: Loa Andersson <[email-masked]>
Date: Tue, 08 Dec 2009 14:37:39 +0100

Chris,

see inline please.

>        should be returned (indicating incompatible sub-tlv).

This is what I had proposed

I see the rational behind what you are saying, so

1. We agree that this is an error, and I'm also fine with
    sending the error message indicating incompatible sub-TLV
2. I'm less convinced, but open to discuss, turning off "the
    function". Are you proposing turning off the function indicated
    by the sub-TLV? Or any active OAM funtions? I believe the
    first. I would be rather hesitant to do any changes based
    on something that we can identify as an error.
    Though I guess that your reasoning is that the flag indicates
    "turn off".
    I can see that, but would like to have more comments.

/Loa

--

---

From: Francesco Fondelli <[email-masked]>
Date: Tue, 8 Dec 2009 19:19:27 +0100

>   I can see that, but would like to have more comments.

An error is an error, send back a big NACK to the originator
of the request and do nothing (well... one may log something).
I'd go for the original proposal (which is already described
in the oam-configuration-fwk ID, I think).  My 2p.

> /Loa

Ciao
FF

---

From: Chris Benson <[email-masked]>
Date: Tue, 8 Dec 2009 11:51:57 -0800 (PST)

Loa,

Yes, I believe you understood my original suggestion.
My intention was to suggest that if a specific flag is NOT set, 
AND the related function was previously enabled, then it would 
become disabled (turned off).

The only case under discussion (by me) is where there
is erroneously also a specific-function-related sub-TLV 
parameter present, which I think we agree should only
be present when turning ON a function (flag SET).

I am less in favour of my own proposal today (following
one other negative response), because I guess there will
remain only a small number of flags, and only a correspondingly
small number of sub-TLV parameters that should NOT be present 
when the flag is NOT set.

My original comment was to simplify the parsing of whether
a previously enabled function should be turned OFF.

[I previously suggested:]
   IF ((a function was previously enabled)
      AND (its specific flag is now NOT set))
   THEN disable the function.

... regardless of any erroneously included sub-TLVs.

But as has been emphasized [thanks Francesco], this can be 
considered (in the erroneous case) to be:

[BAD corollary of my suggestion:]
   IF (the received message is erroneously inconsistent)
   THEN maybe do it anyway.

which is more important to avoid than slightly more
complicated parsing.

I'm withdrawing my suggestion, and agree with Loa's
original 4 numbered cases, as characterized by Francesco
Fondelli (an error is an error and deserves a NAK).

So, "never mind", and thanks for the responses.

Chris Benson.

On Tue, 8 Dec 2009, Loa Andersson wrote:

>>  Date: Tue, 08 Dec 2009 14:37:39 +0100
>>  To: Chris Benson <[email-masked]>, "[email-masked]" <[email-masked]>,
>>      "[email-masked]" <[email-masked]>