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

Alexander Okonnikov <alexander.okonnikov@gmail.com> Fri, 27 November 2020 12:49 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 B27D03A0AE6 for <lsr@ietfa.amsl.com>; Fri, 27 Nov 2020 04:49:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 qCe6mtmZAKeq for <lsr@ietfa.amsl.com>; Fri, 27 Nov 2020 04:49:22 -0800 (PST)
Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (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 D41103A0AE5 for <lsr@ietf.org>; Fri, 27 Nov 2020 04:49:21 -0800 (PST)
Received: by mail-lf1-x12d.google.com with SMTP id l11so6918381lfg.0 for <lsr@ietf.org>; Fri, 27 Nov 2020 04:49:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+OG5iEkLSNUcmULQpolOSMsNymuyccpx3SMNlKMV2vw=; b=cTelOQwIMK9adTkgGJYKHFochHxsOc5cqhTPz4xRYu2KocMoK6LvA0cBOnuOdt/fjs UzABj9T5porwVWhgTHheRv5uRlaBF5XGl2tX4nFMZljAN4l4wAj3QXPpK56vrLjpftlF u7ypG+fV84m+e+Pn9nuzK9bZk/zKIIrvkC88LgZSFJhgfZJ8gN4erW62CGkX8TYCYJ0l GeLdqLEjvRso7m+jpcxUzvDp51MGX74KB+4b2yluyxC+yy+LSPWcbll/htQi0BHeYmxm PX2jc2wjYvkgIFjar9PLN0A9d/pvBg2BXbkH5IABTdSFlXGSRTsvJqu+GZGBAsu6P/fx /daw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+OG5iEkLSNUcmULQpolOSMsNymuyccpx3SMNlKMV2vw=; b=HLviVnsvjZSsgoFzMcL/BTXEBvij5uwh2ZQxJLzDb+jE4HE2P52zAr/exo0EG4B5gS wG6RZ9QIKCaqDtL9LZ7Ir6/98Zncid2uEq7ZiL8eF+WGd0hdGOKEpBzZ/ZDhupf5oYUZ S1m5tvHg5IYEejiwTLbLnIhCQ0hSSGwCIlT7Y1gytYNlU3OnJQzf0mUf+D7MqjhORVWu MIjVenOCKiUh4XLNVsRF0qzOGo2Hs0IbsLbeNqlWKi+i7HffmBY65U4MpVIWFTp1zAyE jYM6CzENtbhbvZHSvTdnb5/0Cbq83vJqGsyMBKxrptTh/SuxQjEZTWzohJIvnvD84EJm ds3w==
X-Gm-Message-State: AOAM533xbwPfxKX4oTybW3/d2ExgqyTRmL4ZjycqQQloe9k9AazxFAy3 LdW8sB1tHAdgFRvdhO1tgRw=
X-Google-Smtp-Source: ABdhPJzloRKkGl44GQ9fi5b+eLVquGpLN8jskQneRdVgoGrTEeqsmOUeL85spTer/jLnBdCod+C/hg==
X-Received: by 2002:a19:6d15:: with SMTP id i21mr3143046lfc.166.1606481359853; Fri, 27 Nov 2020 04:49:19 -0800 (PST)
Received: from [10.0.1.3] ([194.39.99.206]) by smtp.gmail.com with ESMTPSA id m202sm675317lfa.208.2020.11.27.04.49.19 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 27 Nov 2020 04:49:19 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
From: Alexander Okonnikov <alexander.okonnikov@gmail.com>
In-Reply-To: <3d3d863b-3e1f-ea87-0c45-09e119aa7c8f@cisco.com>
Date: Fri, 27 Nov 2020 15:49:18 +0300
Cc: lsr@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <3FE4F6F8-6819-425E-852F-6B5B968ECAF5@gmail.com>
References: <61201EB5-3F36-401A-9D39-FB0C577C7966@gmail.com> <3d3d863b-3e1f-ea87-0c45-09e119aa7c8f@cisco.com>
To: Peter Psenak <ppsenak@cisco.com>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/L__NPBhjieYlUkp6MfCgMpWAEaQ>
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: Fri, 27 Nov 2020 12:49:24 -0000

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.

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.

Thank you.

> 27 нояб. 2020 г., в 14:50, Peter Psenak <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
>> https://www.ietf.org/mailman/listinfo/lsr
>