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

[Ketan Talaulikar]

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 OSPF
route computation functionality.

Sec 2.1

For intra-area prefix advertisements, the Prefix Source OSPF Router-ID
Sub-TLV MUST be considered invalid and ignored if the OSPF Router ID field
is not the same as the Advertising Router field in the containing LSA.
Similar validation cannot be reliably performed for inter-area and external
prefix advertisements.¶


A received Prefix Source OSPF Router-ID Sub-TLV with the OSPF Router ID
field set to 0 MUST be considered invalid and ignored. Additionally,
reception of such sub-TLVs SHOULD be logged as an error (subject to rate
limiting).

As editor of this document, it is absolutely clear to me that we are
referring to the sub-TLV and not the prefix advertisement. So, when the
value is set to 0, the sub-TLV is invalid and ignored - the prefix
reachability is not at all affected.
This is the reason why I am firmly opposed to using Prefix Originator value
0 for UPA or any other indication.

I hope I am able to convince you :-)

Thanks,
Ketan



On Tue, Nov 7, 2023 at 12:44 AM Les Ginsberg (ginsberg) 
wrote:

> 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 9084 where it is
> stated that advertisements with “Router ID field set to 0 MUST be
> considered invalid and ignored” - though Ketan has indicated this usage is
> undesirable.
>
> However, no equivalent statement was ever made for IS-IS in RFC 7794 – so
> this simply does not work in the case of IS-IS.
>
> I (among others) pointed this out to the authors of draft-wang multiple
> times over the years, but my feedback was ignored.
>
>
>
> Which is an example of why I would like to echo Ketan’s sentiments – let’s
> please put an end to this non-constructive discussion.
>
>
>
> The authors of draft-wang have had many opportunities over the years to
> respond in a more constructive way to feedback. They were also – as Peter
> has indicated – given an opportunity to co-author
> draft-ietf-lsr-igp-ureach-prefix-announce out of respect for them bringing
> the problem space to the attention of the WG. They declined – which of
> course is their right. But they do not have the right to endlessly oppose
> the consensus of the WG.
>
>
>
> Let’s please move on.
>
>
>
>Les
>
>
>
>
>
> *From:* Lsr  *On Behalf Of * Ketan Talaulikar
> *Sent:* Monday, November 6, 2023 3:01 PM
> *To:* John Drake 
> *Cc:* Peter Psenak (ppsenak) ; Aijun Wang <
> wangai...@tsinghua.org.cn>; lsr@ietf.org
> *Subject:* 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, someone would
> want to encode some different meaning for all 1's value in the originator
> address. We cannot be doing such (IMHO) HACKS in the protocol encodings.
>
>
>
> It is better to signal the semantics/meaning explicitly using specific
> flags that are meaningful.
>
>
>
> The authors of draft-ppsenak (now a WG document) agreed to this feedback
> from WG members and incorporated the U/UP flags in their draft. However,
> the authors of draft-wang seem to continue to refuse to accept feedback. It
> is perhaps one of the reasons why the WG adopted the draft-ppsenak and not
> draft-wang.
>
>
>
> WG chairs, is there a way to put an end to this debate such that it does
> not continue endlessly?
>
>
>
> Thanks,
>
> Ketan
>
>
>
> [1] thread
> https://mailarchive.ietf.org/arch/msg/lsr/FNbqHPhphY3GOfw-NWkLjmoRDVs/
>
>
>
>
>
> On Mon, Nov 6, 2023 at 7:31 PM John Drake  40yahoo@dmarc.ietf.org> wrote:
>
> 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 08:41:38 AM PST, Aijun Wang <
> wangai...@tsinghua.org.cn> wrote:
>
>
>
>
>
> 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

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

[Les Ginsberg (ginsberg)]

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 9084 where it is stated 
that advertisements with “Router ID field set to 0 MUST be considered invalid 
and ignored” - though Ketan has indicated this usage is undesirable.
However, no equivalent statement was ever made for IS-IS in RFC 7794 – so this 
simply does not work in the case of IS-IS.
I (among others) pointed this out to the authors of draft-wang multiple times 
over the years, but my feedback was ignored.

Which is an example of why I would like to echo Ketan’s sentiments – let’s 
please put an end to this non-constructive discussion.

The authors of draft-wang have had many opportunities over the years to respond 
in a more constructive way to feedback. They were also – as Peter has indicated 
– given an opportunity to co-author draft-ietf-lsr-igp-ureach-prefix-announce 
out of respect for them bringing the problem space to the attention of the WG. 
They declined – which of course is their right. But they do not have the right 
to endlessly oppose the consensus of the WG.

