Re: [mpls] I-D ACTION:draft-ietf-mpls-p2mp-sig-requirement-03.txt

Seisho Yasukawa <yasukawa.seisho@lab.ntt.co.jp> Thu, 07 July 2005 12:56 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqVvk-0005Fx-U1; Thu, 07 Jul 2005 08:56:40 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqVvh-0005F2-3H for mpls@megatron.ietf.org; Thu, 07 Jul 2005 08:56:37 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02558 for <mpls@ietf.org>; Thu, 7 Jul 2005 08:56:35 -0400 (EDT)
Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqWMp-0005kY-15 for mpls@ietf.org; Thu, 07 Jul 2005 09:24:43 -0400
Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j67CuJJO009911; Thu, 7 Jul 2005 21:56:19 +0900 (JST)
Received: from vcs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j67CuI9f023950; Thu, 7 Jul 2005 21:56:19 +0900 (JST)
Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j67CuItZ023940; Thu, 7 Jul 2005 21:56:18 +0900 (JST)
Received: from mfs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j67CuIE6026442; Thu, 7 Jul 2005 21:56:18 +0900 (JST)
Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j67CuIkw026439; Thu, 7 Jul 2005 21:56:18 +0900 (JST)
Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j67CuHR3003789; Thu, 7 Jul 2005 21:56:17 +0900 (JST)
Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j67CuHRn000781; Thu, 7 Jul 2005 21:56:17 +0900 (JST)
Received: from imc.m.ecl.ntt.co.jp (imc0.m.ecl.ntt.co.jp [129.60.5.141]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j67CuH9B000775; Thu, 7 Jul 2005 21:56:17 +0900 (JST)
Received: from win-yasukawa.lab.ntt.co.jp by imc.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id VAA15041; Thu, 7 Jul 2005 21:56:16 +0900 (JST)
Message-Id: <5.0.2.5.2.20050707215258.078221a0@imc.m.ecl.ntt.co.jp>
X-Sender: sy003@imc.m.ecl.ntt.co.jp
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2-J
Date: Thu, 07 Jul 2005 22:13:12 +0900
To: Adrian Farrel <adrian@olddog.co.uk>, neil.2.harrison@bt.com
From: Seisho Yasukawa <yasukawa.seisho@lab.ntt.co.jp>
Subject: Re: [mpls] I-D ACTION:draft-ietf-mpls-p2mp-sig-requirement-03.txt
In-Reply-To: <04e401c5827c$b897aa30$db849ed9@Puppy>
References: <0536FC9B908BEC4597EE721BE6A353890A9F1D77@i2km07-ukbr.domain1.systemhost.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1
Cc: mpls@ietf.org
X-BeenThere: mpls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/mpls>
List-Post: <mailto:mpls@lists.ietf.org>
List-Help: <mailto:mpls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@lists.ietf.org?subject=subscribe>
Sender: mpls-bounces@lists.ietf.org
Errors-To: mpls-bounces@lists.ietf.org

Hi Neil,

Thank you for reviewing the draft and providing following comments.
Even though it seems me Adrian already covered my point, I would like to rephrase
that we would like to cover P2MP OAM aspects in the separate draft because
OAM is important and we should discuss this issue based on not only from
signaling perspective.

Regards,
Seisho

At 23:47 05/07/06 +0100, Adrian Farrel wrote:
>Hi Neil,
>
>Speaking as a co-author of draft-ietf-mpls-p2mp-sig-requirement-03.txt and
>of draft-yasukawa-mpls-p2mp-oam-reqs-00.txt I can give an answer. Seisho
>may want to comment further.
>
>"protected by" is certainly not supposed to suggest that each and every
>fault can be rectified by fast error recovery mechanisms. And, of course,
>it would be crazy to expect that since failures of, for example, the
>ingress router are not recoverable.
>
>So, yes, "protected by" refers to defects that are protectable and
>reported/detected, and only applies if the service has actually been
>protected.
>
>As you say, fault rectification is only going to take place if it is
>detected in or reported to the layer in which we are deploying P2MP MPLS
>TE. Further, as we attempt to say in the P2MP OAM requirements draft
>(and/or inherit from the P2P OAM requirements draft) the higher layer must
>be careful not to react too precipitously to a fault which the lower layer
>may be in the process of solving.
>
>With regard to "non-objectives". The non-objectives stated are NOT
>non-objectives of the MPLS WG wrt to P2MP TE signaling. They are
>non-objectives of *this* I-D. As the specific OAM subsection states, P2MP
>OAM is discussed in a separate I-D.
>
>There are three reasons for this:
>1. OAM is not really a signaling requirement.
>2. It is sufficiently large and important that folding it into the
>signaling requirements I-D would make the signaling requirements I-D
>unwieldy.
>3. P2MP OAM needs to apply more widely than just TE (e.g. to LDP
>multicast)
>
>Cheers,
>Adrian
>
>----- Original Message -----
>From: <neil.2.harrison@bt.com>
>To: <yasukawa.seisho@lab.ntt.co.jp>
>Cc: <mpls@ietf.org>
>Sent: Wednesday, July 06, 2005 11:32 AM
>Subject: RE: [mpls] I-D ACTION:draft-ietf-mpls-p2mp-sig-requirement-03.txt
>
>
>Seisho,
>
>I have a question on this draft:
>
>In section 1 there is the following stated requirement:
>"A P2MP TE LSP will be protected by fast error recovery mechanisms to
>minimize disconnection of a P2MP service."
>
>Which is obviously sensible, and of course implies that all the defect
>cases of interest can be detected and the appropriate consequent actions
>taken.  Note this should include defects of this layer network and not
>just defects that arise in lower layer networks.  And remember....the
>links between nodes in this layer network are provided by (p2p) trails
>in a lower layer network....and this client/server relationship recurses
>to the duct.  The point I am making here is that IF the lower layer
>network has decent OAM itself you should get some indication of failure
>from this, but this is over/above any defects you detect in this layer
>network either from (i) lower layer defects or (ii) defects arising in
>this layer network (which of course cannot be detected at all in any
>lower layer network).
>
>
>Yet it says in section 1.1 that a 'non-objective' is:
>"OAM for P2MP LSPs"
>
>Can someone please explain this apparent contradiction?
>
>
>regards, Neil
>
>_______________________________________________
>mpls mailing list
>mpls@lists.ietf.org
>https://www1.ietf.org/mailman/listinfo/mpls


_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls