Subject: Updated specs

From: Dave Katz <[email-masked]>
Date: Sun, 20 Feb 2005 23:12:51 -0800

I've posted updated specs for the BFD base, one hop, and multihop docs 
to the secretariat, just in the nick of time (as usual.)  Hopefully 
I've satisfied all of the latest boilerplate requirements so the docs 
don't get rejected.  Should show up in the next couple of days.

--Dave1 (for Dave2)

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 23 Feb 2005 13:43:40 -0500

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