Re: [OSPF] Advertising S-BFD discriminators in OSPF
"Carlos Pignataro (cpignata)" <cpignata@cisco.com> Fri, 26 September 2014 09:08 UTC
Return-Path: <cpignata@cisco.com>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 567D61A1AAA for <ospf@ietfa.amsl.com>; Fri, 26 Sep 2014 02:08:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.287
X-Spam-Level:
X-Spam-Status: No, score=-15.287 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.786, 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 3cncnYfNx9bI for <ospf@ietfa.amsl.com>; Fri, 26 Sep 2014 02:08:32 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 742DB1A1A54 for <ospf@ietf.org>; Fri, 26 Sep 2014 02:08:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5751; q=dns/txt; s=iport; t=1411722513; x=1412932113; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=40ZH5LdO09WH5a4tHakajXu1yHtO92HxcgUict/m3RM=; b=Odg2ihSuprDHinu7+WBFg4vkL7nVcTrxERI1P94hxWB5XCbRFdGkXX2V GuXDDI3+/70jFNS+epU8afTNou2YKmYeuqPtKkwC3dtAZt233OiI5J4Di 833ScFyX/U2cV/ZuBDnKZLvIhXsJ0S8nOPKD39sSmhripAclSZDpOatW9 U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhAFAEgsJVStJA2I/2dsb2JhbABggmsjU1cEyjMKh04CgQQWAXuEAwEBAQMBAQEBNzQLBQsCAQgYHhAnCyUCBA4FiDYIAQzAdgEXiiqFETAzB4MugR0FjykighiEOocJgWKKWIkgg2NsAYFHgQIBAQE
X-IronPort-AV: E=Sophos;i="5.04,603,1406592000"; d="scan'208";a="81480353"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-4.cisco.com with ESMTP; 26 Sep 2014 09:08:32 +0000
Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s8Q98V3V017311 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 26 Sep 2014 09:08:31 GMT
Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0195.001; Fri, 26 Sep 2014 04:08:31 -0500
From: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
To: Karsten Thomann <karsten_thomann@linfre.de>
Thread-Topic: [OSPF] Advertising S-BFD discriminators in OSPF
Thread-Index: AQHP2PVhGay6guaisE2mpkzmQOEuupwS8/UAgABS0oCAAAmnAIAAE6IAgAAQuAA=
Date: Fri, 26 Sep 2014 09:08:30 +0000
Message-ID: <E88546B4-C1BE-41EC-B5DA-1FB6268A165B@cisco.com>
References: <CAG1kdogCgCOeN4OaXZe2F7a2w6FYdFS=cmxcj6_aOOOtosMi2w@mail.gmail.com> <54246A47.5060307@cisco.com> <CAG1kdoib9DZkzihefnpE_DbYwqTb5jW4a-VsQcwYrB8NAV5qgw@mail.gmail.com> <54250677.9020606@cisco.com> <CAG1kdohMTw1ENawr+cP3RiqmS_Z1jAFVT-BOCmKo3Fy2gyvwQg@mail.gmail.com> <54251F08.7060502@linfre.de>
In-Reply-To: <54251F08.7060502@linfre.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.21.87.159]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <594929322B002E4CA29B43E930B620B3@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/1MsZoDKm_zGG86qEy_2EjvJBnFw
Cc: OSPF - OSPF WG List <ospf@ietf.org>
Subject: Re: [OSPF] Advertising S-BFD discriminators in OSPF
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ospf/>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Sep 2014 09:08:34 -0000
Michael, That first sentence quoted below has the key -- Basically, the S-BFD discriminator is tied to the node. It is an RI piece, with very a very small amount of data. Further, it is information that relates directly to OSPF, as IGPs are clients and users of S-BFD. It is not OSPF data per se, you are correct, but it is a "information relating to the aggregate OSPF router". Thanks, Carlos. On Sep 26, 2014, at 9:08 AM, Karsten Thomann <karsten_thomann@linfre.de> wrote: > Hi, > > RFC 4970 Section 3 includes: > > The purpose of the Router Information (RI) LSA is to advertise > information relating to the aggregate OSPF router. Normally, this > should be confined to TLVs with a single value or very few values. > It is not meant to be a generic container to carry any and all > information. > > I think the first sentence allows it, as it is related to the ospf router, > even if it is not an ospf internal information. > Michael is right that not everything should be in the RI LSA as already > mentioned in the RFC, increasing the count of LSAs which need to be > flooded across the domain has also drawbacks in term of scalability. > > Regards, > > Karsten > > > Am 26.09.2014 08:58, schrieb Manav Bhatia: >> Hi Michael, >> >> :-) >> >> Lets not deal with analogies (my bad!) lest we get misled by those. >> >> Clearly you and I look at RI LSAs differently. I dont think what youre >> suggesting is even remotely preposterous. However, i do believe that >> RIs can serve more than merely announcing OSPF specific router >> capabilities. >> >> And once again, we already have a precedent where RI was used for >> announcing non OSPF specific capability -- which means that the >> co-authors of this draft arent the only ones who think of RIs as being >> a generic tool for router capability advertisement. >> >> Lets hear what others have to say on this. >> >> Cheers, Manav >> >> >> On Fri, Sep 26, 2014 at 11:53 AM, Michael Barnes <mjbarnes@cisco.com> wrote: >>> Hi Manav, >>> >>> That's a pretty funny analogy. I've got another one for you. >>> >>> Say the RI LSA is like a corporate learjet for a tool company. When it gets >>> flown around it's never full so you decide to use it to ship wrenches on it >>> along with the executives. You're proud of your wrenches and want everyone >>> to know how great they are, but do you really want to ship them that way? >>> Maybe it's better to put the wrenches in their own vehicle. >>> >>> So to be a little more serious, if the router wants to proudly proclaim its >>> S-BFD capability then it deserves its own special LSA rather than being >>> packed into one used for other things. >>> >>> Cheers, >>> Michael >>> >>> >>> On 09/25/2014 06:27 PM, Manav Bhatia wrote: >>>> Hi Michael, >>>> >>>> Very interesting. >>>> >>>> I think there is a disconnect because of our interpretation of what an >>>> RI LSA is envisioned to carry. I assume its meant to advertise >>>> "optional router capabilities" while you believe its to be used solely >>>> for advertising "optional OSPF router capabilities". IMO, limiting the >>>> scope of RI to just OSPF is like using a humvee with all its bells and >>>> whistles to distribute balloons to the children in your friendly >>>> neighborhood park! We wanted a mechanism wherein each router could >>>> proudly tell the world that it was an S-BFD capable node and along >>>> with it also advertise the unique discriminator that the others would >>>> use to reach it. RI we felt, was the perfect tool that we could use >>>> for this purpose. >>>> >>>> And btw we're not the first ones to use RI for advertising a router >>>> capability that isnt pertinent to OSPF per se (RFC 5088). >>>> >>>> Cheers, Manav >>>> >>>> On Fri, Sep 26, 2014 at 12:47 AM, Michael Barnes <mjbarnes@cisco.com> >>>> wrote: >>>>> Hi Manav, >>>>> >>>>> Perhaps I missed some earlier discussion, on why you decided to add the >>>>> S-BFD Discriminator TLV to the RI LSA, but I would prefer it not be in >>>>> that >>>>> LSA. I would like to leave the RI LSA with only information pertinent to >>>>> OSPF rather than pollute it with information for which OSPF has no >>>>> interest. >>>>> If you're concerned with a trend of creating a new Opaque type for every >>>>> application which might want OSPF to carry information for it, then I >>>>> would >>>>> suggest we create a generic Application Information LSA. >>>>> >>>>> Regards, >>>>> Michael >>>>> >>>>> >>>>> On 05/30/2014 01:47 AM, Manav Bhatia wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> We had submitted the following draft a couple of weeks ago. >>>>>> >>>>>> http://tools.ietf.org/id/draft-bhatia-ospf-sbfd-discriminator-00.txt >>>>>> >>>>>> This draft introduces a new OSPF RI TLV that allows OSPF routers to >>>>>> flood the S-BFD discriminator values in the routing domain. >>>>>> >>>>>> S-BFD is a new charter item (will be approved very soon) in the BFD WG. >>>>>> >>>>>> Would appreciate comments on this. >>>>>> >>>>>> Cheers, Manav >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OSPF mailing list >>>>>> OSPF@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ospf >>>>>> >>>> . >>>> >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf
- [OSPF] Advertising S-BFD discriminators in OSPF Manav Bhatia
- Re: [OSPF] Advertising S-BFD discriminators in OS… Michael Barnes
- Re: [OSPF] Advertising S-BFD discriminators in OS… Manav Bhatia
- Re: [OSPF] Advertising S-BFD discriminators in OS… Michael Barnes
- Re: [OSPF] Advertising S-BFD discriminators in OS… Manav Bhatia
- Re: [OSPF] Advertising S-BFD discriminators in OS… Karsten Thomann
- Re: [OSPF] Advertising S-BFD discriminators in OS… Carlos Pignataro (cpignata)
- Re: [OSPF] Advertising S-BFD discriminators in OS… Acee Lindem
- Re: [OSPF] Advertising S-BFD discriminators in OS… Michael Barnes