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

From: "Eric Gray" <[email-masked]>
Date: Mon, 26 Jan 2009 17:15:45 -0600

Neil,

	Please see below...

--
Eric

Neil (1st time) =>
(ii)  Do we need to be clear about whether a bidirectional congruently
      routed connection is set-up as a single paired entity or as 2
      independent entities?

      That is, there are the following possibilities that I tried to
      take into account:

      - bidirectional pair of independently set-up and independently
        routed connections
      - bidirectional pair of independently set-up but congruently
        routed connections
      - bidirectional pair of simultaneously set-up (ie considered
        as a single entity) and congruently routed connections

      (I think the 4th possibility makes no sense, ie simultaneous 
      set-up as single entity but independently routed...so have 
      excluded listing it here).

      I was effectively not including the 2nd bullet case above, ie if
      congruently routed then always assume set-up as a paired single
      entity.

Eric >>
Eric >> Assuming we want to make the implied distinction, and that
Eric >> we're only talking about bi-directional paths, the set
Eric >> should become:
Eric >> 
Eric >> - Independently Routed
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.

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.
_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: <[email-masked]>
Date: Mon, 26 Jan 2009 23:58:06 -0000

Thanks Eric....this one had me foxed for a while too...snipped right to

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

---

From: "Eric Gray" <[email-masked]>
Date: Tue, 27 Jan 2009 10:11:08 -0600

Neil,

	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.

	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?

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

regards, Neil

---

From: <[email-masked]>
Date: Tue, 27 Jan 2009 17:14:13 -0000

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

---

From: "Igor Bryskin" <[email-masked]>
Date: Tue, 27 Jan 2009 15:25:53 -0500

Neil,

I think there is a difference between verification of:
a) connection data plane health 
and
b) CP/MP and DP connection state alignment.

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. 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. (b)
on the other hand is a great tool 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 

regards, neil

---

From: <[email-masked]>
Date: Tue, 27 Jan 2009 21:43:11 -0000

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

> 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
> 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of [email-masked]
> Subject: Re: [mpls-tp] -03 of requirements draft & actions 
> still toberesolved
> 
> Thanks Eric
> > 	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
> 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.
> > 
> > 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
> > 
> > points of a layer network'.  That might also explain a point that 
> > foxed me with one of your earlier responses.
> > > 
> 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.
> > 
> accordance 
> > 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).
> > 
> > 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

---

From: Maarten Vissers <[email-masked]>
Date: Thu, 29 Jan 2009 16:57:52 +0100

Neil,

Label swapping is an important means to scale any (admin) layer network. A
technology that is unable to swap labels will never be able to become a
world-wide layer network, and will thus not be able to provide connections
between ports located anywhere in the world. Such technology is of no
interest in a transport network where at the end of the day we need to
provide world-wide connectivity.

--------

The lesson learned during the development of Ethernet OAM was that 10% of
the service contracts require pro-active monitoring and 90% do not require
pro-active monitoring. These 10% service contracts represent about 30% of
the actual service instances (connections, VPNs). 70% of the service
instances is thus not pro-active monitored.

This resulted in the requirement in Ethernet VLAN MEPs to monitor for
"unexpected CCM" frames and block traffic in such case in MEPs in which the
CCM generation was disabled. Any received CCM frame is an indication that
there is a misconnection with a MEP supporting pro-active monitoring.

It is not realistic to assume that operators will pro-active monitoring 100%
of the service instances in the channel layer. 

I assume that the path and section layer connections are 100% monitored as
those provide the infrastructure for the much, much larger number of service
instances (of which 70% is not pro-active monitored).

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: dinsdag 27 januari 2009 0:58
To: [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] -03 of requirements draft & actions still to
beresolved

point here:

> known about in the DP at the trail termination points at the ends of 
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.
> 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 
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

---

From: <[email-masked]>
Date: Thu, 29 Jan 2009 16:13:21 -0000

Maarten,

wrt your 1st point:  You assume we want to interwork non top-of-stack
networks across E-NNIs....but we don't as it's a complete waste of time.

