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

"Acee Lindem (acee)" <acee@cisco.com> Fri, 13 November 2015 19:54 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 519D71B2BB4 for <ospf@ietfa.amsl.com>; Fri, 13 Nov 2015 11:54:20 -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 EDxNP1pcBMoU for <ospf@ietfa.amsl.com>; Fri, 13 Nov 2015 11:54:17 -0800 (PST)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0B621B2BC7 for <ospf@ietf.org>; Fri, 13 Nov 2015 11:54:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13470; q=dns/txt; s=iport; t=1447444456; x=1448654056; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=iWWSQ7i3teAXdxpD8mFCkF05Wg37WXEd1EiZLxyKEpo=; b=GbTlgwx1weHV61UX2c+rvpVfAEom+Dlq/cnN6wqy0pl2MhTPshDJpXc6 +OCnaSmRu7eYdtbzyBnJAJxYph45HRpa7DVj5sNq06h7S/Ag2P9GYVe4v 0oUXxokNemdAzyEdEmPVieku2+1MpKMJVFn8gLVcTUIhKBdIS5xWBdWSy s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AnAgB8P0ZW/4YNJK1egztTbwa+QgENg?= =?us-ascii?q?WUXCoVvAhyBIjgUAQEBAQEBAYEKhDUBAQQBAQELFRExCQsQAgEIGAICJgICAiU?= =?us-ascii?q?LFRACBAENBYguDQOvZZBAAQEBAQEBAQEBAQEBAQEBAQEBAQEBFASBAYpRhCoLB?= =?us-ascii?q?gE1FoJugUQFh0aKeYQJAYUciAqBW4RAgyWPE4NxAR8BAUKCER2BVnKDdAgXI4E?= =?us-ascii?q?HAQEB?=
X-IronPort-AV: E=Sophos;i="5.20,289,1444694400"; d="scan'208";a="46625618"
Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-5.cisco.com with ESMTP; 13 Nov 2015 19:54:15 +0000
Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id tADJsEja026714 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 13 Nov 2015 19:54:14 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 13 Nov 2015 14:54:13 -0500
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.000; Fri, 13 Nov 2015 14:54:13 -0500
From: "Acee Lindem (acee)" <acee@cisco.com>
To: "Peter Psenak (ppsenak)" <ppsenak@cisco.com>, "julien.meuric@orange.com" <julien.meuric@orange.com>, Jeff Tantsura <jeff.tantsura@ericsson.com>
Thread-Topic: [OSPF] Regarding draft-ppsenak-ospf-te-link-attr-reuse-00
Thread-Index: AQHRC/ZPFuY7qCnGR1+q4c+BrPcEhJ519m0AgABAsgCAAA+BEIAAHj+AgAEl3ZCAAId6gIAAAigAgAS8qACAEFpkFIAAW5gAgAAXWwCAA2VBgIAJSprygABeDAD//9XugA==
Date: Fri, 13 Nov 2015 19:54:13 +0000
Message-ID: <D26BA7A1.3D7ED%acee@cisco.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> <56447BC1.9080409@cisco.com> <16755_1447433279_5646143F_16755_202_1_5646143E.8000701@orange.com> <56461CDC.1050406@cisco.com>
In-Reply-To: <56461CDC.1050406@cisco.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.203]
Content-Type: text/plain; charset="utf-8"
Content-ID: <FDCA354BE8E3FA4A9077B20EC5F6E910@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/ospf/Oy7aUhpoYH8QmZBr1BsLQZvW6mw>
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: Fri, 13 Nov 2015 19:54:20 -0000

Furthermore, I don’t see how you’d interpret this as Jeff being against
advertising SRLG in a more efficient and standard manner for IP
applications. He was simply acknowledging the fact that there is
proprietary usage of the GMPLS TE extensions beyond GMPLS.

Thanks,
Acee 

On 11/13/15, 12:24 PM, "Peter Psenak (ppsenak)" <ppsenak@cisco.com> wrote:

>Hi Julien,
>
>please see inline:
>
>On 11/13/15 17:47 , julien.meuric@orange.com wrote:
>> Hi Peter,
>>
>> See [JM] below.
>>
>>
>> Nov. 12, 2015 - ppsenak@cisco.com:
>>> 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.
>>
>> [JM] I am happy to quote Jeff on this: "thanks to GMPLS IGP extensions
>> as per RFC's 4203 & 5307 SRLG info is there, it is up to implementation
>> how to use it."
>> 
>>(https://mailarchive.ietf.org/arch/msg/rtgwg/yURBLVi2LqrEz33wKkauV0j9cmA)
>
>Jeff is a co-author of the ospf-te-link-attr-reuse, so I let him express
>his opinion, but he has responded on the list already saying:
>
>"I'm familiar with at least 2 implementations which have this issue,
>this draft solves real problem."
>
>>
>>>
>>> The risk is when you do what you propose to do as it breaks the
>>>existing
>>> TE
>>
>> [JM] This is different from Acee's point: "usage of the TE LSAs for
>> non-TE purposes was NEVER standardized". It is not about breaking, it is
>> about documenting use cases beyond the original one.
>>
>>   - 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.
>>
>> [JM] Supposing I am an operator who is playful enough to manage a
>> network area using a topology for TE traffic that does not match the
>> IP/LDP topology (you may find this realistic, I do not). Then, a router
>> ignoring that an SRLG-enabled link has no available bandwidth/a specific
>> affinity/a non-PSC switching capability/etc. is misbehaving.
>
>well, that is not necessarily true, for example 0 bandwidth tunnels are
>often used. RFC3630 does not mandate bandwidth, affinity or any other
>link attributes in TE Opaque LSAs. Link Type and Link ID sub-TLVs are
>mandatory, rest are optional.
>
>>
>> Anyway, this moves beyond the issue at stake here. Acee states that some
>> implementations need new definitions to go beyond the original use case.
>> I would like to limit the number of fields opening the doors to
>> operational inconsistencies. In these regards, an "applicability
>> statement of TE LSA parameters beyond MPLS-TE" may be a way to address
>> our concerns.
>
>I'm afraid we can not afford to change the RCF that has been published
>12 years back. This would make it backward incompatible.
>
>>
>> Enjoy the week-end,
>
>you too!
>
>thanks,
>Peter
>
>>
>> Julien
>>
>>
>>>
>>>
>>> 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
>>>>>
>>>> .
>>>>
>>>
>>
>> 
>>_________________________________________________________________________
>>________________________________________________
>>
>>
>> Ce message et ses pieces jointes peuvent contenir des informations
>> confidentielles ou privilegiees et ne doivent donc
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
>> recu ce message par erreur, veuillez le signaler
>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
>> electroniques etant susceptibles d'alteration,
>> Orange decline toute responsabilite si ce message a ete altere, deforme
>> ou falsifie. Merci.
>>
>> This message and its attachments may contain confidential or privileged
>> information that may be protected by law;
>> they should not be distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender and
>> delete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have
>> been modified, changed or falsified.
>> Thank you.
>>
>> .
>>
>