Let’s please move on.

   Les


From: Lsr  On Behalf Of Ketan Talaulikar
Sent: Monday, November 6, 2023 3:01 PM
To: John Drake 
Cc: Peter Psenak (ppsenak) ; Aijun Wang 
; lsr@ietf.org
Subject: 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, someone would want to 
encode some different meaning for all 1's value in the originator address. We 
cannot be doing such (IMHO) HACKS in the protocol encodings.

It is better to signal the semantics/meaning explicitly using specific flags 
that are meaningful.

The authors of draft-ppsenak (now a WG document) agreed to this feedback from 
WG members and incorporated the U/UP flags in their draft. However, the authors 
of draft-wang seem to continue to refuse to accept feedback. It is perhaps one 
of the reasons why the WG adopted the draft-ppsenak and not draft-wang.

WG chairs, is there a way to put an end to this debate such that it does not 
continue endlessly?

Thanks,
Ketan

[1] thread 
https://mailarchive.ietf.org/arch/msg/lsr/FNbqHPhphY3GOfw-NWkLjmoRDVs/


On Mon, Nov 6, 2023 at 7:31 PM John Drake 
mailto:40yahoo@dmarc.ietf.org>> wrote:
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 08:41:38 AM PST, Aijun Wang 
mailto:wangai...@tsinghua.org.cn>> wrote:


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 
mailto:ppse...@cisco.com>> wrote:
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 advantage of using other undefined, 
to-be-standardized, to-be-implemented sub-TLV?

many people have already commented on why overloading the “prefix originator” 
sub-TLV to signal unreachability is a bad idea. Please accept that feedback.

[WAJ] No one gives the technical analysis. Can you explain technically in 
detail?

You can set the prefix metric to LS-infinity to indicate the unreachability, 
why can’t we the prefix originator to NULL to indicate the 
unreachability?———The key idea for using “prefix originator” is here: if there 
is no router originate the associated prefix, then it is certainly unreachable. 
It is more straightforward than the LS_Infinity, and is also more easily 
implemented, deployed than the to-be-defined, to-be-standardized sub-TLV.





2) It is unnecessary to define the “UP” flag——if the operator know the 
unreachable event in advance, they can also schedule the switchover of the 
related services in advance. Why bother IGP to transfer such information?

looks like there are folks that see the value in it. I let them to comment 
more, but I don't necessarily see a problem in an extra bit. If you don't like 
it, don't use it.




3) There is very limited usage of LS_Infinity in current network. From the 
operator’s viewpoint, we will decrease its usage also 

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

[Ketan Talaulikar]

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, someone would
want to encode some different meaning for all 1's value in the originator
address. We cannot be doing such (IMHO) HACKS in the protocol encodings.

It is better to signal the semantics/meaning explicitly using specific
flags that are meaningful.

The authors of draft-ppsenak (now a WG document) agreed to this feedback
from WG members and incorporated the U/UP flags in their draft. However,
the authors of draft-wang seem to continue to refuse to accept feedback. It
is perhaps one of the reasons why the WG adopted the draft-ppsenak and not
draft-wang.

WG chairs, is there a way to put an end to this debate such that it does
not continue endlessly?

Thanks,
Ketan

[1] thread
https://mailarchive.ietf.org/arch/msg/lsr/FNbqHPhphY3GOfw-NWkLjmoRDVs/


On Mon, Nov 6, 2023 at 7:31 PM John Drake  wrote:

