Subject: Re: [PWE3] [mpls-tp] poll on draft-he-mpls-tp-csf-03.txt

From: Yuanlong Jiang <[email-masked]>
Date: Wed, 01 Dec 2010 17:06:36 +0800

Support.

I believe this mechanism is needed in MPLS-TP.

Thanks
Yuanlong

----- Original Message ----- 
From: "Loa Andersson" <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>; "MPLS-TP ad hoc 
team" <[email-masked]>
Sent: Thursday, November 18, 2010 7:56 PM
Subject: [mpls-tp] poll on draft-he-mpls-tp-csf-03.txt

> all,
>
> this is to start a two week poll on making
>
> http://www.ietf.org/internet-drafts/draft-he-mpls-tp-csf-03.txt
>
> a mpls working group document.
>
> Please send comments support/not support to the mpls-tp maililng list.
>
> The poll ends Thursday Dec 2, 2010.
>
> /Loa
> -- 
>
>
> Loa Andersson                         email: [email-masked]
> Sr Strategy and Standards Manager            [email-masked]
> Ericsson Inc                          phone: +46 10 717 52 13
>                                              +46 767 72 92 13
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: zhanghaiyan <[email-masked]>
Date: Wed, 01 Dec 2010 09:35:19 +0000

Yes, support.

B.R.
Haiyan

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 Loa Andersson
发送时间: 2010年11月18日 19:56
收件人: [email-masked]; [email-masked]; [email-masked]; MPLS-TP ad hoc team
主题: [mpls-tp] poll on draft-he-mpls-tp-csf-03.txt

all,

/Loa
-- 

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

---

From: John E Drake <[email-masked]>
Date: Wed, 1 Dec 2010 04:34:53 -0800

I am not convinced.  It seems like it belongs in the Pseudo Wire application, which already has this capability.

Sent from my iPhone

> -----Original Message-----
> From: Yuanlong Jiang [mailto:[email-masked]]
> Sent: Wednesday, December 01, 2010 1:07 AM
> To: Loa Andersson; [email-masked]; [email-masked]; [email-masked];
> MPLS-TP ad hoc team
> Subject: [AHMPLS-TP] Re: [mpls-tp] poll on draft-he-mpls-tp-csf-03.txt
> 
> Support.
>

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 1 Dec 2010 13:46:54 +0100

But what about other client services... e.g. adapted by service-LSP and
not by PWE3?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
ext John E Drake
Sent: Wednesday, December 01, 2010 2:35 PM
To: Yuanlong Jiang; Loa Andersson; [email-masked]; [email-masked];
[email-masked]; MPLS-TP ad hoc team
Subject: Re: [PWE3] [AHMPLS-TP] Re: [mpls-tp] poll
ondraft-he-mpls-tp-csf-03.txt

I am not convinced.  It seems like it belongs in the Pseudo Wire
application, which already has this capability.

Sent from my iPhone

---

From: John E Drake <[email-masked]>
Date: Wed, 1 Dec 2010 05:29:43 -0800

Nurit,

As I understand the original requirement from Malcolm Betts, this capability is required for those cases in which a client is unable to detect the failure of its peer.  In MPLS-TP, we have three clients, PW, IP, and MPLS, and I am quite sure that IP and MPLS clients can take care of themselves wrt detecting peer failure.

Thanks,

John

Sent from my iPhone

> From: Sprecher, Nurit (NSN - IL/Hod HaSharon)
> [mailto:[email-masked]]
> Sent: Wednesday, December 01, 2010 4:47 AM
> To: John E Drake; Yuanlong Jiang; Loa Andersson; [email-masked]; mpls-
> [email-masked]; [email-masked]; MPLS-TP ad hoc team
> Subject: RE: [PWE3] [AHMPLS-TP] Re: [mpls-tp] poll ondraft-he-mpls-tp-
> csf-03.txt
>

---

From: Vivien Sterling <[email-masked]>
Date: Thu, 2 Dec 2010 08:21:18 +0800

Yes, support.

-- 
Cheers,
Vivien

---

From: Yuanlong Jiang <[email-masked]>
Date: Thu, 02 Dec 2010 09:00:27 +0800

John,

PW service is not the sole application of MPLS-TP.
Therefore a more general mechanism applicable to other service is useful.

Regards
Yuanlong

----- Original Message ----- 
From: "John E Drake" <[email-masked]>
To: "Yuanlong Jiang" <[email-masked]>; "Loa Andersson" <[email-masked]>; 
<[email-masked]>; <[email-masked]>; <[email-masked]>; "MPLS-TP ad hoc team" 
<[email-masked]>
Sent: Wednesday, December 01, 2010 8:34 PM
Subject: RE: [AHMPLS-TP] Re: [mpls-tp] poll on draft-he-mpls-tp-csf-03.txt

Sent from my iPhone

---

From: Yuanlong Jiang <[email-masked]>
Date: Thu, 02 Dec 2010 09:18:59 +0800

John,

Typically, IP will only detect a failure in a time scale of minutes.
That is one reason why MPLS-TP OAM and Protection & Switching is needed.
I am not sure which mechanism in MPLS provides the CSF-like capability, 
could you give more hints?

Thanks
Yuanlong

----- Original Message ----- 
From: "John E Drake" <[email-masked]>
To: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>; 
"Yuanlong Jiang" <[email-masked]>; "Loa Andersson" <[email-masked]>; 
<[email-masked]>; <[email-masked]>; <[email-masked]>; "MPLS-TP ad hoc team" 
<[email-masked]>
Sent: Wednesday, December 01, 2010 9:29 PM
Subject: RE: [PWE3] [AHMPLS-TP] Re: [mpls-tp] poll 
ondraft-he-mpls-tp-csf-03.txt

> Nurit,
>
> As I understand the original requirement from Malcolm Betts, this 
> capability is required for those cases in which a client is unable to 
> detect the failure of its peer.  In MPLS-TP, we have three clients, PW, 
> IP, and MPLS, and I am quite sure that IP and MPLS clients can take care 
> of themselves wrt detecting peer failure.
>
> Thanks,
>
> John
>
> Sent from my iPhone
>

---

From: Yuanlong Jiang <[email-masked]>
Date: Thu, 02 Dec 2010 13:04:36 +0800

Eric,

Please see my comments inline.

Thanks
Yuanlong

----- Original Message ----- 
From: "Eric Osborne (eosborne)" <[email-masked]>
To: "Yuanlong Jiang" <[email-masked]>; "John E Drake" 
<[email-masked]>; "Sprecher, Nurit (NSN - IL/Hod HaSharon)" 
<[email-masked]>; "Loa Andersson" <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>; "MPLS-TP ad hoc team" 
<[email-masked]>
Sent: Thursday, December 02, 2010 9:34 AM
Subject: RE: [mpls] [PWE3] [AHMPLS-TP] Re: [mpls-tp] 
pollondraft-he-mpls-tp-csf-03.txt

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Yuanlong Jiang
> Sent: Wednesday, December 01, 2010 8:19 PM
> To: John E Drake; Sprecher, Nurit (NSN - IL/Hod HaSharon); Loa
Andersson;
> [email-masked]; [email-masked]; [email-masked]; MPLS-TP ad hoc team
> Subject: Re: [mpls] [PWE3] [AHMPLS-TP] Re: [mpls-tp]
pollondraft-he-mpls-
> tp-csf-03.txt

