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

[Peter Psenak]

Hi Ketan,

On 03/12/2020 11:26, Ketan Talaulikar (ketant) wrote:
Hi Peter,
Please check inline below.

-----Original Message-----
From: Peter Psenak <ppse...@cisco.com>
Sent: 03 December 2020 15:48
To: Ketan Talaulikar (ketant) <ket...@cisco.com>; Acee Lindem (acee) 
<acee=40cisco....@dmarc.ietf.org>; Van De Velde, Gunter (Nokia - BE/Antwerp) 
<gunter.van_de_ve...@nokia.com>; Alexander Okonnikov <alexander.okonni...@gmail.com>; Acee Lindem 
(acee) <a...@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-boun...@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_ve...@nokia.com>; Alexander Okonnikov
<alexander.okonni...@gmail.com>; Peter Psenak (ppsenak)
<ppse...@cisco.com>; Acee Lindem (acee) <a...@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-boun...@ietf.org <mailto:lsr-boun...@ietf.org>> on
behalf of Gunter Van de Velde <gunter.van_de_ve...@nokia.com
<mailto:gunter.van_de_ve...@nokia.com>>
*Date: *Monday, November 30, 2020 at 12:21 PM
*To: *"Acee Lindem (acee)" <acee=40cisco....@dmarc.ietf.org
<mailto:acee=40cisco....@dmarc.ietf.org>>, Alexander Okonnikov
<alexander.okonni...@gmail.com
<mailto:alexander.okonni...@gmail.com>>,
"Peter Psenak (ppsenak)" <ppse...@cisco.com
<mailto:ppse...@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-boun...@ietf.org <mailto:lsr-boun...@ietf.org>> *On
Behalf Of *Acee Lindem (acee)
*Sent:* Monday, November 30, 2020 18:01
*To:* Alexander Okonnikov <alexander.okonni...@gmail.com
<mailto:alexander.okonni...@gmail.com>>; Peter Psenak (ppsenak)
<ppse...@cisco.com <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, 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-boun...@ietf.org <mailto:lsr-boun...@ietf.org>> on
behalf of Alexander Okonnikov <alexander.okonni...@gmail.com
<mailto:alexander.okonni...@gmail.com>>
*Date: *Monday, November 30, 2020 at 5:27 AM
*To: *"Peter Psenak (ppsenak)" <ppse...@cisco.com
<mailto:ppse...@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 <ppse...@cisco.com
     <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 <ppse...@cisco.com
             <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
                 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





_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr