IETF Logo Mail Archive

Re: [OSPF] Comment on draft-ppsenak-ospf-te-link-attr-reuse-01

"Acee Lindem (acee)" <acee@cisco.com> Tue, 23 February 2016 19:05 UTC

Return-Path: <acee@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 EE56B1A8033 for <ospf@ietfa.amsl.com>; Tue, 23 Feb 2016 11:05:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.507
X-Spam-Level:
X-Spam-Status: No, score=-14.507 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.006, 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 woNGQlEilMM7 for <ospf@ietfa.amsl.com>; Tue, 23 Feb 2016 11:05:46 -0800 (PST)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CC971A891A for <ospf@ietf.org>; Tue, 23 Feb 2016 11:05:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3334; q=dns/txt; s=iport; t=1456254346; x=1457463946; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=GUlXWB/P100X/e1+00txRSamzC8C+2P4cFJAeMbS1uw=; b=IZ5IbBA3sSLqsXzLTvOtVp0IRK/7Wfxbm9C0hzx7HzAMZAFCNikm6pmm /gwCOglwlLY+7d5kUuhDJanHlF3j4qfgThl05UqFlmnhDMnKpAE2T7OGO nF9rRaAalya82I54LaoN66CNBe1WVwibVDCQ/s8vnia3kvIBCSj1w6Bin o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AMAgCjrMxW/4wNJK1egzqBPwa4UoITAQ2BZoYNAhyBMDgUAQEBAQEBAWQnhEIBAQQjEUUQAgEIGgImAgICMBUQAgQOBYgdrjKOdQEBAQEBAQEBAQEBAQEBAQEBAQEXe4lRhASDMYE6BZcHAY1dgVyNFYVyiFYBHgEBQoNkaoc4fQEBAQ
X-IronPort-AV: E=Sophos;i="5.22,490,1449532800"; d="scan'208";a="241630509"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 23 Feb 2016 19:05:45 +0000
Received: from XCH-ALN-012.cisco.com (xch-aln-012.cisco.com [173.36.7.22]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u1NJ5jH8030287 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 23 Feb 2016 19:05:45 GMT
Received: from xch-rcd-015.cisco.com (173.37.102.25) by XCH-ALN-012.cisco.com (173.36.7.22) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 23 Feb 2016 13:05:45 -0600
Received: from xch-rcd-015.cisco.com ([173.37.102.25]) by XCH-RCD-015.cisco.com ([173.37.102.25]) with mapi id 15.00.1104.009; Tue, 23 Feb 2016 13:05:45 -0600
From: "Acee Lindem (acee)" <acee@cisco.com>
To: Julien Meuric <julien.meuric@orange.com>
Thread-Topic: [OSPF] Comment on draft-ppsenak-ospf-te-link-attr-reuse-01
Thread-Index: AQHRaN7xjIo+aS0wwkCugeJWKKQ8MZ8x9c97gAIPQwCABcFZgIAAUv2A
Date: Tue, 23 Feb 2016 19:05:45 +0000
Message-ID: <D2F21711.4E269%acee@cisco.com>
References: <56C35B58.8080301@orange.com> <56C44A8E.7010300@cisco.com> <56C5E7AD.4060508@orange.com> <D2ECFDE3.4D725%acee@cisco.com> <56CC2199.6080701@orange.com>
In-Reply-To: <56CC2199.6080701@orange.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.116.152.199]
Content-Type: text/plain; charset="utf-8"
Content-ID: <B724B609C678A64E919D4EFFBE065C34@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/ospf/D5_xrZ6i2jAuSEjh7Txh3zy7HGE>
Cc: OSPF WG List <ospf@ietf.org>
Subject: Re: [OSPF] Comment on draft-ppsenak-ospf-te-link-attr-reuse-01
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 23 Feb 2016 19:05:48 -0000

Hi Julien, 

On 2/23/16, 4:08 AM, "Julien Meuric" <julien.meuric@orange.com> wrote:

>Hi Acee,
>
>Feb. 20, 2016 - acee@cisco.com:
>> Hi Julien,
>
>[snip]
>
>>>>> What is more, I really think that the current wording  is too loose
>>>>>in
>>>>> "it is expected that the information in these LSA [sic] would be
>>>>> identical". I do not see the drawback of having full alignment of
>>>>> values
>>>>> in case of duplication, but I see the operational risk of nightmare
>>>>>in
>>>>> case they are not. As a result, I suggest to rephrase into: "If the
>>>>> same
>>>>> link attribute is advertised in both LSAs, the information in these
>>>>> LSAs
>>>>> MUST be identical."
>>>>
>>>> given the OSPF protocol operation above can not be guaranteed. LSAs
>>>> arrive asynchronously and there can be intervals during which the
>>>> consistency of the information between two different LSAs can not be
>>>> guaranteed.
>>>
>>> [JM] We fully agree on that. To make sure this is not creating an
>>> ambiguity, you may rephrase as:
>>> "If the same link attribute is advertised in both LSAs, the information
>>> packed in these LSAs by advertising routers MUST be identical."
>>
>> Are we sure on this? Today we can have an OSPF metric that is
>>independent
>> of the OSPF TE Metric - why wouldn’t we want the same flexibility with
>> SRLG?
>
>[JM] From my perspective, I concur. Metrics are purely administrative
>parameters: it makes sense to allow operators to use different routing
>decision between SPF and TE. Conversely, SRLGs are supposed to abstract
>the underlying infrastructure to enable diverse routing: this gives a
>clear semantic on the SRLG link parameter. I do not see any value in
>using two different infrastructure descriptions, while I see some risk
>of operational mess in case one forget to update one of the parameter
>sets.
>I also believe that if double SRLG capability had been an operator's
>requirement, we would have started from there and confronted that to
>both IGPs. This is a different motivation here.

I agree that I don’t really see a requirement for separate TE and IP
SRLGs. However, I’m not sure this is something that the protocol. Perhaps
this falls into the category of “RECOMMENDED”.  We will discuss amongst
the authors once Peter returns from vacation.

Acee 


>
>Cheers,
>
>Julien
>
>
>> Thanks,
>> Acee
>>
>[snip]

v2.23.0 | Report a Bug | By Email