I must not understand the point you're making.  For one thing, BFD is
quite often configured to detect failures in significantly less than a
minute.
[JYL] The question is: Can we assume BFD is universally deployed for IP and 
PW?
If the answer is yes, then CSF is not needed, even for the PW application.

> That is one reason why MPLS-TP OAM and Protection & Switching is
needed.

What are others?
[JYL] Maybe you'd better refer to RFC 5654 for a comprehensive reqs :)

> could you give more hints?

Even regular IGP/LDP hellos (no special tuning, no BFD) very frequently
are configured to detect failures in far less than "minutes".
[JYL] Not sure this can be used to indicate the failure of  IP service.
Even so, do we need to firstly determine what protocol is carried and then 
decide which mechanism could be used?

eric

> Subject: RE: [PWE3] [AHMPLS-TP] Re: [mpls-tp] poll
ondraft-he-mpls-tp-csf-
> 03.txt
> > detect the failure of its peer.  In MPLS-TP, we have three clients,
> > PW, IP, and MPLS, and I am quite sure that IP and MPLS clients can
> > take care of themselves wrt detecting peer failure.
> >
> > Thanks,
> >
> > John
> >
> > Sent from my iPhone
> >
> >> ondraft-he-mpls-tp- csf-03.txt
> >>
> >> But what about other client services... e.g. adapted by service-LSP
> >> and not by PWE3?
> >>
> >> From: [email-masked] [mailto:[email-masked]] On
Behalf
> >> Of ext John E Drake
> >> > To: <[email-masked]>; <[email-masked]>; <[email-masked]>;
"MPLS-TP
> >> > ad hoc team" <[email-masked]>
> >> > > Please send comments support/not support to the mpls-tp
maililng
> >> > list.
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: <[email-masked]>
Date: Thu, 2 Dec 2010 08:07:27 +0000

Eric...you are correct.  The key point you are making is that it is the OAM mechanisms in the *IP layer network* that act totally independent of whatever server layer is used to create each of the link connections in the IP layer.  We must stop functionally coupling different layer networks...it is just plain wrong as I explained further in my post this morning (GMT).

regards, neil 

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Eric Osborne (eosborne)
> Sent: 02 December 2010 01:34
> To: Yuanlong Jiang; John E Drake; Sprecher, Nurit (NSN - 
> IL/Hod HaSharon); Loa Andersson; [email-masked]; 
> [email-masked]; [email-masked]; MPLS-TP ad hoc team
> I must not understand the point you're making.  For one 
> thing, BFD is quite often configured to detect failures in 
> significantly less than a minute.
> 
> Even regular IGP/LDP hellos (no special tuning, no BFD) very 
> frequently are configured to detect failures in far less than 
> "minutes".
> 
> 
> 
> 
> 
> eric
> 
> > 
> > Thanks
> > Yuanlong
> > 
> > <[email-masked]>; <[email-masked]>; <[email-masked]>; 
> "MPLS-TP ad hoc 
> > team"
> > >> > Subject: [AHMPLS-TP] Re: [mpls-tp] poll on 
> draft-he-mpls-tp-csf-
> > >> 03.txt
> > >> >
> > >> > Support.
> > >> >
> > >> > >                                              +46 767 
> 72 92 13

---

From: <[email-masked]>
Date: Thu, 2 Dec 2010 08:25:19 +0000

As a general observation, it is  not sensible to try and operate an efficient cl-ps mode network at scale without a distributed directed routing function...so practically the point below is specious.

In principle however, there is no reason why adjacent IP nodes (in their layer network topology) could not have DP OAM hellos operating that are not associated with any specific CP/MP function/protocol.

However, all this is missing the key point...and that is we should not have functional coupling between different layer networks (in any DP/CP/MP component sense) as each layer must look after itself.  If it can't then either (i) fix the deficient layer network technology or (ii) live with it....what we should not be doing is screwing-up some other layer network.

regards, Neil

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of LEVRAU, LIEVEN (LIEVEN)
> Sent: 02 December 2010 06:49
> Subject: Re: [mpls-tp] [PWE3] [AHMPLS-TP] Re: poll 
> Nope - ip can detect it via BFD on scale way below minutes.
> What you are refereeing to is the IGP control plane time out.
> The issue is to detect failures accurately and fast in the 
> data plane when there is no control plane.
> ./
> Lieven
> 
> Behalf Of Yuanlong Jiang
> Sent: 02 December 2010 02:19
> To: John E Drake; Sprecher, Nurit (NSN - IL/Hod HaSharon); 
> Loa Andersson; [email-masked]; [email-masked]; 
> I am not sure which mechanism in MPLS provides the CSF-like 
> capability, could you give more hints?
> 
> Thanks
> Yuanlong
> 
> To: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" 
> <[email-masked]>; "Yuanlong Jiang" 
> <[email-masked]>; "Loa Andersson" <[email-masked]>; 
> "MPLS-TP ad hoc team" 
> >> From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> >> Of ext John E Drake
> >> > To: <[email-masked]>; <[email-masked]>; 
> <[email-masked]>; "MPLS-TP 
> >> > > Please send comments support/not support to the 
> mpls-tp maililng
> >> > list.
> >> > >

---

From: <[email-masked]>
Date: Thu, 2 Dec 2010 19:57:00 +0900

Yes, support.

Best Regards,
Hideki ENDO

---

From: John E Drake <[email-masked]>
Date: Thu, 2 Dec 2010 04:21:52 -0800

I have no idea where you got that impression, but if your equipment operates at those time scales, god bless you.

Sent from my iPhone

> Sent: Wednesday, December 01, 2010 5:19 PM
> Andersson; [email-masked]; [email-masked]; [email-masked]; MPLS-TP ad
> hoc team
> Subject: Re: [PWE3] [AHMPLS-TP] Re: [mpls-tp] poll ondraft-he-mpls-tp-
> csf-03.txt
> 
> John,
> 
> PW,
> and
> >> > To: <[email-masked]>; <[email-masked]>; <[email-masked]>; "MPLS-TP
> ad
> >> > hoc

---

From: John E Drake <[email-masked]>
Date: Thu, 2 Dec 2010 04:23:23 -0800

Please read my other emails on this topic

Sent from my iPhone

> Sent: Wednesday, December 01, 2010 5:00 PM
> To: John E Drake; Loa Andersson; [email-masked]; [email-masked];
> Subject: Re: [AHMPLS-TP] Re: [mpls-tp] poll on draft-he-mpls-tp-csf-
> 03.txt
> 
> John,
>

---

