Re: [OSPF] Advertising S-BFD discriminators in OSPF

Michael Barnes <mjbarnes@cisco.com> Fri, 26 September 2014 14:12 UTC

Return-Path: <mjbarnes@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 F19AF1A88D2 for <ospf@ietfa.amsl.com>; Fri, 26 Sep 2014 07:12:30 -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 TOGXv7gpa5_I for <ospf@ietfa.amsl.com>; Fri, 26 Sep 2014 07:12:29 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CD731A886F for <ospf@ietf.org>; Fri, 26 Sep 2014 07:12:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6234; q=dns/txt; s=iport; t=1411740749; x=1412950349; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=KBqCfKsNq8Nb/0UGgiqDIn/4t+qCdV86hgsJt6HSm70=; b=gwdS9mj2UB7HEkdO0VEn79t6p0JJMI515qgiF3vg4q6DpyOSeJX64uAB yviNLznjNqURGHYeIVaPOQe319VIPv2nNCSVTLjbu7C30JHZ/uQO0rhv6 u7cjQkSKoeWxT3tPPw9d8QvBl5IdK7FD8SIQx615+qpfAfgjRUlEwGmxY w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ag4FABBzJVStJV2b/2dsb2JhbABggw5TV8o/CodOAoEHFgF7hAQBAQQBAQEvAQU2CgEQCxgJFg8JAwIBAgEVMAYNAQUCAQGIOg2/eQEXiiqFEWMHhEsBBIRhhm6DWoZ0hDiCUYFihW+EaYkghAMdLwGCSQEBAQ
X-IronPort-AV: E=Sophos;i="5.04,604,1406592000"; d="scan'208";a="358428356"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP; 26 Sep 2014 14:12:27 +0000
Received: from [10.21.95.156] (sjc-vpn5-1948.cisco.com [10.21.95.156]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s8QECQNt019622 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 26 Sep 2014 14:12:27 GMT
Message-ID: <54257449.2060703@cisco.com>
Date: Fri, 26 Sep 2014 07:12:25 -0700
From: Michael Barnes <mjbarnes@cisco.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130110 Thunderbird/17.0.2
MIME-Version: 1.0
To: Acee Lindem <acee@lindem.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> <BE1416FB-7592-4951-AE49-FC153A5BB89D@lindem.com>
In-Reply-To: <BE1416FB-7592-4951-AE49-FC153A5BB89D@lindem.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/1fuwRBLlSsWeEXNOZ5ksPQPpkN0
Cc: 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 14:12:31 -0000

Hi Acee,

I obviously missed this part of the discussion for rfc5088. Thanks for 
drawing my attention to this.

Regards,
Michael

On 09/26/2014 04:49 AM, Acee Lindem wrote:
> Hi Michael, Manav, Karsten,
>
> We did have this discussion back when we put the first piece of
> non-OSPF information in the OSPF RI LSA and conceded that the OSPF RI
> LSA could be used for all types of information.
>
> https://datatracker.ietf.org/doc/rfc5088/
>
> On the same subject, I have further conceded that this will be used
> for variable length information and am doing a bis version of the
> RFC4970 accommodating multiple instance of the RI LSA. I will be
> presenting the updates in Honolulu.
>
> https://datatracker.ietf.org/doc/draft-acee-ospf-rfc4970bis/
>
> Thanks, Acee P.S. I’m glad I didn’t reply last night - we might have
> missed out on all the analogies ;^).
>
>
> On Sep 26, 2014, at 4: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
>
> .
>