> 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 08:41:38 AM PST, Aijun Wang <
> wangai...@tsinghua.org.cn> wrote:
>
>
> 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 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 advantage of using other
> undefined, to-be-standardized, to-be-implemented sub-TLV?
>
>
> many people have already commented on why overloading the “prefix
> originator” sub-TLV to signal unreachability is a bad idea. Please accept
> that feedback.
>
>
> [WAJ] No one gives the technical analysis. Can you explain technically in
> detail?
>
> You can set the prefix metric to LS-infinity to indicate the
> unreachability, why can’t we the prefix originator to NULL to indicate the
> unreachability?———The key idea for using “prefix originator” is here: if
> there is no router originate the associated prefix, then it is certainly
> unreachable. It is more straightforward than the LS_Infinity, and is also
> more easily implemented, deployed than the to-be-defined,
> to-be-standardized sub-TLV.
>
>
>
> 2) It is unnecessary to define the “UP” flag——if the operator know the
> unreachable event in advance, they can also schedule the switchover of the
> related services in advance. Why bother IGP to transfer such information?
>
>
> looks like there are folks that see the value in it. I let them to comment
> more, but I don't necessarily see a problem in an extra bit. If you don't
> like it, don't use it.
>
>
>
> 3) There is very limited usage of LS_Infinity in current network. From the
> operator’s viewpoint, we will decrease its usage also in future. Then the
> solution should try their best to avoid their usages——Current solutions
> instead enhance its usage——It is unacceptable. Let’s keep the network
> simple.
>
>
> the reasons for using the LSInfinity for unreachability has been discussed
> at great length a;ready. It's the backward compatibility for routers not
> supporting the new signalling - we need to avoid them interpreting the
> unreachability as reachability.
>
>
> [WAJ] My emphasis is that we shouldn’t enhance the usage of
> LS-Infinity(you propose that the LS-Infinity metric must be carried)
> Instead, we should try to fade them out:
> 1) If all routers within one area/domain all support the new capabilities,
> we need not require the summary LSA to carry LS-infinity metric.
>
> 2) The Maxage of LSA can also be used to achieve the similar effects of
> legacy node bypassing.
>
>
>
> 4) We can’t ignore the partitions scenarios or let’s it go.
>
>
> if you feel like the partition is the problem, you can write a separate
> draft and address it there. We are NOT trying to solve it with UPA draft.
> And for a reason.
>
>
> [WAJ] They are coupled. If you don’t consider it now, you need to update
> your proposal later.
>
>
>
>
> 5) There should be some mechanisms to control the volume of advertised
> unreachable information, when compared with reachable information, as done
> in
> https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-12#section-6
> .
>
>
>
> please look at the section 6 of the UPA draft.
>
>
> [WAJ] I am 

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

[John Drake]

 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 08:41:38 AM PST, Aijun Wang 
 wrote:  
 
 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 WangChina Telecom

On Nov 6, 2023, at 14:53, Peter Psenak  wrote:



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 advantage of using other undefined, 
to-be-standardized, to-be-implemented sub-TLV?


many people have already commented on why overloading the “prefix originator” 
sub-TLV to signal unreachability is a bad idea. Please accept that feedback.


[WAJ] No one gives the technical analysis. Can you explain technically in 
detail? 
You can set the prefix metric to LS-infinity to indicate the unreachability, 
why can’t we the prefix originator to NULL to indicate the 
unreachability?———The key idea for using “prefix originator” is here: if there 
is no router originate the associated prefix, then it is certainly unreachable. 
It is more straightforward than the LS_Infinity, and is also more easily 
implemented, deployed than the to-be-defined, to-be-standardized sub-TLV.






2) It is unnecessary to define the “UP” flag——if the operator know the 
unreachable event in advance, they can also schedule the switchover of the 
related services in advance. Why bother IGP to transfer such information?


looks like there are folks that see the value in it. I let them to comment 
more, but I don't necessarily see a problem in an extra bit. If you don't like 
it, don't use it.






3) There is very limited usage of LS_Infinity in current network. From the 
operator’s viewpoint, we will decrease its usage also in future. Then the 
solution should try their best to avoid their usages——Current solutions instead 
enhance its usage——It is unacceptable. Let’s keep the network simple.




the reasons for using the LSInfinity for unreachability has been discussed at 
great length a;ready. It's the backward compatibility for routers not 
supporting the new signalling - we need to avoid them interpreting the 
unreachability as reachability.


[WAJ] My emphasis is that we shouldn’t enhance the usage of LS-Infinity(you 
propose that the LS-Infinity metric must be carried) Instead, we should try to 
fade them out:1) If all routers within one area/domain all support the new 
capabilities, we need not require the summary LSA to carry LS-infinity metric.
2) The Maxage of LSA can also be used to achieve the similar effects of legacy 
node bypassing.




4) We can’t ignore the partitions scenarios or let’s it go.


if you feel like the partition is the problem, you can write a separate draft 
and address it there. We are NOT trying to solve it with UPA draft. And for a 
reason.


[WAJ] They are coupled. If you don’t consider it now, you need to update your 
proposal later.







5) There should be some mechanisms to control the volume of advertised 
unreachable information, when compared with reachable information, as done in 
https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-12#section-6.



please look at the section 6 of the UPA draft.


[WAJ] I am referring to the balance advertisement of reachable information, as 
did in the above link, not the simple statement as the following: “It is also 
recommended that implementations limit the number of UPA advertisements which 
can be originated at a given time. “
Actually, even for your above statement, 
https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-12#name-deployment-considerations-4
 gives more guidelines, I think you can refer to it again.


thanks,
Peter






Please consider the above technical issues carefully before evaluating and 
adopted any proposal.





If the above issues can’t be solved, we request the WG to adopt also the 
https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/,which
 cover and solve all of the above issues.





