Re: [OSPF] Regarding draft-ppsenak-ospf-te-link-attr-reuse-00

Peter Psenak <ppsenak@cisco.com> Thu, 12 November 2015 11:45 UTC

Return-Path: <ppsenak@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 C03AE1A1B6E for <ospf@ietfa.amsl.com>; Thu, 12 Nov 2015 03:45:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 8FqqK69_NhAq for <ospf@ietfa.amsl.com>; Thu, 12 Nov 2015 03:45:08 -0800 (PST)
Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 854731A1B65 for <ospf@ietf.org>; Thu, 12 Nov 2015 03:45:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5525; q=dns/txt; s=iport; t=1447328707; x=1448538307; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=GajbZAcmYMLO8pNyuhKitTGnUGeZWDK+eIOxnOugSUA=; b=Zn+09Mjob63iCWJpKo41oElMyZAYIk5r6aiwx65PsycLLU0IvgRcmnF5 FyDdtonqy7wL0IrrHC7A4EhLkL9oa4/oC6QARHI8gr9Bro6aiY6RqT1eL BV7vYyY81APyDZnLo23CJdR9ZIkcRSZ5dlao4ItF0tKYdl5JfKUJVD8yi E=;
X-IronPort-AV: E=Sophos;i="5.20,281,1444694400"; d="scan'208";a="56384341"
Received: from vla196-nat.cisco.com (HELO bgl-core-1.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 12 Nov 2015 11:45:04 +0000
Received: from [10.61.217.146] ([10.61.217.146]) by bgl-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id tACBj2iJ017143; Thu, 12 Nov 2015 11:45:03 GMT
Message-ID: <56447BC1.9080409@cisco.com>
Date: Thu, 12 Nov 2015 12:45:05 +0100
From: Peter Psenak <ppsenak@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Julien Meuric <julien.meuric@orange.com>, "Acee Lindem (acee)" <acee@cisco.com>, Jeff Tantsura <jeff.tantsura@ericsson.com>
References: <D24CF2B7.37452%acee@cisco.com> <BLUPR05MB292E9628E4172C733C59BA8A9380@BLUPR05MB292.namprd05.prod.outlook.com> <5627CDF6.605@cisco.com> <BLUPR05MB292B99DA8B1B9E253A0E83BA9380@BLUPR05MB292.namprd05.prod.outlook.com> <5627F457.8020701@cisco.com> <BLUPR05MB2927E888C41831AF2786280A9270@BLUPR05MB292.namprd05.prod.outlook.com> <CAG4d1rctdk6QcrhjEj2n-1VM2HTzQJvFxgamneis+fsiH0rcTw@mail.gmail.com> <562917FE.6070100@cisco.com> <D252C136.384AC%acee@cisco.com> <E70EB200-09AE-464C-A0B2-38F480489F16@ericsson.com> <563B0F53.8010803@orange.com> <563B15E0.90101@cisco.com> <563B2978.10507@orange.com> <D263B0C8.3CC87%acee@cisco.com> <5642209B.3010304@orange.com>
In-Reply-To: <5642209B.3010304@orange.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/ospf/ZtOQq7mUZ-6oY4CIwweLKfdBGJk>
Cc: OSPF WG List <ospf@ietf.org>
Subject: Re: [OSPF] Regarding draft-ppsenak-ospf-te-link-attr-reuse-00
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: Thu, 12 Nov 2015 11:45:10 -0000

Julien,

On 11/10/15 17:51 , Julien Meuric wrote:
> Hi Acee,
>
> I think we do not need to agree on the philosophical question whether
> defining detour path by packet header instead of signaling states brings
> the feature out of TE...
>
> Anyway we agree that consolidating information from 3 separates LSA is
> not the most efficient processing. My point is that this slight
> improvement does not balance the risk of inconsistent
> advertisements/configuration that the current I-D does not (even try to)
> prevent.

let me disagree. Current I-D clearly states what TE Opaque LSAs are used 
for.

The risk is when you do what you propose to do as it breaks the existing 
TE - e.g. you advertise the link in TE Opaque LSA and some remote router 
would try to establish a TE path via such link, even though the link is 
not enabled for that. Result is that the signaling would keep failing or 
in worst case, when signaling is not involved, traffic will be dropped 
when trying to use such link.


regards,
Peter

>
> Regards,
>
> Julien
>
>
> Nov. 07, 2015 - acee@cisco.com:
>> Hi Julien,
>>
>> One such non-TE application where there is a clear advantage of
>> advertising these attributes is segment routing TI-LFA. In addition to
>> all
>> the detriments of requiring advertisement of TE LSAs when TE is not
>> enabled, one would need to consolidate information for a link from 3
>> separate LSAs (the base Router-LSA, the prefix-list attribute LSA for the
>> adjacency SID, and the TE LSA). Clearly, it is better to advertise the
>> applicable attributes in the Prefix/Link Attribute LSA and reduce this
>> burden. You will note that this advantage isn’t apparent in IS-IS where
>> everything is advertised in one monolithic LSP.
>>
>> Thanks,
>> Acee
>>
>> On 11/5/15, 7:03 PM, "OSPF on behalf of Julien Meuric"
>> <ospf-bounces@ietf.org on behalf of julien.meuric@orange.com> wrote:
>>
>>> Hello Peter,
>>>
>>> Nov. 05, 2015 - ppsenak@cisco.com:
>>>> Hi Julien,
>>>>
>>>> On 11/5/15 09:12 , Julien Meuric wrote:
>>>>> Hi Jeff,
>>>>>
>>>>> Following the WG session yesterday, I'm glad to (lately) join the
>>>>> thread. Please, see my comments below as [JM].
>>>>>
>>>>>
>>>>> Oct. 26, 2015 - jeff.tantsura@ericsson.com:
>>>>>> Hi,
>>>>>> No hats
>>>>>>
>>>>>> I'm familiar with at least 2 implementations which have this issue,
>>>>>> this draft solves real problem.
>>>>>>
>>>>>> Regards,
>>>>>> Jeff
>>>>>
>>>>> [JM] Then you may consider patching them to do parameter
>>>>> duplication on
>>>>> the receiver side, not on the wire and/or the emitter configuration...
>>>>> Do you imagine operational people tearing hair out while trying to
>>>>> guess
>>>>> if they need to configure SRLGs in here, there or both? All the
>>>>> more as
>>>>> two places would multiply configuration discrepancies.
>>>>
>>>> above is incorrect.
>>>> Nobody is proposing to configure things like SRLG on multiple places.
>>> [JM] Actually you do in the I-D: "it is expected that the information
>>> would be identical. If they are different..."
>>>
>>>> You configure it on a single place, as you do today. If IGP is enabled
>>>> for global SRLG protection, IGP pulls the SRLGs and advertise them in
>>>> the Extended Prefix LSA. If TE is enabled and want to use SRLGs, it
>>>> pulls it from the same place, form the TE Opaque LSA and asks IGP to
>>>> flood it.
>>> [JM] This reads to me like "in case both types of LSAs are used, values
>>> MUST be identical". This is very different from the loose text in your
>>> I-D.
>>>
>>>>
>>>>>
>>>>> In the I-D, the beginning and the end of section 3.1 provide a good
>>>>> summary:
>>>>> - "One approach for advertising link attributes is to _continue_ to
>>>>> use
>>>>> TE Opaque LSA"
>>>>> - advantages: "no additional standardization requirement", "link
>>>>> attributes are only advertised once".
>>>>> I cannot agree more on these.
>>>>
>>>> have you read the "disadvantage" section as well?
>>> [JM] Of course not, since Shraddha already solved them in his original
>>> e-mail. :-)
>>>
>>>>>
>>>>> In other words, some new use cases, not matching the original one, do
>>>>> not justify to allocate new code points to the same information (cf.
>>>>> IS-IS non-issue). In the IETF, uses cases aim at scoping protocol
>>>>> work,
>>>>> they aren't made to limit protocol future uses.
>>>>
>>>> I;m afraid you are missing the point.
>>>> TE Opaquer LSA are defined as LSAs that advertise TE topology that is
>>>> disjoint from the IGP topology (RFC3630). We can NOT make the link part
>>>> of the TE topology, just because we want to advertise SRLG or some
>>>> other
>>>> attribute that is used by IGP for LFA - that would break the RFC3630.
>>> [JM] Indeed, I am missing the point where a link state protocol is
>>> forbidden to access the link parameters it is distributing in its link
>>> state advertisements. Please, point me to the section from RFC 3630 it
>>> "breaks".
>>>
>>>>
>>>> thanks,
>>>> Peter
>>>>
>>> [JM] You're welcome,
>>>
>>> Julien
>>>
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Julien
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>
> .
>