From: Thomas Nadeau <[email-masked]>
Date: Thu, 2 Dec 2010 07:59:42 -0500

Hi,

> Typically, IP will only detect a failure in a time scale of minutes.

	That is not really true. Have you heard of BFD or LSP ping?
The typical configurations of those tools is much faster than on
the order of minutes.  It is also typical to configure regular IGP
timers to run faster than that. In typical networks convergence times
are still sometimes on the order of minutes, but there are a number
of best practices for tuning timers and other configuration options
that optimize this down to sub-minute times now too.

> That is one reason why MPLS-TP OAM and Protection & Switching is needed.

	I would argue that based on the argument above, there is no
need for special protection switching mechanisms for MPLS-TP, and that
instead, we should be looking closely at reusing/optimizing those
that exist already first.  Again, based on the argument above, it 
would seem that the existing mechanisms are sufficient.

	--Tom

> I am not sure which mechanism in MPLS provides the CSF-like capability, could you give more hints?
> 
> Thanks
> Yuanlong
> 
> ----- Original Message ----- From: "John E Drake" <[email-masked]>
> To: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>; "Yuanlong Jiang" <[email-masked]>; "Loa Andersson" <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>; "MPLS-TP ad hoc team" <[email-masked]>
> Subject: RE: [PWE3] [AHMPLS-TP] Re: [mpls-tp] poll ondraft-he-mpls-tp-csf-03.txt
> 
> 
>> Nurit,
>>

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Thu, 2 Dec 2010 08:14:16 -0500

Are we ignoring the existence of BFD altogether?

Cheers,
Rajiv

Sent from my Phone

---

From: <[email-masked]>
Date: Thu, 2 Dec 2010 13:27:55 +0000

"something happened, notify everybody who might want to know" 

How do you (the server layer) know who wants to know and how do you address them?
I made this point some considerable time ago in relation to AIS.

Andy

Andy Reid
Chief Network Services Strategist
BT Innovate
                                                                                          
Office:	+44 (0)20 8726 3075
Mobile:	+44 (0)7917 025451
Fax :       +44 (0)1277 324015
Email:	[email-masked]
WWW:	http://www.bt.com/

This email contains BT information, which may be privileged or confidential.
It's meant only for the individual(s) or entity named above. If you're not the intended
recipient, note that disclosing, copying, distributing or using this information
is prohibited. If you've received this email in error, please let me know immediately
on the email address above. Thank you.
We monitor our email system, and may record your emails.

British Telecommunications plc
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no: 1800000

---

From: John E Drake <[email-masked]>
Date: Thu, 2 Dec 2010 05:45:00 -0800

That statement is incorrect.  MPLS-TP uses BFD for CC/CV/RDI (http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/)

Sent from my iPhone

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> LEVRAU, LIEVEN (LIEVEN)
> Sent: Thursday, December 02, 2010 5:17 AM
> To: Rajiv Asati (rajiva); Yuanlong Jiang
> Cc: [email-masked]; Sprecher, Nurit (NSN - IL/Hod HaSharon); MPLS-TP ad
> hoc team; [email-masked]; [email-masked]
> Subject: Re: [mpls] [PWE3] [AHMPLS-TP] Re: [mpls-tp] pollondraft-he-
> mpls-tp-csf-03.txt
> 
> provocative statement alert- We should as we are talking about MPLS-TP
> and not about IP network layer.
> 
> ./
> Lieven
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Rajiv Asati (rajiva)
> Sent: 02 December 2010 14:14
> To: Yuanlong Jiang
> Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon); MPLS-TP ad hoc team;
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [mpls] [PWE3] [AHMPLS-TP] Re: [mpls-tp] pollondraft-he-
> mpls-tp-csf-03.txt
> 
> <[email-masked]>; "Yuanlong Jiang" <[email-masked]>; "Loa
> Andersson" <[email-masked]>; <[email-masked]>; <[email-masked]>;
> <[email-masked]>; "MPLS-TP ad hoc team" <[email-masked]>
> IP, and MPLS, and I am quite sure that IP and MPLS clients can take
> care of themselves wrt detecting peer failure.
> >>
> >> Thanks,
> >>
> >> John
> >>
> >> Sent from my iPhone
> >>
> Behalf Of
> >>> > To: <[email-masked]>; <[email-masked]>; <[email-masked]>; "MPLS-
> TP ad
> >>> > hoc

---

From: Maarten Vissers <[email-masked]>
Date: Thu, 02 Dec 2010 15:12:26 +0100

Andy,

The server layer network does not have to know which clients want to know,
as this is controlled by the server/client adaptation sink functions. 

The server_AI carries the SF and SD information, and the server/client_A_Sk
function or functions (multiple clients) will pass this SF/SD information to
those clients that want to know, via their client_CI_SSF/CI_SSD signals
and/or via client-AIS/FDI maintenance signals.

If a specific client instance is not interested in it, then it can ignore
this information; otherwise it can use the information.

Regards,
Maarten

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of [email-masked]
> Sent: 2 December 2010 14:28
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: [mpls-tp] [mpls] [PWE3] [AHMPLS-TP] Re: poll ondraft-he-
> mpls-tp-csf-03.txt
>

---

From: <[email-masked]>
Date: Thu, 2 Dec 2010 15:40:12 +0100

Agree with Lieven.

We need to avoid making predictions about the capability & complexity (& even existence) of a certain client layer technology (most of all considering terminal nodes connected by attachment circuits), but still provide effective fault notifications in packet transport applications. Herefore, IMHO, CSF is helpful and required.

Of course, we also strongly need to avoid confusing control plane and data plane tasks (e.g. relying on LDP session timeouts for fault detection).

Best regards
Manuel

> Sent: Thursday, December 02, 2010 2:17 PM
> Cc: [email-masked]; Sprecher,Nurit (NSN - IL/Hod HaSharon); MPLS-TP ad hoc
> team; [email-masked]; [email-masked]
> Subject: Re: [mpls] [PWE3] [AHMPLS-TP] Re:[mpls-tp] pollondraft-he-mpls-
> tp-csf-03.txt
> 
> provocative statement alert- We should as we are talking about MPLS-TP and
> not about IP network layer.
> 
> ./
> Lieven
> Subject: Re: [mpls] [PWE3] [AHMPLS-TP] Re: [mpls-tp] pollondraft-he-mpls-
> tp-csf-03.txt
> 
> <[email-masked]>; <[email-masked]>; <[email-masked]>; "MPLS-TP ad hoc
> detect the failure of its peer.  In MPLS-TP, we have three clients, PW, IP,
> and MPLS, and I am quite sure that IP and MPLS clients can take care of
> themselves wrt detecting peer failure.
> >>
> >> Thanks,
> >>
> >> John
> >>
> >> Sent from my iPhone
> >>

---

From: <[email-masked]>
Date: Thu, 2 Dec 2010 15:46:14 +0100

John, 

I am concerned that this discussion is fuelled by some misunderstandings. 

No matter what OAM is used in the packet transport layer ("server layer" if you want), we cannot expect that to be present in the client layer.