Aijun Wang


China Telecom




___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
  ___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Aijun Wang]

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 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 advantage of using other 
>> undefined, to-be-standardized, to-be-implemented sub-TLV?
> 
> many people have already commented on why overloading the “prefix originator” 
> sub-TLV to signal unreachability is a bad idea. Please accept that feedback.

[WAJ] No one gives the technical analysis. Can you explain technically in 
detail? 

You can set the prefix metric to LS-infinity to indicate the unreachability, 
why can’t we the prefix originator to NULL to indicate the 
unreachability?———The key idea for using “prefix originator” is here: if there 
is no router originate the associated prefix, then it is certainly unreachable. 
It is more straightforward than the LS_Infinity, and is also more easily 
implemented, deployed than the to-be-defined, to-be-standardized sub-TLV.

> 
>> 
>> 2) It is unnecessary to define the “UP” flag——if the operator know the 
>> unreachable event in advance, they can also schedule the switchover of the 
>> related services in advance. Why bother IGP to transfer such information?
> 
> looks like there are folks that see the value in it. I let them to comment 
> more, but I don't necessarily see a problem in an extra bit. If you don't 
> like it, don't use it.
> 
> 
>> 
>> 3) There is very limited usage of LS_Infinity in current network. From the 
>> operator’s viewpoint, we will decrease its usage also in future. Then the 
>> solution should try their best to avoid their usages——Current solutions 
>> instead enhance its usage——It is unacceptable. Let’s keep the network simple.
>> 
> the reasons for using the LSInfinity for unreachability has been discussed at 
> great length a;ready. It's the backward compatibility for routers not 
> supporting the new signalling - we need to avoid them interpreting the 
> unreachability as reachability.

[WAJ] My emphasis is that we shouldn’t enhance the usage of LS-Infinity(you 
propose that the LS-Infinity metric must be carried) Instead, we should try to 
fade them out:
1) If all routers within one area/domain all support the new capabilities, we 
need not require the summary LSA to carry LS-infinity metric.

2) The Maxage of LSA can also be used to achieve the similar effects of legacy 
node bypassing.

> 
> 
>> 4) We can’t ignore the partitions scenarios or let’s it go.
> 
> if you feel like the partition is the problem, you can write a separate draft 
> and address it there. We are NOT trying to solve it with UPA draft. And for a 
> reason.

[WAJ] They are coupled. If you don’t consider it now, you need to update your 
proposal later.

> 
> 
>> 
>> 5) There should be some mechanisms to control the volume of advertised 
>> unreachable information, when compared with reachable information, as done 
>> in 
>> https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-12#section-6.
> 
> 
> please look at the section 6 of the UPA draft.

[WAJ] I am referring to the balance advertisement of reachable information, as 
did in the above link, not the simple statement as the following: “It is also 
recommended that implementations limit the number of UPA advertisements which 
can be originated at a given time. “

Actually, even for your above statement, 
https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-12#name-deployment-considerations-4
 gives more guidelines, I think you can refer to it again.

> 
> thanks,
> Peter
> 
> 
>> 
>> Please consider the above technical issues carefully before evaluating and 
>> adopted any proposal.
>> 
>> If the above issues can’t be solved, we request the WG to adopt also the 
>> https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/,which
>>  cover and solve all of the above issues.
>> 
>> Aijun Wang
>> China Telecom
> 
> 
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Les Ginsberg (ginsberg)]

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:



  *   Implementations provide a knob to control the use of MP-TLV
  *   Implementations report an alarm if an MP-TLV is received when use of 
MP-TLVs is disabled.
  *   Implementations report an alarm if local LSP generation requires the use 
of MP-TLVs when generation of MP-TLVs is disabled.



Following these guidelines, MP-TLVs would only be present in a network when the 
control is set to use them AND the operator enters a config which requires 
sending more than 255 bytes. And violations of these conditions would be 
reported.



   Les



> -Original Message-

> From: Christian Hopps 

> Sent: Monday, November 6, 2023 6:10 AM

> To: Les Ginsberg (ginsberg) 

> Cc: Christian Hopps ; lsr@ietf.org

> Subject: Re: 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

> wrong" etc, is not helpful to moving things forward.

>

> In both cases, when you actually need multi-part-tlv, you have to deploy the

> new software to all the routers that will use it; however the multi-part-tlv 
> draft

> allows for a messy sort of "it still works as long as you don't need 
> multi-part-

> tlv on routers that don't understand it" operation. So you hand craft your

> software deployment to match your network config to make that work.

>

> The Big TLV solution does not allow for this "messy but functioning

