Re: [Lsr] Generic metric: application-specific vs application-independent

[Shraddha Hegde]

Operators have built their networks with link attributes
being configured and used by any application. For example
igp-metric is used by ISIS, then came LDP that used same igp-metric,
RSVP could also use igp-metric. Then came ISIS-SR and SR-TE
and even flex-algo. All these applications could use the same igp-metric.
The networks have evolved like this for 20-30 years.
If an operator wants to design his network for this kind of
network evolution with generic metric going forward, ASLA does not
currently provide an effective solution. ASLA currently has limitations
that make it more complex than necessary for operators who want to
evolve their networks this way.

I am working on a draft to propose improvements to ASLA to
make this kind of evolution less complex. I'll post a draft
soon that will describe limitations of ASLA in its current form
along with proposed improvements.

I would still like to hear about use cases that require
generic metric to be applications-specific and cannot be solved with
application-independent generic metric.


Rgds
Shraddha



Juniper Business Use Only
From: Les Ginsberg (ginsberg) 
Sent: Thursday, July 29, 2021 2:00 AM
To: Tony Li 
Cc: lsr@ietf.org; Shraddha Hegde 
Subject: RE: [Lsr] Generic metric: application-specific vs 
application-independent

[External Email. Be cautious of content]

Tony -

You ask very important questions - but - as Acee has answered in a subsequent 
email - all of these questions were openly debated in the WG during the work on 
what became RFC8919/8920. This debate was contentious, took years, and the WG 
eventually reached consensus on what became the two RFCs.

If every time a new attribute is defined we reopen the original debate, then we 
will never move forward and we will have great difficulty in deploying 
interoperable implementations.

I can respect that you might have preferred a different conclusion on the part 
of the WG - but I hope you will also acknowledge that this is now a resolved 
issue and we need to move forward following the existing RFCs.

Parenthetically, I do believe that answers to your questions can be found in 
the RFCs. The answers may not satisfy you - but we did attempt to include the 
context which drove the ASLA solution.
Thanx.

Les


From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Tony 
Li
Sent: Wednesday, July 28, 2021 1:06 PM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Cc: lsr@ietf.org; Shraddha Hegde 
mailto:shraddha=40juniper@dmarc.ietf.org>>
Subject: Re: [Lsr] Generic metric: application-specific vs 
application-independent


Les,

ASLA exists to support the advertisement of attributes which can be used in 
application specific ways.


Why do we need separate and different copies of attributes for different 
applications?

The SRLG tries to capture the risk relationships between multiple links. Those 
relationships don't change depending on the application.

Link attributes don't require the variability that ASLA provides, and the 
overhead is high.  How does this cost/benefit ratio make sense?


In any particular deployment case, a given attribute advertisement might be 
used by one app, multiple apps, or all apps.
ASLA allows to unambiguously support all of these cases with a single 
advertisement encoding format.

The correct question to be resolving here is indeed the question which has been 
discussed in an earlier thread: Is Generic Metric a link attribute which can 
have application specific use cases? I think the question to that is 
unquestionably "yes".
That should be enough (IMO of course) to close the discussion.


Well, one nice thing is that there is an entire space of metrics available.  If 
application A wants to use metric 16 and application B wants to use metric 122, 
that's already doable.

Why do we need a separate space per application

Tony

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

Re: [Lsr] Comments on "Passive Interface Attribute" - draft-wang-lsr-passive-interface-attribute

[Gyan Mishra]

Hi Acee

In-line

On Thu, Jul 29, 2021 at 4:24 PM Acee Lindem (acee)  wrote:

> Speaking as WG member:
>
>
>
> Authors,
>
>
>
> I think this draft is still flawed. Regarding the terminology, I don’t
> think it should refer to passive interfaces at all since they aren’t
> referenced in protocol documents. Rather, you should use stub-link
> consistently – including the title. However, I don’t think this makes any
> difference as I think you need to “go back to the drawing board”.
>
>  Gyan> Agreed.  We will change any references to passive  to stub.
>
> Why do other routers in the domain need to know the link if it isn’t
> connected to any other routers? The stub-link is an artifact of OSPFv2 used
> to advertise local prefixes. As you noticed, it was removed in OSPFv3 and
> local prefixes are advertised in Intra-Area-Prefix LSAs (and
> E-Inter-Area-Prefix-LSAs). I really think you are trying to advertise
> attributes of a prefix and not a link. In fact, in OSPFv3 there is no
> address associated with the link – I see you have attempted to remedy this
> by adding a sub-TLV to advertise the prefix associated with the link ;^).
> So, now this local prefix will be advertised two different ways?
>
> Gyan>(We did remedy as you asked)  Per yours and I believe Peters a d
> others recommendation with OSPFV2 update RFC 7684 change from fixed format
> LSA to TLV based similar to OSPFV3 RFC 8362 which the other big change was
> the breakout of “topological” construct from the prefix creating separate
> router links LSA for “topological” and prefix LSA for prefixes.  As the
> passive or stub concept as you have reiterated to the authors is really
> topological and  of prefix based to use router links and not router prefix
> to add the new stub TLV so that is what we did for both OSPFV2 and OSPFV3
> and added new top level stub  TLV for ISIS.
>
> Specifically, what is BGP controller going to do with the stub link
> advertisement that it couldn’t do with a prefix advertisement?  Also, why
> can’t the AS boundary router report the inter-AS prefix via BGP-LS? The
> other routers in the IGP domain have no use for this information.
>
>  Gyan> From a use case perspective the goal is to make this new stub TLV
> generic so it can be used for any use case where you have a stub LSA that
> is advertised that can be tracked by the PCE controller for the NB BGP-LS
> building of the topological graphs and being able to distinguish any stub
> nets from  transit nets with neighbors.
>
> What is the use-case for knowing that a prefix is associated with a
> loopback? We already have the N-Flag (Node) for prefixes… What is your
> loopback use case?
>
> Gyan> When NBI BGP-LS builds the topological graphs it’s any stub link
> which could be inter-as or loopbacks or any interfaces so they can be
> differentiated when the LSDB is build for the TEDs database.
>
> Also, what is the Vlan interface use case? What possible use could other
> routers in the domain have for this information?
>
> Gyan> I believe vlan is just another example but it’s really any interface
> that is a stub link with no neighbors can be treated differently by the NBI
> BGP-LS, when the topological graph is built.
>
> Thanks,
> Acee
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
-- 



