Subject: Re: [mpls-tp] -03 of requirements draft & actions still toberesolved

From: "Igor Bryskin" <[email-masked]>
Date: Wed, 28 Jan 2009 09:34:55 -0500

Hi Neil,

As always it is great talking to you.

Please, see in-line.

Igor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, January 27, 2009 4:43 PM
To: Igor Bryskin; [email-masked]
Cc: [email-masked]
Subject: RE: [mpls-tp] -03 of requirements draft & actions still
toberesolved

Hi Igor...a while since we spoke....now this is an interesting mail,
please see in-line:

Igor Bryskin wrote 27 January 2009 20:26
> 
> Neil,
> 
> I think there is a difference between verification of:
> a) connection data plane health
> and
> b) CP/MP and DP connection state alignment.
NH=> In some respects I agree.
> 
> For one thing, CP/MP and DP states could be perfectly aligned 
> in layer network N, but data packets are dropped or reach 
> wrong destination because of impairments in layer network 
> N-1.
NH=> Interesting observation.  You are going to have to help me
understand why you say this, because this should not generally be
possible if you truly mean layer network N and layer network N-1 and
there is a transparent client/server relationship between them. Other
than in the end-system adaptation of the server layer (where we might
have traffic unit delineation/idle-fill/PID type of functions) the core
nodes of a transport network *connection* should be shifting bits of the
server layer traffic unit transparently and retaining sequence
order....in particular, the server layer (in the adaptation) must make
no assumptions about the meaning of the client layer symbols and
certainly should not change them (this is what transparency really
means).

If the server layer drops client traffic units or misdelivers them to
the wrong client (and assuming the same type of client mode/technology
(else they won't parse)) then this will be detectable in the client
layer networks affected.....and if there is some form of unintended
replication/leaking in the server layer this too ought to pick up a
problem with its own OAM.  This observation also helps reinforce why
each layer network needs its own independent OAM

If OTOH you means *sublayers*, like we have in MPLS and I expect MPLS-TP
(ie S bit issue), then yes there can be both horizontal misconnectivity
within a sublayer level and vertical misconnectivity between different
sublayer levels.  And with sublayers you can much more easily indeed get
the behaviour you note.

But your observation intrigues me Igor.  Have you some empirical
evidence of the type of defect you seem to be describing wrt some client
X and server Y...as it is not something I have come across with
traditional co-cs mode transport networks, and in the past I have done
loads of testing of these.

IB==============
IB>> Let’s consider a two-layer network (Ethernet/optical) with connections in the optical co-cs layer making up network flexibility (links) for the Ethernet co-ps layer. Let’s assume that each layer has its own OAM and is managed by a separate instance of Control Plane (the two layers may be administratively owned by separate parties). Now suppose something bad happened with one of the optical layer connections (e.g. it got mis-configured during automatic recovery from a detected failure). Yes, of course, you are right: in theory such a problem should be detected by the optical layer OAM and the client layer should be notified accordingly. But then again, in theory mis-configurations should not happen when connections are automatically provisioned via Control Plane, but they do happen, right? Anyway, let’s assume that the mis-configuration went unnoticed for whatever reason by the Ethernet layer. 

Now let’s look from the Ethernet layer network perspective. It is easy to implement a Control Plane tool, which would signal a message hop-by-hop along the connection, and on each processing node compare the connection Control Plane and Data Plane state (that is, query the Forwarding table). This tool will find nothing wrong with any of the Ethernet layer connections: forwarding tables are configured exactly as the Control Plane instructed. However, OAM will detect problems for the connections going through the effected by the optical layer mis-configuration link.

So, the points that I was trying to make are:
a) CPorMP and DP state alignment does not necessarily mean connection DP health (i.e. that the connection is actually working);
b) OAM is CP/MP independent and targets the verification of DP health, rather, than DP/CPorMP state alignment;
c) The tool to verify the DP/CPorMP alignment is a part of the CP/MP, and hence depends on the CP/MP you use.