> deployment", and this is why I believe people prefer the multi-part TLV

> solution. That should be enough to move things forward IMO.

>

> Thanks,

> Chris.

> [wg-member]

>

> "Les Ginsberg (ginsberg)" mailto:ginsb...@cisco.com>> 
> writes:

>

> > 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 any attempt to deploy a configuration

> > which requires the advertisement of more than 255 bytes for that

> > object is likely to result in some type of failure.

> >

> > That failure could manifest itself as routing loops or blackholes or

> > in other ways. This is explicitly stated in https://www.ietf.org/

> > archive/id/draft-pkaneria-lsr-multi-tlv-04.html#

> > name-deployment-considerations :

> >

> >

> >

> > “Sending of MP-TLVs in the presence of nodes which do not correctly

> > process such advertisements can result in interoperability issues,

> > including incorrect forwarding of packets.”

> >

> >

> >

> > No one has ever tried to state otherwise.

> >

> >

> >

> > But it is also true that encodings other than MP suffer from the same

> > limitation. The authors of Big-TLV try to claim otherwise, but this

> > does not stand up to scrutiny – see my replies to Huaimo for more

> > details as to why.

> >

> >

> >

> > Would it be great if we could find a way to allow “incremental

> > deployment”? Sure – but it isn’t possible. As Tony Li stated at the

> > last IETF (paraphrasing):

> >

> >

> >

> > “This isn’t great – but it’s the best we can do.”

> >

> >

> >

> > As to why this particular problem is not amenable, it is because the

> > content that is being advertised consists of existing sub-TLVs that

> > all nodes in the network are required to process for correct

> > operation. There isn’t some information which is “old” and some

> > information which is “new”. It is all “old” – there is just more of

> > it.

> >

> >

> >

> > I honestly thought we had gotten past this point with our discussions

> > (both in the WG and some post WG 1-1 discussions) at IETF 117. But

> > now you have raised this point again.

> >

> > I share your angst, but there is an undeniable deployment need to

> > advertise more than 255 bytes per object – so we need to move

> > forward.

> >

> >

> >

> >Les

> >

> >

> >

> >

> >

> >

> >

> >

> >

> >


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Christian Hopps]

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 wrong" etc, is not helpful to moving things forward.

In both cases, when you actually need multi-part-tlv, you have to deploy the new software 
to all the routers that will use it; however the multi-part-tlv draft allows for a messy 
sort of "it still works as long as you don't need multi-part-tlv on routers that 
don't understand it" operation. So you hand craft your software deployment to match 
your network config to make that work.

The Big TLV solution does not allow for this "messy but functioning 
deployment", and this is why I believe people prefer the multi-part TLV solution. 
That should be enough to move things forward IMO.

Thanks,
Chris.
[wg-member]

"Les Ginsberg (ginsberg)"  writes:


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 any attempt to deploy a configuration
which requires the advertisement of more than 255 bytes for that
object is likely to result in some type of failure.

That failure could manifest itself as routing loops or blackholes or
in other ways. This is explicitly stated in https://www.ietf.org/
archive/id/draft-pkaneria-lsr-multi-tlv-04.html#
name-deployment-considerations :



“Sending of MP-TLVs in the presence of nodes which do not correctly
process such advertisements can result in interoperability issues,
including incorrect forwarding of packets.”



No one has ever tried to state otherwise.



But it is also true that encodings other than MP suffer from the same
limitation. The authors of Big-TLV try to claim otherwise, but this
does not stand up to scrutiny – see my replies to Huaimo for more
details as to why.



Would it be great if we could find a way to allow “incremental
deployment”? Sure – but it isn’t possible. As Tony Li stated at the
last IETF (paraphrasing):



“This isn’t great – but it’s the best we can do.”



As to why this particular problem is not amenable, it is because the
content that is being advertised consists of existing sub-TLVs that
all nodes in the network are required to process for correct
operation. There isn’t some information which is “old” and some
information which is “new”. It is all “old” – there is just more of
it.



I honestly thought we had gotten past this point with our discussions
(both in the WG and some post WG 1-1 discussions) at IETF 117. But
now you have raised this point again.

I share your angst, but there is an undeniable deployment need to
advertise more than 255 bytes per object – so we need to move
forward.



   Les












___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Peter Psenak]

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 advantage of using other 
undefined, to-be-standardized, to-be-implemented sub-TLV?


many people have already commented on why overloading the “prefix 
originator” sub-TLV to signal unreachability is a bad idea. Please 
accept that feedback.




2) It is unnecessary to define the “UP” flag——if the operator know the 
unreachable event in advance, they can also schedule the switchover of 
the related services in advance. Why bother IGP to transfer such 
information?


