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

["Ketan Talaulikar (ketant)" <[e-mail]>]

Hi Peter,

Please check inline below.

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