Cheers,
Igor    

> In my opinion OAM addresses (a). It should work 
> independent from CP or MP and should continue to work the 
> same way in case of CP<=>MP connection ownership transfer.
NH=> Absolutely...this is one point I have campaigned on long and hard
on for many years....the DP OAM should be totally agnostic to whether
the CP or MP is involved, and indeed which CP signalling protocol is
used.

> (b) on the other hand is a great tool
NH=> What is a great tool?  You mean the remark I made about the ability
to look at core nodal forwarding tables if one notices some
misconnectivity problem at trail term pts?

Thanks Igor....look forward to some amplification of the problem you
noted earlier.

regards, Neil

> to have as the first 
> step in investigating problems detected by (a), but it is not 
> OAM, rather, it is an intrinsic part of CP or MP and its 
> implementation depends very much on CP or MP you use.
> 
> Cheers,
> Igor
> 
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Tuesday, January 27, 2009 12:14 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [mpls-tp] -03 of requirements draft & actions 
> still toberesolved
> 
> Thanks Eric
> who wrote 27 January 2009 16:11
> 
> >     You didn't really answer the question about whether or not you 
> > consider the operator to be part of the CP/MP, hence your response 
> > below appears to say that OAM is meant to determine that the DP is 
> > aligned with the information in the CP/MP.  With this statement it 
> > becomes essential to know whether or not you think of the 
> operator as 
> > part of the CP/MP, because - if he/she is not
> > - then this statement is rather hard to accept.
> NH=> Of course the operator can act as the exact route 
> calculating agent.....but the operator can also just specify 
> the end points and let something else work out the exact 
> route taken.  My point wrt to the OAM was something 
> different...see below.
> > 
> >     What do you think is more likely: that there will be a DP 
> > misalignment with actual configured forwarding information, or that 
> > there will be a CP/MP misalignment with the operator's DP 
> intentions?  
> > It's my understanding that advantages of OAM send and receive 
> > configuration as an independent configuration step is that it 
> > increases the likelihood of detecting a configuration error.
> > 
> >     Or am I mis-reading your apparent statement that OAM is used to 
> > verify CP/MP alignment with actual DP flows?
> NH=> The main thing we are checking with the CV OAM is that 
> the correct source is getting to the correct sink(s)...and 
> also that there are no unintended sources arriving those 
> sink(s).  Besides the obvious requirement to know when 
> something becomes broken (for whatever reason this happens) 
> another key objective here is to protect one customer's 
> traffic from leaking into another customer's traffic....one 
> can consider as a security issue.
> 
> Misconnectivity problems can occur at any time after we 
> establish the connections.  So the CP/MP has a view of what 
> it has done and the DP OAM keeps checking that this is indeed 
> working as expected...and the DP OAM will flag this as a 
> problem should a defect occur......and if needed (eg leaking 
> traffic type of defect) one can then go and look to see what 
> is actually held in the forwarding tables (and if the 
> forwarding labels are not swapped but absolute (ie real DA 
> addresses) then this ought to make figuring out what has gone 
> wrong easier).  
> 
> regards, neil
> > 
> > --
> > Eric
> > 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: Monday, January 26, 2009 6:58 PM
> > To: Eric Gray
> > Cc: [email-masked]
> > Subject: RE: [mpls-tp] -03 of requirements draft & actions still to 
> > beresolved
> > Importance: High
> > 
> > Thanks Eric....this one had me foxed for a while 
> too...snipped right 
> > to point here:
> > 
> > > Eric >> - Congruently Routed and associated at the Layer
> > Network level
> > > 
> > > NH=> Not sure what you mean by this.....are you simply
> > meaning 'only
> > > known about in the DP at the trail termination points at
> > the ends of
> > > the connection'?  The CP/MP would have to know what the 
> core nodal 
> > > routing was.
> > > 
> > > Only known about [in the DP] at the [trail] termination
> > points [at the
> > > end of the connection] is what I mean.
> > NH=> Got you...when you say 'layer network' you really mean 'access 
> > points of a layer network'.  That might also explain a point that 
> > foxed me with one of your earlier responses.
> > > 
> > > In the configuration case, whether or not the CP/MP needs to know 
> > > about the core nodal routing depends (a lot) on what you mean by 
> > > CP/MP.  For example, if only the operator knows the routing, 
> > > transforms this into a set of configuration operations 
> that will be 
> > > carried out by the MP on a node-by-node basis, and so
> > intructs the MP
> > > - then the CP/MP knows about the core routing only to the
> > extent that
> > > you consider that operator to be a component of the CP/MP.
> > NH=> I think that point is not really relevant to the issue.  
> > Route computation can be done by any entity.  But what is 
> relevant is 
> > that once the route calculation is available it is the CP/MP that 
> > configures the forwarding tables for ports in nodes, and that 
> > information is now held in the CP/MP.
> > 
> > But we still need to check that the DP really is working in 
> accordance 
> > with what we (and the CP/MP) think is held in the nodes.
> > 
> > If have a co-ps mode network based on label-swapping (like
> > MPLS-TP) we have a risk of traffic getting misdirected in 
> the DP.  And 
> > so to verify that the DP is really in alignment with the 
> information 
> > held in the CP/MP we have to run a CV OAM flow that contains the 
> > connection's SA on all connections irrespective of their 
> importance.  
> > This arises due to the need to cater for the case of 
> traffic from an 
> > important connection being unintendedly replicated and 
> leaked into a 
> > non-important connection (which we would not otherwise bother to 
> > monitor).
> > 
> > Of course, if one uses absolute addressing and does not 
> swap labels on 
> > each hop (just like the co-ps mode does, albeit here having 
> > connections) then you can avoid running OAM on all connections and 
> > then having to monitor all connections as the network will be 
> > self-protecting from leaking traffic.
> > And of course if one wants to investigate any leaking traffic (even 
> > though it can't propagate) it's now a jolly sight easier to 'look 
> > into' the nodes and check if what the fowarding tables really hold 
> > tally with what the CP/MP thinks should be in there....since labels 
> > never get changed on each hop.
> > 
> > regards, Neil
> > 
> >  
> > 
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp
> 

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

---

From: <[email-masked]>
Date: Thu, 29 Jan 2009 10:05:08 -0000

Thanks Igor for the explanation.  I think that what you suggest might
happen would only be possible if there was a lack of decent CV-like OAM
in each layer network.  If each connection sends a CV with its true
trail SA (not some locally generated arbitrary string) then we should be
OK, ie each layer can detect any misconnectivity (including unintended
replication + merging).
 
The only corner case I can think of where this might fail is where the
addressing used in 2 different client layer networks which are BOTH of
the same mode/technology  was such that a server layer misconnection
mismerges traffic from one client into the other client AND it just so
happens the SA in the CV packets is the same.  But this is such a remote
possibility it seem highly unlikely.  And even here:
-    the server should note some case of misconnectivity from it own CV
flows
-    if we have merging of good and bad traffic streams in the client
this should also be picked up as a rate of CV arrival that is twice what
is expected.....and when I wrote Y.1711 all those years ago I did try
and cater for this one in the defect cases defined therein
 
In general, provided each layer network has the right sort of CV OAM
carrying a true SA then I think we are largely OK.
 
regards, Neil

________________________________

	From: Igor Bryskin [mailto:[email-masked]] 
	Sent: 28 January 2009 14:35
	To: Igor Bryskin; Harrison,N,Neil,CXM R; [email-masked]
	Cc: [email-masked]
	Subject: RE: [mpls-tp] -03 of requirements draft & actions still
toberesolved

	Hi Neil,

	Please, see in-line.
	
	Igor

	-----Original Message-----
	From: [email-masked] [mailto:[email-masked]]
	Sent: Tuesday, January 27, 2009 4:43 PM
	To: Igor Bryskin; [email-masked]
	Cc: [email-masked]
	Subject: RE: [mpls-tp] -03 of requirements draft & actions still
	toberesolved
	
	Hi Igor...a while since we spoke....now this is an interesting
mail,
	please see in-line:
	
	NH=> Interesting observation.  You are going to have to help me
	understand why you say this, because this should not generally
be
	possible if you truly mean layer network N and layer network N-1
and
	there is a transparent client/server relationship between them.
Other
	than in the end-system adaptation of the server layer (where we
might
	have traffic unit delineation/idle-fill/PID type of functions)
the core
	nodes of a transport network *connection* should be shifting
bits of the
	server layer traffic unit transparently and retaining sequence
	order....in particular, the server layer (in the adaptation)
must make
	no assumptions about the meaning of the client layer symbols and
	certainly should not change them (this is what transparency
really
	means).
	
	If the server layer drops client traffic units or misdelivers
them to
	the wrong client (and assuming the same type of client
mode/technology
	(else they won't parse)) then this will be detectable in the
client
	layer networks affected.....and if there is some form of
unintended
	replication/leaking in the server layer this too ought to pick
up a
	problem with its own OAM.  This observation also helps reinforce
why
	each layer network needs its own independent OAM
	
	If OTOH you means *sublayers*, like we have in MPLS and I expect
MPLS-TP
	(ie S bit issue), then yes there can be both horizontal
misconnectivity
	within a sublayer level and vertical misconnectivity between
different
	sublayer levels.  And with sublayers you can much more easily
indeed get
	the behaviour you note.
	
	But your observation intrigues me Igor.  Have you some empirical
	evidence of the type of defect you seem to be describing wrt
some client
	X and server Y...as it is not something I have come across with
	traditional co-cs mode transport networks, and in the past I
have done
	loads of testing of these.
	
	IB==============
	IB>> Let's consider a two-layer network (Ethernet/optical) with
connections in the optical co-cs layer making up network flexibility
(links) for the Ethernet co-ps layer. Let's assume that each layer has
its own OAM and is managed by a separate instance of Control Plane (the
two layers may be administratively owned by separate parties). Now
suppose something bad happened with one of the optical layer connections
(e.g. it got mis-configured during automatic recovery from a detected
failure). Yes, of course, you are right: in theory such a problem should
be detected by the optical layer OAM and the client layer should be
notified accordingly. But then again, in theory mis-configurations
should not happen when connections are automatically provisioned via
Control Plane, but they do happen, right? Anyway, let's assume that the
mis-configuration went unnoticed for whatever reason by the Ethernet
layer.
	
	Now let's look from the Ethernet layer network perspective. It
is easy to implement a Control Plane tool, which would signal a message
hop-by-hop along the connection, and on each processing node compare the
connection Control Plane and Data Plane state (that is, query the
Forwarding table). This tool will find nothing wrong with any of the
Ethernet layer connections: forwarding tables are configured exactly as
the Control Plane instructed. However, OAM will detect problems for the
connections going through the effected by the optical layer
mis-configuration link.
	
	So, the points that I was trying to make are:
	a) CPorMP and DP state alignment does not necessarily mean
connection DP health (i.e. that the connection is actually working);
	b) OAM is CP/MP independent and targets the verification of DP
health, rather, than DP/CPorMP state alignment;
	c) The tool to verify the DP/CPorMP alignment is a part of the
CP/MP, and hence depends on the CP/MP you use.
	
	Cheers,
	Igor   
	
	> same way in case of CP<=>MP connection ownership transfer.
	NH=> Absolutely...this is one point I have campaigned on long
and hard
	on for many years....the DP OAM should be totally agnostic to
whether
	the CP or MP is involved, and indeed which CP signalling
protocol is
	used.

	> (b) on the other hand is a great tool
	NH=> What is a great tool?  You mean the remark I made about the
ability
	to look at core nodal forwarding tables if one notices some
	misconnectivity problem at trail term pts?
	
	Thanks Igor....look forward to some amplification of the problem
you
	noted earlier.
	
	regards, Neil