*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mis...@verizon.com *



*M 301 502-1347*
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Comments on "Prefix Unreachable Announcement" - draft-wang-lsr-prefix-unreachable-annoucement

[Gyan Mishra]

Hi Acee


On Thu, Jul 29, 2021 at 9:40 PM Acee Lindem (acee)  wrote:

> Hi Gyan,
>
>
>
> *From: *Gyan Mishra 
> *Date: *Thursday, July 29, 2021 at 9:13 PM
> *To: *Acee Lindem 
> *Cc: *"draft-wang-lsr-prefix-unreachable-annoucem...@ietf.org" <
> draft-wang-lsr-prefix-unreachable-annoucem...@ietf.org>, "lsr@ietf.org" <
> lsr@ietf.org>
> *Subject: *Re: [Lsr] Comments on "Prefix Unreachable Announcement" -
> draft-wang-lsr-prefix-unreachable-annoucement
>
>
>
>
>
> Hi Acee
>
>
>
> Answers in-line
>
>
>
> On Thu, Jul 29, 2021 at 7:02 PM Acee Lindem (acee)  40cisco@dmarc.ietf.org> wrote:
>
> Speaking as WG member:
>
>
>
> Authors,
>
>
>
> I have comments and questions on the draft – many of them that I have
> raised before.
>
>
>
> 1.   If you use the standard advertisements and overload the
> prefix-originator information, all the routers in the domain will need to
> support it and you will have a fork lift upgrade. Otherwise, the ABRs which
> don’t advertise a prefix unreachable will actually attract traffic from
> down level routers. I’ve raised this several times in the past.
>
>Gyan> Yes to use the PUA feature all nodes must be upgraded.
>
>
>
> Section 7 has been updated to reflect.
>
>
>
> *7 
> .
>   Deployment Considerations*
>
>
>
>To support the PUA advertisement, the ABRs should be upgraded
>
>according to the procedures described in Section 4 
> .
>
>
>
> This just says the ABRs need to be upgraded. I’m saying all the routers need 
> to be upgraded since any router in the path misinterpreting the PUA and 
> actually installing it as a positive route could result in a blackhole or 
> worse, a loop.
>
>
Gyan> Good catch & you are correct all devices need to be upgraded.
Will update the draft.

>
>
> 1.
>
> 2.   How do you know what prefixes to protect with this PUA mechanism? Is
> it any prefix you’ve seen in the past? What if the prefix is actually taken
> out of service? What if it was a misconfiguration? What if the prefix is
> unreachable when the ABR IGP is started?
>
> So the main scenario this is used for is RFC 5283  inter area LDP
> extension for LPM match instead for MPLS standard exact match for FEC.  For
> this MPLS scenario where the operators had carved core AS into multiple
> areas or levels.  So the BGP next hop attribute update source loop0 is what
> we are tracking that is summarized so when the egress PE goes down the LSP
> now does not black hole on the ABR and the control plane convergence occurs
> with the PUA mechanism and forces the LSP to get built to the alternate
> PE.  In this scenario and maybe even others the PUA is being used to track
> the next hop and force the failover. This solution can apply as well to non
> MPLS, IP based scenario BGP next hop convergence to trigger the control
> plane convergence with PUA negative advertisement so can also apply to SRv6.
>
>
>
> So how would the ABRs know which prefixes these are? Is it any summary
> component or are they configured?
>
> Gyan> So it could be any prefix within the summary range that could have
> the PUA action occur, but the most important one is the BGP next hop
> attribute loop to be tracked.
>
   We will add text around that we can have an ACL to match only
interesting prefixes which in this case the only one is the next hop
attribute.

