Re: [OSPF] Review Request: New Version Notification for draft-hegde-ospf-node-admin-tag-00.txt

Anton Smirnov <asmirnov@cisco.com> Wed, 23 October 2013 12:09 UTC

Return-Path: <asmirnov@cisco.com>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60A8111E8361 for <ospf@ietfa.amsl.com>; Wed, 23 Oct 2013 05:09:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xgCeUUw6Jcg5 for <ospf@ietfa.amsl.com>; Wed, 23 Oct 2013 05:09:17 -0700 (PDT)
Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 2E5D511E818B for <ospf@ietf.org>; Wed, 23 Oct 2013 05:09:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2209; q=dns/txt; s=iport; t=1382530155; x=1383739755; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=2vlXhgApCs2IChMyVKPKtLZGsUL7VTgjSFuOH+fsJkQ=; b=dsSDovgvYddU1P3qDZt4IY+dUqsrk3bUiml1KCNC+cLB7mTK02wI4VHu qk0K3bDBaMMxIy+7gd4f2dzpshX8qsQG0BPrLOKDrZztEbkty/GEtqxaX 0b+lQ93Uyy86dkh9NwgipJ7dJxl074So0V8Qrsmk4BLuKyWbDvp5ZFaDQ 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgMFALS7Z1KQ/khN/2dsb2JhbABZgwe8X4J6gScWdIIlAQEBBDg/AQEQCxgJFg8JAwIBAgFFBg0BBwEBiAK7EY4QgT4HhCoDmAmSB4FmgUA6gS0
X-IronPort-AV: E=Sophos;i="4.93,554,1378857600"; d="scan'208";a="18952898"
Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-4.cisco.com with ESMTP; 23 Oct 2013 12:09:13 +0000
Received: from as-lnx.cisco.com (ams-asmirnov-8714.cisco.com [10.55.140.85]) (authenticated bits=0) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r9NC98ml015289 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Oct 2013 12:09:11 GMT
Message-ID: <5267BC64.9090804@cisco.com>
Date: Wed, 23 Oct 2013 14:09:08 +0200
From: Anton Smirnov <asmirnov@cisco.com>
Organization: Cisco Systems
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: Acee Lindem <acee.lindem@ericsson.com>
References: <94A203EA12AECE4BA92D42DBFFE0AE47030A1CA2@eusaamb101.ericsson.se> <5266D691.703@cisco.com> <94A203EA12AECE4BA92D42DBFFE0AE47030A3CE3@eusaamb101.ericsson.se>
In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE47030A3CE3@eusaamb101.ericsson.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Authenticated-User: asmirnov
Cc: OSPF List <ospf@ietf.org>, Harish Raghuveer <hraghuveer@juniper.net>, Rob Shakir <rob.shakir@bt.com>
Subject: Re: [OSPF] Review Request: New Version Notification for draft-hegde-ospf-node-admin-tag-00.txt
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.12
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: Wed, 23 Oct 2013 12:09:22 -0000

    Hi Acce,
    you are just not formulating your objections in the correct way. For 
example, if specification said that Tag TLV must not exceed 64 Kb in 
size that would technically put a bound but this would be both pointless 
and wouldn't satisfy you.

    Another part is why RI LSA is being singled out - why unbound data 
in, say, Network LSA is OK and unbound data in RI LSA is not? Especially 
given that RI LSA can be extended to the adjacent LSIDs and the Network 
LSA cannot.

    Tag data ARE expected to be very small and very stable, so the 
choice of RI LSA to advertise them is very reasonable.

Anton


On 10/22/2013 10:05 PM, Acee Lindem wrote:
> I don't disagree that the typical use case is a single tag with the
> likelihood of mult-tag use cases diminishing exponentially as the
> number of tags increases. My point is that unbounded TLVs MUST NOT be
> included in the OSPF RI LSA. What part of that is hard to
> understand? I think that 16 is a reasonable maximum and that beyond
> 16 would imply encoding ulterior information that should have its own
> TLV or LSA anyway. Acee
>
> On Oct 22, 2013, at 3:48 PM, Anton Smirnov wrote:
>
>> Hi Acee, it looks to me that the most probable deployment will use
>> 1 tag. Router advertising 100 tags already sounds unreasonable.
>> Defining new LSID to originate LSA with (typically) only 4 bytes of
>> useful information is not optimal. Choice of RI LSA to advertise
>> some small data is reasonable. RI LSA is far from getting too big.
>> If there is a concern of RI LSA overfilling then we can extend
>> range of opaque IDs - but is it really necessary at this point?
>>
>> Anton
>>
>>
>> On 10/21/2013 09:55 PM, Acee Lindem wrote:
>>> I think we are in a circular argument here and I'm not discuss
>>> this independently with each of the authors. Either you have to
>>> limit the number of tags, define a new LSA, or do the work to
>>> make RI LSA multi-instance. All are viable alternatives with
>>> differing pros and cons - including it in the existing RI LSA is
>>> not a viable alternative. Remember to request a session if you
>>> plan to present it at IETF 88.
>>>
>>> Thanks, Acee