Re: [Lsr] Technical questions for draft about unreachable prefixes announcement

Hi Les, I disagree with your reading of RFC9084 (OSPF Prefix Originator). Sec 1 This document proposes extensions to the OSPF protocol for the inclusion of information associated with the router originating the prefix along with the prefix advertisement. These extensions do not change the core

Re: [Lsr] Technical questions for draft about unreachable prefixes announcement

To add to what Ketan has stated… draft-wang-lsr-prefix-unreachable-annoucement defines the same mechanism for both OSPF and IS-IS i.e., it proposes to use a prefix-originator sub-TLV with address set to 0.0.0.0 to indicate unreachability. For OSPF, this might be considered compatible with RFC

Re: [Lsr] Technical questions for draft about unreachable prefixes announcement

Hi Aijun, As your co-author on the OSPF Prefix Originator RFC, I have stated many times (e.g. [1]) that overloading semantics of Prefix Originator is not a good or clean protocol encoding. Semantically, it is wrong and a very bad protocol design in my opinion. Going by this logic, tomorrow,

Re: [Lsr] Technical questions for draft about unreachable prefixes announcement

Aijun, You castigated Peter for his lack of rigor in his reply to your email, however, I think that was completely unfounded.  Further, your reply to Peter seems to be argument by emphatic assertion, rather than "technical analysis/comparison". Thanks, John  On Monday, November 6, 2023 at

Re: [Lsr] Technical questions for draft about unreachable prefixes announcement

Hi, Peter: Let’s focus on the technical analysis/comparison for the mentioned issues, and don’t repeat the subjective comments that without any solid analysis. Detail replies inline below. Aijun Wang China Telecom > On Nov 6, 2023, at 14:53, Peter Psenak wrote: > > Aijun, > > please see

Re: [Lsr] draft-pkaneria-lsr-multi-tlv and "backwards compatibility"

Chris - Thanx for the reply - and glad to see we seem to be headed in the same direction. Just wanted to clarify that the MP draft does NOT advocate partial deployment. https://www.ietf.org/archive/id/draft-pkaneria-lsr-multi-tlv-04.html#name-deployment-considerations recommends: *

Re: [Lsr] draft-pkaneria-lsr-multi-tlv and "backwards compatibility"

My point is that people are not using the same definition of backward compatibility. This is why this argument over it is going in circles. I'm suggesting that when you consider each persons definition of backward compatibility, then neither side is wrong. So saying things like "No. You are

Re: [Lsr] Technical questions for draft about unreachable prefixes announcement

Aijun, please see inline: On 06/11/2023 13:23, Aijun Wang wrote: Hi, all: Here are some technical questions for the hurry adopted draft about unreachable prefixes announcement: 1) There exists already “prefix originator” sub-TLV to indicate the associated prefix is unreachable, what’s the

[Lsr] draft-pkaneria-lsr-multi-tlv and "backwards compatibility"

Chris (and everyone) - A more complete response to your comments regarding "backwards compatibility", routing loops, etc. It is absolutely true that until all nodes in the network support advertisement (meaning at least receive processing) of more than 255 bytes for a given object, that

Re: [Lsr] My comment on https://datatracker.ietf.org/doc/html/draft-wang-lsr-flex-algo-link-loss-00

Speaking as WG member: RFC 7471 contains a definition of link loss: 4.4.5. Link Loss This 24-bit field carries link packet loss as a percentage of the total traffic sent over a configurable interval. The basic unit is 0.03%, where (2^24 - 2) is 50.331642%. This value is the

Re: [Lsr] 答复: My comment on https://datatracker.ietf.org/doc/html/draft-wang-lsr-flex-algo-link-loss-00

Hi Yifan Wang, thank you for the clarification on the packet loss measurement. I agree that TWAMP/TWAMP-Lite could be used to measure packet loss using synthetic packets. I would note that STAMP (RFC 8762 ) has all the functionality of TWAMP. Also, the

Re: [Lsr] Are NomCom feedbacks still open ?

Note that feedback is still open for 2023 NOMCOM candidates. Here is the URL: https://datatracker.ietf.org/nomcom/2023/feedback/ Thanks, Acee > > On Sat, Nov 4, 2023, at 21:13, Eric Vyncke (evyncke) wrote: >> Hello Martin, >> >> As the IETF-118 week is about to start, should the WG chairs

[Lsr] Technical questions for draft about unreachable prefixes announcement

Hi, all: Here are some technical questions for the hurry adopted draft about unreachable prefixes announcement: 1) There exists already “prefix originator” sub-TLV to indicate the associated prefix is unreachable, what’s the advantage of using other undefined, to-be-standardized,

Re: [Lsr] My comment on https://datatracker.ietf.org/doc/html/draft-wang-lsr-flex-algo-link-loss-00

Hi Sasha, FYI, packet loss for a link can be measured using the procedure defined in the following draft, including direct measurement for customer traffic. https://www.ietf.org/archive/id/draft-ietf-spring-stamp-srpm-10.html The draft can refer to the above reference if it helps. thanks,

[Lsr] 答复: My comment on https://datatracker.ietf.org/doc/html/draft-wang-lsr-flex-algo-link-loss-00

Hi, Thanks for the comments. In the afternoon presentation I mainly introduce the path computation method based on link loss. Here are the consideration of how packet loss on a link is measured: 1. The packet loss rate is measured based on the TWAMP or TWAMP LIGHT. It doesn’t depend on

[Lsr] "Non-routing information distribution” side meeting, Tuesday 8:30-9:30AM, Karlin 4 room

Hi Dear all in LSR & IDR, Please pardon me to shout out that there will be a side meeting “Non-routing information distribution”, which is obviously highly related to our WGs. As we all know, it is a long-term issue that always cause people concern about carrying too much information that are

Re: [Lsr] My comment on https://datatracker.ietf.org/doc/html/draft-wang-lsr-flex-algo-link-loss-00

Hi Sasha, Fully agree with the indicated Packet loss variance problematic aspects. Hysteresis mechanism might help but also might imply undesired extra complexity. Nitsan Dolev From: Alexander Vainshtein Sent: Monday, November 6, 2023 12:15 PM To:

[Lsr] My comment on https://datatracker.ietf.org/doc/html/draft-wang-lsr-flex-algo-link-loss-00

Hi, Just repeating my comment at the mike: The draft does not explain how packet loss on a link is measured. If this measurement is based on real traffic, excluding the link from the topology for certain flexible algorithms may result in the packet loss going down and the link becoming