Subject: [CCAMP] Monitoring control

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Sat, 14 Nov 2009 17:19:22 +0100

Hi,
	
During this meeting it appeared we have reached a limit in terms of
functionality associated to messaging and processing of extended ERO/RRO
and LSP Attributes in particular for their re-use in context of
monitoring control. The first should be limited to "topological/spatial
information" and the latter to attributes associated to the whole "path"
(no distinction of the individual hops).

So, if monitoring control can accommodate configuration
non-simultaneously with the signaling of the path, I suggest to devise a
couple of lines of thinking for monitoring control (incl. configuration,
activation, etc.) messaging and processing:

- Monitoring control message should only be processed if corresponding
PSB/RSB exist (at MP) and should be targeted with a sequence of MP's
(can take the form of a route object) so as to "skip" hops that are not
MPs.

- Monitoring control message should only be processed by MPs whose
identity can be gathered from RRO (one may use the object to tag MP) but
not limited to.

- Monitoring control message (and objects it carries) should not
functionaly overlap with already defined in Path/Resv and associated
objects.

- To cope with "multi-AS"/"multi-area" LSP (abstract nodes), the
monitoring control message should be able to carry a monitoring profile
relayed by each AS/area.

- The Path message shall make clear if the actual LSP will only be
activated once monitoring setup is completed or not. this allows to have
unmonitored LSP (that may subsequently configured to be monitored).

- As there is a decoupling between LSP and monitoring setup, if the
control message is not received at MP a notification should trigger the
sender/head-end.

- The directionality of the LSP setup shall not interfere with the
exchange of the OAM message exchanges 

These are just ideas as I considered that after my comment on the mike
proposing a possible way forward would be helpful.

Comments appreciated.
-dimitri.

---

From: "Attila Takacs" <[email-masked]>
Date: Tue, 17 Nov 2009 18:08:22 +0100

Hi Dimitri,
Thanks for the summary!
Please see my comments inline.

________________________________

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of PAPADIMITRIOU Dimitri
	Sent: Saturday, November 14, 2009 5:19 PM
	To: [email-masked]
	Subject: [CCAMP] Monitoring control

	Hi, 
	        
	During this meeting it appeared we have reached a limit in terms
of functionality associated to messaging and processing of extended
ERO/RRO and LSP Attributes in particular for their re-use in context of
monitoring control. The first should be limited to "topological/spatial
information" and the latter to attributes associated to the whole "path"
(no distinction of the individual hops). 

I see two use-cases where specific configuration of intermediate nodes
along the LSP may be needed. One is the configuration of some OAM
functions like TCM and maybe some MIP functions. The other area is WSON
aspects discussed in section 4 of
draft-bernstein-ccamp-wson-signaling-05.  

	- Monitoring control message should only be processed if
corresponding PSB/RSB exist (at MP) and should be targeted with a
sequence of MP's (can take the form of a route object) so as to "skip"
hops that are not MPs. 

You seem to suggest a separate message exchange for OAM after LSP setup.
I do not think this is needed, OAM configuration, even if intermediate
nodes would have to be configured, is sequential and follows exactly the
steps of LSP setup and Path/Resv processing. Exactly this is the value
in binding OAM configuration to LSP signaling. 

I doubt that selective intermediate node configuration would be
extensively used for multiple hops of an LSP; I think it is more
realistic to assume that only a subset of LSPs will actually require
intermediate node configuration and even for those LSPs only a very
limited number of intermediate nodes will have to be configured
selectively.

Thanks,
Attila

	- Monitoring control message should only be processed by MPs
whose identity can be gathered from RRO (one may use the object to tag
MP) but not limited to. 

objects. . 

	- The Path message shall make clear if the actual LSP will only
be activated once monitoring setup is completed or not. this allows to
have unmonitored LSP (that may subsequently configured to be monitored).

	- As there is a decoupling between LSP and monitoring setup, if
the control message is not received at MP a notification should trigger
the sender/head-end.

	- The directionality of the LSP setup shall not interfere with
the exchange of the OAM message exchanges 

	These are just ideas as I considered that after my comment on
