Re: [Lsr] Link Data value for Multi-area links

Alexander Okonnikov <alexander.okonnikov@gmail.com> Mon, 30 November 2020 17:47 UTC

Return-Path: <alexander.okonnikov@gmail.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9241C3A0EFF for <lsr@ietfa.amsl.com>; Mon, 30 Nov 2020 09:47:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 kbja4glFZ2QT for <lsr@ietfa.amsl.com>; Mon, 30 Nov 2020 09:47:09 -0800 (PST)
Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EA7E3A0EFC for <lsr@ietf.org>; Mon, 30 Nov 2020 09:47:09 -0800 (PST)
Received: by mail-lf1-x12a.google.com with SMTP id a9so23258911lfh.2 for <lsr@ietf.org>; Mon, 30 Nov 2020 09:47:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=vA+Tv4QOmf5U/bSy/gk0fnK3JFcuaEZXs5HtiSBZknc=; b=MjP9Rl05jMoU2V4uI/sFpe194+JcU1M4veob1Z/jDrP76nVc73T8XLGGs0f9NJy6+q jg7snowbbispYE2uyN/YKS2cEkqWYuOwKhugStderZMxWam6Gai8P5vlXipugqRVaWGI EXu8knv9z+ebedzn7rks+kLvzwYiyaAc2icOyQFb4uAmI9zsCt0gjLyIvVMBeL0hv+XO opZml0BrJcpLwWSELNi0uIynPJS7p9bbFXqX7H6ikPCebFuYkIkUS1c4bFP3Ysibcgqp Ve3qtuLKh2+jAvjWhiJ0tMH0ZuA6aR5UQB39NfNnmtoq8NnFA1cao0K2+5rVddJyHsUg CaUA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=vA+Tv4QOmf5U/bSy/gk0fnK3JFcuaEZXs5HtiSBZknc=; b=jm63ooRDMlBGxwElZztpHk5urnnh1Uf7OhXbT4b1P2RyOBlKAJf64GgBLqRy9taOZ2 cK7b3keOYKPHcDJAeMf28RIJhLCsbp2AflZaw/NJN4E+XdgCiJs95ozu67vTBu1AUbbi QbLbbwCeAmNN1q7GyNIZtdUJkRa2aPZBg3Hez8JvNfkTmVD2Opo3So8G8c1/jiq2VNTw 4br2Q79SIYY5tMU2TjTxl8KkwrJf2jQOskuPobJpdZ/DSPLndxWb4b0fLGqaTfeX63An wc8u/I7MPoltxTxCnk4WVHf0IfOtMUoifRRyL9UPQf9276x3/Dv6GaYrLlf+Jid+uLom +v7g==
X-Gm-Message-State: AOAM53057+UE4sAzUb5GCudiLlotJY/0oETyfEuuZKPfmN0mAUXm6OQf oHUr+8tiPE+/hxtOSf1Z3PA=
X-Google-Smtp-Source: ABdhPJwnegK9qSg7R6FHNaHEGk+nXapBd/b1AsbsYX5xlYi3E+HroNqq98r1rzVQVsTB21BNRqALNw==
X-Received: by 2002:a19:17:: with SMTP id 23mr10103163lfa.389.1606758426985; Mon, 30 Nov 2020 09:47:06 -0800 (PST)
Received: from [10.0.1.3] ([194.39.99.206]) by smtp.gmail.com with ESMTPSA id h2sm2419360lfc.76.2020.11.30.09.47.06 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Nov 2020 09:47:06 -0800 (PST)
From: Alexander Okonnikov <alexander.okonnikov@gmail.com>
Message-Id: <D9F406B7-793A-458D-AEA7-74E6746017F8@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_DD054582-A014-4CC6-AF11-30CB73D93E04"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Mon, 30 Nov 2020 20:47:05 +0300
In-Reply-To: <AM0PR07MB6386BE057F092AD0837FE299E0F50@AM0PR07MB6386.eurprd07.prod.outlook.com>
Cc: "Acee Lindem (acee)" <acee=40cisco.com@dmarc.ietf.org>, "Peter Psenak (ppsenak)" <ppsenak@cisco.com>, "lsr@ietf.org" <lsr@ietf.org>
To: "Van De Velde, Gunter (Nokia - BE/Antwerp)" <gunter.van_de_velde@nokia.com>
References: <61201EB5-3F36-401A-9D39-FB0C577C7966@gmail.com> <3d3d863b-3e1f-ea87-0c45-09e119aa7c8f@cisco.com> <3FE4F6F8-6819-425E-852F-6B5B968ECAF5@gmail.com> <57b88873-b0e9-c2d3-2732-7f2629eebf27@cisco.com> <5D89BE28-934A-4EE3-915A-456AAD7AC59C@gmail.com> <F386F007-BA51-44B6-9795-18DE3E564D75@cisco.com> <AM0PR07MB6386BE057F092AD0837FE299E0F50@AM0PR07MB6386.eurprd07.prod.outlook.com>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/2xXoQYGoIJ-CxFYzlqRHFot7hZg>
Subject: Re: [Lsr] Link Data value for Multi-area links
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Nov 2020 17:47:14 -0000