Of course, in case the client layer is MPLS-TP too, all the fancy OAM (e.g. CC/CV/RDI) could be in use there as well (but out of administrative control of the transport operator).

Best Regards 
Manuel 

> John E Drake
> Sent: Thursday, December 02, 2010 2:45 PM
> To: LEVRAU, LIEVEN (LIEVEN); RajivAsati (rajiva); Yuanlong Jiang
> Subject: Re: [mpls] [PWE3] [AHMPLS-TP]Re: [mpls-tp] pollondraft-he-mpls-
> tp-csf-03.txt
> 
> That statement is incorrect.  MPLS-TP uses BFD for CC/CV/RDI
> (http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/)
> 
> 
> Sent from my iPhone
> 
>

---

From: John E Drake <[email-masked]>
Date: Thu, 2 Dec 2010 06:57:40 -0800

I think you are missing the point.  Viz, any L2 technology will go through a PW and PWs already have a CSF equivalent.  The other TP clients are IP and MPLS, and they have their own detection mechanisms. 

Sent from my iPhone

> [email-masked]
> Sent: Thursday, December 02, 2010 6:40 AM
> To: [email-masked]; [email-masked];
> [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked];
> Subject: Re: [mpls] [PWE3] [AHMPLS-TP] Re:[mpls-tp] pollondraft-he-
> mpls-tp-csf-03.txt
> 
> 
> Agree with Lieven.
> 
> We need to avoid making predictions about the capability & complexity
> (& even existence) of a certain client layer technology (most of all
> considering terminal nodes connected by attachment circuits), but still
> provide effective fault notifications in packet transport applications.
> Herefore, IMHO, CSF is helpful and required.
> 
> Of course, we also strongly need to avoid confusing control plane and
> data plane tasks (e.g. relying on LDP session timeouts for fault
> detection).
> 
> Best regards
> Manuel
> 
> mpls-
> <[email-masked]>;
> PW, IP,
> > >>> > Subject: [AHMPLS-TP] Re: [mpls-tp] poll on draft-he-mpls-tp-
> csf-
> > >>> 03.txt
> > >>> >
> > >>> > Support.
> > >>> >

---

From: <[email-masked]>
Date: Thu, 2 Dec 2010 14:56:46 +0000

In-line please. 

> Behalf Of [email-masked]
> Sent: 02 December 2010 14:46
> To: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]
> Subject: Re: [PWE3] [mpls] [AHMPLS-TP]Re: [mpls-tp] 
> No matter what OAM is used in the packet transport layer 
> ("server layer" if you want), we cannot expect that to be 
> present in the client layer.

NH=> So what?  The client layer MUST be independent of the server in all respects...not just DP OAM.
> 
> Of course, in case the client layer is MPLS-TP too, all the 
> fancy OAM (e.g. CC/CV/RDI)

NH=> 'Fancy OAM'...good heavens...CV+RDI are the absolute minimum....and we should keep the defect detection OAM as simple/sparse as possible).  Unnecessary (or 'fancy' if you prefer) OAM are things like AIS in co-ps and TCM stuff.

regards, Neil

 could be in use there as well (but 
> out of administrative control of the transport operator).
> 
> Best Regards
> Manuel 
> 
> > Of John E Drake
> > Cc: [email-masked]; Sprecher,Nurit (NSN - IL/Hod HaSharon); 
> MPLS-TP ad 
> > Subject: Re: [mpls] [PWE3] [AHMPLS-TP]Re: [mpls-tp] 
> > pollondraft-he-mpls- tp-csf-03.txt
> > 
> > > Of LEVRAU, LIEVEN (LIEVEN)
> > > Cc: [email-masked]; Sprecher, Nurit (NSN - IL/Hod 
> HaSharon); MPLS-TP 
> > > ad hoc team; [email-masked]; [email-masked]
> > > provocative statement alert- We should as we are talking about 
> > > MPLS-TP and not about IP network layer.
> > >
> > > ./
> > > Lieven
> > > Of Rajiv Asati (rajiva)
> > > <[email-masked]>; "Yuanlong Jiang" <[email-masked]>; 
> > > "Loa Andersson" <[email-masked]>; <[email-masked]>; <[email-masked]>; 
> > > capability is required for those cases in which a client 
> is unable 
> > > to detect the failure of its peer.  In MPLS-TP, we have three 
> > > clients, PW, IP, and MPLS, and I am quite sure that IP and MPLS 
> > > clients can take care of themselves wrt detecting peer failure.
> > > >>
> > > >> Thanks,
> > > >>
> > > >> John
> > > >>
> > > >> Sent from my iPhone
> > > >>
> > > >>> To: John E Drake; Yuanlong Jiang; Loa Andersson; 
> [email-masked];
> > > mpls-
> > > >>> ondraft-he-mpls-
> > > tp-
> > > >>> To: Yuanlong Jiang; Loa Andersson; [email-masked]; 
> > > >>> > "MPLS-
> > > >>> > >                                              +46 
> 767 72 92 
> > > >>> > > 13 _______________________________________________
> > > >>> > > mpls-tp mailing list
> > > >>> > > [email-masked]

---

From: Maarten Vissers <[email-masked]>
Date: Thu, 02 Dec 2010 16:02:15 +0100

Eric,

CSF is used 
- in cases where the client does not have an AIS defined and it is necessary
to forward a client SF condition to the far end [when there is no control
plane] (rationale for GFP-CSF, ETH-CSF)
- in cases where the operator has two admin domains with NMSs that do not
exchange ingress failure information (rationale for OPUk-CSF); when customer
calls MNS B helpdesk, this helpdesk will be able to inform the customer that
the UNI at the other end has failed.

Regards,
Maarten

> Sent: 2 December 2010 12:18
> To: Yuanlong Jiang; John E Drake; Sprecher, Nurit (NSN - IL/Hod
> HaSharon); Loa Andersson; [email-masked]; [email-masked];
> Subject: Re: [mpls-tp] [mpls] [PWE3] [AHMPLS-TP] Re: pollondraft-he-
> mpls-tp-csf-03.txt
> 
> Inline with EO#
> 
> ...
> 
> > >
> > > John,
> > >
> > [JYL] The question is: Can we assume BFD is universally deployed for
> IP
> > and PW?
> EO#  There are three things that end users are going to carry over TP:
> IP, MPLS and L2VPN.  L2VPN, as I understand it, has its own mechanism.
> BFD implementations are stable and widely available for IP and MPLS and
> interoperate across multiple vendors.  I would not say that BFD is
> universally deployed, but that it is easily and universally deployable
> for those who want it.
> 
> It does seem that we agree that CSF and BFD solve the same problem -
> right?
> 
> >
> EO#  My mistake, I read your email as "That is one reason why CSF is
> needed"...that'll teach me to read too quickly. :)
> I agree that OAM and Survivability (encompassing both protection and
> restoration) are needed.  It is not obvious to me why this need for
> OAM+S translates into an obvious and undeniable need for CSF.
> 
> Please note that I am neither for nor against CSF at this point - I'm
> trying to understand what problem it solves that cannot already be
> solved by tools which already exist.  So far it seems like we agree
> that
> BFD is an appropriate tool for IP and MPLS networks - correct?
> 
> >
> frequently
> EO#  Not to get all layer-model-crazy, but if the client wants to
> detect
> a failure the provider doesn't need to determine anything about the
> carried protocol in order to allow them to do so.  In my experience no
> matter what the provider tries to do for the client, the client will
> always want to run their own liveness protocol over the provider's
> network anyways.
> 
> Trust, but verify.  Or perhaps "trust, but not very much".
> 
> 
> 
> 
> 
> eric
> 
> 
> >
> >
> > eric
> >
> > >
> > > Thanks
> > > Yuanlong
> > >
> > > > capability is required for those cases in which a client is
> unable
> > to
> > > >> > >                                              +46 767 72 92
> 13