looks like there are folks that see the value in it. I let them to 
comment more, but I don't necessarily see a problem in an extra bit. If 
you don't like it, don't use it.





3) There is very limited usage of LS_Infinity in current network. From 
the operator’s viewpoint, we will decrease its usage also in future. 
Then the solution should try their best to avoid their usages——Current 
solutions instead enhance its usage——It is unacceptable. Let’s keep 
the network simple.


the reasons for using the LSInfinity for unreachability has been 
discussed at great length a;ready. It's the backward compatibility for 
routers not supporting the new signalling - we need to avoid them 
interpreting the unreachability as reachability.




4) We can’t ignore the partitions scenarios or let’s it go.


if you feel like the partition is the problem, you can write a separate 
draft and address it there. We are NOT trying to solve it with UPA 
draft. And for a reason.





5) There should be some mechanisms to control the volume of advertised 
unreachable information, when compared with reachable information, as 
done in 
https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-12#section-6.



please look at the section 6 of the UPA draft.

thanks,
Peter




Please consider the above technical issues carefully before evaluating 
and adopted any proposal.


If the above issues can’t be solved, we request the WG to adopt also 
the 
https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/,which 
cover and solve all of the above issues.


Aijun Wang
China Telecom



___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Les Ginsberg (ginsberg)]

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 any attempt to deploy a configuration which requires the 
advertisement of more than 255 bytes for that object is likely to result in 
some type of failure.

That failure could manifest itself as routing loops or blackholes or in other 
ways. This is explicitly stated in 
https://www.ietf.org/archive/id/draft-pkaneria-lsr-multi-tlv-04.html#name-deployment-considerations
 :



“Sending of MP-TLVs in the presence of nodes which do not correctly process 
such advertisements can result in interoperability issues, including incorrect 
forwarding of packets.”



No one has ever tried to state otherwise.



But it is also true that encodings other than MP suffer from the same 
limitation. The authors of Big-TLV try to claim otherwise, but this does not 
stand up to scrutiny – see my replies to Huaimo for more details as to why.



Would it be great if we could find a way to allow “incremental deployment”? 
Sure – but it isn’t possible. As Tony Li stated at the last IETF (paraphrasing):



“This isn’t great – but it’s the best we can do.”



As to why this particular problem is not amenable, it is because the content 
that is being advertised consists of existing sub-TLVs that all nodes in the 
network are required to process for correct operation. There isn’t some 
information which is “old” and some information which is “new”. It is all “old” 
– there is just more of it.



I honestly thought we had gotten past this point with our discussions (both in 
the WG and some post WG 1-1 discussions) at IETF 117. But now you have raised 
this point again.

I share your angst, but there is an undeniable deployment need to advertise 
more than 255 bytes per object – so we need to move forward.



   Les










___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Acee Lindem]

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 highest
   packet loss percentage that can be expressed (the assumption being
   that precision is more important on high speed links than the ability
   to advertise loss rates greater than this, and that high speed links
   with over 50% loss are unusable).  Therefore, measured values that
   are larger than the field maximum SHOULD be encoded as the maximum
   value.

This would seem to me not include loss due to QoS policing. However, it would 
seem the measurement technique would be impacted this. It would be good to get 
input with Sasha, Greg, and others how to define link loss. Of course, 
measurement techniques are under the charter of other WGs. 

RFC 7471 includes a discussion (albeit brief) of advertisement hysteresis. This 
draft should include a discussion of computational hysteresis. However, I don’t 
see this as required for WG adoption. 

Thanks,
Acee


