Hi Peter, Please check inline below.
-----Original Message----- From: Peter Psenak <[email protected]> Sent: 03 December 2020 15:48 To: Ketan Talaulikar (ketant) <[email protected]>; Acee Lindem (acee) <[email protected]>; Van De Velde, Gunter (Nokia - BE/Antwerp) <[email protected]>; Alexander Okonnikov <[email protected]>; Acee Lindem (acee) <[email protected]> Cc: [email protected] 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 <[email protected]> *On Behalf Of *Acee Lindem (acee) > *Sent:* 30 November 2020 23:18 > *To:* Van De Velde, Gunter (Nokia - BE/Antwerp) > <[email protected]>; Alexander Okonnikov > <[email protected]>; Peter Psenak (ppsenak) > <[email protected]>; Acee Lindem (acee) <[email protected]> > *Cc:* [email protected] > *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 <[email protected] <mailto:[email protected]>> on > behalf of Gunter Van de Velde <[email protected] > <mailto:[email protected]>> > *Date: *Monday, November 30, 2020 at 12:21 PM > *To: *"Acee Lindem (acee)" <[email protected] > <mailto:[email protected]>>, Alexander Okonnikov > <[email protected] > <mailto:[email protected]>>, > "Peter Psenak (ppsenak)" <[email protected] > <mailto:[email protected]>> > *Cc: *"[email protected] <mailto:[email protected]>" <[email protected] > <mailto:[email protected]>> > *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 <[email protected] <mailto:[email protected]>> *On > Behalf Of *Acee Lindem (acee) > *Sent:* Monday, November 30, 2020 18:01 > *To:* Alexander Okonnikov <[email protected] > <mailto:[email protected]>>; Peter Psenak (ppsenak) > <[email protected] <mailto:[email protected]>> > *Cc:* [email protected] <mailto:[email protected]> > *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 <[email protected] <mailto:[email protected]>> on > behalf of Alexander Okonnikov <[email protected] > <mailto:[email protected]>> > *Date: *Monday, November 30, 2020 at 5:27 AM > *To: *"Peter Psenak (ppsenak)" <[email protected] > <mailto:[email protected]>> > *Cc: *"[email protected] <mailto:[email protected]>" <[email protected] > <mailto:[email protected]>> > *Subject: *Re: [Lsr] Link Data value for Multi-area links > > Hi Peter, > > 30 нояб. 2020 г., в 12:56, Peter Psenak <[email protected] > <mailto:[email protected]>> написал(а): > > 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 <[email protected] > <mailto:[email protected]>> написал(а): > > 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 > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/lsr > _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