Hi Acee,

RFC 5185 says that interface data structure is created for each multi-area adjacency. I guess that we are not allowed to allocate several ifIndex values for the same IP interface, because it is property of router's interface, not OSPF interface. Hence, we have several OSPF interfaces with the same ifIndex in unnumbered case and, thus, ambiguity in Interface table. The same for numbered - we have IP interface address (one), which is the same for multiple OSPF interfaces, and we again obtain ambiguity. Per my understanding advertising neighbor's IP address (or ifIndex) in Link Data doesn't help here.

> 30 нояб. 2020 г., в 20:20, Van De Velde, Gunter (Nokia - BE/Antwerp) <gunter.van_de_velde@nokia.com> написал(а):
> 
> The oddnes is that the architecture decision in RFC5185 to select remote-ip-address instead of local-ip-address for the ‘Link Data’ is making things much more complicated.
> I am surprised to see that using the remote-ip-address is seen as the ‘better’ choice as selecting local-ip-address. To me it seems as a worse choice.
>  
> A question that was asked: How router will be able to match Link TLV (RFC 3630) to corresponding Link in Router LSA?
>  
> Answer:
> For unnumbered links we can match Link TLV with Router TLV using the IfIndex when there is no stub type 3 link (=easy)
> For numbered:
> we must first look if the there is a stub type 3 link
> If stub type 3 exists, then the RFC3630 local ip address must be used to identify the correspond link within the router TLV to the neighbor
> If the stub type 3 link did not exist in Router TLV link, then the maybe the link is unnumbered, and we try to match upon IfIndex… This may give a match or no match
> If there is no match, then maybe the link is MADJ and we must use the RFC3630 remote IP address to match upon the Link Data
> = over-complex. (If we used  for RFC5185 ‘Link Data = local ip address’ then (2) would given answer directly)
>  
> In addition, for a router it is much simpler to learn and advertise local-ip-address in Router LSAs then using a remote-ip-address.
> I also believe that if we want to search something in TEDB after receiving a TE Link TLV. How can we identify from the TE Link TLV if multi-area or not multi-area? If we can not, then how can we create the correct key?
>  
> Looking at the above, the choice of using remote-ip-address for RFC5185 Link Data seems not the best design that we can do, and is adding OSPF complexity without benefits.
>  
> Should this not be corrected in RFC5185 and simply use local-ip-address instead of the remote-ip-address for Multi-area Link Data and avoid the additional unnecessary complexity the current RFC for numbered links?
>  
> Brgds,
> G/
>  
>  
> From: Lsr <lsr-bounces@ietf.org> On Behalf Of Acee Lindem (acee)
> Sent: Monday, November 30, 2020 18:01
> To: Alexander Okonnikov <alexander.okonnikov@gmail.com>om>; Peter Psenak (ppsenak) <ppsenak@cisco.com>
> Cc: lsr@ietf.org
> Subject: Re: [Lsr] Link Data value for Multi-area links
>  
> Hi Alex, 
>  
> Multi-Area interface disambiguation is required to support the OSPF MIB as specified in RFC 4750. The table indexing doesn’t include the area. For example:
>  
> --  OSPF Interface Table
>  
>   ospfIfTable OBJECT-TYPE
>        SYNTAX       SEQUENCE OF OspfIfEntry
>        MAX-ACCESS   not-accessible
>        STATUS       current
>        DESCRIPTION
>           "The OSPF Interface Table describes the interfaces
>           from the viewpoint of OSPF.
>           It augments the ipAddrTable with OSPF specific information."
>        REFERENCE
>           "OSPF Version 2, Appendix C.3  Router interface
>           parameters"
>        ::= { ospf 7 }
>  
>   ospfIfEntry OBJECT-TYPE
>        SYNTAX       OspfIfEntry
>        MAX-ACCESS   not-accessible
>        STATUS       current
>        DESCRIPTION
>           "The OSPF interface entry describes one interface
>           from the viewpoint of OSPF.
>  
>           Information in this table is persistent and when this object
>           is written the entity SHOULD save the change to non-volatile
>           storage."
>        INDEX { ospfIfIpAddress, ospfAddressLessIf }
>        ::= { ospfIfTable 1 }
>  
> Note that if you really want to support this optimally, you could use a separate subnet pre-area and have adjacencies on secondary addresses. My Redback/Ericsson implementation allowed for this.   
>  
> Thanks,
> Acee
>  
>  
> From: Lsr <lsr-bounces@ietf.org <mailto:lsr-bounces@ietf.org>> on behalf of Alexander Okonnikov <alexander.okonnikov@gmail.com <mailto:alexander.okonnikov@gmail.com>>
> Date: Monday, November 30, 2020 at 5:27 AM
> To: "Peter Psenak (ppsenak)" <ppsenak@cisco.com <mailto:ppsenak@cisco.com>>
> Cc: "lsr@ietf.org <mailto:lsr@ietf.org>" <lsr@ietf.org <mailto:lsr@ietf.org>>
> Subject: Re: [Lsr] Link Data value for Multi-area links
>  
> Hi Peter,
>  
> 
> 30 нояб. 2020 г., в 12:56, Peter Psenak <ppsenak@cisco.com <mailto:ppsenak@cisco.com>> написал(а):
>  
> Hi Alex,
> 
> On 27/11/2020 13:49, Alexander Okonnikov wrote:
> 
> Hi Peter,
> Which kind of ambiguity is meant? In case of numbered point-to-point each link has its own unique IP address, so there is no ambiguity.
> Per my understanding this problem has appeared due to follow reasons:
> 1) In old versions of the draft (up to -05) it was proposed that multi-area links are treated as unnumbered. ifIndex to be encoded in Link Data field, irrespectively whether interface has its own IP address (numbered) or borrow it (unnumbered);
> 2) From -06 to -08 multi-area links are still treated as unnumbered, but if interface is numbered, then IP address of the neighbor (rather than local one) to be encoded into Link Data, in order to make the link look like unnumbered;
> 3) In version -09 of the draft and in RFC 5185 itself there is no more mentions that multi-area link to be treated as unnumbered. Rather, another approach is used - if router's interface is numbered, then link is also numbered; if router's interface is unnumbered, then link is unnumbered. The rule that specifies omitting corresponding type 3 link is added. Mention of 'unnumbered' link is also removed from section 3 in RFC 5185. >
> Hence, in version -09 with removing unnumbered nature of multi-area links Link Data for numbered links had to be changed from Neighbor's IP address to own IP address, as it is specified in RFC 2328. From perspective of other routers this link can be treated as numbered or unnumbered, depending on configuration of neighbor's corresponding interface.
> 
> you are free to advertise the link as unnumbered. RFC5185 is not mandating to send IP address really.
>  
> The same valid for numbered ones. I.e. I'm free to advertise the link as numbered. This is straightforward when the link is numbered indeed. And if we would prefer to have deal with unnumbered interfaces, we would not need RFC 5185 (section 1.2).
>  
> 
> One question - how neighboring router will perform next-hop calculation (in case it needs to do so)? If neighbor is configured with numbered interface, it will treat Link Data as IP next hop, which will be its own IP interface address.
> Another question - how router will be able to match Link TLV (RFC 3630) to corresponding Link in Router LSA? For example, we want to calculate RSVP-TE LSP based on IGP metric (RFC 3785) and thus router needs to match IGP link to TE link.
> 
> I don't believe you are going to do any traffic engineering over a multi-area adjacency. MADJ is there to address the OSPF route preference rules that may lead to sub-optimal routing. MADJ link is not advertised for TE purposes.
>  
> Why not? We need multi-area configuration and at the same time we need ability to build intra-area RSVP-TE LSPs within each of areas. And what about calculating IP next hop? Which compatibility is meant in section 3?
>  
> thanks,
> Peter
>  
> Thank you.
>  
> 
> Thank you.
> 
> 27 нояб. 2020 г., в 14:50, Peter Psenak <ppsenak@cisco.com <mailto:ppsenak@cisco.com>> написал(а):
> 
> Alexander,
> 
> On 26/11/2020 17:58, Alexander Okonnikov wrote:
> 
> Hi WG,
> RFC 5185 says that Neighbor's IP address to be encoded into Link Data field. Per RFC 2328 router's own IP address to be encoded into Link Data. What is the reason to advertise neighbor's IP address for multi-area links and not local IP address? It seems like bug. Could someone comment on this?
> 
> Advertising a neighbor address/ifindex helps to eliminate ambiguity in case of parallel point-to-point adjacencies. It's not perfect, but that's how it was specified. So it's not a bug.
> 
> thanks,
> Peter
> 
> 
> Thanks in advance.
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org <mailto:Lsr@ietf.org>
> https://www.ietf.org/mailman/listinfo/lsr <https://www.ietf.org/mailman/listinfo/lsr>