> On Nov 6, 2023, at 13:31, Greg Mirsky  wrote:
> 
> 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 Direct measurement extension of STAMP (RFC 8972 
> ) can measure data traffic loss 
> using operator-defined "in-profile" characteristics of the monitored flow.
> 
> Regards,
> Greg
> 
> On Mon, Nov 6, 2023 at 1:08 PM wangyifan (AI) 
>  > wrote:
>> 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 the real traffic.
>> 
>> 2. The TWAMP session can be deployed to measure the packet loss rate 
>> before the flexible algorithm is configured. Consequently the packet loss 
>> caused by real traffic tests can be prevented.
>> 
>> 3. The measured packet loss rate can be suppressed to prevent frequent 
>> traffic switching caused by link loss changes.
>> 
>>  
>> 
>> Regards,
>> 
>> Yifan Wang.
>> 
>>  
>> 
>> 发件人: Lsr mailto:lsr-boun...@ietf.org>> 代表 Alexander 
>> Vainshtein
>> 发送时间: 2023年11月6日 18:15
>> 收件人: draft-wang-lsr-flex-algo-link-loss.auth...@ietf.org 
>> 
>> 抄送: lsr@ietf.org ; Nitsan Dolev > >
>> 主题: [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 eligible for traffic again.
>> 
>>  
>> 
>> For this scheme to work, link loss measurement should be done in a way that 
>> does not depend on the amount of customer traffic crossing the link.
>> 
>>  
>> 
>> I also think that, even with such a scheme, some kind of hysteresis 
>> mechanism is required to prevent link being frequently excluded and admitted 
>> back if the packet loss rate fluctuates around the threshold level,
>> 
>>  
>> 
>>  
>> 
>> My 2c,
>> 
>> Sasha
>> 
>>  
>> 
>>  
>> 
>> Disclaimer
>> 
>> This e-mail together with any attachments may contain information of Ribbon 
>> Communications Inc. and its Affiliates that is confidential and/or 
>> proprietary for the sole use of the intended recipient. Any review, 
>> disclosure, reliance or distribution by others or forwarding without express 
>> permission is strictly prohibited. If you are not the intended recipient, 
>> please notify the sender immediately and then delete all copies, including 
>> any attachments.
>> 
>> ___
>> Lsr mailing list
>> Lsr@ietf.org 
>> https://www.ietf.org/mailman/listinfo/lsr
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Greg Mirsky]

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 Direct measurement extension of STAMP (RFC 8972
) can measure data traffic loss
using operator-defined "in-profile" characteristics of the monitored flow.

Regards,
Greg

On Mon, Nov 6, 2023 at 1:08 PM wangyifan (AI)  wrote:

> 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 the real traffic.
>
> 2. The TWAMP session can be deployed to measure the packet loss rate
> before the flexible algorithm is configured. Consequently the packet loss
> caused by real traffic tests can be prevented.
>
> 3. The measured packet loss rate can be suppressed to prevent
> frequent traffic switching caused by link loss changes.
>
>
>
> Regards,
>
> Yifan Wang.
>
>
>
> *发件人:* Lsr  *代表 *Alexander Vainshtein
> *发送时间:* 2023年11月6日 18:15
> *收件人:* draft-wang-lsr-flex-algo-link-loss.auth...@ietf.org
> *抄送:* lsr@ietf.org; Nitsan Dolev 
> *主题:* [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 eligible for traffic again.
>
>
>
> For this scheme to work, link loss measurement should be done in a way
> that does not depend on the amount of customer traffic crossing the link.
>
>
>
> I also think that, even with such a scheme, some kind of hysteresis
> mechanism is required to prevent link being frequently excluded and
> admitted back if the packet loss rate fluctuates around the threshold level,
>
>
>
>
>
> My 2c,
>
> Sasha
>
>
>
>
>
> *Disclaimer*
>
> This e-mail together with any attachments may contain information of
> Ribbon Communications Inc. and its Affiliates that is confidential and/or
> proprietary for the sole use of the intended recipient. Any review,
> disclosure, reliance or distribution by others or forwarding without
> express permission is strictly prohibited. If you are not the intended
> recipient, please notify the sender immediately and then delete all copies,
> including any attachments.
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Are NomCom feedbacks still open ?

[Acee Lindem]

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 still 
>> suggest to the meeting participants to provide NomCom with feedbacks on 
>> their known nominees ? Even if the advertised limit was last Friday (if 
>> not mistaken)? The feedback form is still open ;-)
>> 
>> Hope it helps,
>> 
>> -éric
> 

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] Technical questions for draft about unreachable prefixes announcement

[Aijun Wang]

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, to-be-implemented sub-TLV?

2) It is unnecessary to define the “UP” flag——if the operator know the 
unreachable event in advance, they can also schedule the switchover of the 
related services in advance. Why bother IGP to transfer such information?

3) There is very limited usage of LS_Infinity in current network. From the 
operator’s viewpoint, we will decrease its usage also in future. Then the 
solution should try their best to avoid their usages——Current solutions instead 
enhance its usage——It is unacceptable. Let’s keep the network simple.

4) We can’t ignore the partitions scenarios or let’s it go.

5) There should be some mechanisms to control the volume of advertised 
unreachable information, when compared with reachable information, as done in 
https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-12#section-6.

Please consider the above technical issues carefully before evaluating and 
adopted any proposal.

If the above issues can’t be solved, we request the WG to adopt also the 
https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/,which
 cover and solve all of the above issues.

Aijun Wang
China Telecom___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Rakesh Gandhi]

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,
Rakesh



