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 0xffffffff (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) <ketant=
[email protected]> 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 <[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]> on behalf of Gunter Van de Velde <
> [email protected]>
> *Date: *Monday, November 30, 2020 at 12:21 PM
> *To: *"Acee Lindem (acee)" <[email protected]>, Alexander
> Okonnikov <[email protected]>, "Peter Psenak (ppsenak)" <
> [email protected]>
> *Cc: *"[email protected]" <[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]> *On Behalf Of *Acee Lindem (acee)
> *Sent:* Monday, November 30, 2020 18:01
> *To:* Alexander Okonnikov <[email protected]>; Peter Psenak
> (ppsenak) <[email protected]>
> *Cc:* [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]> on behalf of Alexander Okonnikov <
> [email protected]>
> *Date: *Monday, November 30, 2020 at 5:27 AM
> *To: *"Peter Psenak (ppsenak)" <[email protected]>
> *Cc: *"[email protected]" <[email protected]>
> *Subject: *Re: [Lsr] Link Data value for Multi-area links
>
>
>
> Hi Peter,
>
>
>
> 30 нояб. 2020 г., в 12:56, Peter Psenak <[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]> написал(а):
>
> 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]
> https://www.ietf.org/mailman/listinfo/lsr
>
>
> _______________________________________________
> Lsr mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/lsr
>
--
<http://www.verizon.com/>
*Gyan Mishra*
*Network Solutions A**rchitect *
*M 301 502-134713101 Columbia Pike *Silver Spring, MD
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
