t;
>> On Sep 21, 2023, at 10:50, Alexander Okonnikov
>> wrote:
>>
>> Hi WG,
>>
>> Regarding the errata - the errata claims that cause of it is the bug in an
>> implementation, sending DBD with Interface MTU = 0. Maybe it is so, but it
>> seems
Hi WG,
Regarding the errata - the errata claims that cause of it is the bug in an
implementation, sending DBD with Interface MTU = 0. Maybe it is so, but it
seems that real bug is in implementation(s), receiving and dropping such DPD.
Both RFCs - 5838 and 5340 - inherit rules for receiving DBD
Hi Acee, Rajesh,
RFC 6565 states that the same communities, defined in RFC 4577, are reused.
Just before the text, quoted by Rajesh, there is statement:
"The BGP Extended Communities attributes defined in [RFC4577] are reused for
convenience."
RFC 4577 defines sub-type 0x05 and also refers to
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
&
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
(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.
Thank you.
> 27 нояб. 2020 г., в 14:50, Peter Psenak написал(а):
>
> Alexander,
>
> On 26/11/2020 1
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
ot reachable, the AS-External LSA could be stale and the
> route it originally advertised could be unreachable or administrative
> prohibited irrespective of the reachability of the forwarding address.
> Thanks,
> Acee
>
> On 3/1/19, 8:16 AM, "Lsr on behalf of Alexander
Hi Acee,
For me current version doesn't change the solution. My comments are follow:
1. Introduction
"TE Extensions to OSPFv2 [RFC3630] and OSPFv3 [RFC5329] have been described to
support intra-area TE in IPv4 and IPv6 networks, respectively. In both cases,
the TE database provides a tight
; Hi Alex,
>
> From: Alexander Okonnikov <mailto:alexander.okonni...@gmail.com>>
> Date: Tuesday, February 5, 2019 at 12:59 PM
> To: Acee Lindem mailto:a...@cisco.com>>, "cc...@ietf.org
> <mailto:cc...@ietf.org>" mailto:cc...@ietf.org>>,
> "ls
, but only
introduction of Link Local TLV. IANA has no corresponding registry - "Types
for Sub-TLVs of Link Local TLV (Value 4)".
Thanks in advance.
Best regards,
Alexander Okonnikov
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.o
Hi Anton,
I tend to agree with Ketan, but with slightly different proposal. Would not it
be simpler to advertise IPv6 Router Address TLV (TLV type 3) by OSPFv2 Opaque
LSA (in addition to advertising of Router Address TLV) and to advertise Router
Address TLV (TLV type 1) by OSPFv3
assume that some router uses
Interface IDs for two-way check, but it is not so straightforward when we have
deal with FAs.
Acee, two-way check could be disabled on the router that is owner of FA, but
how other routers will distinguish regular P2P from FA?
Thank you.
Best regards,
Alexander Okonnikov
13 matches
Mail list logo