On Mon, Nov 6, 2023 at 11:15 AM Alexander Vainshtein <
alexander.vainsht...@rbbn.com> wrote:

> 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 eligible for traffic again.
>
>
>
> For this scheme to work, link loss measurement should be done in a way
> that does not depend on the amount of customer traffic crossing the link.
>
>
>
> I also think that, even with such a scheme, some kind of hysteresis
> mechanism is required to prevent link being frequently excluded and
> admitted back if the packet loss rate fluctuates around the threshold level,
>
>
>
>
>
> My 2c,
>
> Sasha
>
>
>
>
> *Disclaimer*
>
> This e-mail together with any attachments may contain information of
> Ribbon Communications Inc. and its Affiliates that is confidential and/or
> proprietary for the sole use of the intended recipient. Any review,
> disclosure, reliance or distribution by others or forwarding without
> express permission is strictly prohibited. If you are not the intended
> recipient, please notify the sender immediately and then delete all copies,
> including any attachments.
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[wangyifan (AI)]

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 the real traffic.

2. The TWAMP session can be deployed to measure the packet loss rate before 
the flexible algorithm is configured. Consequently the packet loss caused by 
real traffic tests can be prevented.

3. The measured packet loss rate can be suppressed to prevent frequent 
traffic switching caused by link loss changes.

Regards,
Yifan Wang.

发件人: Lsr  代表 Alexander Vainshtein
发送时间: 2023年11月6日 18:15
收件人: draft-wang-lsr-flex-algo-link-loss.auth...@ietf.org
抄送: lsr@ietf.org; Nitsan Dolev 
主题: [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 eligible for traffic again.

For this scheme to work, link loss measurement should be done in a way that 
does not depend on the amount of customer traffic crossing the link.

I also think that, even with such a scheme, some kind of hysteresis mechanism 
is required to prevent link being frequently excluded and admitted back if the 
packet loss rate fluctuates around the threshold level,


My 2c,
Sasha



Disclaimer

This e-mail together with any attachments may contain information of Ribbon 
Communications Inc. and its Affiliates that is confidential and/or proprietary 
for the sole use of the intended recipient. Any review, disclosure, reliance or 
distribution by others or forwarding without express permission is strictly 
prohibited. If you are not the intended recipient, please notify the sender 
immediately and then delete all copies, including any attachments.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Liubing (Leo)]

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 not directly related to routing in 
routing protocols.
We have some existing work addressing this problem (RFC6823 IS-IS Generic 
Information, OSPF-GT etc.), and also some new proposal (DROID etc.). And maybe 
we could also have a look at the tools developed in ops area as well (e.g. 
ANIMA output). So let’s figure out whether we could sort out a consensus of 
which way to go.

So if you are interested in this topic, please join the side meeting on Tuesday 
8:30-9:30AM, Karlin 4 room.
For remote participants, there is a webex link: 
https://ietf.webex.com/meet/sidemeetingietf1 .

Many thanks for your attension.

B.R.
Bing
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Nitsan Dolev]

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: draft-wang-lsr-flex-algo-link-loss.auth...@ietf.org
Cc: lsr@ietf.org; Nitsan Dolev 
Subject: 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 eligible for traffic again.

For this scheme to work, link loss measurement should be done in a way that 
does not depend on the amount of customer traffic crossing the link.

I also think that, even with such a scheme, some kind of hysteresis mechanism 
is required to prevent link being frequently excluded and admitted back if the 
packet loss rate fluctuates around the threshold level,


My 2c,
Sasha

Disclaimer

This e-mail together with any attachments may contain information of Ribbon 
Communications Inc. and its Affiliates that is confidential and/or proprietary 
for the sole use of the intended recipient. Any review, disclosure, reliance or 
distribution by others or forwarding without express permission is strictly 
prohibited. If you are not the intended recipient, please notify the sender 
immediately and then delete all copies, including any attachments.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Alexander Vainshtein]

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 eligible for traffic again.

For this scheme to work, link loss measurement should be done in a way that 
does not depend on the amount of customer traffic crossing the link.

I also think that, even with such a scheme, some kind of hysteresis mechanism 
is required to prevent link being frequently excluded and admitted back if the 
packet loss rate fluctuates around the threshold level,


My 2c,
Sasha

Disclaimer

This e-mail together with any attachments may contain information of Ribbon 
Communications Inc. and its Affiliates that is confidential and/or proprietary 
for the sole use of the intended recipient. Any review, disclosure, reliance or 
distribution by others or forwarding without express permission is strictly 
prohibited. If you are not the intended recipient, please notify the sender 
immediately and then delete all copies, including any attachments.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr