Subject: Re: [mpls-tp] Draft-asm-mpls-tp-bfd-cc-cv-04

From: <[email-masked]>
Date: Fri, 14 May 2010 09:15:54 +0100

Argggh....hit with the message size issue again...re-sending snipped, my
apologies.

________________________________

	From: Harrison,N,Neil,DKQ7 R 
	Sent: 14 May 2010 09:13
	To: 'David Allan I'; [email-masked]
	Cc: [email-masked]
	Subject: RE: [mpls-tp] Draft-asm-mpls-tp-bfd-cc-cv-04

	Thanks Dave, sorry to have to come back to you on this but I did
not find this response very helpful and certainly not technically
persuasive.  Having read the document now I am a little shocked at the
poor sentence construction and technical errors I find therein...has
anyone who has put their name to this actually read it (even the
abstract, which has both types of error)?
	 
	I cannot support this draft, its just so poor at a deeper
architectural level......a few more remarks in-line:

________________________________

		From: David Allan I [mailto:[email-masked]] 
		Sent: 13 May 2010 17:00
		To: Harrison,N,Neil,DKQ7 R; [email-masked]
		Cc: [email-masked]
		Subject: RE: [mpls-tp] Draft-asm-mpls-tp-bfd-cc-cv-04

		HI Neil:
		 
		We shouldn't confuse the role of the discriminator and
authoritative identification of source/path binding required by CV... 
		NH=> Meaning what exactly? 
		 
		The discriminator allows a generalized implentation
(that works for IP, MPLS, MPLS_TP etc.) to quickly and simply map
session state after which more authoritative identification of source
becomes possible. 
		 
		NH=> Having read the 'MPLS-TP identifiers' draft one can
see just what a mess addressing has become in MPLS in general.  The
addressing structure of the quite unnecessary PW layer network leaves
one amazed at just how bad/wrong one can get things.
		 
		I am not getting this idea of 'session' in a tramnsport
network.  The term 'session' (ie linked to an external file/stream
application driving TOS network holding behaviour) and 'transport
network' (which is NOT a TOS network, MPLS-TP is like this) do not gel
at all IMO (major understatement).  
		 
		My reading is more like this: "the discriminator allows
vendors to reuse what they have already created for BFD, even if this is
wrong/poor for the network mode and use-case considered"...noting that
we need different OAM approaches in each of the 3 modes. 
		 
		As I noted earlier...we should be using a CV OAM message
on co-ps mode networks that is created/removed at the trail termination
points of *this* layer network (ie it does not need IP layer network
header as it has nothing to do with any IP layer network)  and uses the
right SA information relevent to *this* co-ps mode layer network.  Which
is why I find the draft on MPLS-TP identifiers not only totally
unhelpful but also N/A as we don't even use them anyway in an OAM CV
context!...all this identifiers draft shows is what a mess/hotchpotch we
have made of addressing in this whole area.  The authors, however,
should be congratulated on having the nerve to publish this expose on
the mess that is MPLS-TP addressing.

		  Failing to successfully map state in the first place
could be considered to be a pre-screening step. 
		 
		NH=> This misses me entirely for a properly designed
co-ps mode layer network....the point here is what exactly?
		 
		The CP/MP in a co-cs or co-ps mode layer network
sets-up/tears-down a connection AND  activates/deactivates the DP OAM
(between trail termination points in this layer network)...so why do we
need some 'pre-screening' (whatever this means) step?  'Session' implies
TOS external application driven..session is thus not a relevant term IMO
to a transparent network-builder transport service.
		 
		BFD for IP/MPLS had an IP header 
		NH=> So what?  Not only is this cross layer design but
it is quite irrelevant IMO....we are not dealing with OAM in a cl-ps IP
layer network here.
		 
		 , hence a more authoritative identification that this
was not a mis-connected session was possible than is currently possible
with CC under a GAL/GACH by itself, however in the presence of MP2P and
PHP it could not be absolutely authoritative. 
		NH=>The reason mp2p LDP and PHP have to go in MPLS-TP is
they are totally at odds with providing operators with a means to
control resource usage...which is a fairly fundamental requirement of a
transport network!  So this is a red-herring issue IMO. 
		 
		In the MPLS-TP case it can be. Given the presence of a
source TLV and a labelled last hop sufficient infomation exists in both
DP operation and PDU design to do this.  
		NH=> So...to summarise....we are still trying to
re-use/make BFD fit the bill in MPLS-TP even though it is technically
flawed ....but perhaps the punch line should really be 'who cares as
MPLS-TP is not a transport network anyway..its just yet another spin of
MPLS'.  Come on guys...how can anyone take MPLS-TP seriously as a
transport network when it has sublayering and (even more impressively
daft) MS PWs?
		 
		That is what we are documenting in draft-asm... 
		 
		NH=>Hmmm....'never mind the quality feel the width'
comes to mind.......I suppose it keeps one busy though ;-)
		 
		hope this helps 
		 
		NH=> I really wish it did Dave...why do I get the
impression your technical heart is not in this.   I find the whole
MPLS-TP situation increasingly embarassing as we are trying to duck
really important technical issues IMO. 
		 
		regards, Neil
		D
		 <NH snipped>

---

From: David Allan I <[email-masked]>
Date: Fri, 14 May 2010 10:00:10 -0400

HI Neil:
Thanks Dave, sorry to have to come back to you on this but I did not find this response very helpful and certainly not technically persuasive.  Having read the document now I am a little shocked at the poor sentence construction and technical errors I find therein...has anyone who has put their name to this actually read it (even the abstract, which has both types of error)?

It is a work in progress... we'll be stirving to improve it.
I cannot support this draft, its just so poor at a deeper architectural level......a few more remarks in-line:

HI Neil:

We shouldn't confuse the role of the discriminator and authoritative identification of source/path binding required by CV...
NH=> Meaning what exactly?
providing authoritative identification of source is not the function of the discriminator.

The discriminator allows a generalized implentation (that works for IP, MPLS, MPLS_TP etc.) to quickly and simply map session state after which more authoritative identification of source becomes possible.

NH=> Having read the 'MPLS-TP identifiers' draft one can see just what a mess addressing has become in MPLS in general.  The addressing structure of the quite unnecessary PW layer network leaves one amazed at just how bad/wrong one can get things.
That is outside the scope of draft ASM.

I am not getting this idea of 'session' in a tramnsport network.  The term 'session' (ie linked to an external file/stream application driving TOS network holding behaviour) and 'transport network' (which is NOT a TOS network, MPLS-TP is like this) do not gel at all IMO (major understatement).
It is the terminology of the incumbent protocol: BFD, IMO we'd be wise not to reinvent it, else we'd create intepretation problems.

My reading is more like this: "the discriminator allows vendors to reuse what they have already created for BFD, even if this is wrong/poor for the network mode and use-case considered"...noting that we need different OAM approaches in each of the 3 modes.
In a greenfield scenario, I'd agree. This is not. There is 10 years of deployed kit out there and a design mandate to reuse IETF tools where possible.

As I noted earlier...we should be using a CV OAM message on co-ps mode networks that is created/removed at the trail termination points of *this* layer network (ie it does not need IP layer network header as it has nothing to do with any IP layer network)  and uses the right SA information relevent to *this* co-ps mode layer network.  Which is why I find the draft on MPLS-TP identifiers not only totally unhelpful but also N/A as we don't even use them anyway in an OAM CV context!...all this identifiers draft shows is what a mess/hotchpotch we have made of addressing in this whole area.  The authors, however, should be congratulated on having the nerve to publish this expose on the mess that is MPLS-TP addressing
If you don't mind, I'll ignore that for now...

  Failing to successfully map state in the first place could be considered to be a pre-screening step.

NH=> This misses me entirely for a properly designed co-ps mode layer network....the point here is what exactly?
BFD was designed to be a generalized heartbeat and as such can be applied across the MPLS architecture, not just TP, and as such does not/cannot explicitly index state via inheritance from the dataplane in all circumstances. Hence it does it in a self contained manner, and then goes on from there. You and I seem to have different design objectives here.

The CP/MP in a co-cs or co-ps mode layer network sets-up/tears-down a connection AND  activates/deactivates the DP OAM (between trail termination points in this layer network)...so why do we need some 'pre-screening' (whatever this means) step?  'Session' implies TOS external application driven..session is thus not a relevant term IMO to a transparent network-builder transport service.
Pre-screening was simply explanatory text. Getting a BFD discrminator that had no state associated with it, would be analogous to receiving a labelled packet with no ILM for the label. A pretty broad hint that somthing was wrong.

BFD for IP/MPLS had an IP header
NH=> So what?  Not only is this cross layer design but it is quite irrelevant IMO....we are not dealing with OAM in a cl-ps IP layer network here.
I was trying to draw the distinction between previous usage where knowledge of source was part of the design but not embodied exclusively in the discriminator, which seems to be a source of confusion in this thread.

 , hence a more authoritative identification that this was not a mis-connected session was possible than is currently possible with CC under a GAL/GACH by itself, however in the presence of MP2P and PHP it could not be absolutely authoritative.
NH=>The reason mp2p LDP and PHP have to go in MPLS-TP is they are totally at odds with providing operators with a means to control resource usage...which is a fairly fundamental requirement of a transport network!  So this is a red-herring issue IMO.
It wasn't actually an issue, more just background to the discussion...

In the MPLS-TP case it can be. Given the presence of a source TLV and a labelled last hop sufficient infomation exists in both DP operation and PDU design to do this.
NH=> So...to summarise....we are still trying to re-use/make BFD fit the bill in MPLS-TP even though it is technically flawed ....but perhaps the punch line should really be 'who cares as MPLS-TP is not a transport network anyway..its just yet another spin of MPLS'.  Come on guys...how can anyone take MPLS-TP seriously as a transport network when it has sublayering and (even more impressively daft) MS PWs?
I do not see that it is any more flawed than any other solution. BFD's design features that assist scalable implementation and allow the tool to be widely deployed across the entire MPLS architecture IMO are actually positives... and I'm not aware of anything else on the table that can make that claim...

NH=>Hmmm....'never mind the quality feel the width' comes to mind.......I suppose it keeps one busy though ;-)
Like I think  I've indicated, we seem to have different design objectives/criteria of goodness...

hope this helps

NH=> I really wish it did Dave...why do I get the impression your technical heart is not in this.   I find the whole MPLS-TP situation increasingly embarassing as we are trying to duck really important technical issues IMO.
Hopefully the dialog above clairifies a few points...

best
D