---

From: "Eric Osborne (eosborne)" <[email-masked]>
Date: Wed, 1 Dec 2010 19:34:08 -0600

Of
Andersson;
pollondraft-he-mpls-

What are others?

> I am not sure which mechanism in MPLS provides the CSF-like
capability,

eric

ondraft-he-mpls-tp-csf-
Behalf
"MPLS-TP
maililng

---

From: "LEVRAU, LIEVEN (LIEVEN)" <[email-masked]>
Date: Thu, 2 Dec 2010 07:48:37 +0100

Nope - ip can detect it via BFD on scale way below minutes.
What you are refereeing to is the IGP control plane time out.
The issue is to detect failures accurately and fast in the data plane when there is no control plane.
./
Lieven

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Yuanlong Jiang
Sent: 02 December 2010 02:19
To: John E Drake; Sprecher, Nurit (NSN - IL/Hod HaSharon); Loa Andersson; [email-masked]; [email-masked]; [email-masked]; MPLS-TP ad hoc team
Subject: Re: [PWE3] [AHMPLS-TP] Re: [mpls-tp] poll ondraft-he-mpls-tp-csf-03.txt

John,

Thanks
Yuanlong

---

From: "Eric Osborne (eosborne)" <[email-masked]>
Date: Thu, 2 Dec 2010 05:17:51 -0600

Inline with EO#

...

IP

Please note that I am neither for nor against CSF at this point - I'm
trying to understand what problem it solves that cannot already be
solved by tools which already exist.  So far it seems like we agree that
BFD is an appropriate tool for IP and MPLS networks - correct?

frequently
> decide which mechanism could be used?

EO#  Not to get all layer-model-crazy, but if the client wants to detect

eric

> > >> To: Yuanlong Jiang; Loa Andersson; [email-masked];
[email-masked];
draft-he-mpls-tp-csf-

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 2 Dec 2010 12:25:36 +0100 (CET)

On Thu, 2 Dec 2010, LEVRAU, LIEVEN (LIEVEN) wrote:

> The issue is to detect failures accurately and fast in the data plane 
> when there is no control plane. ./ Lieven

On a point to point ethernet link there is often the MAC layer signalling 
the IP layer that the port went down (not enough light or autoneg detected 
one-way up or alike).

I see it as desireable that any L2 transport provide the same 
functionality, be it via OAM packets or something else.

Yes, BFD does solve some of this problem but it's still a "send packets 
over the link and see if it works"-protocol instead of "something 
happened, notify everybody who might want to know"-protocol. It's very 
common to have lower layers tell upper layers something went wrong so this 
would be in the same spirit as far as I can see?

MAC layer can tell L2/L3 port it went down.
Routers can tell via ICMP that a TCP session should fail because 
destination IP is unreachable.
Getting AIS/RDI/LOS on a POS port tells IP layer to re-route.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: "LEVRAU, LIEVEN (LIEVEN)" <[email-masked]>
Date: Thu, 2 Dec 2010 14:16:37 +0100

provocative statement alert- We should as we are talking about MPLS-TP and not about IP network layer.

./
Lieven
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rajiv Asati (rajiva)
Sent: 02 December 2010 14:14
To: Yuanlong Jiang
Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon); MPLS-TP ad hoc team; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] [PWE3] [AHMPLS-TP] Re: [mpls-tp] pollondraft-he-mpls-tp-csf-03.txt

Cheers,
Rajiv

Sent from my Phone

---

From: "LEVRAU, LIEVEN (LIEVEN)" <[email-masked]>
Date: Thu, 2 Dec 2010 14:18:07 +0100

Hi Mikael please see in line
./
Lieven
-----Original Message-----
From: Mikael Abrahamsson [mailto:[email-masked]] 
Sent: 02 December 2010 12:26
To: LEVRAU, LIEVEN (LIEVEN)
Cc: Yuanlong Jiang; John E Drake; Sprecher, Nurit (NSN - IL/Hod HaSharon); Loa Andersson; [email-masked]; [email-masked]; [email-masked]; MPLS-TP ad hoc team
Subject: Re: [mpls] [PWE3] [AHMPLS-TP] Re: [mpls-tp] poll ondraft-he-mpls-tp-csf-03.txt

On a point to point ethernet link there is often the MAC layer signalling 
the IP layer that the port went down (not enough light or autoneg detected 
one-way up or alike).
[LL] right but now we can have a few differences scenario's:.
There might be no IP on that link.
There might be no Ethernet OAM /There might be no Ethernet, but something else (like you implied).
There might only LSP OAM

[LL] yes but that is not my argument - it needs to operate also in an environment that potentially doesn't have IP addressing in the data plane.
Yes, BFD does solve some of this problem but it's still a "send packets 
over the link and see if it works"-protocol instead of "something 
happened, notify everybody who might want to know"-protocol. 
[LL] agreed - and it works on the IP network layer.
It's very 
common to have lower layers tell upper layers something went wrong so this 
would be in the same spirit as far as I can see?
[LL] yup

[LL] agreed although the latter are slightly different error/failure conditions.

---

From: "Eric Osborne (eosborne)" <[email-masked]>
Date: Thu, 2 Dec 2010 09:09:30 -0600

Hi Maarten-

  Inline....

> From: Maarten Vissers [mailto:[email-masked]]
> Sent: Thursday, December 02, 2010 10:02 AM
> To: Eric Osborne (eosborne); [email-masked]; [email-masked];
> [email-masked]; 'MPLS-TP ad hoc team'
> Subject: RE: [mpls-tp] [mpls] [PWE3] [AHMPLS-TP]
Re:pollondraft-he-mpls-
> tp-csf-03.txt
> 
> Eric,
> 
> CSF is used
> - in cases where the client does not have an AIS defined and it is
> necessary to forward a client SF condition to the far end [when there
is
> no control plane] (rationale for GFP-CSF, ETH-CSF)

What client layers of MPLS-TP do not have some form of fast failure
detection defined?