the mike proposing a possible way forward would be helpful.

	Comments appreciated. 
	-dimitri.

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Tue, 17 Nov 2009 23:17:33 +0100

Hi Attila,

[snip headers]
		        
		During this meeting it appeared we have reached a limit
in terms of functionality associated to messaging and processing of
extended ERO/RRO and LSP Attributes in particular for their re-use in
context of monitoring control. The first should be limited to
"topological/spatial information" and the latter to attributes
associated to the whole "path" (no distinction of the individual hops). 

	I see two use-cases where specific configuration of intermediate
nodes along the LSP may be needed. One is the configuration of some OAM
functions like TCM and maybe some MIP functions. The other area is WSON
aspects discussed in section 4 of
draft-bernstein-ccamp-wson-signaling-05.

[dp] my opinion here is to design monitoring control toward commonality.
the point is that I do not know up to which the level one can assume
this commonality when "spectral" routing constraints needs to be taken
into account. for traffic engineering application that do rely on
spatial informations I am close to think this level can be quite high.

	You seem to suggest a separate message exchange for OAM after
LSP setup.

[dp] Not necessarily but if kept bundled there is a need to limit
"impact" on signaling in the context of traffic engineering. I would say
if an existing "message" is re-used with a different sequence of hops
this would be an hybrid approach. As food for thought please take a look
at RFC 2745.

[dp] Actually, there is a tradeoff here that shall be understood
(between messaging, processing, timing/efficiency, robustness,
complexity), e.g., the overhead per LSP is minimal when all "hops" are
MPs and maximal only when one of them needs to be "configured" (or even
none). 

[dp] Is this estimation robust over time ? I mean you assume that only
"part" of the number of LSPs would be monitored. Thus, it is the
application that would "limit" the overhead not the protocol design. 

[dp] Shall I assume that you do not have comments on the other points ?

		Thanks,
	Attila

		- Monitoring control message should only be processed by
MPs whose identity can be gathered from RRO (one may use the object to
tag MP) but not limited to. 

		- Monitoring control message (and objects it carries)
should not functionaly overlap with already defined in Path/Resv and
associated objects. . 

		- To cope with "multi-AS"/"multi-area" LSP (abstract
nodes), the monitoring control message should be able to carry a
monitoring profile relayed by each AS/area. 

		- The Path message shall make clear if the actual LSP
will only be activated once monitoring setup is completed or not. this
allows to have unmonitored LSP (that may subsequently configured to be
monitored).

		- As there is a decoupling between LSP and monitoring
setup, if the control message is not received at MP a notification
should trigger the sender/head-end.

		- The directionality of the LSP setup shall not
interfere with the exchange of the OAM message exchanges 

		These are just ideas as I considered that after my
comment on the mike proposing a possible way forward would be helpful.

		Comments appreciated. 
		-dimitri.

---

From: "Attila Takacs" <[email-masked]>
Date: Fri, 20 Nov 2009 15:17:46 +0100

Hi Dimitri, 
		        
> 		During this meeting it appeared we have reached 
> a limit in terms of functionality associated to messaging and 
> processing of extended ERO/RRO and LSP Attributes in 
> particular for their re-use in context of monitoring control. 
> The first should be limited to "topological/spatial 
> information" and the latter to attributes associated to the 
> whole "path" (no distinction of the individual hops). 
> 
> 	I see two use-cases where specific configuration of 
> intermediate nodes along the LSP may be needed. One is the 
> configuration of some OAM functions like TCM and maybe some 
> MIP functions. The other area is WSON aspects discussed in 
> section 4 of draft-bernstein-ccamp-wson-signaling-05.
> 
> the point is that I do not know up to which the level one can 
> assume this commonality when "spectral" routing constraints 
> needs to be taken into account. for traffic engineering 
> application that do rely on spatial informations I am close 
> to think this level can be quite high.
> 

[at] OAM and WSON aspects are different, but if the mechanisms are
similar then they could make use of a similar solution to carry
intermediate node configuration.

There are a set of different question here, 
- do we need a way to add support to carry per hop configuration info
into RSVP-TE
	=there seems to be a case for this

