Comments on draft-suping-bfd-mpls-fecmismatch-00.txt

"Thomas D. Nadeau" <tnadeau@cisco.com> Thu, 24 February 2005 01:30 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13931; Wed, 23 Feb 2005 20:30:16 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D48CN-0001Nw-Jo; Wed, 23 Feb 2005 20:53:52 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D41UU-0007uk-44; Wed, 23 Feb 2005 13:44:06 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D41US-0007uB-OV for rtg-bfd@megatron.ietf.org; Wed, 23 Feb 2005 13:44:04 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26471 for <rtg-bfd@ietf.org>; Wed, 23 Feb 2005 13:43:55 -0500 (EST)
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D41r4-0004nl-IH for rtg-bfd@ietf.org; Wed, 23 Feb 2005 14:07:29 -0500
Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 23 Feb 2005 11:58:17 +0000
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
X-IronPort-AV: i="3.90,110,1107734400"; d="scan'208"; a="228378082:sNHT22274192"
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j1NIhfq8008594; Wed, 23 Feb 2005 10:43:42 -0800 (PST)
Received: from [192.168.1.100] (che-vpn-cluster-2-82.cisco.com [10.86.242.82]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id API39651; Wed, 23 Feb 2005 13:43:42 -0500 (EST)
In-Reply-To: <a3166edb57d59c525cdc34e08948323b@juniper.net>
References: <a3166edb57d59c525cdc34e08948323b@juniper.net>
Mime-Version: 1.0 (Apple Message framework v619.2)
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Message-Id: <99c30923ede00099e967a65552e77c02@cisco.com>
Content-Transfer-Encoding: 7bit
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
Date: Wed, 23 Feb 2005 13:43:40 -0500
To: "'rtg-bfd@ietf.org'" <rtg-bfd@ietf.org>
X-Mailer: Apple Mail (2.619.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da
Content-Transfer-Encoding: 7bit
Cc: David Ward <dward@cisco.com>, Dave Katz <dkatz@juniper.net>
Subject: Comments on draft-suping-bfd-mpls-fecmismatch-00.txt
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
Sender: rtg-bfd-bounces@ietf.org
Errors-To: rtg-bfd-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c
Content-Transfer-Encoding: 7bit

	I have reviewed draft-suping-bfd-mpls-fecmismatch-00.txt
and have some comments regarding this draft.

	Editorial:

	The draft isn't well put together in that the
document doesn't read very well, and the details
of what it is trying to accomplish are scarce.

	Technical:

		The whole basis of the document is that of
performing incoming FEC validation based on
the premise that invalid packets can arrive
and be processed at an incorrect router. There
are two problems with this as specified in
the draft. First, you already get FEC validation
with BFD/MPLS by virtue of the fact that a session
exists only to service a particular FEC. This session
is bound to a unique session identification once
established. For MPLS this is explained in the BFD/MPLS
draft for bootstrapping sessions. Given that each
session is set up for a particular FEC, if
a router receives a packet for a BFD session that
doesn't exist (or has been removed), the FEC
is by virtue invalid and should be dropped/ignored
(see the security sections in the BFD base drafts).

	The second problem I have with this approach
is that if you disagree with my assumption that
sessions are only set up for valid sessions, and
believe that they can be falsely set up, this is
where the security sections of the BFD base drafts
come in. There are ways of doing the full
"belts and suspenders" approach to setting up sessions
and maintaining their ongoing validity which I think
guarantees that things are established exactly
and only exactly as desired, and stay that way.

	The final technical issue I have with the document
is that it is based on ITU Y.1713, which is based on
ITU recommendation Y.1711. If we take a close look at
the scope section of the updated version of Y.1711,
we will find that the protocol is limited to
connection-oriented network constructs ONLY. For
MPLS this means that it ONLY applies to
MPLS-TE LSPs and possibly things that can ride
over those LSPs (i.e.: pseudowires that use
a TE LSP between PEs).  It also means that since
Y.1713 is based on Y.1711, it inherits its scoped
limitations as well.

	Given the three technical issues I raised above,
which I think are major and limiting, I don't
see a good reason to go and modify the BFD header
to accommodate this approach, as is what the draft
further specifies. Even if points 1 and 2 are addressed,
the fact that the scope of the approach outlined
is severely limited, I can't see anything here
that gives enough motivation for going and having to
repair all of the existing implementations of BFD
to facilitate it.

	--Tom