Re: [Lsr] Link Data value for Multi-area links
All, If we were to do an RFC 5185BIS, my opinion is that it would say that the MADJ OSPF interfaces are not included in the OSPF MIB tables that don’t support the ambiguity. Now we have the ietf-ospf.yang model with interfaces lists in the area hierarchy. At present, this is a very low priority for me and I probably wouldn’t take the lead on this any time soon. a Thanks, Acee From: "Ketan Talaulikar (ketant)" Date: Friday, December 4, 2020 at 3:20 AM To: Aijun Wang , Acee Lindem , Alexander Okonnikov , Gunter Van de Velde Cc: "lsr@ietf.org" , "Peter Psenak (ppsenak)" Subject: RE: [Lsr] Link Data value for Multi-area links Hi Aijun, OSPF MIB RFC4750 was published before MADJ was introduced in OSPF. I would think it is quite natural that it does not consider MADJ. If your proposal is to fix/extend OSPF MIB in 202x for MADJ then do please go ahead. As a reference you can look at how this is handled in the OSPF YANG model : https://tools.ietf.org/html/draft-ietf-ospf-yang-29#section-2.7 MADJ is a well-known, widely implemented and deployed feature. What we have been debating is more of a “point fix” to RFC5185. So I do not follow what is it exactly that you are proposing? Thanks, Ketan From: Aijun Wang Sent: 04 December 2020 12:31 To: Ketan Talaulikar (ketant) ; 'Acee Lindem (acee)' ; '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 Hi, Ketan: Using the local ip address or IfIndex can solve the correlation with the Link TLV in RFC3630, but it still does not resolve the ambiguity problem that required by RFC4750(OSPF MIB) as Acee mentioned. Do we still follow this way? Best Regards Aijun Wang China Telecom From: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>> Sent: Thursday, December 3, 2020 5:35 PM To: Aijun Wang mailto:wangai...@tsinghua.org.cn>>; 'Acee Lindem (acee)' mailto:acee=40cisco@dmarc.ietf.org>>; 'Alexander Okonnikov' mailto:alexander.okonni...@gmail.com>>; 'Van De Velde, Gunter (Nokia - BE/Antwerp)' mailto:gunter.van_de_ve...@nokia.com>> Cc: lsr@ietf.org<mailto:lsr@ietf.org>; Peter Psenak (ppsenak) mailto:ppse...@cisco.com>> Subject: RE: [Lsr] Link Data value for Multi-area links Hi Aijun, Please check my previous response on this thread. The matter is quite simple and easily addressed. IMHO we do not need to invent a new protocol contraption or repurpose your stub-link proposal for this situation. Thanks, Ketan From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Aijun Wang Sent: 01 December 2020 09:22 To: 'Acee Lindem (acee)' mailto:acee=40cisco@dmarc.ietf.org>>; 'Alexander Okonnikov' mailto:alexander.okonni...@gmail.com>>; 'Van De Velde, Gunter (Nokia - BE/Antwerp)' mailto:gunter.van_de_ve...@nokia.com>> Cc: lsr@ietf.org<mailto:lsr@ietf.org>; Peter Psenak (ppsenak) mailto:ppse...@cisco.com>> Subject: Re: [Lsr] Link Data value for Multi-area links Hi, 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? Best Regards Aijun Wang China Telecom From: lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org> mailto:lsr-boun...@ietf.org>> On Behalf Of Acee Lindem (acee) Sent: Tuesday, December 1, 2020 1:58 AM To: Alexander Okonnikov mailto:alexander.okonni...@gmail.com>>; Van De Velde, Gunter (Nokia - BE/Antwerp) mailto:gunter.van_de_ve...@nokia.com>> Cc: lsr@ietf.org<mailto:lsr@ietf.org>; Peter Psenak (ppsenak) mailto:ppse...@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
Re: [Lsr] Link Data value for Multi-area links
Hi Aijun, OSPF MIB RFC4750 was published before MADJ was introduced in OSPF. I would think it is quite natural that it does not consider MADJ. If your proposal is to fix/extend OSPF MIB in 202x for MADJ then do please go ahead. As a reference you can look at how this is handled in the OSPF YANG model : https://tools.ietf.org/html/draft-ietf-ospf-yang-29#section-2.7 MADJ is a well-known, widely implemented and deployed feature. What we have been debating is more of a “point fix” to RFC5185. So I do not follow what is it exactly that you are proposing? Thanks, Ketan From: Aijun Wang Sent: 04 December 2020 12:31 To: Ketan Talaulikar (ketant) ; 'Acee Lindem (acee)' ; '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 Hi, Ketan: Using the local ip address or IfIndex can solve the correlation with the Link TLV in RFC3630, but it still does not resolve the ambiguity problem that required by RFC4750(OSPF MIB) as Acee mentioned. Do we still follow this way? Best Regards Aijun Wang China Telecom From: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>> Sent: Thursday, December 3, 2020 5:35 PM To: Aijun Wang mailto:wangai...@tsinghua.org.cn>>; 'Acee Lindem (acee)' mailto:acee=40cisco@dmarc.ietf.org>>; 'Alexander Okonnikov' mailto:alexander.okonni...@gmail.com>>; 'Van De Velde, Gunter (Nokia - BE/Antwerp)' mailto:gunter.van_de_ve...@nokia.com>> Cc: lsr@ietf.org<mailto:lsr@ietf.org>; Peter Psenak (ppsenak) mailto:ppse...@cisco.com>> Subject: RE: [Lsr] Link Data value for Multi-area links Hi Aijun, Please check my previous response on this thread. The matter is quite simple and easily addressed. IMHO we do not need to invent a new protocol contraption or repurpose your stub-link proposal for this situation. Thanks, Ketan From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Aijun Wang Sent: 01 December 2020 09:22 To: 'Acee Lindem (acee)' mailto:acee=40cisco@dmarc.ietf.org>>; 'Alexander Okonnikov' mailto:alexander.okonni...@gmail.com>>; 'Van De Velde, Gunter (Nokia - BE/Antwerp)' mailto:gunter.van_de_ve...@nokia.com>> Cc: lsr@ietf.org<mailto:lsr@ietf.org>; Peter Psenak (ppsenak) mailto:ppse...@cisco.com>> Subject: Re: [Lsr] Link Data value for Multi-area links Hi, 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? Best Regards Aijun Wang China Telecom From: lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org> mailto:lsr-boun...@ietf.org>> On Behalf Of Acee Lindem (acee) Sent: Tuesday, December 1, 2020 1:58 AM To: Alexander Okonnikov mailto:alexander.okonni...@gmail.com>>; Van De Velde, Gunter (Nokia - BE/Antwerp) mailto:gunter.van_de_ve...@nokia.com>> Cc: lsr@ietf.org<mailto:lsr@ietf.org>; Peter Psenak (ppsenak) mailto:ppse...@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 mailto:alexander.okonni...@gmail.com>> Date: Monday, November 30, 2020 at 12:47 PM To: Gunter Van de Velde mailto:gunter.van_de_ve...@nokia.com>> Cc: Acee Lindem mailto:a...@cisco.com>>, "Peter Psenak (ppsenak)" mailto:ppse...@cisco.com>>, "lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org
Re: [Lsr] Link Data value for Multi-area links
Hi, Ketan: Using the local ip address or IfIndex can solve the correlation with the Link TLV in RFC3630, but it still does not resolve the ambiguity problem that required by RFC4750(OSPF MIB) as Acee mentioned. Do we still follow this way? Best Regards Aijun Wang China Telecom From: Ketan Talaulikar (ketant) Sent: Thursday, December 3, 2020 5:35 PM To: Aijun Wang ; 'Acee Lindem (acee)' ; '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 Hi Aijun, Please check my previous response on this thread. The matter is quite simple and easily addressed. IMHO we do not need to invent a new protocol contraption or repurpose your stub-link proposal for this situation. Thanks, Ketan From: Lsr mailto:lsr-boun...@ietf.org> > On Behalf Of Aijun Wang Sent: 01 December 2020 09:22 To: 'Acee Lindem (acee)' mailto:acee=40cisco@dmarc.ietf.org> >; 'Alexander Okonnikov' mailto:alexander.okonni...@gmail.com> >; 'Van De Velde, Gunter (Nokia - BE/Antwerp)' mailto:gunter.van_de_ve...@nokia.com> > Cc: lsr@ietf.org <mailto:lsr@ietf.org> ; Peter Psenak (ppsenak) mailto:ppse...@cisco.com> > Subject: Re: [Lsr] Link Data value for Multi-area links Hi, 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? Best Regards Aijun Wang China Telecom From: lsr-boun...@ietf.org <mailto:lsr-boun...@ietf.org> mailto:lsr-boun...@ietf.org> > On Behalf Of Acee Lindem (acee) Sent: Tuesday, December 1, 2020 1:58 AM To: Alexander Okonnikov mailto:alexander.okonni...@gmail.com> >; Van De Velde, Gunter (Nokia - BE/Antwerp) mailto:gunter.van_de_ve...@nokia.com> > Cc: lsr@ietf.org <mailto:lsr@ietf.org> ; Peter Psenak (ppsenak) mailto:ppse...@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 mailto:alexander.okonni...@gmail.com> > Date: Monday, November 30, 2020 at 12:47 PM To: Gunter Van de Velde mailto:gunter.van_de_ve...@nokia.com> > Cc: Acee Lindem mailto:a...@cisco.com> >, "Peter Psenak (ppsenak)" mailto:ppse...@cisco.com> >, "lsr@ietf.org <mailto:lsr@ietf.org> " mailto: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 нояб. 2020 г., в 20:20, Van De Velde, Gunter (Nokia - BE/Antwerp) mailto:gunter.van_de_ve...@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
Re: [Lsr] Link Data value for Multi-area links
All I agree most vendor implementation of MADJ follow RFC 2328 I think for the same reason as the confusion mentioned on this thread with link data being the neighbor router which would make very confusing to troubleshoot. Since RFC 5185 is treating the MADJ as P2P it should really follow the P2P method of RFC 2328. For interoperability I think having this issue with RFC 5185 and some vendors may follow this approach and some may prefer to use more sensible RFC 2328 approach. Agreed this must be corrected. RFC 2328 12.4.1.1. Describing point-to-point interfaces For point-to-point interfaces, one or more link descriptions are added to the router-LSA as follows: o If the neighboring router is fully adjacent, add a Type 1 link (point-to-point). The Link ID should be set to the Router ID of the neighboring router. For numbered point-to-point networks, the Link Data should specify the IP interface address. For unnumbered point-to-point networks, the Link Data field should specify the interface's MIB-II [Ref8 <https://tools.ietf.org/html/rfc2328#ref-Ref8>] ifIndex value. The cost should be set to the output cost of the point-to-point interface. o In addition, as long as the state of the interface is "Point-to-Point" (and regardless of the neighboring router state), a Type 3 link (stub network) should be added. There are two forms that this stub link can take: Option 1 Assuming that the neighboring router's IP address is known, set the Link ID of the Type 3 link to the neighbor's IP address, the Link Data to the mask 0x (indicating a host route), and the cost to the interface's configured output cost.[15] Option 2 If a subnet has been assigned to the point-to- point link, set the Link ID of the Type 3 link to the subnet's IP address, the Link Data to the subnet's mask, and the cost to the interface's configured output cost.[16] On Thu, Dec 3, 2020 at 4:31 AM Ketan Talaulikar (ketant) wrote: > Hello All, > > > > The text in RFC5185 for picking the neighbor’s IP Address or IfIndex for > the link-data is indeed very odd and flies against how things are done for > normal p2p links per RFC2328. > > > > The implementations that I am aware of do not really following this > “decision” of RFC5185 and instead stick to RFC2328 architecture by picking > the local IP address or IfIndex even for MADJ links. This way, a remote > router cannot really distinguish between a normal P2P link or a MADJ – they > look the same in the LSDB. > > > > While the neighbor IP address can be learnt via the source address used > for the hello messages, there is really no simple way to learn the > neighbor’s IfIndex for unnumbered links [1]. > > > > So IMHO the RFC5185 is in error and we should fix this if we have > consensus in the WG via a BIS as suggested by Acee. > > > > Gunter, I am not getting into your other questions because of what I’ve > mentioned above > > > > Thanks, > > Ketan > > > > [1] Note that over time we have introduced such mechanisms (RFC8510), but > they have all been optional and not “base/required” behavior. > > > > *From:* Lsr *On Behalf Of *Acee Lindem (acee) > *Sent:* 30 November 2020 23:18 > *To:* Van De Velde, Gunter (Nokia - BE/Antwerp) < > gunter.van_de_ve...@nokia.com>; Alexander Okonnikov < > alexander.okonni...@gmail.com>; Peter Psenak (ppsenak) ; > Acee Lindem (acee) > *Cc:* lsr@ietf.org > *Subject:* Re: [Lsr] Link Data value for Multi-area links > > > > You are welcome to propose an alternate solution which could possibly be > accepted as a BIS document. However, this is not something that can be > simply changed in an Errata to reduce the complexity. > > Thanks, > Acee > > > > *From: *Lsr on behalf of Gunter Van de Velde < > gunter.van_de_ve...@nokia.com> > *Date: *Monday, November 30, 2020 at 12:21 PM > *To: *"Acee Lindem (acee)" , Alexander > Okonnikov , "Peter Psenak (ppsenak)" < > ppse...@cisco.com> > *Cc: *"lsr@ietf.org" > *Subject: *Re: [Lsr] Link Data value for Multi-area links > > > > The oddnes is that the architecture decision in RFC5185 to select > r
Re: [Lsr] Link Data value for Multi-area links
Hi Ketan, On 03/12/2020 11:26, Ketan Talaulikar (ketant) wrote: Hi Peter, Please check inline below. -Original Message- From: Peter Psenak Sent: 03 December 2020 15:48 To: Ketan Talaulikar (ketant) ; Acee Lindem (acee) ; Van De Velde, Gunter (Nokia - BE/Antwerp) ; Alexander Okonnikov ; Acee Lindem (acee) Cc: lsr@ietf.org Subject: Re: [Lsr] Link Data value for Multi-area links Hi Ketan, On 03/12/2020 10:31, Ketan Talaulikar (ketant) wrote: Hello All, The text in RFC5185 for picking the neighbor’s IP Address or IfIndex for the link-data is indeed very odd and flies against how things are done for normal p2p links per RFC2328. The implementations that I am aware of do not really following this “decision” of RFC5185 and instead stick to RFC2328 architecture by picking the local IP address or IfIndex even for MADJ links. This way, a remote router cannot really distinguish between a normal P2P link or a MADJ – they look the same in the LSDB. While the neighbor IP address can be learnt via the source address used for the hello messages, there is really no simple way to learn the neighbor’s IfIndex for unnumbered links [1]. rfc8510? [KT] Yes So IMHO the RFC5185 is in error and we should fix this if we have consensus in the WG via a BIS as suggested by Acee. I'm not convinced about the error. Nor about the need of the bis. [KT] The question is why is RFC5185 not aligned with base OSPF RFC2328 on this aspect? What was the need for MADJ to have a reverse link-data information as compared to normal P2P links? it has been defined that way and I believe it works. Unless there is something that is broken, why would we need to change? thanks, Peter Thanks, Ketan my 2c, Peter Gunter, I am not getting into your other questions because of what I’ve mentioned above Thanks, Ketan [1] Note that over time we have introduced such mechanisms (RFC8510), but they have all been optional and not “base/required” behavior. *From:*Lsr *On Behalf Of *Acee Lindem (acee) *Sent:* 30 November 2020 23:18 *To:* Van De Velde, Gunter (Nokia - BE/Antwerp) ; Alexander Okonnikov ; Peter Psenak (ppsenak) ; Acee Lindem (acee) *Cc:* lsr@ietf.org *Subject:* Re: [Lsr] Link Data value for Multi-area links You are welcome to propose an alternate solution which could possibly be accepted as a BIS document. However, this is not something that can be simply changed in an Errata to reduce the complexity. Thanks, Acee *From: *Lsr mailto:lsr-boun...@ietf.org>> on behalf of Gunter Van de Velde mailto:gunter.van_de_ve...@nokia.com>> *Date: *Monday, November 30, 2020 at 12:21 PM *To: *"Acee Lindem (acee)" mailto:acee=40cisco@dmarc.ietf.org>>, Alexander Okonnikov mailto:alexander.okonni...@gmail.com>>, "Peter Psenak (ppsenak)" mailto:ppse...@cisco.com>> *Cc: *"lsr@ietf.org <mailto:lsr@ietf.org>" mailto:lsr@ietf.org>> *Subject: *Re: [Lsr] Link Data value for Multi-area links 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: 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… 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.= 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 mailto:lsr-boun...@ietf.org>
Re: [Lsr] Link Data value for Multi-area links
Hi Peter, Please check inline below. -Original Message- From: Peter Psenak Sent: 03 December 2020 15:48 To: Ketan Talaulikar (ketant) ; Acee Lindem (acee) ; Van De Velde, Gunter (Nokia - BE/Antwerp) ; Alexander Okonnikov ; Acee Lindem (acee) Cc: lsr@ietf.org Subject: Re: [Lsr] Link Data value for Multi-area links Hi Ketan, On 03/12/2020 10:31, Ketan Talaulikar (ketant) wrote: > Hello All, > > The text in RFC5185 for picking the neighbor’s IP Address or IfIndex > for the link-data is indeed very odd and flies against how things are > done for normal p2p links per RFC2328. > > The implementations that I am aware of do not really following this > “decision” of RFC5185 and instead stick to RFC2328 architecture by > picking the local IP address or IfIndex even for MADJ links. This way, > a remote router cannot really distinguish between a normal P2P link or > a MADJ – they look the same in the LSDB. > > While the neighbor IP address can be learnt via the source address > used for the hello messages, there is really no simple way to learn > the neighbor’s IfIndex for unnumbered links [1]. rfc8510? [KT] Yes > > So IMHO the RFC5185 is in error and we should fix this if we have > consensus in the WG via a BIS as suggested by Acee. I'm not convinced about the error. Nor about the need of the bis. [KT] The question is why is RFC5185 not aligned with base OSPF RFC2328 on this aspect? What was the need for MADJ to have a reverse link-data information as compared to normal P2P links? Thanks, Ketan my 2c, Peter > > Gunter, I am not getting into your other questions because of what > I’ve mentioned above > > Thanks, > > Ketan > > [1] Note that over time we have introduced such mechanisms (RFC8510), > but they have all been optional and not “base/required” behavior. > > *From:*Lsr *On Behalf Of *Acee Lindem (acee) > *Sent:* 30 November 2020 23:18 > *To:* Van De Velde, Gunter (Nokia - BE/Antwerp) > ; Alexander Okonnikov > ; Peter Psenak (ppsenak) > ; Acee Lindem (acee) > *Cc:* lsr@ietf.org > *Subject:* Re: [Lsr] Link Data value for Multi-area links > > You are welcome to propose an alternate solution which could possibly > be accepted as a BIS document. However, this is not something that can > be simply changed in an Errata to reduce the complexity. > > Thanks, > Acee > > *From: *Lsr mailto:lsr-boun...@ietf.org>> on > behalf of Gunter Van de Velde <mailto:gunter.van_de_ve...@nokia.com>> > *Date: *Monday, November 30, 2020 at 12:21 PM > *To: *"Acee Lindem (acee)" <mailto:acee=40cisco@dmarc.ietf.org>>, Alexander Okonnikov > <mailto:alexander.okonni...@gmail.com>>, > "Peter Psenak (ppsenak)" <mailto:ppse...@cisco.com>> > *Cc: *"lsr@ietf.org <mailto:lsr@ietf.org>" <mailto:lsr@ietf.org>> > *Subject: *Re: [Lsr] Link Data value for Multi-area links > > 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: > > 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… 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.= 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
Re: [Lsr] Link Data value for Multi-area links
Hi Ketan, On 03/12/2020 10:31, Ketan Talaulikar (ketant) wrote: Hello All, The text in RFC5185 for picking the neighbor’s IP Address or IfIndex for the link-data is indeed very odd and flies against how things are done for normal p2p links per RFC2328. The implementations that I am aware of do not really following this “decision” of RFC5185 and instead stick to RFC2328 architecture by picking the local IP address or IfIndex even for MADJ links. This way, a remote router cannot really distinguish between a normal P2P link or a MADJ – they look the same in the LSDB. While the neighbor IP address can be learnt via the source address used for the hello messages, there is really no simple way to learn the neighbor’s IfIndex for unnumbered links [1]. rfc8510? So IMHO the RFC5185 is in error and we should fix this if we have consensus in the WG via a BIS as suggested by Acee. I'm not convinced about the error. Nor about the need of the bis. my 2c, Peter Gunter, I am not getting into your other questions because of what I’ve mentioned above Thanks, Ketan [1] Note that over time we have introduced such mechanisms (RFC8510), but they have all been optional and not “base/required” behavior. *From:*Lsr *On Behalf Of *Acee Lindem (acee) *Sent:* 30 November 2020 23:18 *To:* Van De Velde, Gunter (Nokia - BE/Antwerp) ; Alexander Okonnikov ; Peter Psenak (ppsenak) ; Acee Lindem (acee) *Cc:* lsr@ietf.org *Subject:* Re: [Lsr] Link Data value for Multi-area links You are welcome to propose an alternate solution which could possibly be accepted as a BIS document. However, this is not something that can be simply changed in an Errata to reduce the complexity. Thanks, Acee *From: *Lsr mailto:lsr-boun...@ietf.org>> on behalf of Gunter Van de Velde <mailto:gunter.van_de_ve...@nokia.com>> *Date: *Monday, November 30, 2020 at 12:21 PM *To: *"Acee Lindem (acee)" <mailto:acee=40cisco@dmarc.ietf.org>>, Alexander Okonnikov mailto:alexander.okonni...@gmail.com>>, "Peter Psenak (ppsenak)" mailto:ppse...@cisco.com>> *Cc: *"lsr@ietf.org <mailto:lsr@ietf.org>" <mailto:lsr@ietf.org>> *Subject: *Re: [Lsr] Link Data value for Multi-area links 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: 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… 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.= 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 mailto:lsr-boun...@ietf.org>> *On Behalf Of *Acee Lindem (acee) *Sent:* Monday, November 30, 2020 18:01 *To:* Alexander Okonnikov <mailto:alexander.okonni...@gmail.com>>; Peter Psenak (ppsenak) mailto:ppse...@cisco.com>> *Cc:* lsr@ietf.org <mailto: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 DESCR
Re: [Lsr] Link Data value for Multi-area links
Hi Aijun, Please check my previous response on this thread. The matter is quite simple and easily addressed. IMHO we do not need to invent a new protocol contraption or repurpose your stub-link proposal for this situation. Thanks, Ketan From: Lsr On Behalf Of Aijun Wang Sent: 01 December 2020 09:22 To: 'Acee Lindem (acee)' ; '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 Hi, 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? Best Regards Aijun Wang China Telecom From: lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org> mailto:lsr-boun...@ietf.org>> On Behalf Of Acee Lindem (acee) Sent: Tuesday, December 1, 2020 1:58 AM To: Alexander Okonnikov mailto:alexander.okonni...@gmail.com>>; Van De Velde, Gunter (Nokia - BE/Antwerp) mailto:gunter.van_de_ve...@nokia.com>> Cc: lsr@ietf.org<mailto:lsr@ietf.org>; Peter Psenak (ppsenak) mailto:ppse...@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 mailto:alexander.okonni...@gmail.com>> Date: Monday, November 30, 2020 at 12:47 PM To: Gunter Van de Velde mailto:gunter.van_de_ve...@nokia.com>> Cc: Acee Lindem mailto:a...@cisco.com>>, "Peter Psenak (ppsenak)" mailto:ppse...@cisco.com>>, "lsr@ietf.org<mailto:lsr@ietf.org>" mailto: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 нояб. 2020 г., в 20:20, Van De Velde, Gunter (Nokia - BE/Antwerp) mailto:gunter.van_de_ve...@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: 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… 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.
Re: [Lsr] Link Data value for Multi-area links
Hello All, The text in RFC5185 for picking the neighbor’s IP Address or IfIndex for the link-data is indeed very odd and flies against how things are done for normal p2p links per RFC2328. The implementations that I am aware of do not really following this “decision” of RFC5185 and instead stick to RFC2328 architecture by picking the local IP address or IfIndex even for MADJ links. This way, a remote router cannot really distinguish between a normal P2P link or a MADJ – they look the same in the LSDB. While the neighbor IP address can be learnt via the source address used for the hello messages, there is really no simple way to learn the neighbor’s IfIndex for unnumbered links [1]. So IMHO the RFC5185 is in error and we should fix this if we have consensus in the WG via a BIS as suggested by Acee. Gunter, I am not getting into your other questions because of what I’ve mentioned above Thanks, Ketan [1] Note that over time we have introduced such mechanisms (RFC8510), but they have all been optional and not “base/required” behavior. From: Lsr On Behalf Of Acee Lindem (acee) Sent: 30 November 2020 23:18 To: Van De Velde, Gunter (Nokia - BE/Antwerp) ; Alexander Okonnikov ; Peter Psenak (ppsenak) ; Acee Lindem (acee) Cc: lsr@ietf.org Subject: Re: [Lsr] Link Data value for Multi-area links You are welcome to propose an alternate solution which could possibly be accepted as a BIS document. However, this is not something that can be simply changed in an Errata to reduce the complexity. Thanks, Acee From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of Gunter Van de Velde mailto:gunter.van_de_ve...@nokia.com>> Date: Monday, November 30, 2020 at 12:21 PM To: "Acee Lindem (acee)" mailto:acee=40cisco@dmarc.ietf.org>>, Alexander Okonnikov mailto:alexander.okonni...@gmail.com>>, "Peter Psenak (ppsenak)" mailto:ppse...@cisco.com>> Cc: "lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>> Subject: Re: [Lsr] Link Data value for Multi-area links 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: 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… 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. = 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 mailto:lsr-boun...@ietf.org>> On Behalf Of Acee Lindem (acee) Sent: Monday, November 30, 2020 18:01 To: Alexander Okonnikov mailto:alexander.okonni...@gmail.com>>; Peter Psenak (ppsenak) mailto:ppse...@cisco.com>> Cc: lsr@ietf.org<mailto: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, Appe
Re: [Lsr] Link Data value for Multi-area links
Hi, 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? Best Regards Aijun Wang China Telecom From: lsr-boun...@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 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 mailto:alexander.okonni...@gmail.com> > Date: Monday, November 30, 2020 at 12:47 PM To: Gunter Van de Velde mailto:gunter.van_de_ve...@nokia.com> > Cc: Acee Lindem mailto:a...@cisco.com> >, "Peter Psenak (ppsenak)" mailto:ppse...@cisco.com> >, "lsr@ietf.org <mailto:lsr@ietf.org> " mailto: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 нояб. 2020 г., в 20:20, Van De Velde, Gunter (Nokia - BE/Antwerp) mailto:gunter.van_de_ve...@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: 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… 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. = 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.
Re: [Lsr] Link Data value for Multi-area links
You are welcome to propose an alternate solution which could possibly be
accepted as a BIS document. However, this is not something that can be simply
changed in an Errata to reduce the complexity.
Thanks,
Acee
From: Lsr on behalf of Gunter Van de Velde
Date: Monday, November 30, 2020 at 12:21 PM
To: "Acee Lindem (acee)" , Alexander Okonnikov
, "Peter Psenak (ppsenak)"
Cc: "lsr@ietf.org"
Subject: Re: [Lsr] Link Data value for Multi-area links
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:
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… 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. = 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 On Behalf Of Acee Lindem (acee)
Sent: Monday, November 30, 2020 18:01
To: Alexander Okonnikov ; Peter Psenak (ppsenak)
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 mailto:lsr-boun...@ietf.org>> on behalf of
Alexander Okonnikov
mailto:alexander.okonni...@gmail.com>>
Date: Monday, November 30, 2020 at 5:27 AM
To: "Peter Psenak (ppsenak)" mailto:ppse...@cisco.com>>
Cc: "lsr@ietf.org<mailto: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
mailto:ppse...@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
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 нояб. 2020 г., в 20:20, Van De Velde, Gunter (Nokia - BE/Antwerp)
> написал(а):
>
> 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 On Behalf Of Acee Lindem (acee)
> Sent: Monday, November 30, 2020 18:01
> To: Alexander Okonnikov ; Peter Psenak
> (ppsenak)
> 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 mailto:lsr-boun...@ietf.org>> on behalf of
> Alexander Okonnikov <mailto:alexander.okonni...@gmail.com>>
> Date: Monday, November 30, 2020 at 5:27 AM
> To: "Peter Psenak (ppsenak)" mailto:ppse...@cisco.com>>
> C
Re: [Lsr] Link Data value for Multi-area links
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:
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… 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. = 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 On Behalf Of Acee Lindem (acee)
Sent: Monday, November 30, 2020 18:01
To: Alexander Okonnikov ; Peter Psenak (ppsenak)
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 mailto:lsr-boun...@ietf.org>> on behalf of
Alexander Okonnikov
mailto:alexander.okonni...@gmail.com>>
Date: Monday, November 30, 2020 at 5:27 AM
To: "Peter Psenak (ppsenak)" mailto:ppse...@cisco.com>>
Cc: "lsr@ietf.org<mailto: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
mailto:ppse...@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
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 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
Hi Peter,
30 нояб. 2020 г., в 12:56, Peter Psenak
mailto:ppse...@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
mailto:ppse...@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 someo
Re: [Lsr] Link Data value for Multi-area links
Hi Peter, > 30 нояб. 2020 г., в 12:56, Peter Psenak написал(а): > > 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 написал(а): >>> >>> 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 ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Link Data value for Multi-area links
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. 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. thanks, Peter Thank you. 27 нояб. 2020 г., в 14:50, Peter Psenak написал(а): 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 ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Link Data value for Multi-area links
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 написал(а): > > 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 > ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Link Data value for Multi-area links
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 ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Link Data value for Multi-area links
Alex, I believe the text in section 2.7 talks about Router LSA advertisements which contains both local information as well as information describing each formed adjacency with each neighbour. The RFC just talks about the new added part. Thx, R. On Thu, Nov 26, 2020 at 5:58 PM Alexander Okonnikov < alexander.okonni...@gmail.com> 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? > > Thanks in advance. > ___ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Link Data value for Multi-area links
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? Thanks in advance. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