> 1.
>
> 2.   The forwarding plane behavior is non-standard? How does it work?
> This is clearly under specified
>
> There is no change to the data plane forwarding
>
>  behavior.  The change is with the control plane to set the next hop
> loopback from the down PE that no longer in the RIB/FIB to null so the
> control plane converges on the alternate next hop.  When the control plane
> convergence occurs based on the PUA negative advertisement the data plane
> follows and the RIB/FIB get programmed as they would normally.
>
>
>
> Ahh… I was about to ask this same question on the “IS-IS and OSPF
> Extension for Event Notification” draft. So while both these drafts claim
> to not upgrade the route table, both do but indirectly when next-hop for
> the BGP loopback is removed
>
 Gyan> It does but the IGP control plane perspective but does  not in any
> way change the data plane behavior which of course automatically follows
> the control plane.
>
> 1.   .
>
> 2.   This is somewhat minor compared to the other
>
>
>
> 1.   comments, in section 6 both conditions 1 and 2 can be true at the
> same time. In the event the other comments are resolved, this section needs
> some work.
>
>  We would make #1 less then or equal to do both conditions can never be
> true simultaneously in the next update.
>
> Ok – this needs to be clarified as well as whether one stops as soon as a
> condition is satisfied, i.e., an implied “else” between conditions.
>
>
   Gyan>Yes  Will do

 

Re: [Lsr] Comments on "Prefix Unreachable Announcement" - draft-wang-lsr-prefix-unreachable-annoucement

[Acee Lindem (acee)]

Hi Gyan,

From: Gyan Mishra 
Date: Thursday, July 29, 2021 at 9:13 PM
To: Acee Lindem 
Cc: "draft-wang-lsr-prefix-unreachable-annoucem...@ietf.org" 
, "lsr@ietf.org" 

Subject: Re: [Lsr] Comments on "Prefix Unreachable Announcement" - 
draft-wang-lsr-prefix-unreachable-annoucement


Hi Acee

Answers in-line

On Thu, Jul 29, 2021 at 7:02 PM Acee Lindem (acee) 
mailto:40cisco@dmarc.ietf.org>> wrote:
Speaking as WG member:

Authors,

I have comments and questions on the draft – many of them that I have raised 
before.


1.   If you use the standard advertisements and overload the prefix-originator 
information, all the routers in the domain will need to support it and you will 
have a fork lift upgrade. Otherwise, the ABRs which don’t advertise a prefix 
unreachable will actually attract traffic from down level routers. I’ve raised 
this several times in the past.
   Gyan> Yes to use the PUA feature all nodes must be upgraded.

Section 7 has been updated to reflect.


7.
  Deployment Considerations



   To support the PUA advertisement, the ABRs should be upgraded

   according to the procedures described in Section 
4.



This just says the ABRs need to be upgraded. I’m saying all the routers need to 
be upgraded since any router in the path misinterpreting the PUA and actually 
installing it as a positive route could result in a blackhole or worse, a loop.


1.

2.   How do you know what prefixes to protect with this PUA mechanism? Is it 
any prefix you’ve seen in the past? What if the prefix is actually taken out of 
service? What if it was a misconfiguration? What if the prefix is unreachable 
when the ABR IGP is started?
So the main scenario this is used for is RFC 5283  inter area LDP extension for 
LPM match instead for MPLS standard exact match for FEC.  For this MPLS 
scenario where the operators had carved core AS into multiple areas or levels.  
So the BGP next hop attribute update source loop0 is what we are tracking that 
is summarized so when the egress PE goes down the LSP now does not black hole 
on the ABR and the control plane convergence occurs with the PUA mechanism and 
forces the LSP to get built to the alternate PE.  In this scenario and maybe 
even others the PUA is being used to track the next hop and force the failover. 
This solution can apply as well to non MPLS, IP based scenario BGP next hop 
convergence to trigger the control plane convergence with PUA negative 
advertisement so can also apply to SRv6.

So how would the ABRs know which prefixes these are? Is it any summary 
component or are they configured?


1.

2.   The forwarding plane behavior is non-standard? How does it work? This is 
clearly under specified
There is no change to the data plane forwarding
 behavior.  The change is with the control plane to set the next hop loopback 
from the down PE that no longer in the RIB/FIB to null so the control plane 
converges on the alternate next hop.  When the control plane convergence occurs 
based on the PUA negative advertisement the data plane follows and the RIB/FIB 
get programmed as they would normally.

Ahh… I was about to ask this same question on the “IS-IS and OSPF Extension for 
Event Notification” draft. So while both these drafts claim to not upgrade the 
route table, both do but indirectly when next-hop for the BGP loopback is 
removed.


1.   .

2.   This is somewhat minor compared to the other


1.   comments, in section 6 both conditions 1 and 2 can be true at the same 
time. In the event the other comments are resolved, this section needs some 
work.
 We would make #1 less then or equal to do both conditions can never be true 
simultaneously in the next update.
Ok – this needs to be clarified as well as whether one stops as soon as a 
condition is satisfied, i.e., an implied “else” between conditions.
Thanks,
Acee


Thanks,
Acee
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
--

[Image removed by sender.]

Gyan Mishra

Network Solutions Architect

Email gyan.s.mis...@verizon.com

M 301 502-1347

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

Re: [Lsr] Comments on "Prefix Unreachable Announcement" - draft-wang-lsr-prefix-unreachable-annoucement

[Gyan Mishra]

Hi Acee

Answers in-line

On Thu, Jul 29, 2021 at 7:02 PM Acee Lindem (acee)  wrote:

