k (ppsenak)"
Subject: RE: [Lsr] Link Data value for Multi-area links
Hi Aijun,
OSPF MIB RFC4750 was published before MADJ was introduced in OSPF. I would
think it is quite natural that it does not consider MADJ. If your proposal is
to fix/extend OSPF MIB in 202x for MADJ then do please go
Sent: 04 December 2020 12:31
To: Ketan Talaulikar (ketant) ; 'Acee Lindem (acee)'
; 'Alexander Okonnikov'
; 'Van De Velde, Gunter (Nokia - BE/Antwerp)'
Cc: lsr@ietf.org; Peter Psenak (ppsenak)
Subject: RE: [Lsr] Link Data value for Multi-area links
Hi, Ketan:
Using the local ip address
From: Ketan Talaulikar (ketant)
Sent: Thursday, December 3, 2020 5:35 PM
To: Aijun Wang ; 'Acee Lindem (acee)'
; 'Alexander Okonnikov'
; 'Van De Velde, Gunter (Nokia - BE/Antwerp)'
Cc: lsr@ietf.org; Peter Psenak (ppsenak)
Subject: RE: [Lsr] Link Data value for Multi-area links
Hi Aijun
e 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) ;
> Acee Lindem (acee)
> *Cc:* lsr@iet
Okonnikov ; Acee Lindem
(acee)
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
; *To: *"Acee Lindem (acee)" <mailto:acee=40cisco@dmarc.ietf.org>>, Alexander Okonnikov
> <mailto:alexander.okonni...@gmail.com>>,
> "Peter Psenak (ppsenak)" <mailto:ppse...@cisco.com>>
> *Cc: *"lsr@ietf.org <mailto:lsr@ietf.org>" &
ot; mailto:ppse...@cisco.com>>
*Cc: *"lsr@ietf.org <mailto: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-addr
2020 09:22
To: 'Acee Lindem (acee)' ; 'Alexander
Okonnikov' ; 'Van De Velde, Gunter (Nokia -
BE/Antwerp)'
Cc: lsr@ietf.org; Peter Psenak (ppsenak)
Subject: Re: [Lsr] Link Data value for Multi-area links
Hi,
How about using the stub-link that we proposed and discussed at
https
Okonnikov ; Peter Psenak (ppsenak)
; Acee Lindem (acee)
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
Lindem
(acee)
Sent: Tuesday, December 1, 2020 1:58 AM
To: Alexander Okonnikov ; Van De Velde, Gunter
(Nokia - BE/Antwerp)
Cc: lsr@ietf.org; Peter Psenak (ppsenak)
Subject: Re: [Lsr] Link Data value for Multi-area links
Speaking on WG member:
Hi Alex,
I knew this was coming. In 2008, 99.9
:21 PM
To: "Acee Lindem (acee)" , Alexander Okonnikov
, "Peter Psenak (ppsenak)"
Cc: "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
dress
> 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 On Behalf Of Acee Lindem (acee)
> Sent: Monday, November 30, 2020 18:01
&
(ppsenak)
Cc: 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
"lsr@ietf.org"
Subject: Re: [Lsr] Link Data value for Multi-area links
Hi Peter,
30 нояб. 2020 г., в 12:56, Peter Psenak
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
Hi Peter,
> 30 нояб. 2020 г., в 12:56, Peter Psenak написал(а):
>
> 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
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
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
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
Alex,
I believe the text in section 2.7 talks about Router LSA advertisements
which contains both local information as well as information describing
each formed adjacency with each neighbour. The RFC just talks about the new
added part.
Thx,
R.
On Thu, Nov 26, 2020 at 5:58 PM Alexander
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
20 matches
Mail list logo
