Subject: Re: [mpls-tp] Concerns Re: pollon makingdraft-asm-mpls-tp-bfd-cc-cv an mpls working group document

From: <[email-masked]>
Date: Thu, 20 May 2010 08:33:48 +0100

Re-sending snipped....too big message received.

________________________________

	From: Harrison,N,Neil,DKQ7 R 
	Sent: 20 May 2010 08:05
	To: 'David Allan I'; 'Yang Yang'; 'Sprecher, Nurit (NSN -
IL/HodHaSharon)'
	Cc: [email-masked]'; [email-masked]'
	Subject: RE: [mpls-tp] Concerns Re: pollon
makingdraft-asm-mpls-tp-bfd-cc-cv an mpls working group document

	Dave is dead right...we want very simple/sparse OAM that is
'always-on' and used for defect detection/handling.  We can have more
complex OAM for 'on-demand' diagnostics.  Why?
	 
	1   We want the defect detection OAM to be massively scalable
and uber reliable.  So we want the absolute min of config, including
changes across failure/restore events - one more reason why I am against
lots of a priori configured TCM levels.  We also should not provide OAM
functions here that are not necessary...FDI/AIS is like this.  Note -
The 3 network modes are different....one size OAM does not fit
all....AIS is a must have in the co-cs mode, a total non-requirement in
the cl-ps mode and adds no useful information in the co-ps mode (its
just a source of unreliability and a scalability problem).
	 
	2    We expect the 'on-demand' OAM to be used quite rarely...if
it isn't, then the base network technology or the network
design/planning-cycle is broken  (this is also why QoS must be
essentially a non-issue in a well designed co-ps mode network...and
especially so in one that purports to provide a *transparent* 'network
builder' transport function).  The best on-demand diagnostics OAM there
is IMO is a passive tap off of an end-end CV (or PM) flow.
	 
	Having said all that.....the OAM should draw from the same
format and in the co-ps mode it should:
	-    be unidirectional (I trust everyone has understood why, ie
due to a connection being a constraining single source construct under
defect-free conditions)....however, due to its cl-ps mode origins BFD
was of a request/response nature which is not what is required for the
key co-ps mode OAM functions
	-    be generated/terminated at trail termination points of
co-ps mode connections...BFD isn't...one can almost regard it as an
'external message application' that comes down through client adaptation
	-    have the identical header to a normal traffic unit....it
does not in MPLS-TP, the OAM sits under an additional labelled header
that should only be used for OOB CP/MP protocols ....this is just plain
bad design folks
	-    the CV function must carry an absolute SA of the
connection....BFD does not (because of its cl-ps origins since the
traffic unit itself carries the absolute SA here!)..and IMO this is
effectively a showstopper right now, and for an even greater reason that
I am still awaiting some sort of answer, ie we have no clarity IMO of
what a SA is for an MPLS-TP connection is, and we need to understand how
to differentiate (i) sublayering (ie classical LSP nesting that is
actually NOT required in a transport network) where the nested LSPs draw
from the *same* access point addressing pool and (ii) proper
client/server layering where the nested LSPs draw from *different*
access point addressing pools.
	 
	I actually cannot see how this topic can be sensibly progressed
until the last point I raise above is resolved....even if we ignore all
the others.
	 
	regards, Neil

________________________________

		From: [email-masked]
[mailto:[email-masked]] On Behalf Of David Allan I
		Sent: 19 May 2010 22:44
		To: Yang Yang; Sprecher, Nurit (NSN - IL/HodHaSharon)
		Cc: [email-masked]; [email-masked]
		Subject: Re: [mpls-tp] Concerns Re: pollon
makingdraft-asm-mpls-tp-bfd-cc-cv an mpls working group document

		HI Yang:
		 
		What constitutes one tool is in the eye of the
beholder....Somthing that does everything all the time is implied by
that statement, which IMO is not useful or desirable.
		 
		I look to BFD as a proactive tool, therefore I'd expect
the design to be optimized accordingly. On demand tools have different
scaling and functional requirements, hence again I'd want them designed
accordingly...
		 
		"Horses for courses..." as they say...I would not want
BFD extended to the point where scaling was inappropriately compromised
simply to meet what I consider to be an artificial requirement...
		 
		cheers
		D

NH=> Snipped

---

From: John E Drake <[email-masked]>
Date: Thu, 20 May 2010 10:34:11 -0700

Neil,

I have some comments inline.  I snipped those comments of yours which have no relevance to the discussion of the subject I-D.

Thanks,

John

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of [email-masked]
> Sent: Thursday, May 20, 2010 12:34 AM
> To: [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: [mpls-tp] Concerns Re: pollon makingdraft-asm-mpls-tp-bfd-cc-
> cv an mpls working group document
> 
> 

JD:  I really think you should read the BFD spec before characterizing it incorrectly.  The steady state operation is effectively two unidirectional streams at possibly different rates.

> 'external message application' that comes down through client adaptation

JD:  This is also incorrect.

> I am still awaiting some sort of answer,

JD:  The identifier is the MEP ID of the sending MEP.