> Speaking as WG member:
>
>
>
> Authors,
>
>
>
> I have comments and questions on the draft – many of them that I have
> raised before.
>
>
>
>1. If you use the standard advertisements and overload the
>prefix-originator information, all the routers in the domain will need to
>support it and you will have a fork lift upgrade. Otherwise, the ABRs which
>don’t advertise a prefix unreachable will actually attract traffic from
>down level routers. I’ve raised this several times in the past.
>
>Gyan> Yes to use the PUA feature all nodes must be upgraded.

Section 7 has been updated to reflect.

7 
.
Deployment Considerations

   To support the PUA advertisement, the ABRs should be upgraded
   according to the procedures described in Section 4
.



>1.
>2. How do you know what prefixes to protect with this PUA mechanism?
>Is it any prefix you’ve seen in the past? What if the prefix is actually
>taken out of service? What if it was a misconfiguration? What if the prefix
>is unreachable when the ABR IGP is started?
>
> So the main scenario this is used for is RFC 5283  inter area LDP
extension for LPM match instead for MPLS standard exact match for FEC.  For
this MPLS scenario where the operators had carved core AS into multiple
areas or levels.  So the BGP next hop attribute update source loop0 is what
we are tracking that is summarized so when the egress PE goes down the LSP
now does not black hole on the ABR and the control plane convergence occurs
with the PUA mechanism and forces the LSP to get built to the alternate
PE.  In this scenario and maybe even others the PUA is being used to track
the next hop and force the failover. This solution can apply as well to non
MPLS, IP based scenario BGP next hop convergence to trigger the control
plane convergence with PUA negative advertisement so can also apply to SRv6.


>1.
>2. The forwarding plane behavior is non-standard? How does it work?
>This is clearly under specified
>
> There is no change to the data plane forwarding
 behavior.  The change is with the control plane to set the next hop
loopback from the down PE that no longer in the RIB/FIB to null so the
control plane converges on the alternate next hop.  When the control plane
convergence occurs based on the PUA negative advertisement the data plane
follows and the RIB/FIB get programmed as they would normally.


>1. .
>2. This is somewhat minor compared to the other
>
>

>1. comments, in section 6 both conditions 1 and 2 can be true at the
>same time. In the event the other comments are resolved, this section needs
>some work.
>
>  We would make #1 less then or equal to do both conditions can never be
> true simultaneously in the next update.
>
> Thanks,
> Acee
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
-- 



*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mis...@verizon.com *



*M 301 502-1347*
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] draft-decraene-lsr-isis-flooding-speed & IETF 111

[guillaume.solignac]

Les,

Please see [GS2] inline.


Guillaume –

Please see LES2: inline.

*From:* guillaume.solig...@orange.com 
 >

*Sent:* Thursday, July 29, 2021 10:34 AM
*To:* Les Ginsberg (ginsberg) >; bruno.decra...@orange.com 
; lsr-cha...@ietf.org 


*Cc:* lsr@ietf.org 
*Subject:* Re: [Lsr] draft-decraene-lsr-isis-flooding-speed & IETF 111

Les,

Thanks for taking your time to answer.

Le 29/07/2021 à 18:26, Les Ginsberg (ginsberg) a écrit :

Guillaume –

Thanx for the thoughtful response.

Responses inline.

*From:* guillaume.solig...@orange.com



*Sent:* Thursday, July 29, 2021 3:20 AM
*To:* Les Ginsberg (ginsberg) 
; bruno.decra...@orange.com
; lsr-cha...@ietf.org

*Cc:* lsr@ietf.org 
*Subject:* Re: [Lsr] draft-decraene-lsr-isis-flooding-speed & IETF 111

Hello Les,

Jumping in since I have some insight as well.

Le 29/07/2021 à 08:51, Les Ginsberg (ginsberg) a écrit :

Bruno –

Resuming this thread…

I assure you that we have the same goals.

We are not yet in agreement on the best way to achieve those
goals.

Your slides show indeed we have the same goal, and we agree on one
way to deal with the matter (congestion control).


Looking forward to the WG discussion on Friday.

To get some discussion going in advance – if you have time to
do so (which I know is challenging especially during IETF
week) – I call your attention to slides 15-18 in the
presentation we have prepared:


https://datatracker.ietf.org/meeting/111/materials/slides-111-lsr-21-isis-flood-scale-00



I do not intend to present these slides during my portion of
the presentation time – but I included them as potential
points of discussion during the discussion portion of the
meeting (though the WG chairs will decide how best to direct
that portion of the time).

I call your attention specifically to Slide 16, which
discusses the functional elements in the input path typically
seen on router platforms.

Each of these elements has controls associated with it – from
queue sizes to punt rates, etc. that play a significant role
in delivery of incoming IS-IS PDUs to the protocol running in
the control plan.

Your slides –

https://datatracker.ietf.org/meeting/111/materials/slides-111-lsr-22-flow-congestion-control-00




 focus only on the direct input queue to IS-IS in the control
plane. I do not see how the state of the other staging
elements on the path from PDU ingress to IS-IS implementation
reading the PDUs in the control plane is known and/or used in
determining the flow control state signaled to the
transmitting neighbor. If, for example, PDUs were being
dropped on ingress and never made it to IS-IS in the control
plane, how would your algorithm be aware of this and react to
this?

In my experience, the state of these lower level staging
elements plays a significant role.

I can imagine that some form of signaling from the dataplane
to the control plane about the state of these lower level
elements could be possible – and that signaling could be used
as input to a receiver based control algorithm. However, given
the differences as to how individual platforms implement these
lower level elements,  I see it as challenging to get each
platform to provide the necessary signaling in real time and
to normalize it in a way so that IS-IS flow control logic in
the control plane can use the data in a platform independent
way. I believe this represents a significant bar to successful
deployment of receiver-based flow control.

That's one point we want to clarify, the flow control algorithm
does not focus on the "IO path" between the line card and the
control plane. There is no magic there, it does not directly deals
with congestion on the IO path. It happens it has some nice
properties even in case of drops before reaching the control
plane, but it's arguably not sufficient. That's why we also
propose a congestion control algorithm. While it is not necessary
to establish a standard since it's only local, it helps ha

[Lsr] Comments on "Prefix Unreachable Announcement" - draft-wang-lsr-prefix-unreachable-annoucement

[Acee Lindem (acee)]

Speaking as WG member:

Authors,

I have comments and questions on the draft – many of them that I have raised 
before.


  1.  If you use the standard advertisements and overload the prefix-originator 
information, all the routers in the domain will need to support it and you will 
have a fork lift upgrade. Otherwise, the ABRs which don’t advertise a prefix 
unreachable will actually attract traffic from down level routers. I’ve raised 
this several times in the past.
  2.  How do you know what prefixes to protect with this PUA mechanism? Is it 
any prefix you’ve seen in the past? What if the prefix is actually taken out of 
service? What if it was a misconfiguration? What if the prefix is unreachable 
when the ABR IGP is started?
  3.  The forwarding plane behavior is non-standard? How does it work? This is 
clearly under specified.
  4.  This is somewhat minor compared to the other comments, in section 6 both 
conditions 1 and 2 can be true at the same time. In the event the other 
comments are resolved, this section needs some work.

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

Re: [Lsr] draft-decraene-lsr-isis-flooding-speed & IETF 111

[Les Ginsberg (ginsberg)]

Guillaume –

Please see LES2: inline.

From: guillaume.solig...@orange.com 
mailto:guillaume.solig...@orange.com>>
Sent: Thursday, July 29, 2021 10:34 AM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
bruno.decra...@orange.com; 
lsr-cha...@ietf.org
Cc: lsr@ietf.org
Subject: Re: [Lsr] draft-decraene-lsr-isis-flooding-speed & IETF 111


Les,

Thanks for taking your time to answer.
Le 29/07/2021 à 18:26, Les Ginsberg (ginsberg) a écrit :
Guillaume –

Thanx for the thoughtful response.
Responses inline.

From: guillaume.solig...@orange.com 

Sent: Thursday, July 29, 2021 3:20 AM
To: Les Ginsberg (ginsberg) ; 
bruno.decra...@orange.com; 
lsr-cha...@ietf.org
Cc: lsr@ietf.org
Subject: Re: [Lsr] draft-decraene-lsr-isis-flooding-speed & IETF 111

Hello Les,

Jumping in since I have some insight as well.
Le 29/07/2021 à 08:51, Les Ginsberg (ginsberg) a écrit :
Bruno –

Resuming this thread…

I assure you that we have the same goals.
We are not yet in agreement on the best way to achieve those goals.
Your slides show indeed we have the same goal, and we agree on one way to deal 
with the matter (congestion control).



Looking forward to the WG discussion on Friday.

To get some discussion going in advance – if you have time to do so (which I 
know is challenging especially during IETF week) – I call your attention to 
slides 15-18 in the presentation we have prepared:

https://datatracker.ietf.org/meeting/111/materials/slides-111-lsr-21-isis-flood-scale-00

I do not intend to present these slides during my portion of the presentation 
time – but I included them as potential points of discussion during the 
discussion portion of the meeting (though the WG chairs will decide how best to 
direct that portion of the time).
I call your attention specifically to Slide 16, which discusses the functional 
elements in the input path typically seen on router platforms.
Each of these elements has controls associated with it – from queue sizes to 
punt rates, etc. that play a significant role in delivery of incoming IS-IS 
PDUs to the protocol running in the control plan.

Your slides – 
https://datatracker.ietf.org/meeting/111/materials/slides-111-lsr-22-flow-congestion-control-00
 focus only on the direct input queue to IS-IS in the control plane. I do not 
see how the state of the other staging elements on the path from PDU ingress to 
IS-IS implementation reading the PDUs in the control plane is known and/or used 
in determining the flow control state signaled to the transmitting neighbor. 
If, for example, PDUs were being dropped on ingress and never made it to IS-IS 
in the control plane, how would your algorithm be aware of this and react to 
this?

In my experience, the state of these lower level staging elements plays a 
significant role.

