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 <ppsenak@cisco.com>
> Sent: 03 December 2020 15:48
> To: Ketan Talaulikar (ketant) <ketant@cisco.com>; Acee Lindem (acee) <acee=40cisco.com@dmarc.ietf.org>; Van De Velde, Gunter (Nokia - BE/Antwerp) <gunter.van_de_velde@nokia.com>; Alexander Okonnikov <alexander.okonnikov@gmail.com>; Acee Lindem (acee) <acee@cisco.com>
> 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 <lsr-bounces@ietf.org> *On Behalf Of *Acee Lindem (acee)
>> *Sent:* 30 November 2020 23:18
>> *To:* Van De Velde, Gunter (Nokia - BE/Antwerp)
>> <gunter.van_de_velde@nokia.com>; Alexander Okonnikov
>> <alexander.okonnikov@gmail.com>; Peter Psenak (ppsenak)
>> <ppsenak@cisco.com>; Acee Lindem (acee) <acee@cisco.com>
>> *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 <lsr-bounces@ietf.org <mailto:lsr-bounces@ietf.org>> on
>> behalf of Gunter Van de Velde <gunter.van_de_velde@nokia.com
>> <mailto:gunter.van_de_velde@nokia.com>>
>> *Date: *Monday, November 30, 2020 at 12:21 PM
>> *To: *"Acee Lindem (acee)" <acee=40cisco.com@dmarc.ietf.org
>> <mailto:acee=40cisco.com@dmarc.ietf.org>>, Alexander Okonnikov
>> <alexander.okonnikov@gmail.com
>> <mailto:alexander.okonnikov@gmail.com>>,
>> "Peter Psenak (ppsenak)" <ppsenak@cisco.com
>> <mailto:ppsenak@cisco.com>>
>> *Cc: *"lsr@ietf.org <mailto:lsr@ietf.org>" <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 <lsr-bounces@ietf.org <mailto:lsr-bounces@ietf.org>> *On
>> Behalf Of *Acee Lindem (acee)
>> *Sent:* Monday, November 30, 2020 18:01
>> *To:* Alexander Okonnikov <alexander.okonnikov@gmail.com
>> <mailto:alexander.okonnikov@gmail.com>>; Peter Psenak (ppsenak)
>> <ppsenak@cisco.com <mailto:ppsenak@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, 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 <lsr-bounces@ietf.org <mailto:lsr-bounces@ietf.org>> on
>> behalf of Alexander Okonnikov <alexander.okonnikov@gmail.com
>> <mailto:alexander.okonnikov@gmail.com>>
>> *Date: *Monday, November 30, 2020 at 5:27 AM
>> *To: *"Peter Psenak (ppsenak)" <ppsenak@cisco.com
>> <mailto:ppsenak@cisco.com>>
>> *Cc: *"lsr@ietf.org <mailto:lsr@ietf.org>" <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 <ppsenak@cisco.com
>>      <mailto:ppsenak@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 <ppsenak@cisco.com
>>              <mailto:ppsenak@cisco.com>> написал(а):
>>
>>              Alexander,
>>
>>              On 26/11/2020 17:58, Alexander Okonnikov wrote:
>>
>>                  Hi WG,
>>                  RFC 5185 says that Neighbor's IP address to be encoded
>>                  into Link Data field. Per RFC 2328 router's own IP
>>                  address to be encoded into Link Data. What is the reason
>>                  to advertise neighbor's IP address for multi-area links
>>                  and not local IP address? It seems like bug. Could
>>                  someone comment on this?
>>
>>
>>              Advertising a neighbor address/ifindex helps to eliminate
>>              ambiguity in case of parallel point-to-point adjacencies.
>>              It's not perfect, but that's how it was specified. So it's
>>              not a bug.
>>
>>              thanks,
>>              Peter
>>
>>                  Thanks in advance.
>>                  _______________________________________________
>>                  Lsr mailing list
>>                  Lsr@ietf.org <mailto:Lsr@ietf.org>
>>                  https://www.ietf.org/mailman/listinfo/lsr
>>
> 
> 
> 