Re: [Isis-wg] FW: New Version Notification for draft-ginsberg-isis-sbfd-discriminator-00.txt

"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Thu, 08 May 2014 20:40 UTC

Return-Path: <ginsberg@cisco.com>
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E38D1A0095; Thu, 8 May 2014 13:40:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.152
X-Spam-Level:
X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FrwJigJFKgJL; Thu, 8 May 2014 13:40:45 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 027C91A0067; Thu, 8 May 2014 13:40:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3398; q=dns/txt; s=iport; t=1399581640; x=1400791240; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=wlRPM7y+WowjN6UMUejYOpaU4xbJrGE/cMhIk7Ij2tM=; b=f3cIfab2yh5NTt2BEu/6oN6dnDf/GcQg90XFvf5mdP8cbgy5nhZ7jGF5 +sGbqFFjcG/41OR0n5nEj0Ncbvv6+wnV0th+Gefq9myEmExnLmcRBFXt+ ZgMdD/PDXO0qOb84zNrPUNYeeBT8W8xIMZqCzyHXxREgDy02Yf6/THs90 Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgsFAHHra1OtJA2N/2dsb2JhbABZgwaBJ8ViAYEUFnSCJQEBAQQ6PQIMBAIBCA4DBAEBAQoUCQcyFAgBCAIEDgUIiDnQXheNeyYxBwaDJIEVAQOsM4F3gT+BbkE
X-IronPort-AV: E=Sophos;i="4.97,1013,1389744000"; d="scan'208";a="323473381"
Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-6.cisco.com with ESMTP; 08 May 2014 20:40:23 +0000
Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s48KeMh6030031 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 8 May 2014 20:40:22 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.230]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Thu, 8 May 2014 15:40:22 -0500
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: Jeffrey Haas <jhaas@pfrc.org>
Thread-Topic: FW: New Version Notification for draft-ginsberg-isis-sbfd-discriminator-00.txt
Thread-Index: AQHPasw+ft5/3BK2OUCTWOWP0ceEqZs2wwSAgAChxQD//7dn8IAAWdIA//+seMA=
Date: Thu, 08 May 2014 20:40:22 +0000
Message-ID: <F3ADE4747C9E124B89F0ED2180CC814F23D87AC1@xmb-aln-x02.cisco.com>
References: <20140508144606.23448.98448.idtracker@ietfa.amsl.com> <F3ADE4747C9E124B89F0ED2180CC814F23D873B9@xmb-aln-x02.cisco.com> <20140508192534.GA24787@pfrc> <F3ADE4747C9E124B89F0ED2180CC814F23D87A01@xmb-aln-x02.cisco.com> <20140508202712.GF3935@pfrc>
In-Reply-To: <20140508202712.GF3935@pfrc>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [128.107.163.140]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/isis-wg/R5ohkTmQujqyDqipd70G-clEPME
Cc: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, "isis-wg@ietf.org" <isis-wg@ietf.org>
Subject: Re: [Isis-wg] FW: New Version Notification for draft-ginsberg-isis-sbfd-discriminator-00.txt
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/isis-wg/>
List-Post: <mailto:isis-wg@ietf.org>
List-Help: <mailto:isis-wg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 May 2014 20:40:47 -0000

Jeff -

The issue of IGPs advertising application information has been much discussed over the last few years. Using IGP flooding for distributing application info is "appealing" because IGP flooding has been proven to be both efficient and reliable. But it compromises the basic function of the protocol by overloading the link state database with "non-routing information".

In the case of IS-IS, the means to support using the IGP to advertise application info was addressed via GENINFO (RFC 6823) and MI (RFC 6822). So if S-BFD use cases ever evolve into something complex enough to require a full fledged set of application specific info and you think IGP flooding is your best vehicle for advertising you can then follow the guidelines defined in those two RFCs - which will include writing an S-BFD application RFC, obtaining an application ID codepoint from IANA, and using a separate instance of the protocol to advertise whatever you want. 

For the base protocols, all we intend to support is advertisement of the assigned discrominators - nothing more. This is sufficient to support use cases that the IGPs themselves may find valuable - but is certainly not sufficient to support other possible use cases - nor is it intended to be.

If your argument is that the advertisement MUST support all possible S-BFD use cases then we should simply not do this at all in the IGPs.

    Les

> -----Original Message-----
> From: Jeffrey Haas [mailto:jhaas@pfrc.org]
> Sent: Thursday, May 08, 2014 1:27 PM
> To: Les Ginsberg (ginsberg)
> Cc: Jeffrey Haas; isis-wg@ietf.org; rtg-bfd@ietf.org
> Subject: Re: FW: New Version Notification for draft-ginsberg-isis-sbfd-
> discriminator-00.txt
> 
> Les,
> 
> On Thu, May 08, 2014 at 08:10:35PM +0000, Les Ginsberg (ginsberg) wrote:
> > How S-BFD Discriminators get used is a subject that no doubt the BFD WG
> > will discuss at length in the near future. However, the additional
> > information that may be required to differentiate how - when multiple
> > discriminators are advertised by a node - each discriminator should be
> > used is out of scope for the IGP advertisement. This gets into the area of
> > application information which has to be defined/standardized elsewhere
> and
> > does not belong in the IGP advertisements. So the deliberate intent here
> > as far as the IGP advertisement is to limit it to simply a list of
> > assigned discriminators - nothing more.
> 
> I don't buy the argument, even though the underlying reasoning may not be
> your responsibility. :-)
> 
> IGPs distribute node and link reachability.  The underlying mechanism that
> is being used isn't even binding the information so much to the node as it
> is to protocol plumbing.
> 
> If the feature is intended to be node-addressable or potentially
> link-addressable is very much relevant to how the feature is developed and
> used.  If we're not to the point of answering those two very basic
> questions, then the IGP drafts are premature.  And almost certainly,
> squatting on a code point even tentatively is premature.  I strongly suggest
> moving it to TBD in the next version of the draft.
> 
> That said, I suspect the use cases will shake out very shortly and hopefully
> the point will be moot in -01.
> 
> -- Jeff