I can imagine that some form of signaling from the dataplane to the control 
plane about the state of these lower level elements could be possible – and 
that signaling could be used as input to a receiver based control algorithm. 
However, given the differences as to how individual platforms implement these 
lower level elements,  I see it as challenging to get each platform to provide 
the necessary signaling in real time and to normalize it in a way so that IS-IS 
flow control logic in the control plane can use the data in a platform 
independent way. I believe this represents a significant bar to successful 
deployment of receiver-based flow control.

That's one point we want to clarify, the flow control algorithm does not focus 
on the "IO path" between the line card and the control plane. There is no magic 
there, it does not directly deals with congestion on the IO path. It happens it 
has some nice properties even in case of drops before reaching the control 
plane, but it's arguably not sufficient. That's why we also propose a 
congestion control algorithm. While it is not necessary to establish a standard 
since it's only local, it helps having a baseline if one does not want to spend 
time re-developing its own algorithm.

Our slides also show the result of our congestion control algorithm, which is 
the part that deals with IO path losses. Very much like your algorithm, ours 
sees this IO path as a black box.

[LES:] This is an aspect on which I need further clarification.

From the POV of the control plane, in the absence of enhanced signaling (which 
I believe is problematic to implement – and you seem to agree) you simply have 
no knowledge as to whether incoming PDUs have been dropped or are simply 
delayed.
[GS] From the receiver side, absolutely.
[LES2:] This is also true from the TX side. At a given moment all the TX side 
knows is that an ACK for a giv

[Lsr] Comments on "Passive Interface Attribute" - draft-wang-lsr-passive-interface-attribute

[Acee Lindem (acee)]

Speaking as WG member:

Authors,

I think this draft is still flawed. Regarding the terminology, I don’t think it 
should refer to passive interfaces at all since they aren’t referenced in 
protocol documents. Rather, you should use stub-link consistently – including 
the title. However, I don’t think this makes any difference as I think you need 
to “go back to the drawing board”.

Why do other routers in the domain need to know the link if it isn’t connected 
to any other routers? The stub-link is an artifact of OSPFv2 used to advertise 
local prefixes. As you noticed, it was removed in OSPFv3 and local prefixes are 
advertised in Intra-Area-Prefix LSAs (and E-Inter-Area-Prefix-LSAs). I really 
think you are trying to advertise attributes of a prefix and not a link. In 
fact, in OSPFv3 there is no address associated with the link – I see you have 
attempted to remedy this by adding a sub-TLV to advertise the prefix associated 
with the link ;^). So, now this local prefix will be advertised two different 
ways?

Specifically, what is BGP controller going to do with the stub link 
advertisement that it couldn’t do with a prefix advertisement?  Also, why can’t 
the AS boundary router report the inter-AS prefix via BGP-LS? The other routers 
in the IGP domain have no use for this information.

What is the use-case for knowing that a prefix is associated with a loopback? 
We already have the N-Flag (Node) for prefixes… What is your loopback use case?

Also, what is the Vlan interface use case? What possible use could other 
routers in the domain have for this information?

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

Re: [Lsr] draft-decraene-lsr-isis-flooding-speed & IETF 111

[guillaume.solignac]

Les,

Thanks for taking your time to answer.

Le 29/07/2021 à 18:26, Les Ginsberg (ginsberg) a écrit :


Guillaume –

Thanx for the thoughtful response.

Responses inline.

*From:* guillaume.solig...@orange.com 
*Sent:* Thursday, July 29, 2021 3:20 AM
*To:* Les Ginsberg (ginsberg) ; 
bruno.decra...@orange.com; lsr-cha...@ietf.org

*Cc:* lsr@ietf.org
*Subject:* Re: [Lsr] draft-decraene-lsr-isis-flooding-speed & IETF 111

Hello Les,

Jumping in since I have some insight as well.

Le 29/07/2021 à 08:51, Les Ginsberg (ginsberg) a écrit :

Bruno –

Resuming this thread…

I assure you that we have the same goals.

We are not yet in agreement on the best way to achieve those goals.

Your slides show indeed we have the same goal, and we agree on one way 
to deal with the matter (congestion control).


Looking forward to the WG discussion on Friday.

To get some discussion going in advance – if you have time to do
so (which I know is challenging especially during IETF week) – I
call your attention to slides 15-18 in the presentation we have
prepared:


https://datatracker.ietf.org/meeting/111/materials/slides-111-lsr-21-isis-flood-scale-00



I do not intend to present these slides during my portion of the
presentation time – but I included them as potential points of
discussion during the discussion portion of the meeting (though
the WG chairs will decide how best to direct that portion of the
time).

I call your attention specifically to Slide 16, which discusses
the functional elements in the input path typically seen on router
platforms.

Each of these elements has controls associated with it – from
queue sizes to punt rates, etc. that play a significant role in
delivery of incoming IS-IS PDUs to the protocol running in the
control plan.

Your slides –

https://datatracker.ietf.org/meeting/111/materials/slides-111-lsr-22-flow-congestion-control-00




 focus only on the direct input queue to IS-IS in the control
plane. I do not see how the state of the other staging elements on
the path from PDU ingress to IS-IS implementation reading the PDUs
in the control plane is known and/or used in determining the flow
control state signaled to the transmitting neighbor. If, for
example, PDUs were being dropped on ingress and never made it to
IS-IS in the control plane, how would your algorithm be aware of
this and react to this?