wrt your 2nd point:  You are simply confirming what I keep trying to
tell you, eg OAM needs to be sparse/simple, the behaviours of each mode
are different (and so are their OAM requirements), we must not
overburden the network with shed loads of OAM to config (eg that TCM
would create...you'd also make it far less reliable), we can't afford to
run PM flows on all connections, etc, etc.  

Further, in the co-ps mode case you are making a very good case for
PBB-TE, because with label swapping you must run CV flows on all
connections if you want to catch the rare cases of critical traffic
leaking into non-critical traffic.....you don't have to run any CV flows
on any connections in PBB-TE to get this protection because (i) it uses
absolute DA labels that are not swapped and (ii) each traffic unit
carries its own SA (CV check).  Its also great for checking/verifying
the forwarding tables because the values stored there are invariant
across the network.

regards Neil

> From: Maarten Vissers [mailto:[email-masked]] 
> Sent: 29 January 2009 15:58
> To: Harrison,N,Neil,CXM R; [email-masked]
> Cc: [email-masked]
> Label swapping is an important means to scale any (admin) 
> layer network. A technology that is unable to swap labels 
> will never be able to become a world-wide layer network, and 
> will thus not be able to provide connections between ports 
> located anywhere in the world. Such technology is of no 
> interest in a transport network where at the end of the day 
> we need to provide world-wide connectivity.
> 
> --------
> 
> The lesson learned during the development of Ethernet OAM was 
> that 10% of the service contracts require pro-active 
> monitoring and 90% do not require pro-active monitoring. 
> These 10% service contracts represent about 30% of the actual 
> service instances (connections, VPNs). 70% of the service 
> This resulted in the requirement in Ethernet VLAN MEPs to 
> monitor for "unexpected CCM" frames and block traffic in such 
> case in MEPs in which the CCM generation was disabled. Any 
> received CCM frame is an indication that there is a 
> misconnection with a MEP supporting pro-active monitoring.
> 
> It is not realistic to assume that operators will pro-active 
> monitoring 100% of the service instances in the channel layer. 
> 
> I assume that the path and section layer connections are 100% 
> monitored as those provide the infrastructure for the much, 
> much larger number of service instances (of which 70% is not 
> pro-active monitored).
> 
> Regards,
> Maarten
>

---

From: "David Allan" <[email-masked]>
Date: Thu, 29 Jan 2009 11:19:49 -0500

Maarten:

Label swapping is simply a pairwise shorthand for higher order network
connection naming and/or addressing, a.k.a. an additional level of
indirection. I do not see that it bequeaths any special scaling
improvement over alternatives, and the existence of the internet would
tend to suggest there are alternative with superior scaling
properites...where the shorthand step is skipped and the naming or
addressing appears directly in the dataplane...IP being the obvious
example of addressing, PBB-TE being an exemplar of connection naming
appearing in the dataplane

Cheers
Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Maarten Vissers
Sent: Thursday, January 29, 2009 10:58 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] -03 of requirements draft & actions stillto
beresolved

Neil,

Label swapping is an important means to scale any (admin) layer network.
A technology that is unable to swap labels will never be able to become
a world-wide layer network, and will thus not be able to provide
connections between ports located anywhere in the world. Such technology
is of no interest in a transport network where at the end of the day we
need to provide world-wide connectivity.

--------

The lesson learned during the development of Ethernet OAM was that 10%
of the service contracts require pro-active monitoring and 90% do not
require pro-active monitoring. These 10% service contracts represent
about 30% of the actual service instances (connections, VPNs). 70% of
the service instances is thus not pro-active monitored.

This resulted in the requirement in Ethernet VLAN MEPs to monitor for
"unexpected CCM" frames and block traffic in such case in MEPs in which
the CCM generation was disabled. Any received CCM frame is an indication
that there is a misconnection with a MEP supporting pro-active
monitoring.

It is not realistic to assume that operators will pro-active monitoring
100% of the service instances in the channel layer. 

I assume that the path and section layer connections are 100% monitored
as those provide the infrastructure for the much, much larger number of
service instances (of which 70% is not pro-active monitored).

Regards,
Maarten

-----Original Message-----

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