It also seems likely that if we come up with some new, ubiquitous client
layer that it will have its own particular set of requirements for
failure detection that may not be met by a generic mechanism such as the
proposed CSF.

> exchange ingress failure information (rationale for OPUk-CSF); when
> customer calls MNS B helpdesk, this helpdesk will be able to inform
the
> customer that the UNI at the other end has failed.

Are there really network operators out there who would not find out that
a circuit has silently failed until they make a phone call?  Is this
where the "IP converges in O(minutes)" thing comes from?  

eric

> > > I must not understand the point you're making.  For one thing, BFD
> > > is quite often configured to detect failures in significantly less
> > > than
> > a
> > > minute.
> > BFD implementations are stable and widely available for IP and MPLS
> > and interoperate across multiple vendors.  I would not say that BFD
is
> > > [JYL] Maybe you'd better refer to RFC 5654 for a comprehensive
reqs
> > :)
> > needed"...that'll teach me to read too quickly. :) I agree that OAM
> > and Survivability (encompassing both protection and
> > that BFD is an appropriate tool for IP and MPLS networks - correct?
> >
> > >
> > > Even so, do we need to firstly determine what protocol is carried
> > > and
> > then
> > detect a failure the provider doesn't need to determine anything
about
> > the carried protocol in order to allow them to do so.  In my
> > experience no matter what the provider tries to do for the client,
the
> > client will always want to run their own liveness protocol over the
> > provider's network anyways.
> >
> > > > "Yuanlong Jiang" <[email-masked]>; "Loa Andersson"
> > > > <[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>;
> > > > "MPLS-TP ad
> > > > > As I understand the original requirement from Malcolm Betts,
> > > > > this capability is required for those cases in which a client
is
[email-masked];
> > > > >> I am not convinced.  It seems like it belongs in the Pseudo
> > > > >> Wire application, which already has this capability.
> > > > >>
> > > > >> Sent from my iPhone
> > > > >>
> > > > >>
> > > > >> > > Ericsson Inc                          phone: +46 10 717
52
> > > > >> > >                                              +46 767 72
92

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 2 Dec 2010 10:00:12 -0800

Dear John,
I think that MPLS-TP OAM CC/CV/RDI solution is based on BFD. It is not BFD
in its entirety but is a subset with some aspects being specific for MPLS-TP
and not part of RFC 5880.

Regards,
Greg

On Thu, Dec 2, 2010 at 5:45 AM, John E Drake <[email-masked]> wrote:

> That statement is incorrect.  MPLS-TP uses BFD for CC/CV/RDI (
> http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/)
>
>
> Sent from my iPhone
>
>

---

From: John E Drake <[email-masked]>
Date: Thu, 2 Dec 2010 10:26:39 -0800

At this level of discussion, what's your point?

Sent from my iPhone

From: Greg Mirsky [mailto:[email-masked]]
Sent: Thursday, December 02, 2010 10:00 AM
To: John E Drake
Cc: LEVRAU, LIEVEN (LIEVEN); Rajiv Asati (rajiva); Yuanlong Jiang; [email-masked]; Sprecher, Nurit (NSN - IL/Hod HaSharon); MPLS-TP ad hoc team; [email-masked]; [email-masked]
Subject: Re: [mpls] [PWE3] [AHMPLS-TP] Re: [mpls-tp] pollondraft-he-mpls-tp-csf-03.txt

Dear John,
I think that MPLS-TP OAM CC/CV/RDI solution is based on BFD. It is not BFD in its entirety but is a subset with some aspects being specific for MPLS-TP and not part of RFC 5880.

Regards,
Greg
On Thu, Dec 2, 2010 at 5:45 AM, John E Drake <[email-masked]<mailto:[email-masked]>> wrote:
That statement is incorrect.  MPLS-TP uses BFD for CC/CV/RDI (http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/)

Sent from my iPhone

> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of
> LEVRAU, LIEVEN (LIEVEN)
> Cc: [email-masked]<mailto:[email-masked]>; Sprecher, Nurit (NSN - IL/Hod HaSharon); MPLS-TP ad
> hoc team; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of
> Rajiv Asati (rajiva)
> [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
> On Dec 1, 2010, at 8:19 PM, Yuanlong Jiang <[email-masked]<mailto:[email-masked]>> wrote:
>
> > John,
> >
> > ----- Original Message ----- From: "John E Drake"
> <[email-masked]<mailto:[email-masked]>>
> <[email-masked]<mailto:[email-masked]>>; "Yuanlong Jiang" <[email-masked]<mailto:[email-masked]>>; "Loa
> Andersson" <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>>;
> <[email-masked]<mailto:[email-masked]>>; "MPLS-TP ad hoc team" <[email-masked]<mailto:[email-masked]>>
> >>> [mailto:[email-masked]<mailto:[email-masked]>]
> >>> To: John E Drake; Yuanlong Jiang; Loa Andersson; [email-masked]<mailto:[email-masked]>;
> mpls-
> >>> [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; MPLS-TP ad hoc team
> >>> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On
> Behalf Of
> >>> ext John E Drake
> >>> To: Yuanlong Jiang; Loa Andersson; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;
> >>> [email-masked]<mailto:[email-masked]>; MPLS-TP ad hoc team
> >>> > From: Yuanlong Jiang [mailto:[email-masked]<mailto:[email-masked]>]
> >>> > To: Loa Andersson; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;
> [email-masked]<mailto:[email-masked]>;
> >>> > MPLS-TP ad hoc team
> >>> > From: "Loa Andersson" <[email-masked]<mailto:[email-masked]>>
> >>> > To: <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>>; "MPLS-
> TP ad
> >>> > hoc
> >>> > team" <[email-masked]<mailto:[email-masked]>>
> >>> > > Loa Andersson                         email:
> >>> > [email-masked]<mailto:[email-masked]>
> >>> > > Sr Strategy and Standards Manager            [email-masked]<mailto:[email-masked]>
> >>> > > [email-masked]<mailto:[email-masked]>
> >>> [email-masked]<mailto:[email-masked]>
> > [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>
_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 2 Dec 2010 10:52:58 -0800

To stress that, IMHO, MPLS-TP CC/CV/RDI is neither IP, nor IP/MPLS BFD.

On Thu, Dec 2, 2010 at 10:26 AM, John E Drake <[email-masked]> wrote:

>  At this level of discussion, what’s your point?
>
>
>
> Sent from my iPhone
>
>
>
> *From:* Greg Mirsky [mailto:[email-masked]]
> *Sent:* Thursday, December 02, 2010 10:00 AM
> *To:* John E Drake
> *Cc:* LEVRAU, LIEVEN (LIEVEN); Rajiv Asati (rajiva); Yuanlong Jiang;
> [email-masked]; Sprecher, Nurit (NSN - IL/Hod HaSharon); MPLS-TP ad hoc
> *Subject:* Re: [mpls] [PWE3] [AHMPLS-TP] Re: [mpls-tp]
> > <[email-masked]>
> > >>> > [email-masked]

---

From: John E Drake <[email-masked]>
Date: Thu, 2 Dec 2010 11:20:42 -0800

Hi,

Here is the relevant excerpt from CC/CV/RDI, for those that have not actually read it.

There are two clarifications to the base BFD spec (reference [4]) wrt the behavior of the MinRxInterval = 0.  This is for independent mode *only*, and it may or may not actually be implemented by anyone.

There is a statement that Link Down Indication and Lock Report may be used as inputs to the BFD state machine.  This may be done by mapping them to an existing input to the BFD state machine so the state machine  is not changed in any way.

There is a statement that Poll/Final is currently not used w/ GAL/GACH.  I personally think this is a mistake.

And that's about it.

Thanks,

John

3.5. BFD Profile for MPLS-TP

   BFD MUST operate in asynchronous mode. In this mode, the BFD Control
   packets are periodically sent at configurable time rate. This rate is
   typically a fixed value for the lifetime of the session. In the rare
   circumstance where an operator has a reason to change session
   parameters, the session must be moved to the ADMIN DOWN state.
   Poll/final discipline can only used for VCCV and UDP/IP encapsulated
   BFD.

   The transport profile is designed to operate independent of the
   control plane; hence the C bit SHOULD be set.

   This document specifies bi-directional BFD for p2p transport LSPs,
   hence the M bit MUST be clear.

   There are two modes of operation for bi-directional LSPs. One in
   which the session state of both directions of the LSP is coordinated
   and one constructed from BFD sessions in such a way that the two
   directions operate independently. A single bi-directional BFD session
   is used for coordinated operation. Two independent BFD sessions are
   used for independent operation.

   Coordinated operation is as described in [4]. Independent operation
   requires clarification of two aspects of [4]. Independent operation
   is characterized by the setting of MinRxInterval to zero by the MEP
   that is typically the session originator (referred to as the source
   MEP), and there will be a session originator at either end of the bi-
   directional LSP. Each source MEP will have a corresponding sink MEP
   that has been configured to a Tx interval of zero.

   The base spec is unclear on aspects of how a MEP with a BFD transmit
   rate set to zero behaves. One interpretation is that no periodic
   messages on the reverse component of the bi-directional LSP originate
   with that MEP, it will only originate messages on a state change.

   The first clarification is that when a state change occurs a MEP set
   to a transmit rate of zero sends BFD control messages with a one
   second period on the reverse component until such time that the state
   change is confirmed by the session peer. At this point the MEP set to
   a transmit rate of zero can resume quiescent behavior. This adds
   robustness to all state transitions in the RxInterval=0 case.

   The second is that the originating MEP (the one with a non-zero
   TxInterval) will ignore a DOWN state received from a zero interval
   peer. This means that the zero interval peer will continue to send
   DOWN state messages that include the RDI diagnostic code as the state
   change is never confirmed. This adds robustness to the exchange of
   RDI indication on a uni-directional failure (for both session types
   DOWN with a diagnostic of either control detection period expired or
   neighbor signaled session down offering RDI functionality).

   A further extension to the base specification is that there are
   additional OAM protocol exchanges that act as inputs to the BFD state
   machine; these are the Link Down Indication [5] and the Lock
   Instruct/Lock Report transactions; Lock Report interaction being
   optional.

Sent from my iPhone

From: Greg Mirsky [mailto:[email-masked]]
Sent: Thursday, December 02, 2010 10:53 AM
To: John E Drake
Cc: LEVRAU, LIEVEN (LIEVEN); Rajiv Asati (rajiva); Yuanlong Jiang; [email-masked]; Sprecher, Nurit (NSN - IL/Hod HaSharon); MPLS-TP ad hoc team; [email-masked]; [email-masked]
Subject: Re: [mpls] [PWE3] [AHMPLS-TP] Re: [mpls-tp] pollondraft-he-mpls-tp-csf-03.txt

To stress that, IMHO, MPLS-TP CC/CV/RDI is neither IP, nor IP/MPLS BFD.
On Thu, Dec 2, 2010 at 10:26 AM, John E Drake <[email-masked]<mailto:[email-masked]>> wrote:
At this level of discussion, what's your point?

Sent from my iPhone

From: Greg Mirsky [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, December 02, 2010 10:00 AM
To: John E Drake
Cc: LEVRAU, LIEVEN (LIEVEN); Rajiv Asati (rajiva); Yuanlong Jiang; [email-masked]<mailto:[email-masked]>; Sprecher, Nurit (NSN - IL/Hod HaSharon); MPLS-TP ad hoc team; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Dear John,

Regards,
Greg

Sent from my iPhone

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Fri, 3 Dec 2010 01:02:35 +0000

On 2 Dec 2010, at 05:04, Yuanlong Jiang wrote:
> ----- Original Message ----- From: "Eric Osborne (eosborne)" <[email-masked]>
> [JYL] The question is: Can we assume BFD is universally deployed for IP and PW?

Let's take a step back for a moment. Your original premise is wrong IMO. The need for OAM, protection & switching is MPLS-TP is not predicated on the fact that IP networks can't re-converge quickly enough.

> Even so, do we need to firstly determine what protocol is carried and then decide which mechanism could be used?

The CSF draft covers two cases:
- PWs
- LSPs (and by implication the three clients supported by LSPs, namely IP, PWs and other LSPs)

PWs have a mechanism already and the CSF draft acknowledges that.

LSPs have BFD and other tools to detect failures.

IP has a bunch of mechanisms e.g. IGP hellos if you're building an IP network or various keepalive mechanisms if you're layering IP tunnels on something else.

The premise of the draft is "This document defines such a MPLS-TP OAM tool as Client Signal Fail indication (CSF) to propagate client failures and their clearance across a MPLS-TP domain" based on the fact that "the client layer OAM functionality does not provide an alarm notification/propagation functionality"

For the three possible clients of MPLS-TP, the second sentence I quote above does not hold true and therefore the draft is not needed.

However, if I am wrong and the draft really is needed it should be straightforward for someone to post a description of a practical deployment use case where the existing IP mechanisms are insufficient and the CSF functionality is required in MPLS-TP to proxy for the lack of client level functionality.

Ben

---

From: <[email-masked]>
Date: Fri, 3 Dec 2010 10:32:53 +0000

Hi Ben....I think we need to start being a little more precise....have snipped the thread to the point I want to make:

Ben Niven-Jenkins wrote 03 December 2010 01:03

<snipped>
> LSPs, namely IP, PWs and other LSPs)

NH=> PWs are now (sadly) a layer network in their own right.  They should not exist in MPLS-TP.  However, they do.  But they have OAM and so don't need CSF because of this.
> IP has a bunch of mechanisms e.g. IGP hellos if you're 
> building an IP network or various keepalive mechanisms if 
> you're layering IP tunnels on something else.

NH=> Let me ignore the fact that we should not have sublayering nor PWs in MPLS-TP (though these are conscious mistakes we have decided to make).  So which clients above the PW layer need CSF?  Can we see a list of these please?

Note - Despite the fact the CSF draft is architecturally wrong and technically flawed as I have pointed out before, IMO any attempt at CSF that does not consider all layers to the true TOS layer network and the impact on external message/file/stream applications (eg IP is a true TPS layer network) is a waste of time.  It's a similar argument as to why E-NNIs in non-TOS layer network are also a waste of time.  Sure we can do these things (we can do all manner of unnecessary things) but I would rather not waste effort/money on unnecessary things.

regards, Neil
<snipped to end>

---

From: Jiang Yuanlong <[email-masked]>
Date: Fri, 03 Dec 2010 22:46:08 +0800

Hi Ben,

Thanks for your feedback, please see my comments inline.

Regards
Yuanlong

----- Original Message ----- 
From: "Ben Niven-Jenkins" <[email-masked]>
To: "Yuanlong Jiang" <[email-masked]>
Cc: "Eric Osborne (eosborne)" <[email-masked]>; "John E Drake" <[email-masked]>; "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>; "Loa Andersson" <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>; "MPLS-TP ad hoc team" <[email-masked]>
Sent: Friday, December 03, 2010 9:02 AM
Subject: Re: [mpls-tp] [mpls] [PWE3] [AHMPLS-TP] Re: pollondraft-he-mpls-tp-csf-03.txt

Let's take a step back for a moment. Your original premise is wrong IMO. The need for OAM, protection & switching is MPLS-TP is not predicated on the fact that IP networks can't re-converge quickly enough.
[JYL] Sorry I am misled by the following statements which are extracted from RFC 5860, that MPLS-TP OAM:
   o  the reduction of operational complexity and costs, by allowing for
      efficient and automatic detection, localization, and handling and
      diagnosis of defects, as well as by minimizing service
      interruptions and operational repair times.

   o  the enhancement of network availability, by ensuring that defects
      (for example, those resulting in misdirected customer traffic) and
      faults are detected, diagnosed, and dealt with before a customer
      reports the problem.
There is no any comparison with IP indeed, but your comments make me wonder what is the value of MPLS-TP OAM to routers.
Does this mean it only apply to the transport equipments?

[JYL] IGP hello is not so fast, maybe BFD is also needed for such a use case.
In fact, there is also VCCV BFD available in PW, so do we need any more PW OAM mapping in draft-ietf-pwe3-static-pw-status (except bits defined for the PW redundancy )?

Ben

---

From: Benjamin Niven-Jenkins <[email-masked]>
Date: Sat, 4 Dec 2010 08:12:14 +0000

Yuanlong,

> In fact, there is also VCCV BFD available in PW, so do we need any more PW OAM mapping in draft-ietf-pwe3-static-pw-status (except bits defined for the PW redundancy )?

The draft states that CSF is required for client technologies that can not detect faults themselves. You are now stating the purpose to be to compensate for client technologies where fault detection is not fast enough. That is a different use case.

In the case that IGP hello is not fast enough (and the timers can always be tuned) detecting the fault is only part of the time it takes for the network to reconverge. 

It is still not clear to me why MPLS-TP requires CSF for IP clients when other server technologies that IP runs over do not provide it and IP networks have operated fine

Ben

---

From: <[email-masked]>
Date: Sat, 4 Dec 2010 12:07:10 +0000

Ben (and others) please do not overlook the other key points here.....

This can only apply to the PW layer network and clients of that layer network (as IP does not need this and sublayered LSPs do not need this).

Ignoring the fact that a transport network should treat all clients alike and thus PWs should not appear in MPLS-TP, we still have these 3 important observations:

1	One does not fix an OAM deficiency in a client layer network by creating a functional coupling to a server layer network....so that is a general architectural statement that says the draft is just plain technically wrong;

2	One should not map *server* layer defects *below the MPLS and PW layer networks* at either end into some CSF OAM function in the PW layer network and then onwards into the client (of the PW) layer network.....this further mistake is stated in section 3.1 of the draft.

3	Assuming we do all this anyway it is still essentially a pointless and unnecessary exercise.  Why?  Because if the client layer network X say of the PW layer network is NOT a Top-of-Stack (TOS) layer network then it must, by definition, have a higher layer network (somewhere above it, if not immediately above it) that is a TOS layer network.  This TOS layer network provides the true E2E networking span between the external message/file/stream applications that must exist in all networking cases.  It is thus obviously not sufficient simply to map the PW CSF function to the client layer network X, if the client layer network X cannot then map this CSF function it its client layer network Y...and so on recursively up the stack until we hit the true TOS layer network (which is most often IP anyway and does not need this!).

My colleague Andy Reid also summed the above up succinctly (if in a slightly more obscure way) when he said:
==>
"something happened, notify everybody who might want to know" 

<==

Quite......and this is also why AIS makes absolutely no sense to (i) a cl-ps layer network like IP or Ethernet or (ii) SVC co-cs/ps layer networks as it requires a permanent binding of the client and the server....but it's also easy to show that AIS is not even needed on PVC co-ps mode layer networks.  AIS only has a required role in the traditional regular time-sliced and fixed PVC hierarchy co-cs layer networks of PDH and SDH.  

regards, Neil

> [mailto:[email-masked]] On Behalf Of Benjamin Niven-Jenkins
> Sent: 04 December 2010 08:12
> To: Jiang Yuanlong
> Cc: MPLS-TP ad hoc team; [email-masked]; [email-masked]; 
> [email-masked]
> > - LSPs (and by implication the three clients supported by 
> LSPs, namely 
> > IP, PWs and other LSPs)
> > 
> > The premise of the draft is "This document defines such a 
> MPLS-TP OAM tool as Client Signal Fail indication (CSF) to 
> propagate client failures and their clearance across a 
> MPLS-TP domain" based on the fact that "the client layer OAM 
> functionality does not provide an alarm 
> notification/propagation functionality"
> > 
> > For the three possible clients of MPLS-TP, the second 
> sentence I quote above does not hold true and therefore the 
> draft is not needed.
> > 
> > In fact, there is also VCCV BFD available in PW, so do we 
> need any more PW OAM mapping in 
> draft-ietf-pwe3-static-pw-status (except bits defined for the 
> PW redundancy )?
> > 
> 
> The draft states that CSF is required for client technologies 
> that can not detect faults themselves. You are now stating 
> the purpose to be to compensate for client technologies where 
> fault detection is not fast enough. That is a different use case.
> 
> In the case that IGP hello is not fast enough (and the timers 
> can always be tuned) detecting the fault is only part of the 
> time it takes for the network to reconverge. 
> 
> It is still not clear to me why MPLS-TP requires CSF for IP 
> clients when other server technologies that IP runs over do 
> not provide it and IP networks have operated fine
> 
> > However, if I am wrong and the draft really is needed it 
> should be straightforward for someone to post a description 
> of a practical deployment use case where the existing IP 
> mechanisms are insufficient and the CSF functionality is 
> required in MPLS-TP to proxy for the lack of client level 
> functionality.
> 
> Ben
>