In my experience, the state of these lower level staging elements
plays a significant role.

I can imagine that some form of signaling from the dataplane to
the control plane about the state of these lower level elements
could be possible – and that signaling could be used as input to a
receiver based control algorithm. However, given the differences
as to how individual platforms implement these lower level
elements,  I see it as challenging to get each platform to provide
the necessary signaling in real time and to normalize it in a way
so that IS-IS flow control logic in the control plane can use the
data in a platform independent way. I believe this represents a
significant bar to successful deployment of receiver-based flow
control.

That's one point we want to clarify, the flow control algorithm does 
not focus on the "IO path" between the line card and the control 
plane. There is no magic there, it does not directly deals with 
congestion on the IO path. It happens it has some nice properties even 
in case of drops before reaching the control plane, but it's arguably 
not sufficient. That's why we also propose a congestion control 
algorithm. While it is not necessary to establish a standard since 
it's only local, it helps having a baseline if one does not want to 
spend time re-developing its own algorithm.


Our slides also show the result of our congestion control algorithm, 
which is the part that deals with IO path losses. Very much like your 
algorithm, ours sees this IO path as a black box.


*/[LES:] This is an aspect on which I need further clarification./*

*/From the POV of the control plane, in the absence of enhanced 
signaling (which I believe is problematic to implement – and you seem 
to agree) you simply have no knowledge as to whether incoming PDUs 
have been dropped or are simply delayed./*



[GS] From the receiver side, absolutely.


*//*

*/On Slide 6 you say: “Sender will never send more than RWin 
unacknowledged LSPs”. On Slide 7 you describe how to choose RWIN. But 
all of these methods are fixed in size – not adaptive. And since the 
input queue of packets to IS-IS is not “per interface”, the number you 
choose for RWIN seems to have nothing at all to do with current 
state/neighbor./*


[GS]

Re: [Lsr] draft-decraene-lsr-isis-flooding-speed & IETF 111

[Les Ginsberg (ginsberg)]

Guillaume –

Thanx for the thoughtful response.
Responses inline.

From: guillaume.solig...@orange.com 
Sent: Thursday, July 29, 2021 3:20 AM
To: Les Ginsberg (ginsberg) ; bruno.decra...@orange.com; 
lsr-cha...@ietf.org
Cc: lsr@ietf.org
Subject: Re: [Lsr] draft-decraene-lsr-isis-flooding-speed & IETF 111

Hello Les,

Jumping in since I have some insight as well.
Le 29/07/2021 à 08:51, Les Ginsberg (ginsberg) a écrit :
Bruno –

Resuming this thread…

I assure you that we have the same goals.
We are not yet in agreement on the best way to achieve those goals.
Your slides show indeed we have the same goal, and we agree on one way to deal 
with the matter (congestion control).


Looking forward to the WG discussion on Friday.

To get some discussion going in advance – if you have time to do so (which I 
know is challenging especially during IETF week) – I call your attention to 
slides 15-18 in the presentation we have prepared:

https://datatracker.ietf.org/meeting/111/materials/slides-111-lsr-21-isis-flood-scale-00

I do not intend to present these slides during my portion of the presentation 
time – but I included them as potential points of discussion during the 
discussion portion of the meeting (though the WG chairs will decide how best to 
direct that portion of the time).
I call your attention specifically to Slide 16, which discusses the functional 
elements in the input path typically seen on router platforms.
Each of these elements has controls associated with it – from queue sizes to 
punt rates, etc. that play a significant role in delivery of incoming IS-IS 
PDUs to the protocol running in the control plan.

Your slides – 
https://datatracker.ietf.org/meeting/111/materials/slides-111-lsr-22-flow-congestion-control-00
 focus only on the direct input queue to IS-IS in the control plane. I do not 
see how the state of the other staging elements on the path from PDU ingress to 
IS-IS implementation reading the PDUs in the control plane is known and/or used 
in determining the flow control state signaled to the transmitting neighbor. 
If, for example, PDUs were being dropped on ingress and never made it to IS-IS 
in the control plane, how would your algorithm be aware of this and react to 
this?

In my experience, the state of these lower level staging elements plays a 
significant role.

I can imagine that some form of signaling from the dataplane to the control 
plane about the state of these lower level elements could be possible – and 
that signaling could be used as input to a receiver based control algorithm. 
However, given the differences as to how individual platforms implement these 
lower level elements,  I see it as challenging to get each platform to provide 
the necessary signaling in real time and to normalize it in a way so that IS-IS 
flow control logic in the control plane can use the data in a platform 
independent way. I believe this represents a significant bar to successful 
deployment of receiver-based flow control.

That's one point we want to clarify, the flow control algorithm does not focus 
on the "IO path" between the line card and the control plane. There is no magic 
there, it does not directly deals with congestion on the IO path. It happens it 
has some nice properties even in case of drops before reaching the control 
plane, but it's arguably not sufficient. That's why we also propose a 
congestion control algorithm. While it is not necessary to establish a standard 
since it's only local, it helps having a baseline if one does not want to spend 
time re-developing its own algorithm.

Our slides also show the result of our congestion control algorithm, which is 
the part that deals with IO path losses. Very much like your algorithm, ours 
sees this IO path as a black box.

[LES:] This is an aspect on which I need further clarification.

From the POV of the control plane, in the absence of enhanced signaling (which 
I believe is problematic to implement – and you seem to agree) you simply have 
no knowledge as to whether incoming PDUs have been dropped or are simply 
delayed.

On Slide 6 you say: “Sender will never send more than RWin unacknowledged 
LSPs”. On Slide 7 you describe how to choose RWIN. But all of these methods are 
fixed in size – not adaptive. And since the input queue of packets to IS-IS is 
not “per interface”, the number you choose for RWIN seems to have nothing at 
all to do with current state/neighbor.

You then go on to discuss RTT (which seems to be a configured or pre-determined 
value??) and LPP (LSPs acked/PSNP) – which is only meaningful for the LSPs that 
have actually made their way to IS-IS – no way to account for those that have 
been dropped or delayed.

So it is difficult for me to understand how you are actually accounting for the 
current state of the I/O path in real time on a per neighbor basis.

This is one major reason why we prefer a Tx based flow control mechanism. Tx 
based flow control simply focuses on the relative rates of L

Re: [Lsr] draft-decraene-lsr-isis-flooding-speed & IETF 111

[guillaume.solignac]

Hello Les,

Jumping in since I have some insight as well.

Le 29/07/2021 à 08:51, Les Ginsberg (ginsberg) a écrit :


Bruno –

Resuming this thread…

I assure you that we have the same goals.

We are not yet in agreement on the best way to achieve those goals.

Your slides show indeed we have the same goal, and we agree on one way 
to deal with the matter (congestion control).


Looking forward to the WG discussion on Friday.

To get some discussion going in advance – if you have time to do so 
(which I know is challenging especially during IETF week) – I call 
your attention to slides 15-18 in the presentation we have prepared:


https://datatracker.ietf.org/meeting/111/materials/slides-111-lsr-21-isis-flood-scale-00 



I do not intend to present these slides during my portion of the 
presentation time – but I included them as potential points of 
discussion during the discussion portion of the meeting (though the WG 
chairs will decide how best to direct that portion of the time).


I call your attention specifically to Slide 16, which discusses the 
functional elements in the input path typically seen on router platforms.


Each of these elements has controls associated with it – from queue 
sizes to punt rates, etc. that play a significant role in delivery of 
incoming IS-IS PDUs to the protocol running in the control plan.


Your slides – 
https://datatracker.ietf.org/meeting/111/materials/slides-111-lsr-22-flow-congestion-control-00 
 



 focus only on the direct input queue to IS-IS in the control plane. I 
do not see how the state of the other staging elements on the path 
from PDU ingress to IS-IS implementation reading the PDUs in the 
control plane is known and/or used in determining the flow control 
state signaled to the transmitting neighbor. If, for example, PDUs 
were being dropped on ingress and never made it to IS-IS in the 
control plane, how would your algorithm be aware of this and react to 
this?


In my experience, the state of these lower level staging elements 
plays a significant role.


I can imagine that some form of signaling from the dataplane to the 
control plane about the state of these lower level elements could be 
possible – and that signaling could be used as input to a receiver 
based control algorithm. However, given the differences as to how 
individual platforms implement these lower level elements,  I see it 
as challenging to get each platform to provide the necessary signaling 
in real time and to normalize it in a way so that IS-IS flow control 
logic in the control plane can use the data in a platform independent 
way. I believe this represents a significant bar to successful 
deployment of receiver-based flow control.


That's one point we want to clarify, the flow control algorithm does not 
focus on the "IO path" between the line card and the control plane. 
There is no magic there, it does not directly deals with congestion on 
the IO path. It happens it has some nice properties even in case of 
drops before reaching the control plane, but it's arguably not 
sufficient. That's why we also propose a congestion control algorithm. 
While it is not necessary to establish a standard since it's only local, 
it helps having a baseline if one does not want to spend time 
re-developing its own algorithm.


Our slides also show the result of our congestion control algorithm, 
which is the part that deals with IO path losses. Very much like your 
algorithm, ours sees this IO path as a black box.


This is one major reason why we prefer a Tx based flow control 
mechanism. Tx based flow control simply focuses on the relative rates 
of LSP transmission and reception of Acknowledgments. Whether slower 
acks are due to PDU drops at ingress, slow punt path operation, lack 
of CPU time for IS-IS to process the incoming packets, etc. matters 
not. Whatever the reason, if acks are not keeping pace with 
transmission we know we have to slow down.


As you can see in the slides & draft, we also have a congestion control 
algorithm and we show the results. This congestion control algorithm 
only works with the ACKs (like yours), and gives results in the case of 
"IO congestion" (like yours).


Flow and congestion control are not mutually exclusive; in fact it is 
almost certain it will be necessary to have both at some point. The main 
benefit of limiting the number of unacked packets inflight is to avoid 
loosing packets in case of CPU contention. As this should be a common 
situation (in part for reasons in your slide 15), flow control as we 
propose seems very relevant.


For example, in your Slowing Down scenario, if the slowing down occurs 
at the Control Plane, a congestion control algorithm will lose packets. 
If on top of your algorithm, you limit the number of unacked LSPs (flow 
cont