From nobody Mon Nov 30 19:52:02 2020 Return-Path: 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 1BC623A08A5 for ; Mon, 30 Nov 2020 19:52:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no 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 cD50_vwKs4DM for ; Mon, 30 Nov 2020 19:51:56 -0800 (PST) Received: from mail-m127101.qiye.163.com (mail-m127101.qiye.163.com [115.236.127.101]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 853423A0876 for ; Mon, 30 Nov 2020 19:51:55 -0800 (PST) Received: from DESKTOP2IOH5QC (unknown [219.142.69.75]) by mail-m127101.qiye.163.com (Hmail) with ESMTPA id 41DB746C69; Tue, 1 Dec 2020 11:51:48 +0800 (CST) From: "Aijun Wang" To: "'Acee Lindem \(acee\)'" , "'Alexander Okonnikov'" , "'Van De Velde, Gunter \(Nokia - BE/Antwerp\)'" Cc: , "'Peter Psenak \(ppsenak\)'" 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> <10D19997-F6CA-45A2-A5C3-C14C8FD41069@cisco.com> In-Reply-To: <10D19997-F6CA-45A2-A5C3-C14C8FD41069@cisco.com> Date: Tue, 1 Dec 2020 11:51:47 +0800 Message-ID: <00d801d6c795$4b7d3680$e277a380$@tsinghua.org.cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D9_01D6C7D8.59A3AAD0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJPZKx16EHlYEQ6dUFarTaMgdWqZQGxe/opAbfkCk8B44MDiwJMTvyjAc962aoBv+e1QgIO0I5NAVK5zVmofAq4sA== Content-Language: zh-cn X-HM-Spam-Status: e1kfGhgUHx5ZQUtXWQgYFAkeWUFZS1VLWVdZKFlBSkxLS0o3V1ktWUFJV1 kPCRoVCBIfWUFZSx9PQk1IGk4YGEtIVkpNS01MQk9MS0NOTUJVEwETFhoSFyQUDg9ZV1kWGg8SFR 0UWUFZT0tIVUpKS09ISFVLWQY+ X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6Pxg6HBw4FD8oQkM1OTAOCAMI HB8wCilVSlVKTUtNTEJPTEtCS0hOVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlJSkJVSk9JVU1CVUxOWVdZCAFZQU1KTkhONwY+ X-HM-Tid: 0a761c6d85d39865kuuu41db746c69 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2020 03:52:00 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00D9_01D6C7D8.59A3AAD0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi,=20 =20 How about using the stub-link that we proposed and discussed at = https://mailarchive.ietf.org/arch/msg/lsr/LppwUNb_ngr8m4awaprvSHGFfhg/ = to solve the scenario that described in RFC5185? The possible solution is the following: 1) The ABR form only the normal adjacency within the backbone area. 2) For other area(for example, area 1) that they belong, each of = them advertise the stub-link TLV, which include the network prefix that = other area(area 1) belongs to, and also the metric to such prefix. 3) The OSPF treat the prefixes within this stub-link TLV as the = intra-area prefix in other area(area 1) and will prefer to using them = over the inter-area prefix in the non-multi-area solution. 4) More areas can be configured on such ABRs, eliminate the = necessary to configure interface address within each area, also = eliminate the ambiguity for using the remote peer address to = differentiate the different adjacency. 5) It is also easy to correlate such link information with the TE = information that advertised in RFC3630. Are the above proposal acceptable? =20 Best Regards =20 Aijun Wang China Telecom =20 From: lsr-bounces@ietf.org On Behalf Of Acee = Lindem (acee) Sent: Tuesday, December 1, 2020 1:58 AM To: Alexander Okonnikov ; Van De Velde, = Gunter (Nokia - BE/Antwerp) Cc: lsr@ietf.org; Peter Psenak (ppsenak) Subject: Re: [Lsr] Link Data value for Multi-area links =20 Speaking on WG member: =20 Hi Alex,=20 I knew this was coming. In 2008, 99.9% of the requirements were handled = by supporting an interface in a primary area and one other area. Using = the remote IP address for the other area does handle this case. As I = stated previously, if you support OSPF adjacencies on secondary IP = addresses, the MIB and other complexities are all taken care of and that = would be the solution that I would recommend. However, if you guys want = to spend time trying to improve RFC5185, you are perfectly welcome to = submit a draft.=20 =20 Thanks, Acee =20 From: Alexander Okonnikov > Date: Monday, November 30, 2020 at 12:47 PM To: Gunter Van de Velde > Cc: Acee Lindem >, "Peter Psenak = (ppsenak)" >, = "lsr@ietf.org " > Subject: Re: [Lsr] Link Data value for Multi-area links =20 Hi Acee, =20 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. =20 30 =D0=BD=D0=BE=D1=8F=D0=B1. 2020 =D0=B3., =D0=B2 20:20, Van De Velde, = Gunter (Nokia - BE/Antwerp) > = =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB(=D0=B0): =20 The oddnes is that the architecture decision in RFC5185 to select = remote-ip-address instead of local-ip-address for the =E2=80=98Link = Data=E2=80=99 is making things much more complicated. I am surprised to see that using the remote-ip-address is seen as the = =E2=80=98better=E2=80=99 choice as selecting local-ip-address. To me it = seems as a worse choice. =20 A question that was asked: How router will be able to match Link TLV = (RFC 3630) to corresponding Link in Router LSA? =20 Answer: For unnumbered links we can match Link TLV with Router TLV using the = IfIndex when there is no stub type 3 link (=3Deasy) For numbered: 1. we must first look if the there is a stub type 3 link 2. 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 3. 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=E2=80=A6 This may give a match or no match 4. 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 5. =3D over-complex. (If we used for RFC5185 =E2=80=98Link Data = =3D local ip address=E2=80=99 then (2) would given answer directly) =20 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? =20 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. =20 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? =20 Brgds, G/ =20 =20 From: Lsr > On = Behalf Of Acee Lindem (acee) Sent: Monday, November 30, 2020 18:01 To: Alexander Okonnikov >; Peter Psenak (ppsenak) = > Cc: lsr@ietf.org =20 Subject: Re: [Lsr] Link Data value for Multi-area links =20 Hi Alex,=20 =20 Multi-Area interface disambiguation is required to support the OSPF MIB = as specified in RFC 4750. The table indexing doesn=E2=80=99t include the = area. For example: =20 -- OSPF Interface Table =20 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" ::=3D { ospf 7 } =20 ospfIfEntry OBJECT-TYPE SYNTAX OspfIfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The OSPF interface entry describes one interface from the viewpoint of OSPF. =20 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 } ::=3D { ospfIfTable 1 } =20 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. =20 =20 Thanks, Acee =20 =20 From: Lsr > on = behalf of Alexander Okonnikov > Date: Monday, November 30, 2020 at 5:27 AM To: "Peter Psenak (ppsenak)" > Cc: "lsr@ietf.org " > Subject: Re: [Lsr] Link Data value for Multi-area links =20 Hi Peter, =20 30 =D0=BD=D0=BE=D1=8F=D0=B1. 2020 =D0=B3., =D0=B2 12:56, Peter Psenak = > = =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB(=D0=B0): =20 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. =20 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). =20 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. =20 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? =20 thanks, Peter =20 Thank you. =20 Thank you. 27 =D0=BD=D0=BE=D1=8F=D0=B1. 2020 =D0=B3., =D0=B2 14:50, Peter Psenak = > = =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB(=D0=B0): 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 =20 https://www.ietf.org/mailman/listinfo/lsr =20 ------=_NextPart_000_00D9_01D6C7D8.59A3AAD0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

H= i,

<= o:p> 

H= ow about using the stub-link that we proposed and discussed at https://mailarchive.ietf.org/arch/msg/lsr/LppwUNb_ngr8m4awaprvSHGF= fhg/ to solve the scenario that described in = RFC5185?

T= he possible solution is the following:

<= span style=3D'mso-list:Ignore'>1)     T= he ABR form only the normal adjacency within the backbone = area.

<= span style=3D'mso-list:Ignore'>2)     F= or other area(for example, area 1) that they belong, each of them = advertise the stub-link TLV, which include the network prefix that other = area(area 1) belongs to, and also the metric to such = prefix.

<= span style=3D'mso-list:Ignore'>3)     T= he OSPF treat the prefixes within this stub-link TLV as the intra-area = prefix in other area(area 1) and will prefer to using them over the = inter-area prefix in the non-multi-area = solution.

<= span style=3D'mso-list:Ignore'>4)     M= ore areas can be configured on such ABRs, eliminate the necessary to = configure interface address within each area, also eliminate the = ambiguity for using the remote peer address to differentiate the = different adjacency.

<= span style=3D'mso-list:Ignore'>5)     I= t is also easy to correlate such link information with the TE = information that advertised in RFC3630.

A= re the above proposal acceptable?

<= o:p> 

B= est Regards

<= o:p> 

A= ijun Wang

C= hina Telecom<= o:p>

<= o:p> 

From: lsr-bounces@ietf.org = <lsr-bounces@ietf.org> On Behalf Of Acee Lindem = (acee)
Sent: Tuesday, December 1, 2020 1:58 AM
To: = Alexander Okonnikov <alexander.okonnikov@gmail.com>; Van De Velde, = Gunter (Nokia - BE/Antwerp) = <gunter.van_de_velde@nokia.com>
Cc: lsr@ietf.org; Peter = Psenak (ppsenak) <ppsenak@cisco.com>
Subject: Re: [Lsr] = Link Data value for Multi-area links

 

Speaking on WG member:

 

Hi Alex,

I knew this was coming. In 2008, 99.9% of the requirements = were handled by supporting an interface in a primary area and one other = area. Using the remote IP address for the other area does handle this = case. As I stated previously, if you support OSPF adjacencies on = secondary IP addresses, the MIB and other complexities are all taken = care of and that would be the solution that I would recommend. However, = if you guys want to spend time trying to improve RFC5185, you are = perfectly welcome to submit a draft.

 

Thanks,

Acee

 

From: = Alexander Okonnikov <alexander.okonnikov@gmail.c= om>
Date: Monday, November 30, 2020 at 12:47 = PM
To: Gunter Van de Velde <gunter.van_de_velde@nokia.c= om>
Cc: Acee Lindem <acee@cisco.com>, "Peter = Psenak (ppsenak)" <ppsenak@cisco.com>, "lsr@ietf.org" <lsr@ietf.org>
Subject: Re: = [Lsr] Link Data value for Multi-area = links

 

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 =D0=BD=D0=BE=D1=8F=D0=B1. 2020 =D0=B3., =D0=B2 20:20, = Van De Velde, Gunter (Nokia - BE/Antwerp) <gunter.van_de_velde@nokia.c= om> = =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB(=D0=B0):

=

 

The oddnes is that the architecture decision in RFC5185 to = select remote-ip-address instead of local-ip-address for the = =E2=80=98Link Data=E2=80=99 is making things much more = complicated.

I am surprised to see that using the remote-ip-address is = seen as the =E2=80=98better=E2=80=99 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 = (=3Deasy)

For numbered:

1.       = we must first look if = the there is a stub type 3 link

2.       = 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

3.       = 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=E2=80=A6 This may give a = match or no match

4.       = 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

5.       = =3D over-complex. (If = we used  for RFC5185 =E2=80=98Link Data =3D local ip = address=E2=80=99 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.c= 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=E2=80=99t 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"

       ::=3D { 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 = }

       ::=3D { 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> on = behalf of Alexander Okonnikov <alexander.okonnikov@gmail.c= om>
Date: Monday, November 30, 2020 = at 5:27 AM
To: "Peter Psenak = (ppsenak)" <ppsenak@cisco.com>
Cc: "lsr@ietf.org" <lsr@ietf.org>
Subject: Re: [Lsr] Link Data value = for Multi-area links

 

Hi Peter,

 

30 =D0=BD=D0=BE=D1=8F=D0=B1. 2020 =D0=B3., =D0=B2 12:56, = Peter Psenak <ppsenak@cisco.com> = =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB(=D0=B0):

=

 

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,
Pe= ter

 

Thank you.

 

Thank = you.

27 = =D0=BD=D0=BE=D1=8F=D0=B1. 2020 =D0=B3., =D0=B2 14:50, Peter Psenak = <ppsenak@cisco.com> = =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB(=D0=B0):

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?


Advertisi= ng 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/m= ailman/listinfo/lsr

 

------=_NextPart_000_00D9_01D6C7D8.59A3AAD0--