IETF Logo Mail Archive

Re: [mpls-tp] [mpls] [PWE3] [AHMPLS-TP] Re: poll ondraft-he-mpls-tp-csf-03.txt

"LEVRAU, LIEVEN (LIEVEN)" <lieven.levrau@alcatel-lucent.com> Thu, 02 December 2010 13:17 UTC

Return-Path: <lieven.levrau@alcatel-lucent.com>
X-Original-To: mpls-tp@core3.amsl.com
Delivered-To: mpls-tp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E57CA28C0E7; Thu, 2 Dec 2010 05:17:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.099
X-Spam-Level:
X-Spam-Status: No, score=-4.099 tagged_above=-999 required=5 tests=[AWL=-1.850, BAYES_00=-2.599, HELO_EQ_FR=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ragIUNAJHUnm; Thu, 2 Dec 2010 05:17:08 -0800 (PST)
Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id D89533A693E; Thu, 2 Dec 2010 05:17:07 -0800 (PST)
Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id oB2DICKK010484 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 2 Dec 2010 14:18:12 +0100
Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Thu, 2 Dec 2010 14:18:12 +0100
From: "LEVRAU, LIEVEN (LIEVEN)" <lieven.levrau@alcatel-lucent.com>
To: Mikael Abrahamsson <swmike@swm.pp.se>
Date: Thu, 2 Dec 2010 14:18:07 +0100
Thread-Topic: [mpls] [PWE3] [AHMPLS-TP] Re: [mpls-tp] poll ondraft-he-mpls-tp-csf-03.txt
Thread-Index: AcuSE6tP5hXWq3A4RlWT2Op37MpzOwACyzjA
Message-ID: <E6E66922099CFB4391FAA7A7D3238F9F20AF8DBA@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com>
References: <4CE51469.2020105@pi.nu> <00c201cb9137$0e7b1fd0$6428460a@china.huawei.com> <5E893DB832F57341992548CDBB33316398C53F6CF1@EMBX01-HQ.jnpr.net> <077E41CFFD002C4CAB7DFA4386A532640301C477@DEMUEXC014.nsn-intra.net> <5E893DB832F57341992548CDBB33316398C53F6D0C@EMBX01-HQ.jnpr.net> <006701cb91be$e5b529a0$6428460a@china.huawei.com> <E6E66922099CFB4391FAA7A7D3238F9F20AF89FF@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> <alpine.DEB.1.10.1012021220510.9121@uplift.swm.pp.se>
In-Reply-To: <alpine.DEB.1.10.1012021220510.9121@uplift.swm.pp.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.64 on 155.132.188.84
Cc: Loa, "mpls@ietf.org" <mpls@ietf.org>, "mpls-tp@ietf.org" <mpls-tp@ietf.org>, MPLS-TP ad hoc team <ahmpls-tp@lists.itu.int>, "pwe3@ietf.org" <pwe3@ietf.org>
Subject: Re: [mpls-tp] [mpls] [PWE3] [AHMPLS-TP] Re: poll ondraft-he-mpls-tp-csf-03.txt
X-BeenThere: mpls-tp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: MPLS-TP Mailing list <mpls-tp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mpls-tp>, <mailto:mpls-tp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls-tp>
List-Post: <mailto:mpls-tp@ietf.org>
List-Help: <mailto:mpls-tp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls-tp>, <mailto:mpls-tp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Dec 2010 13:17:09 -0000

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

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

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

[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

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.
[LL] agreed although the latter are slightly different error/failure conditions.
-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

v2.8.7 | Report a Bug | By Email