Hi Peter,
Thanks for confirming my understanding. Please see inline..
On Tue, Apr 2, 2024 at 2:07 PM Peter Psenak wrote:
> Hi Muthu,
>
> On 01/04/2024 09:42, Muthu Arul Mozhi Perumal wrote:
>
> Hi Peter,
>
> Thanks for your response..
>
> First, to confirm if I und
024 at 6:44 PM Peter Psenak wrote:
> Muthu,
>
> On 18/03/2024 10:41, Muthu Arul Mozhi Perumal wrote:
>
> Hi all,
>
> draft-ietf-lsr-igp-ureach-prefix-announce mentions BGP PIC edge as one the
> use cases for UPA in the presence of summarization. However, it is not
> quite cl
Hi all,
draft-ietf-lsr-igp-ureach-prefix-announce mentions BGP PIC edge as one the
use cases for UPA in the presence of summarization. However, it is not
quite clear whether UPA is expected to trigger BGP best path calculation at
the ingress PE (in addition to triggering BGP PIC) in spite of the B
Thanks, Peter.
Would have been better if "LFA types" was expanded (perhaps in the
terminology section). But, I understand this was borrowed from RFC8919 in
the bis..
Regards,
Muthu
On Mon, Aug 14, 2023 at 3:28 PM Peter Psenak wrote:
> Muthu,
>
> On 14/08/2023 02:44, Muthu
Hi,
draft-ietf-lsr-rfc8919bis defines the F-bit in SABM as:
F-bit: Set to specify Loop-Free Alternate (LFA) (includes all LFA
types).
Does all LFA types mean LFA/RLFA/DLFA/TI-LFA as an application?
The draft references RFC5286 for LFA which defines link/node/SRLG
protecting LFAs
Hi Venkat,
I think there are two different aspects in the problem you have described
below:
1. IS-IS database overload
2. Summary prefix
On the first one, I think from ISO/IEC 10589:2002 it is clear that the
database overload bit has relevance only in LSP number 0 and the value
present in other L
>
>
>
> is stating exactly what is in scope for the RFC.
>
>
>
> So I do not think your suggested additional text should be added to RFC
> 7775.
>
>
>
>Les
>
>
>
>
>
> *From:* Muthu Arul Mozhi Perumal
> *Sent:* Monday, Feb
might result in link utilization that is not to the
> liking of a customer, but no interoperability issue will occur.
>
>
>
> So the prioritization you mention below is NOT required to avoid looping.
>
Fully agree..
Regards,
Muthu
>
>
>Les
>
>
>
> *Fro
n Thu, Feb 17, 2022 at 9:46 PM Les Ginsberg (ginsberg)
wrote:
> Muthu –
>
>
>
> Use of Equal Cost Multipath (ECMP) is commonplace.
>
>
>
> Les
>
>
>
> *From:* Muthu Arul Mozhi Perumal
> *Sent:* Thursday, February 17, 2022 7:51 AM
> *To:* Les Ginsb
an cost in the choice of
> “best path”.
>
> All of this is out of scope for RFC 7775.
>
>
>
> Les
>
>
>
> *From:* Lsr *On Behalf Of * Muthu Arul Mozhi
> Perumal
> *Sent:* Thursday, February 17, 2022 6:49 AM
> *To:* lsr
> *Subject:* [Lsr] Preference
Hi,
Need some clarification on the preference among IS-IS IPv6 route types
described in RFC7775 section 3.4 and RFC5308 section 5.
RFC7775 places L1 intra-area routes and L1 external routes at the same
preference level and says that all types of routes listed for a given
preference are treated eq
BFD"
> - draft-ietf-lsr-ospf-bfd-strict-mode-04
>
> Hi Muthu,
>
> I don't have the data for BFD strict-mode interop over virtual links.
> However, p2p unnumbered is commonly deployed and I'll let my co-author
> clarify on interop.
>
> Thanks,
> Ketan
>
reference to RFC5883 for BFD multi-hop use for
> VLINKs.
>
> I hope that works for you.
>
> Thanks,
> Ketan
>
>
> On Wed, Feb 2, 2022 at 11:05 AM Muthu Arul Mozhi Perumal <
> muthu.a...@gmail.com> wrote:
>
>> Hi Ketan,
>>
>> Thanks for your
On Thu, Feb 3, 2022 at 10:14 PM Acee Lindem (acee) wrote:
> Hi Ketan,
>
> Do you remember who this comment came from? I definitely think anyone who
> reads the abstract of the draft wouldn’t be confused and don’t agree with
> the comment.
>
>
>
> Also, this is meant to be a per-interface sub-opt
s, there would need to be a BFD multi-hop session and the
> same would apply to p-t-p unnumbered.
>
> However, I am not sure what specific applicability or operations need to
> be called out for Strict Mode of operations for those links.
>
> Thanks,
> Ketan
>
>
> On Sun,
Hi,
I support the draft. A quick question:
Should it describe the applicability of the mechanism over OSPF virtual
links and unnumbered interfaces? With virtual links, one would have to
establish a multi-hop BFD session, so it is slightly different from a BFD
operational standpoint. For e.g, capab
Hi,
Just curious, keeping the 5G use case and applications aside, is it fair to
consider the new metric analogous to TE metric for a prefix that CSPF can
use? The metric can be split into 'n' parts all internal to the specific
application?
Regards,
Muthu
On Wed, Jan 19, 2022 at 7:36 PM Aijun Wan
Hi,
It is possible to designate experimental RFCs as historic if there is no
evidence of widespread use over a period of time, as is currently being
done for HTTP-related experimental RFCs:
https://datatracker.ietf.org/doc/status-change-http-experiments-to-historic/
Hence, I think having multiple
> Good Luck,
>
> Acee
>
>
>
>
>
>
>
> *From: *Muthu Arul Mozhi Perumal
> *Date: *Wednesday, December 9, 2020 at 8:51 AM
> *To: *Acee Lindem
> *Cc: *"Acee Lindem (acee)" , "
> lsr@ietf.org" , Tulasi Rami Reddy N
> *Subject: *Re: [Ls
>
>
> *From: *Lsr on behalf of Muthu Arul Mozhi Perumal <
> muthu.a...@gmail.com>
> *Date: *Wednesday, December 9, 2020 at 8:18 AM
> *To: *"Acee Lindem (acee)"
> *Cc: *"lsr@ietf.org" , Tulasi Rami Reddy N <
> tulasi.i...@gmail.com>
> *Subj
Hi Acee,
This is a configuration error, right? Wouldn't ospfIfConfigError trap be
more appropriate? There is no good error code for this case in
ospfConfigErrorType,
though. Perhaps, RFC4750 could have reserved some error codes for future
definitions?
Regards,
Muthu
On Wed, Dec 9, 2020 at 6:16 P
A quick question:
If an IP address and a Flexible Algorithm are associated with the
same interface, they are also associated with one another. An IP
address MAY be associated with, at most, one interface.
If multiple IP addresses and multiple flexible algorithms are associated
with a l
Robert,
On Tue, Jun 5, 2018 at 9:28 PM, Robert Raszuk wrote:
> Muthu,
>
>
>> How is the measurement interval and filter coefficients described in the
>> draft related to dissemination?
>>
>
> It is directly related. If you see the title of the section is:
> "Announcement Thresholds and Filt
tions 5,6,7?
Regards,
Muthu
On Tue, Jun 5, 2018 at 5:33 PM, Ketan Talaulikar (ketant)
wrote:
> Hi Muthu,
>
>
>
> These are implementation specific aspects and I am not sure if this is
> something that the draft should be getting into.
>
>
>
> Thanks,
>
> Ketan
mented outside the core
> IGP module and the IGPs simply flood these while satisfying the aspects
> specified in the document.
>
>
>
> Thanks,
>
> Ketan
>
>
>
> *From:* Lsr *On Behalf Of *Muthu Arul Mozhi Perumal
> *Sent:* 05 June 2018 16:42
> *To:* Stef
Please see inline..
On Fri, Jun 1, 2018 at 2:34 AM, Stefano Previdi (IETF)
wrote:
>
>
> On Thu, May 31, 2018, 6:15 PM Muthu Arul Mozhi Perumal <
> muthu.a...@gmail.com> wrote:
>
>> Thanks, Jeff. Would be good to have this clarified in
>>
>> draf
provided to them.
Thoughts, especially from an implementation standpoint?
Regards.
Muthu
On Thu, May 31, 2018 at 11:37 AM, Jeff Tantsura
wrote:
> Muthu,
>
> LSR would be a more suitable list to post to, CCed.
>
> Regards,
> Jeff
>
> > On May 30, 2018, at 18:0
27 matches
Mail list logo