- if so, what kind of info (e.g., complexity) we need to consider 
	=this likely varies for each use case

- find the right place for each type of configuration info
	=there may be simple info (like falgs or a few fields) and more
complex descriptors
	=what to put where is use case dependent

For OAM, ERO seems to me to be a good candidate. I will look at the
scalability issues raised at the meeting when using the ERO; I guess
there are functions that will fit into ERO/RRO without causing problems,
however if there are cases that require a lot of configuration an
alternative solution could be useful.

The WSON case needs to be evaluated separately.

> 		So, if monitoring control can accommodate 
> configuration non-simultaneously with the signaling of the 
> path, I suggest to devise a couple of lines of thinking for 
> monitoring control (incl. configuration, activation, etc.) 
> messaging and processing: 
> 
> 		 
> 		- Monitoring control message should only be 
> processed if corresponding PSB/RSB exist (at MP) and should 
> be targeted with a sequence of MP's (can take the form of a 
> route object) so as to "skip"
> hops that are not MPs. 
> 
> [dp] Not necessarily but if kept bundled there is a need to 
> limit "impact" on signaling in the context of traffic 
> engineering. I would say if an existing "message" is re-used 
> with a different sequence of hops this would be an hybrid 
> approach. As food for thought please take a look at RFC 2745.
> 

[at] It was an interesting reading. There might be cases where an
additional way to carry info could be useful.

>  I do not think this is needed, OAM configuration, even if 
> intermediate nodes would have to be configured, is sequential 
> and follows exactly the steps of LSP setup and Path/Resv 
> processing. Exactly this is the value in binding OAM 
> configuration to LSP signaling. 
> 
> [dp] Actually, there is a tradeoff here that shall be 
> understood (between messaging, processing, timing/efficiency, 
> robustness, complexity), e.g., the overhead per LSP is 
> minimal when all "hops" are MPs and maximal only when one of 
> them needs to be "configured" (or even none). 
> 

[at] Right, if the MPs you have in mind are the MIPs, then configuring
MIPs everywhere or nowhere could be as simple as a single bit. If we
need to configure something on some of the MIPs then depending on the
amount of info message size/processing incereases.

> 	I doubt that selective intermediate node configuration 
> would be extensively used for multiple hops of an LSP; I 
> think it is more realistic to assume that only a subset of 
> LSPs will actually require intermediate node configuration 
> and even for those LSPs only a very limited number of 
> intermediate nodes will have to be configured selectively.
> 
> [dp] Is this estimation robust over time ? I mean you assume 
> that only "part" of the number of LSPs would be monitored. 
> Thus, it is the application that would "limit" the overhead 
> not the protocol design. 
> 

[at]  After a point, shooting for too much generality we could end up
with a too complex solution. I guess having an assumption on the amount
of configuration needed in general and in the case of extremes is
helpful, we could have a simple process for most of the time. 

> [dp] Shall I assume that you do not have comments on the 

[at] Those depend on the assumption of using separate signalling steps,
so we should clear this one first.

> 		Thanks,
> 	Attila
> 	
> 		 
> 
> 		- Monitoring control message should only be 
> processed by MPs whose identity can be gathered from RRO (one 
> may use the object to tag MP) but not limited to. 
> 
> 		- Monitoring control message (and objects it 
> carries) should not functionaly overlap with already defined 
> in Path/Resv and associated objects. . 
> 
> 		- To cope with "multi-AS"/"multi-area" LSP 
> (abstract nodes), the monitoring control message should be 
> able to carry a monitoring profile relayed by each AS/area. 
> 
> 		- The Path message shall make clear if the 
> actual LSP will only be activated once monitoring setup is 
> completed or not. this allows to have unmonitored LSP (that 
> may subsequently configured to be monitored).
> 
> 		- As there is a decoupling between LSP and 
> monitoring setup, if the control message is not received at 
> MP a notification should trigger the sender/head-end.
> 
> 		These are just ideas as I considered that after 
> my comment on the mike proposing a possible way forward would 
> be helpful.
> 
> 		Comments appreciated. 
> 		-dimitri. 
> 
> 
> 
> 
>