Re: [Lsr] IGP TE Metric Extensions

[Robert Raszuk]

​Muthu,​


> ​How is the measurement interval and filter coefficients described in the
> draft related to dissemination?​
>

​It is directly related. If you see the title of the section is:
"Announcement Thresholds and Filters"​

So measurement interval does not intend to describe how often you actually
measure ... it describes a time window where you report the value (which
could consist of many measurements actually taken).

We intentionally left out this part that does not belong to the igp
>> protocol machinery.
>>
>
> ​Which of the functionalities described in sections 5, 6, 7 of the draft
> belong to the IGP protocol machinery?
>


​What draft are you talking about ? I was under impression that we are
discussing RFCs here.

​All functionality from sections 5-7 aim to provide machinery to control
stability of protocol operation. It is one how you measure and this is not
part of the RFCs. and completely different what and how you advertised
derived values from those gathered by your measurements. Now keeping in
mind that you do not advertise when you measure but only when you are
allowed by protocol rules it should be easy to see the point which Stefano
made above.

​Thx,
R.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

[Robert Raszuk]

Tonys / Everyone,

> moreover, I observe that IME ISIS is much more robust under such
optimizations since the CSNPs catch (@ a somehow ugly delay cost)
> any corner cases whereas OSPF after IDBE will happily stay out of sync
forever if flooding skips something (that may actually become a
> reason to introduce periodic stuff on OSPF to do CSNP equivalent

Do we really need for DC use case to have flooding reduction standardized
for all three protocols ? ISIS, OSPFv2 & OSPFv3 ? Would just focusing on
ISIS not be sufficient ?

I am not sure if OSPF folks will feel offended or left behind if this work
proceeds for ISIS only - well at least for now till we get more experience
with the algorithm.

There is no shortage of protocols for MSDC use (M meaning Massive or
apparently Mid-size or even as reality shows Mini as well :)

Sure IGP flooding reduction can be useful beyond DCs, but do we have line
of people which are keen on trying this out outside of DC or DC like campus
environments ?

Thx,
R.

















On Fri, Aug 24, 2018 at 6:06 PM, Tony Przygienda 
wrote:

> OK, good, real work. So from some scar tissue here's one question
>
> a) we are talking any kind of topology for the solution, i.e. generic
> graph?
>
> and then suggestion for IME realistic, operational MUST requirements
>
> b) req a): the solution should support distributed and centralized
> algorithm to compute/signal reduced mesh(es). I personally think
> distributed is the more practical choice for something like this but it's
> my 2c from having lived the telephony controller fashion, the distributed
> fashion and the controller fashion now again ;-)
> c) req b): the solution should include redundancy (i.e. @ least 2
> maximally disjoint vertex covers/lifts) to deal with single link failure
> (unless the link is unavoidably a minimal cut on the graph)
> d) req c): the solution should guarantee disruption free flooding in case
> of
>   i) single link failure
>  ii) single node failure
>  iii) change in one of the vertex lifts
> e) the solution should not lead to "hot-spot" or "minimal-cut" links which
> will disrupt flooding between two partitions on failure or lead to flood
> throughput bottlenecks
>
> I am agnostic to Tony L's thinking about diameter and so on. It makes
> sense but is not necessarily easy to pull into the solution.
>
> moreover, I observe that IME ISIS is much more robust under such
> optimizations since the CSNPs catch (@ a somehow ugly delay cost) any
> corner cases whereas OSPF after IDBE will happily stay out of sync forever
> if flooding skips something (that may actually become a reason to introduce
> periodic stuff on OSPF to do CSNP equivalent albeit it won't be trivial in
> backwards compatible way on my first thought, I was thinking a bit about
> cut/snapshot consistency check [in practical terms OSPF hellos could carry
> a checksum on the DB headers] but we never have that luxury on a link-state
> routing protocol [i.e. we always operate under unbounded epsilon
> consistency ;-) and in case of BGP stable oscialltions BTW not even that
> ;^} ]).
>
> --- tony
>
>
> On Fri, Aug 24, 2018 at 8:36 AM Acee Lindem (acee)  40cisco@dmarc.ietf.org> wrote:
>
>> Speaking as WG member:
>>
>> I agree on this and don't believe we need a separate document or a
>> protracted discussion.
>> Additionally, I don't think we should worry about anything going on in
>> other WGs.
>> Thanks,
>> Acee
>> P.S. I'll provide more input to the discussion as well. As luck would
>> have it, I initiated the discussion and then had a couple more pressing
>> matters (including the cable company's fiber installation contractor
>> messing up my irrigation system ;^(
>>
>> On 8/24/18, 11:04 AM, "Lsr on behalf of tony...@tony.li" <
>> lsr-boun...@ietf.org on behalf of tony...@tony.li> wrote:
>>
>>
>> So, going Old Skool here:
>>
>> Since everyone agrees that this is a reasonable direction, how about
>> we have a real discussion on the list?
>>
>> Requirement number 1 is straightforward: a significant reduction in
>> flooding overhead.
>>
>> The basis for this requirement is the understanding that in a dense
>> topology, there is a great deal of redundancy due to flooding, and that it
>> is this redundancy that supersaturates the control plane.
>>
>> Do we agree on this?
>>
>> Tony
>>
>> ___
>> 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
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

[Robert Raszuk]

Hi Huaimo,

> Introducing centralized feature into IGP will break IGP's distributed
nature

That clearly proves that word "centralized" has been significantly
overloaded here.  To many indeed "centralized" means a controller (like
OpenFlow or SDN) and that such device added to a network is to push
information - typically 1RU linux blade -  here optimized flooding graph.
But this never was the plan with this proposal from its start ie. -00
version.

Centralized means that optimized flooding graph comes from single redundant
node.

Leader election happens automatically and procedures for that are to be
vastly similar to today's DR or DIS election. So with this in mind one may
observe that both OSPF and ISIS are pretty centralized on multiaccess
networks today :)

To your point of multi-vendor networks true - and that is precisely why
upgrade network wide to a release containing consistent algorithm from more
then a single vendor (and even for single vendor) is practically a very
time consuming and difficult process.

Btw I don't think there is any problem here ... The text added to -05
version allows very seamless choice of centralized vs distributed topology
computation by signalling either zero or non zero value in the added to
version -05 area leader sub-tlv.

In other words I don't see any problem or room for debate .. adopting and
implementing -05 allows use of centralized or distributed optimal flooding
computation at the operator's discretion.

Thx,
R.

On Mon, Aug 27, 2018 at 5:10 PM, Huaimo Chen  wrote:

> >> I think distributed is more practical too.
> >I would appreciate more detailed insights as to why you (and others) feel
> this way.  It is not at all obvious to me.
> IGP is distributed in nature. The distributed computation of flooding
> topology like distributed SPF will keep IGP still distributed in nature.
> Introducing centralized feature into IGP will break IGP's distributed
> nature, which may cause some issues/problems.
>
> >> For computing routes, we have been using distributed SPF on every node
> for many years.
> >True, but that algorithm is (and was) very well known and a fixed
> algorithm that would clearly solve the problem at the time. If we were in a
> similar situation, where we were ready to set an algorithm in >concrete, I
> might well agree, but it’s quite clear that we are NOT at that point yet.
> We will need to experiment and modify algorithms, and as discussed, that’s
> easier with a centralized approach.
> After flooding reduction is deployed in an operational (ISP) network, will
> we be allowed to do experiments on their network?
> After an algorithm is determined/selected, will it be changed to another
> algorithm in a short time?
>
> >> In fact, we may not need to run the exact algorithm on every node. As
> long as the algorithms running on different nodes generate the same result,
> that would work.
> >Insuring a globally consistent result without running the exact same
> algorithm on the exact same data will be quite a trick.  Debugging
> distributed problems at scale is already a hard problem.  Having >different
> algorithms in different locations would add another order of magnitude in
> difficulty.  No thank you.
> In some existing networks, some nodes run IGPs from one vendor, some other
> nodes run IGPs from another vendor, and so on. Some may use normal SPF,
> some others may use incremental SPF. It seems that we have had these cases
> for many years.
> >Tony
>
> Best Regards,
> Huaimo
> ___
> 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] LSR Flooding Reduction Drafts - Moving Forward

[Robert Raszuk]

> draft-cc-ospf-flooding-reduction-02 allows operators to select
distributed mode, centralized one or static one smoothly.

Aside from static approach can you summarize in purely technical points
advantages your draft proposes over draft-li-dynamic-flooding-05 ?

Many thx,
R.



On Mon, Aug 27, 2018 at 6:41 PM, Huaimo Chen  wrote:

> Hi Robert,
>
>
>
> >Leader election happens automatically and procedures for that are to be
> vastly similar to today's DR or DIS election. So with this in mind one may
> observe that both OSPF and ISIS are pretty centralized on multiaccess
> networks today :)
>
>
>
> Today’s DR or DIS election is local to a special interface/network such as
> a broadcast interface. Leader election in a network is global. Every node
> in the network depends on it (its flooding topology). These two seems
> different.
>
>
>
> >Btw I don't think there is any problem here ... The text added to -05
> version allows very seamless choice of centralized vs distributed topology
> computation by signalling either zero or non zero value in the added to
> version -05 area leader sub-tlv.
>
> >
>
> >In other words I don't see any problem or room for debate .. adopting and
> implementing -05 allows use of centralized or distributed optimal flooding
> computation at the operator's discretion.
>
>
>
> draft-cc-ospf-flooding-reduction-02 allows operators to select
> distributed mode, centralized one or static one smoothly.
>
>
>
> Best Regards,
>
> Huaimo
>
>
>
> *From:* Robert Raszuk [mailto:rob...@raszuk.net]
> *Sent:* Monday, August 27, 2018 11:31 AM
> *To:* Huaimo Chen 
> *Cc:* tony...@tony.li; lsr@ietf.org; Jeff Tantsura <
> jefftant.i...@gmail.com>; Acee Lindem (acee)  org>; Peter Psenak ; Tony Przygienda <
> tonysi...@gmail.com>
> *Subject:* Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward
>
>
>
> Hi Huaimo,
>
>
>
> > Introducing centralized feature into IGP will break IGP's distributed
> nature
>
>
>
> That clearly proves that word "centralized" has been significantly
> overloaded here.  To many indeed "centralized" means a controller (like
> OpenFlow or SDN) and that such device added to a network is to push
> information - typically 1RU linux blade -  here optimized flooding graph.
> But this never was the plan with this proposal from its start ie. -00
> version.
>
>
>
> Centralized means that optimized flooding graph comes from single
> redundant node.
>
>
>
> Leader election happens automatically and procedures for that are to be
> vastly similar to today's DR or DIS election. So with this in mind one may
> observe that both OSPF and ISIS are pretty centralized on multiaccess
> networks today :)
>
>
>
> To your point of multi-vendor networks true - and that is precisely why
> upgrade network wide to a release containing consistent algorithm from more
> then a single vendor (and even for single vendor) is practically a very
> time consuming and difficult process.
>
>
>
> Btw I don't think there is any problem here ... The text added to -05
> version allows very seamless choice of centralized vs distributed topology
> computation by signalling either zero or non zero value in the added to
> version -05 area leader sub-tlv.
>
>
>
> In other words I don't see any problem or room for debate .. adopting and
> implementing -05 allows use of centralized or distributed optimal flooding
> computation at the operator's discretion.
>
>
>
> Thx,
>
> R.
>
>
>
> On Mon, Aug 27, 2018 at 5:10 PM, Huaimo Chen 
> wrote:
>
> >> I think distributed is more practical too.
> >I would appreciate more detailed insights as to why you (and others) feel
> this way.  It is not at all obvious to me.
> IGP is distributed in nature. The distributed computation of flooding
> topology like distributed SPF will keep IGP still distributed in nature.
> Introducing centralized feature into IGP will break IGP's distributed
> nature, which may cause some issues/problems.
>
> >> For computing routes, we have been using distributed SPF on every node
> for many years.
> >True, but that algorithm is (and was) very well known and a fixed
> algorithm that would clearly solve the problem at the time. If we were in a
> similar situation, where we were ready to set an algorithm in >concrete, I
> might well agree, but it’s quite clear that we are NOT at that point yet.
> We will need to experiment and modify algorithms, and as discussed, that’s
> easier with a centralized approach.
> After flooding reduction is deployed in an operational (ISP) network, will
> we be allowed to do e

Re: [Lsr] [GROW] FW: New Version Notification for draft-gu-network-mornitoring-protol-00.txt

[Robert Raszuk]

Tim,

I already suggested use of BGP-LS *as-is* in this thread on Jul 6th.

But I guess we all agree that this is not the best use of BGP protocol to
be now a vehicle of NMS only because it is easy with BGP to establish a TCP
session and to distribute "stuff" in a relatively loop free fashion.

Thx,
R.

On Wed, Jul 11, 2018 at 2:40 AM, Tim Evens (tievens) <
tievens=40cisco@dmarc.ietf.org> wrote:

> Hi Robin, Yunan, Shunwan,
>
>
>
> I'm a little late to this thread due to being preoccupied with a newborn.
>
>
>
> Below are my comments, which take into consideration the other comments…
> sans the YANG/telemetry debate.  Considering we do use BGP-LS extensively,
> I don't think YANG is the only solution to these link-state monitoring
> use-cases.
>
>
>
> BMP doesn't change or limit what's available in BGP. It encapsulates and
> multiplexes BGP over a single stream for remote monitoring.   BGP-LS
> (RFC7752) can be used today to monitor link state protocols (ISIS, OSPF).
> BGP-LS also can be used to monitor EPE and direct/static routes, which is a
> bit of a stretch on putting that in BGP-LS, but nonetheless…  BGP-LS is
> available via BMP.
>
>
>
> "Section 3.1, ISIS Adjacency Issues"
>
>
>
> As written, this is covered by BGP-LS LINK NLRI.  We see a LINK change
> (advertised verses withdrawn) when the adjacency changes.  If the router
> dies or the control-plane fails in some way, we still see the NLRI change
> from the other side of the adjacency (perspective).
>
>
>
> What we are missing is a BGP-LS "attribute" tlv (on local entries) for
> links/nodes that indicates the REASON why the LINK (also NODE) is
> withdrawn, but this is not available without changing the IGP protocol
> itself (e.g. new ISIS TLV) or by implementing a solution architecture that
> requires BGP-LS feeds from all ISIS/OSPF nodes.  As written, I see NMP
> (including Netconf/gNMI/telemetry) requiring sessions from all nodes since
> the targeted data is not available in ISIS TLV's today.   For example, the
> ISIS LSDB on node-A does not have any local (device specific) information
> from all the other nodes unless there are TLV's to convey that information.
>
>
>
> Regarding requiring BGP-LS feeds from many or all nodes...  We need this
> regardless of this draft because of segment-routing/egress peer
> engineering.   Due to EPE, we already recommend BGP-LS peering (feeds) from
> all EPE nodes (normally via a peering server) so that we can
> collect/monitor EPE (hopefully using https://tools.ietf.org/html/
> draft-ietf-grow-bmp-local-rib-01). Adding LINK/NODE withdrawal/down
> reason should not overstep into YANG/Netconf/Telemetry.
>
>
>
> "3.2.  Forwarding Path Disconnection"
>
>
>
> This seems to be more of a fit for telemetry with interface/link
> monitoring.  Although, if the link was working at some point and it goes
> down due to MTU or otherwise, the BGP-LS REASON attribute should be able to
> convey that.  BGP-LS wouldn't convey anything if the link was never
> established.  Currently, it's assumed that the link advertisement means
> it's established.  This could be changed if we added a LINK NLRI state
> TLV.   The LINK could be updated (advertised) multiple times, changing
> based on state.   If the LINK doesn't establish, the withdrawal could
> indicate the reason.
>
>
>
> "3.3.  ISIS LSP Synchronization Failure"
>
>
>
> If a new BGP-LS LINK attribute is used as mentioned above to convey LINK
> adv state, it should then be feasible to add a state to indicate
> inconsistency. If the link/adj changes to down, then the withdrawal LINK
> reason attribute could indicate the cause.
>
>
>
> The BGP-LS reason and state tlv's would only apply to the links/nodes that
> originate from the BGP-LS speaker.  Other node/link advertisements would
> not have the attribute/tlv.   This is why the solution would recommend
> enabling BGP-LS feeds from nodes that matter enough to get this level of
> local info.  This btw would solve a problem we have with BGP-LS today where
> optional TLV's are not present unless ISIS/OSPF have specific features
> enabled, such as traffic-engineering... even IPv4/IPv6 router ID's are not
> included unless enabled specifically (isis) per node.
>
>
>
> "4.  Extensions of NMP for ISIS"
>
>
>
> Most of the new messages are redundant to the existing BGP-LS
> advertisements and withdrawals.  Telemetry of course could also convey
> this…
>
>
>
> The initiation message could lead to overloading it with all kinds of
> device specific info.   Some constraint is needed.
>
>
>
> The per peer (adjacency) header is missing multi-topology.  BGP-LS
> includes the protocol type (e.g. CT) and MT (missing from this draft).
>
>
>
> All in all, I believe the use-cases described have merit and I think we
> can do this with BGP-LS, which doesn't require BMP but could be used.
>
>
>
> Thanks,
>
> Tim
>
>
>
>
>
> On 7/8/18, 8:59 PM, "GROW on behalf of Greg Skinner" <
> grow-boun...@ietf.org on behalf of gregskinner0=40icloud.com@
> 

Re: [Lsr] Fwd: New Version Notification for draft-li-dynamic-flooding-04.txt

[Robert Raszuk]

I agree with Rob & Tony.

Converging on single algorithm across zoo of vendors is not going to happen
bearing in mind that every single change to such algorithm will require a
massive 1000s nodes software upgrade each time.

Note that even if IETF converges industry may not and that is a practical
aspect.

With current proposal this is just one time upgrade.

Thx,
R.

On Fri, Apr 6, 2018, 18:02 Rob Shakir  wrote:

> Peter,
>
> How do we transition between algorithms in the approach that you suggest?
> Do all non-stub devices need to be upgraded to support the new algorithm
> before such time as we can use it? (I think so, because otherwise some
> non-stub device cannot be guaranteed to flood to its downstream stub
> devices - so we may end up isolating some devices if any device transitions
> before all nodes support it).
>
> The advantage of having something advertised is that one can compute it
> centrally - and keep the per-node functionality simply obeying the
> advertised flooding graph. From an operational perspective, this means that
> one can introduce new experimental flooding topology computation approaches
> in a manner that is decoupled from needing to do software upgrades across
> the whole network. I can also implement non-standard flooding topology
> computations based on the network topology which could be only applicable
> to that particular network (consider if I wanted to do something like take
> into account shared-risk information in the algorithm to allow the
> most-SRLG disjoint flooding topology or so).
>
> This is in addition to the points Tony made. I think this
> centralised-computation-and-flooded approach is elegant. If the error
> handling behaviour for not being able to parse the flooding topology is to
> revert to flooding everywhere, then it seems non-destructive too.
>
> Cheers,
> r.
>
> On Fri, 6 Apr 2018 at 08:50 Peter Psenak  wrote:
>
>> Hi Tony,
>>
>> if we start with a single standardized algorithm, that is easy to
>> implement and deploy. We can leave the door open for additional
>> algorithms to be defined later together with the selection mechanism.
>>
>> I have the feeling that the dependency of the "flooding topology" on the
>> flooded data is going to bring more complexity, than the selection of
>> the distributed algorithm to be used, if we ever need to support more
>> then one.
>>
>> thanks,
>> Peter
>>
>>
>> On 06/04/18 17:19 , tony...@tony.li wrote:
>> >
>> > Hi Peter,
>> >
>> > Thank you for your comments.
>> >
>> >> while I appreciate the flexibility associated with the centralized
>> >> computation of the flooding topology, it has some drawbacks as well:
>> >>
>> >> 1. "flooding topology" must be flooded. This makes the flooding
>> >> dependent on the flooded data itself.
>> >
>> >
>> > Absolutely true. If the computation of the topology is incorrect, that
>> > would certainly be a bug.
>> >
>> >
>> >> 2. The extra flooding of "flooding topology" adds some delay in the
>> >> convergence towards the new "flooding topology”.
>> >
>> >
>> > Since we distribute the flooding topology before there are topology
>> > failures, it would seem like the latency is not a significant concern.
>> >
>> >
>> >> Have you considered the distributed computation of "flooding topology"
>> >> using some standardized algorithm?
>> >
>> >
>> > Yes, Kireeti raised this in London as well. There are some practical
>> > issues with this. How do we ever converge on an algorithm?
>> >
>> > There are many perspectives on what an adequate flooding topology might
>> > be. Different administrations have different considerations and risk
>> > tolerances.
>> >
>> > Debugging is going to be more challenging, as inconsistencies between
>> > two nodes with different ideas of the topology will be difficult to
>> > detect until there is a catastrophic failure.
>> >
>> > I’m trying to do something practical, and it seems like doing this in a
>> > centralized fashion is the quickest, easiest, and most robust way
>> forward.
>> >
>> >
>> >> Eventually we can support multiple standardized algorithms. A node can
>> >> advertise support for several algorithms and the "active" algorithm is
>> >> selected based on some criteria that would guarantee that all nodes in
>> >> the flooding domain select the same one.
>> >
>> >
>> > Seems like that would also require some administrative input.
>> >
>> > So, I agree that that’s a technical possibility, but I think that
>> > there’s significant problems in making that work. I prefer to focus on
>> > something that we can implement more quickly.
>> >
>> > Tony
>> >
>> >
>>
>> ___
>> 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

Re: [Lsr] Fwd: New Version Notification for draft-li-dynamic-flooding-04.txt

[Robert Raszuk]

Les,

Isn't RIFT effectively a new flooding algorithm - while not strictly
designed to be used within current link state protocols - it has the
potential to achieve what you and Peter are proposing isn't it ?

My personal take here would be to progress dynamic flooding *as is* with
the use of DR/DIS as flooding oracles.

If you or anyone however would like to propose a new flooding algorithm to
link state protocols I think nothing stops you to write a separate draft on
that and call it say -optimal-flooding-.

Best,
Robert.



On Fri, Apr 6, 2018 at 10:06 PM, Les Ginsberg (ginsberg)  wrote:

> I think this discussion has already gone much too far in the direction of
> customized flooding optimizations. Such is the nature of the engineering
> mind – give us a problem to solve and we’ll come up with a plethora of
> solutions.
>
>
>
> The right perspective (for me anyway) is this:
>
>
>
> IGPs have been  popular as distribution mechanisms in part because of the
> reliability of  their flooding process. This wasn’t easy to achieve – and
> those of us who have been in the business long enough have seen attempts to
> create something equivalent fall flat on their face because they couldn’t
> handle the corner causes. Simple yet robust has been the guiding principle
> and both IGPs do this well.
>
>
>
> It is also useful to remember that bandwidth utilization for IGP flooding
> is not a problem which we need to solve. It has been demonstrated – even
> long ago with much less bandwidth than we have today – that IGP flooding
> bandwidth isn’t a concern. So proposals which suggest we might need to come
> up with an algorithm that optimizes for bandwidth or SRLGs or whatever
> criteria one could imagine seem unnecessary – as well as incestuous. And
> they certainly complicate the problem.
>
>
>
> I agree with Peter’s suggestion  that a common decentralized algorithm is
> desirable. It will simplify problems associated with reconvergence which I
> think is key.
>
> And I don’t think we really need to support multiple algorithms – it was
> nice of Peter to allow for that – but as we see now everyone is concerned
> about the upgrade issues that come with introducing a new algorithm.
>
>
>
> Let’s agree on one algorithm and be done.
>
> A variant on https://tools.ietf.org/html/rfc6325#section-4.5.1 is one
> such candidate.
>
>
>
>Les
>
>
>
>
>
> *From:* Lsr  *On Behalf Of *Rob Shakir
> *Sent:* Friday, April 06, 2018 9:03 AM
> *To:* Peter Psenak (ppsenak) 
> *Cc:* lsr@ietf.org; tony...@tony.li
> *Subject:* Re: [Lsr] Fwd: New Version Notification for
> draft-li-dynamic-flooding-04.txt
>
>
>
> Peter,
>
>
>
> How do we transition between algorithms in the approach that you suggest?
> Do all non-stub devices need to be upgraded to support the new algorithm
> before such time as we can use it? (I think so, because otherwise some
> non-stub device cannot be guaranteed to flood to its downstream stub
> devices - so we may end up isolating some devices if any device transitions
> before all nodes support it).
>
>
>
> The advantage of having something advertised is that one can compute it
> centrally - and keep the per-node functionality simply obeying the
> advertised flooding graph. From an operational perspective, this means that
> one can introduce new experimental flooding topology computation approaches
> in a manner that is decoupled from needing to do software upgrades across
> the whole network. I can also implement non-standard flooding topology
> computations based on the network topology which could be only applicable
> to that particular network (consider if I wanted to do something like take
> into account shared-risk information in the algorithm to allow the
> most-SRLG disjoint flooding topology or so).
>
>
>
> This is in addition to the points Tony made. I think this
> centralised-computation-and-flooded approach is elegant. If the error
> handling behaviour for not being able to parse the flooding topology is to
> revert to flooding everywhere, then it seems non-destructive too.
>
>
>
> Cheers,
>
> r.
>
>
>
> On Fri, 6 Apr 2018 at 08:50 Peter Psenak  wrote:
>
> Hi Tony,
>
> if we start with a single standardized algorithm, that is easy to
> implement and deploy. We can leave the door open for additional
> algorithms to be defined later together with the selection mechanism.
>
> I have the feeling that the dependency of the "flooding topology" on the
> flooded data is going to bring more complexity, than the selection of
> the distributed algorithm to be used, if we ever need to support more
> then one.
>
> thanks,
> Peter
>
>
> On 06/04/18 17:19 , tony...@tony.li wrote:
> >
> > Hi Peter,
> >
> > Thank you for your comments.
> >
> >> while I appreciate the flexibility associated with the centralized
> >> computation of the flooding topology, it has some drawbacks as well:
> >>
> >> 1. "flooding topology" must be flooded. This 

Re: [Lsr] Comments on draft-ymbk-lsvr-lsoe-00

[Robert Raszuk]

Dear Authors,

Let me just ask one little question 

It seems that ISIS protocol already meets a "Link State Over Ethernet"
definition so why to invent anything new here ?

If you don't like flooding properties of ISIS just disable it. Do not
flood. Do not run SPF in ISIS. Use ISIS only for p2p discovery.

You get for free out of the box all what you are trying to describe in the
subject document. Integrating open source ISIS code just for discovery (ie.
not worring about optimizations of flooding, back-off, timers, spf etc ...)
will be IMO much faster even using any apache license existing
implementation of ISIS.

Last - as Toerless already indicated - solving inevitable inconsistencies
of running LSOE, CDP & LLDP between various devices or in parallel on the
same links is something that should be addressed from day one. Unless you
assume that if someone is to use LSVR is will also have LSOE and any other
alternative discovery mechanisms will be disabled.

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

Re: [Lsr] IS-IS over TCP

[Robert Raszuk]

Hi Henk,

> - We could make BFD mandatory when flooding over TCP ?

I don't think this would be a good idea.

See especially for p2p fiber links loss of light is a much faster and
better trigger/indicator that your link or adjacent router is down.

Using BFD there which in most cases operates in a distributed mode on the
line cards and tells you nothing about LC to RP path, or RP liveness IMO
does not make much sense in such designs.

Of course when your "link" is still p2p but is an emulated one over someone
else IP network this is different story, but I don't think this is most
common deployment model in data center's fabric.

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

Re: [Lsr] IS-IS over TCP

[Robert Raszuk]

All,


> Again, if people think that LSVR is a good idea, then how can they
> think that ISIS flooding over TCP is not a good idea ? This is
> the base idea for our proposal. A quick look at the LSVR draft
> show people from Cisco, Nokia (and Arrcus). (I'm not sure what
> Juniper or Arista or other vendors think about using BGP-LS).
>

I would like to make one additional observation here ...

We are experiencing BGP-LS crusade (completely outside of LSVR) as there is
some demand to send data carried by IGP (incl SR, TE and now even BFD
extensions) to remote controllers over TCP.

I am pretty sure that BGP-LS would have never started if we would have had
an ability to send LSDB content over TCP day one. /* Let's put controller
to controller NNI across ASes aside for a moment. */

With that to me ability to progress with TCP transport extension for ISIS
(and OSPF) is actually more important then work on flooding reduction. I
know it may not be a popular statement, but that is based on both looking
at the operational side as well as BGP protocol side.

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

Re: [Lsr] LSR: Using DSCP for path/topology selection Q

[Robert Raszuk]

Hey Toerless,

Please observe that DSCP based steering may be very useful vehicle for end
hosts/applications influencing how their packets are transported.

So instead of closing that option I recommend we at least take a good look
at what alternative mechanism exists.

And btw I read Peter's note as possibility (or invitation) to define
algorithm which takes into account DSCP rather then a announcement that
this is not there and it should never be.

Cheers,
R.



On Fri, Nov 16, 2018 at 12:22 AM Toerless Eckert  wrote:

>
> Thanks, Les, Peter
>
> So... is there any opinion about creating a normative or BCP
> recommendation to
> not use DSCP to distinguish topologies/flex-algos ? Mabybe this would
> not be appropriate for LSR, but TSVWG, but i think it would be
> participants in LSR that would know if there is actually still any
> customer demand for this option.
>
> Cheers
> Toerless
>
> P.S.: Context of the email is DetNet trying to define what a DetNet flow
> is and currently this includes the thinking that DetNet flows could be
> 6-tuple flows including DSCP because different DSCP could be routed
> differently in the network via MTR, and that concept IMHO would just
> result in making a foal (DetNet) a lot more complex because of a dead
> horse (DSCP MTR).
>
> On Thu, Nov 15, 2018 at 04:41:06AM +, Les Ginsberg (ginsberg) wrote:
> > Toerless -
> >
> > It's pretty hard to understand the context for your email.
> >
> > What leads you to believe that any of the MT specifications you mention
> say anything normative about DSCP and topologies??
> >
> > RFC4915 does not mention DSCP at all - but does make the statement:
> >
> > https://tools.ietf.org/html/rfc4915#section-3.8
> > "It is outside of the scope of this document to specify how the
> >information in various topology specific forwarding structures are
> >used during packet forwarding or how incoming packets are associated
> >with the corresponding topology."
> >
> > RFC 5120 does mention DSCP, but only as an example of something that
> "could" be used to determine on what topology a packet should be forwarded.
> >
> > RFC 7722 also mentions DSCP as an example, but there is a statement in
> Section 3:
> >
> > "It is assumed, but
> >outside the scope of this specification, that the network layer is
> >able to choose which topology to use for each packet"
> >
> > IGP WGs have never attempted to recommend (let alone normatively define)
> any relationship between DSCP and MT.
> >
> > ???
> >
> >Les
> >
> > > -Original Message-
> > > From: Lsr  On Behalf Of Toerless Eckert
> > > Sent: Wednesday, November 14, 2018 6:29 PM
> > > To: lsr@ietf.org
> > > Subject: [Lsr] LSR: Using DSCP for path/topology selection Q
> > >
> > > Whats the current best guidance on using DSCP for selection of path,
> > > specifically for selection of topology with MTR (RFCs 4915, 5120,
> 7722) ?
> > >
> > > My understanding from history is that this looked like a good idea
> > > to customers first, but when implementations became available,
> > > customers really did not want to implement it because of the
> overloading
> > > of DSCP between QoS and routing and the resulting management
> > > complexity.
> > >
> > > Has the idea of using DSCP for path selection been re-introduced in any
> > > later work like flex-Algos ?
> > >
> > > If there could be rough consensus that this is in general a bad idea,
> i wonder
> > > if it would be appropriate to have a short normative document from LSR
> > > defining that the use of DSCP for topology selection is historic and
> > > not recommended anymore and make this an update to above three RFCs,
> > > maybe also pointing out that there are other methods to select a
> > > topology and those remain viable:
> > >
> > > I specifically would not like to see the actual MTR RFCs to be changed
> > > in status, because MTR actually does work quite well and is supported
> > > in products and deployed with IP multicast, even with multiple
> > > topologies for IP multicast in live-live scenarios.
> > >
> > > Thanks!
> > > Toerless
> > >
> > > ___
> > > 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
>
> --
> ---
> t...@cs.fau.de
>
> ___
> 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] LSR: Using DSCP for path/topology selection Q

[Robert Raszuk]

Jeff,

> What architecture?
> PBR is a form of:
> match DSCP X
> set next-hop Y
> needs no interoperability...

That's pretty narrow view. I could say the worst possible example :)  You
would have to either encapsulate or apply your sample config consistently
on every hop. Br.

To me DSCP can be used to map packets to different routing context,
different plane or can be used as a parameter in flex-algorithm.

Thx,
R.





On Fri, Nov 16, 2018 at 8:19 AM Jeff Tantsura 
wrote:

> Tony,
>
> What architecture?
> PBR is a form of:
> match DSCP X
> set next-hop Y
> needs no interoperability...
> If someone wants to describe how they use a particular vendor feature to
> solve a particular problem in a BCP, sure, the more BCPs - the better.
>
> Wrt using DSCP in routing decision process - it was a bad idea back then,
> hasn’t got any better now... besides - now we have got a toolbox that
> wasn’t available then.
>
> Cheers,
> Jeff
> On Thu, Nov 15, 2018 at 22:56 Tony Li  wrote:
>
>>
>>
>> On Nov 15, 2018, at 8:47 PM, Jeff Tantsura 
>> wrote:
>>
>> The question is really - what is here to standardize?
>>
>>
>>
>> There’s a fine architectural BCP here: this is how we are solving problem
>> XYZ.  Please don’t break this.
>>
>> Tony
>>
>>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] IS-IS over TCP

[Robert Raszuk]

Hi Les,

I am very well aware about different scopes of both drafts. Actually I read
them all.

But just wanted to make sure your point about ISIS working fine today with
1000s node networks is really a prove that flooding optimisation is still
*practically* needed/required.

Btw ... Henk has a second proposal - a companion document to flooding over
TCP on flooding reduction too. Perhaps you missed it :)

https://datatracker.ietf.org/doc/draft-hsmit-lsr-isis-dnfm/

Thx,
R.

On Wed, Nov 7, 2018 at 9:54 AM Les Ginsberg (ginsberg) 
wrote:

> Robert –
>
>
>
> The comment being discussed here is in regards to the potential benefits
> of altering IS-IS to use a different way of flooding over an interface.
>
> Whether we agree/disagree on this does not have any bearing on the high
> amount of redundant flooding which occurs in a highly meshed network –
> which I think all of us agree is a problem worth addressing.
>
>
>
> The latter is addressed in a number of drafts – including Henk/Gunter’s
> https://datatracker.ietf.org/doc/draft-hsmit-lsr-isis-dnfm/ .
>
>
>
> But this thread is about
> https://datatracker.ietf.org/doc/draft-hsmit-lsr-isis-flooding-over-tcp/ ..
>
>
>
> Please do not confuse the two.
>
>
>
>Les
>
>
>
>
>
> *From:* Robert Raszuk 
> *Sent:* Wednesday, November 07, 2018 12:39 AM
> *To:* Les Ginsberg (ginsberg) 
> *Cc:* hhws...@xs4all.nl; Tony Li ; lsr@ietf.org
> *Subject:* Re: [Lsr] IS-IS over TCP
>
>
>
> Hi Les,
>
>
>
> > There are existing and successful deployments of an instance with
> thousands of
>
> > neighbors and thousands of nodes in a network and sub-second convergence
> is supported.
>
>
>
> While I completely agree with your above observation (and as a matter of
> fact first person to tell me that was actually Henk around year 2000) may I
> ask what problem are we solving with vast majority of the proposals in
> space of "IGP scaling" for data center deployments currently on the table ?
> Are we perfecting the perfect ?
>
>
>
> It sounds that what is really needed is a deployment guide (perhaps in the
> form of informational RFC) documenting that use of ISIS in 1000(s) node DC
> cluster is fine provided features X, Y, Z are enabled.
>
>
>
> Otherwise folks out there in the field no matter what is done here will
> keep using BGP for huge 50 node DC clusters because RFC7938 says so.
>
>
>
> Cheers,
> Robert.
>
>
>
>
>
> On Wed, Nov 7, 2018 at 5:09 AM Les Ginsberg (ginsberg) 
> wrote:
>
> Henk/Gunter -
>
> Couple of points.
>
> 1)IS-IS PDUs are sent directly over layer 2 - whereas TCP (or other
> transport) are sent over Layer3.
> This means we have a potential fate sharing issue where IIHs (which
> continue to be sent over Layer 2 in your proposal (as I understand it) may
> be successfully exchanged but the transport session set up to send
> LSPs/SNPs may fail. This is the exact issue RFC 6213 has addressed.
>
> What should happen if IIHs are being successfully exchanged, the neighbors
> both indicate support for the extension, but the transport session fails to
> come up or goes down?
> Would you follow similar behavior to RFC 6213 i.e., bring the adjacency
> down? If so, how would you determine when you can bring the adjacency up?
>
> I appreciate you have indicated this as TBD in Section 7.6 of the draft,
> but you also say in Section 7.5 that adjacency should NOT go down when
> transport session fails - which implies we can have an ongoing condition
> where an adjacency is up but
> flooding cannot be done-  which is a pathological condition.
>
> 2)Your statements regarding existing flooding limitations of IS-IS are
> rather dated. Many years ago implementations varied from the base
> specification by allowing much faster flooding and contiguous flooding
> bursts on an interface in support of fast convergence. There are existing
> and successful deployments of an instance with thousands of neighbors and
> thousands of nodes in a network and sub-second convergence is supported. So
> the statement that the existing protocol per interface flooding is a
> blocking factor in highly meshed topologies is not (IMO) accurate. The more
> accurate characterization of the flooding problem in dense topologies is
> the amount of redundant flooding (i.e., a node may receive many copies of a
> new LSP) - which your proposal does nothing to address (I understand it was
> not intended to address this problem which you discuss in a different
> draft).
>
> My point here is that there are existing implementations which would get
> no benefit from your proposal. It might be argued that someone writing a
> new imple

Re: [Lsr] IS-IS over TCP

[Robert Raszuk]

Hi Les,

> There are existing and successful deployments of an instance with
thousands of
> neighbors and thousands of nodes in a network and sub-second convergence
is supported.

While I completely agree with your above observation (and as a matter of
fact first person to tell me that was actually Henk around year 2000) may I
ask what problem are we solving with vast majority of the proposals in
space of "IGP scaling" for data center deployments currently on the table ?
Are we perfecting the perfect ?

It sounds that what is really needed is a deployment guide (perhaps in the
form of informational RFC) documenting that use of ISIS in 1000(s) node DC
cluster is fine provided features X, Y, Z are enabled.

Otherwise folks out there in the field no matter what is done here will
keep using BGP for huge 50 node DC clusters because RFC7938 says so.

Cheers,
Robert.


On Wed, Nov 7, 2018 at 5:09 AM Les Ginsberg (ginsberg) 
wrote:

> Henk/Gunter -
>
> Couple of points.
>
> 1)IS-IS PDUs are sent directly over layer 2 - whereas TCP (or other
> transport) are sent over Layer3.
> This means we have a potential fate sharing issue where IIHs (which
> continue to be sent over Layer 2 in your proposal (as I understand it) may
> be successfully exchanged but the transport session set up to send
> LSPs/SNPs may fail. This is the exact issue RFC 6213 has addressed.
>
> What should happen if IIHs are being successfully exchanged, the neighbors
> both indicate support for the extension, but the transport session fails to
> come up or goes down?
> Would you follow similar behavior to RFC 6213 i.e., bring the adjacency
> down? If so, how would you determine when you can bring the adjacency up?
>
> I appreciate you have indicated this as TBD in Section 7.6 of the draft,
> but you also say in Section 7.5 that adjacency should NOT go down when
> transport session fails - which implies we can have an ongoing condition
> where an adjacency is up but
> flooding cannot be done-  which is a pathological condition.
>
> 2)Your statements regarding existing flooding limitations of IS-IS are
> rather dated. Many years ago implementations varied from the base
> specification by allowing much faster flooding and contiguous flooding
> bursts on an interface in support of fast convergence. There are existing
> and successful deployments of an instance with thousands of neighbors and
> thousands of nodes in a network and sub-second convergence is supported. So
> the statement that the existing protocol per interface flooding is a
> blocking factor in highly meshed topologies is not (IMO) accurate. The more
> accurate characterization of the flooding problem in dense topologies is
> the amount of redundant flooding (i.e., a node may receive many copies of a
> new LSP) - which your proposal does nothing to address (I understand it was
> not intended to address this problem which you discuss in a different
> draft).
>
> My point here is that there are existing implementations which would get
> no benefit from your proposal. It might be argued that someone writing a
> new implementation may find it simpler to make use of a transport mechanism
> like TCP - but I do not think there is compelling data that demonstrates
> that the scalability of an implementation using your proposal is better
> than that of many existing implementations.
>
> This then suggests that for existing implementations the main motivation
> to support your proposal is to help other implementations which have not
> optimized their existing implementations. :-)
> Comments?
>
>Les
>
>
> > -Original Message-
> > From: Lsr  On Behalf Of Henk Smit
> > Sent: Monday, November 05, 2018 8:22 PM
> > To: tony...@tony.li
> > Cc: lsr@ietf.org
> > Subject: Re: [Lsr] IS-IS over TCP
> >
> >
> > Thanks, Tony.
> >
> > We picked TCP because every router on the planet already has a TCP stack
> > in it.
> > That made it the obvious choice.
> >
> > Our draft described a TVL in the IIHs to indicate a router's
> > ability to use TCP for flooding.
> > That TLV has several sub-TVLs.
> > 1) the TCP port-number
> > 2) an IPv4 address
> > 3) and/or an IPv6 address
> >
> > We can change the first sub-TVL so that it indicates:
> > 1) 1 or 2 bytes indicating what protocol to use
> > 2) the remainder of the sub-TLV is an indicator what port-number
> > or other identifier to use to connect over that protocol.
> >
> > This way we can start improving IS-IS with TCP today.
> > And add/replace it with other protocols in the future.
> >
> > henk.
> >
> >
> >
> > tony...@tony.li schreef op 2018-11-06 04:51:
> > > Per the WG meeting, discussing on the list:
> > >
> > > This is good work and I support it.
> > >
> > > I would remind folks that TCP is NOT the only transport protocol
> > > available and that perhaps we should be considering QUIC while we’re
> > > at it.  In particular, flooding is a (relatively) low bandwidth
> > > operation in the modern network and we could avoid slow-start issues
> > > 

Re: [Lsr] Teasing us with secrets

[Robert Raszuk]

IETF seems to be doing great job in defining protocols and their
extensions. It doesn't do that great job in defining the dynamics of
protocols and their recommended behavior. That's called a "vendor's secret
sauce".

This thread seems to be a good example of that.

In BGP there was similar discussions on number of timers which BIPs (best
implementation practices) are well known to limited circle of folks.
Sometimes instead of such timers different safety checks are implemented
under the hood. Take BGP MRAI as example ... some implementations do it one
way some completely other and claim our MRAI is 0. But when asked "Do you
always generate bgp update immediately" -- you hear "Oh NO !"

Draft written by Paul to make it easy to implement for those from outside
the circle did not go far in spite of becoming IDR WG doc:
https://tools.ietf.org/html/draft-ietf-idr-mrai-dep-04

Here we have a proposal to replace part of that sauce with TCP and maybe
QUIC in a backwards compatible fashion to allow for more food diversity.
Yes it is a burden for existing chefs to now have to handle one more in/out
channel, but let's realize that if we keep status quo alternative solutions
to running IGPs may be winning more markets ...

Kind regards,
Robert.


On Mon, Nov 12, 2018 at 6:48 PM  wrote:

>
> Les,
>
> As you’ve said in person, following the LSP transmission and
> re-transmission timer requirements is one of the first things to go.
>
> Yes, updating the RFC with all of the other learnings would be one way
> forward.
>
> Tony
>
>
> > On Nov 12, 2018, at 9:44 AM, Les Ginsberg (ginsberg) 
> wrote:
> >
> > Tony -
> >
> > AFAIK no one has suggested or is planning to update/modify a standard.
> >
> > This falls into a category  of standard deviations that was initially
> documented  in https://tools.ietf.org/html/rfc3719 .
> > If the WG feels this is important enough perhaps the best thing to do is
> update that RFC.
> >
> > I would however like us to agree that the subject of this thread is
> inappropriate. :-)
> >
> >   Les
> >
> >
> >> -Original Message-
> >> From: Tony Li  On Behalf Of tony...@tony.li
> >> Sent: Monday, November 12, 2018 9:14 AM
> >> To: Les Ginsberg (ginsberg) 
> >> Cc: Henk Smit ; lsr@ietf.org
> >> Subject: Re: Teasing us with secrets
> >>
> >>
> >> Les,
> >>
> >>> Discussion of bypassing the ISO 10589 flooding pacing timer was done in
> >> public many years ago when sub-second convergence was introduced.
> >>> Here is one public paper:
> >>>
> >>> https://inl.info.ucl.ac.be/publications/achieving-sub-second-igp-
> >> convergence-.html
> >>>
> >>> There are also multiple vendor specific configuration guides which
> discuss
> >> tuning LSP pacing for fast convergence - please consult your favorite
> vendor's
> >> documentation links (not my place to share such links).
> >>>
> >>> No doubt others can find other public references.
> >>
> >>
> >> Thank you for the reference, that’s helpful.
> >>
> >> Are you aware of the standards status of this document vs ISO 10589?
> >>
> >> It seems to me that unless there’s some document on the standards track
> >> that the average developer might not comply with it.
> >>
> >> Tony
> >
>
> ___
> 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] Open issues with Dynamic Flooding: Including LANs in the Flooding Topology

[Robert Raszuk]

For the purpose of this discussion can someone quote the definition of LAN
?

Why ?

*1*  In most modern data centers I do not see any LANs. Even compute nodes
are L3 nodes connected over /31 or /30 to TORs. From fabric IGP this is
passive interface.

*2* In slightly older DCs there are redundant L3 access routers connecting
in an L2 /24 fashion to TORs and towards computes there is VRRP/HSRP. Is
this LAN we need to worry about ?

*3* Then we have non routing aware devices on say /29 subnets acting as
NFVs - is this a LAN flooding computation needs to worry about ?

Or is LAN only when IGPs decide to compute DR/BDR ?

Maybe before we move on here it would be actually useful to propose a one
page lsr draft stating that implementations should automagically enable
ospf/isis point to point behavior when there is /31 or /30 subnet
configured on the interface ? Is there a reason why this is still a manual
knob ?

Thx,
R.


On Wed, Apr 3, 2019 at 12:34 AM Tony Przygienda  wrote:

> Read it through (fairly slowly even ;-) and seems Les is for simply always
> including LAN in the flood reduction topology. I would concur with that.
> figuring whether a LAN is transit is basically calculation whether it's a
> minimal cut. solving that is polynomial of course. When we have multiple
> LANs to decide what is the maximum subset of LANs that can be cut without
> paritioning the graph (i.e. how many LANs can we omit while still having
> the graph connected) smells to me NP complet'ish but I don't think I ever
> dealt with the problem. At worst it's combination of LANs * polynomial
> computaton so about  sum_1_k (n over k) * polynomial  which looks tad chewy
> to me ... then, LAN floods efficiently in terms of fanout compared to p2p
> replication in IGPs so there's this unknown optimization constant that
> affects overall solution ...
>
> Obvioulsy, someone could implement a very clever algorithm how to avoid
> LANs or account for their efficiency and so on so IMO the draft doesn't
> even need to say anything normative if  no algorithm is given as intended
> AFAIR
>
> --- tony
>
> On Tue, Apr 2, 2019 at 10:32 AM Acee Lindem (acee)  wrote:
>
>> I agree as well.
>> Thanks,
>> Acee
>>
>> On 4/2/19, 1:26 PM, "Lsr on behalf of tony...@tony.li" <
>> lsr-boun...@ietf.org on behalf of tony...@tony.li> wrote:
>>
>>
>> I am in complete agreement with both Les’s extensive analysis and
>> opinion.  ;-)
>>
>> Tony
>>
>>
>> > On Apr 2, 2019, at 8:37 AM, Les Ginsberg (ginsberg) <
>> ginsb...@cisco.com> wrote:
>> >
>> > In reply to my own post, here is my opinion regarding including
>> LANs in the Flooding Topology:
>> >
>> > While I think it would be "nice" and simplifying to be able to
>> ignore LANs, I think we are unable to do so because the possibility that
>> LANs are actually in use as transit links in some topologies exists.
>> >
>> > NOTE: I am not persuaded by the argument that some operators have
>> LANs that could be operated in point-to-point mode but they simply don't
>> configure the links to do so. If a customer is serious about flooding
>> reduction then they need to also do what they can to reduce unnecessary
>> LSPs/LSAs from even being generated.
>> >
>> > Even if we treat LANs as always enabled for flooding , any
>> algorithm to calculate the flooding topology would be sub-optimal if it did
>> not consider the fact that flooding is occurring on the LANs.
>> >
>> > Bottom line, unless we are confident that LANs will not exist in
>> the topologies where flooding optimizations will be used, not supporting
>> LANs seems to be an undesirable restriction.
>> >
>> >   Les
>> >
>> >
>> >> -Original Message-
>> >> From: Lsr  On Behalf Of Les Ginsberg
>> (ginsberg)
>> >> Sent: Tuesday, April 02, 2019 8:31 AM
>> >> To: tony...@tony.li; lsr@ietf.org
>> >> Subject: [Lsr] Open issues with Dynamic Flooding: Including LANs
>> in the
>> >> Flooding Topology
>> >>
>> >> (I have altered the subject so we can discuss the two issues in
>> Tony's
>> >> previous post separately.)
>> >>
>> >>
>> >> There are several  aspects to consider when discussing LAN support
>> in the
>> >> context of flooding optimizations:
>> >>
>> >> 1)Flooding topology advertisement (centralized mode only)
>> >>
>> >> Support for encoding LANs when advertising the flooding topology
>> requires
>> >> that
>> >> we include not only all routers in the set of "nodes" in the
>> network but also
>> >> (to use IS-IS terminology) all “pseudo-nodes” as well. This means
>> when
>> >> advertising the set of nodes and associated indeces used in
>> calculating the
>> >> flooding topology there needs to be an indication as to whether a
>> given
>> >> entry is a node or a pseudo-node. The encoding for this is
>> straightforward
>> >> in IS-IS (include pseudo-node ID in the node identifier) but more
>> complex

Re: [Lsr] Open issues with Dynamic Flooding: Including LANs in the Flooding Topology

[Robert Raszuk]

As far as attack if someone can attach to LAN and if he knows security
details he can do much better then hack IGP.

But oh well if we prefer to continue to ride on current type of roads while
complicating design of new vehicles to accomodate it that is fine too.

Best,
R.

On Wed, Apr 3, 2019, 17:26 Tony Przygienda  wrote:

>
>
> On Wed, Apr 3, 2019 at 1:36 AM Robert Raszuk  wrote:
>
>> Hi Tony,
>>
>> > The fact that we use them in a point-to-point fashion today is somewhat
>> orthogonal, as from
>> > the routing protocol layer, *we cannot tell* whether an interface is
>> point-to-point or not, and we
>> > must be explicitly configured to be in point-to-point mode.
>>
>> Why we cannot tell ? That to me is a protocol specification bug.
>>
>> Sorry if I was not very clear - My question was driven by the idea to
>> actually redefine what LAN is for the purpose of LSR and specifically this
>> discussion and perhaps even drop completely support of dynamic flooding
>> when LAN is detected and present - based on a new definition of LANs.
>>
>> It should not matter if interface is multi access or not.
>>
>> Proposal:
>>
>> To consider LAN an interface on which you receive Hellos from more then
>> one IGP peer.
>>
>>
> leads to simple attack vectors, not possible on misconfiguration
>
> adding something like OSPF capability saying (/31 is automatically
> point-to-point) and enforcing that is possibly but will lead to lots of
> backwards compatibility breaks ...  In ISIS there isn't a simple way to do
> it given an interface may be on multiple subnets (TE TLVs) and so on ...
>
> so yeah, routing protocols are hard, especially the older ones when one
> implements and deploys ;-)
>
> -- tony
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] LANs in IGPs

[Robert Raszuk]

> What extension are you proposing?

If you have only two routers on LAN based on IIH multicast discovery you
are still forming an adj between them (you do that anyway as one of them
will be DIS). But for flooding reduction point of view you can treat it as
p2p link (so it must be signaled as such).

When Nth (N >= 3) router comes up you fall back to LAN mode and here you
can support it or not.

I guess your take is that since you want to support it anyway when N >= 3
there is no point of building the special case for the N=2.

Thx,
R.







On Wed, Apr 3, 2019 at 7:56 PM  wrote:

>
> Hi Robert,
>
> But I really think this isn’t relevant. The use of LANs in the flooding
>> topology is only meaningful if we have a multi-access circuit which is used
>> for transit traffic. And at least some of us are leaning to allowing for
>> that possibility – which is not at all the same thing as saying you SHOULD
>> run in LAN mode even if you don’t have to. Nor is it encouraging the use of
>> multi-access LANs.
>>
>
> I guess this is the question ... is dynamic flooding a new flooding
> paradigm in IGPs to be used everywhere or is it only applicable to densely
> connected topologies ?
>
>
>
> It is only sensible in dense topologies.  In sparse topologies, such as
> you would find in a WAN, there is very little improvement to be had.
>
> For example, at Prague I showed an 8x8 grid.  The FT improvement was only
> 36%.  Given the computational cost, it’s probably not worth it.
>
>
> If this is former - by all means support of real LANs is must have. If
> this is the latter - I doubt.
>
> In fact if this is the latter more simplification in computing flooding
> graph, less complexity in signalling and therefor less bugs will IMHO yield
> much better outcome.
>
> In such cases it may be actually a feature to limit dynamic flooding to
> p2p topologies only.
>
>
>
> Well, I have to disagree.  While it’s nice to say that you will limit that
> feature to those topologies, real operators push the envelope all of the
> time.  Things happen operationally. Folks can definitely use LANs
> advantageously in dense topologies. It makes sense to support them.
>
> If you want a way to more easily enable P2P mode by default – speak to
>> your favorite vendor. That is a feature – not a protocol extension.
>>
>
> Completely disagree. To detect how many IGP peers are on the interface
> and to do the switchover gracefully between 2 vs N or N vs 2 protocol
> extension is needed. It is not a single side local hack.
>
>
>
> What extension are you proposing?
>
> Tony
>
>
> ___
> 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] LANs in IGPs

[Robert Raszuk]

Hi Les,

Sorry – but I really think you are taking this thread off topic.
>

If asking a question which is outside of the box is equal to thread
hijacking then sorry. But you won - subject line changed.

But I really think this isn’t relevant. The use of LANs in the flooding
> topology is only meaningful if we have a multi-access circuit which is used
> for transit traffic. And at least some of us are leaning to allowing for
> that possibility – which is not at all the same thing as saying you SHOULD
> run in LAN mode even if you don’t have to. Nor is it encouraging the use of
> multi-access LANs.
>

I guess this is the question ... is dynamic flooding a new flooding
paradigm in IGPs to be used everywhere or is it only applicable to densely
connected topologies ?

If this is former - by all means support of real LANs is must have. If this
is the latter - I doubt.

In fact if this is the latter more simplification in computing flooding
graph, less complexity in signalling and therefor less bugs will IMHO yield
much better outcome.

In such cases it may be actually a feature to limit dynamic flooding to p2p
topologies only.


> If you want a way to more easily enable P2P mode by default – speak to
> your favorite vendor. That is a feature – not a protocol extension.
>

Completely disagree. To detect how many IGP peers are on the interface  and
to do the switchover gracefully between 2 vs N or N vs 2 protocol extension
is needed. It is not a single side local hack.

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

Re: [Lsr] Open issues with Dynamic Flooding

[Robert Raszuk]

> Slow convergence is obviously not a good thing

Could you please kindly elaborate why ?

With tons of ECMP in DCs or with number of mechanism for very fast data
plane repairs in WAN (well beyond FRR) IMHO any protocol *fast convergence*
is no longer a necessity. Yet many folks still talk about it like the only
possible rescue ...


On Tue, Mar 5, 2019 at 5:42 PM Tony Przygienda  wrote:

> in practical terms +1 to Peter's take here ... Unless we're talking tons
> of failures simultaneously (which AFAI talked to folks are not that common
> but can sometimes happen in DCs BTW due to weird things) smaller scale
> failures with few links would cause potentially diffused "chaining" of
> convergence behavior rather than IGP-style fast healing (and on top of that
> I didn't see a lot of interest in formalizing a rigorous distributed
> algorithm which IMO would be necessary to ensure ultimate convergence when
> only one/subset of links is used). Slow convergence is obviously not a good
> thing unless we assume people will run FRR with its complexity in DC and/or
> no more than one link every fails which seems to me bending assumptions to
> whatever solution is available/preferred. To Tony's point though, on large
> scale failures enabling all links would cause heavy flood load, yes, but in
> a sense it's the "initial bootup" case anyway (especially in centralized
> case) since nodes need all topology to make informed correct decisions
> about what the FT should be if they don't rely on whatever the centralized
> instance thinks (which they won't be able to do given the FT from
> centralized instance will indicate lots links that are "gone" due to
> failure). As to p2p, I suggest to agree whether you use dense mesh (DC)
> case or sparse mesh (WAN) case or "every topology imaginable" since that
> drives lots design trade-offs.
>
> my 2.71828182 cents ;-)
>
> --- tony
>
> On Tue, Mar 5, 2019 at 8:27 AM Peter Psenak  wrote:
>
>> Hi Tony,
>>
>> On 05/03/2019 17:16 , tony...@tony.li wrote:
>> >
>> > Peter,
>> >
>> >>>(a) Temporarily add all of the links that would appear to remedy
>> the partition. This has the advantage that it is very likely to heal the
>> partition and will do so in the minimal amount of convergence time.
>> >>
>> >> I prefer (a) because of the faster convergence.
>> >> Adding all links on a single node to the flooding topology is not
>> going to cause issues to flooding IMHO.
>> >
>> >
>> > Could you (or John) please explain your rationale behind that? It seems
>> counter-intuitive.
>>
>> it's limited to the links on a single node. From all the practical
>> purposes I don't expect single node to have thousands of adjacencies, at
>> least not in the DC topologies for which the dynamic flooding is being
>> primary invented.
>>
>> In the environments with large number of adjacencies (e.g.
>> hub-and-spoke) it is likely that we would have to make all these links
>> part of the flooding topology anyway, because the spoke is typically
>> dual attached to two hubs only. And the incremental adjacency bringup is
>> something that an implementation may already support.
>>
>> >
>> >
>> >
>> >> given that the flooding on the LAN in both OSPF and ISIS is done as
>> multicast, there is currently no way to enable flooding, either permanent
>> or temporary, towards a subset of the neighbors on the LAN. So if the
>> flooding is enabled on a LAN it is done towards all routers connected to
>> the it..
>> >
>> >
>> > Agreed.
>> >
>> >
>> >> Given that all links between routers are p2p these days, I would vote
>> for simplicity and make the LAN always part of the FT.
>> >
>> >
>> > I’m not on board with this yet.  Our simulations suggest that this is
>> not necessarily optimal.  There are lots of topologies (e..g., parallel
>> LANs) where this blanket approach is suboptimal.
>>
>> the question is how much are true LANs used as transit links in today's
>> networks.
>>
>> thanks,
>> Peter
>>
>> >
>> > Tony
>> >
>> > .
>> >
>>
>> ___
>> 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] Open issues with Dynamic Flooding

[Robert Raszuk]

Peter,

> you only have two paths to reach any node.

Who says that you must be limited to two paths only ?

Why not create a flooding graph such that flooding will happen over 4 paths
as opposed to flooding over 16 or 32 today without optimization.

And if you are worried that you loose *wisely selected* all 4 paths before
you manage to distribute new flooding topology you can always flood over 6
:)

Best,
R.







On Tue, Mar 5, 2019 at 9:17 PM Peter Psenak  wrote:

> Robert,
>
> On 05/03/2019 20:12 , Robert Raszuk wrote:
> >
> >> Slow convergence is obviously not a good thing
> >
> > Could you please kindly elaborate why ?
> >
> > With tons of ECMP in DCs or with number of mechanism for very fast data
> > plane repairs in WAN (well beyond FRR) IMHO any protocol *fast
> > convergence* is no longer a necessity. Yet many folks still talk about
> > it like the only possible rescue ...
>
> we are talking about the control plane convergence, not data plane one.
> If the flooding topology is subset of the real topology, then at the
> flooding level you don't have all the ECMPs available - you only have
> two paths to reach any node. In such case it is possible that the
> flooding topology gets partitioned and you want to get out of that state
> quickly, as you may get out of sync with the the reality and eventually
> loose all the data plane ECMPs as a consequence.
>
> thanks,
> Peter
>
> >
> >
> > On Tue, Mar 5, 2019 at 5:42 PM Tony Przygienda  > <mailto:tonysi...@gmail.com>> wrote:
> >
> > in practical terms +1 to Peter's take here ... Unless we're talking
> > tons of failures simultaneously (which AFAI talked to folks are not
> > that common but can sometimes happen in DCs BTW due to weird things)
> > smaller scale failures with few links would cause potentially
> > diffused "chaining" of convergence behavior rather than IGP-style
> > fast healing (and on top of that I didn't see a lot of interest in
> > formalizing a rigorous distributed algorithm which IMO would be
> > necessary to ensure ultimate convergence when only one/subset of
> > links is used). Slow convergence is obviously not a good thing
> > unless we assume people will run FRR with its complexity in DC
> > and/or no more than one link every fails which seems to me bending
> > assumptions to whatever solution is available/preferred. To Tony's
> > point though, on large scale failures enabling all links would cause
> > heavy flood load, yes, but in a sense it's the "initial bootup" case
> > anyway (especially in centralized case) since nodes need all
> > topology to make informed correct decisions about what the FT should
> > be if they don't rely on whatever the centralized instance thinks
> > (which they won't be able to do given the FT from centralized
> > instance will indicate lots links that are "gone" due to failure).
> > As to p2p, I suggest to agree whether you use dense mesh (DC) case
> > or sparse mesh (WAN) case or "every topology imaginable" since that
> > drives lots design trade-offs.
> >
> > my 2.71828182 cents ;-)
> >
> > --- tony
> >
> > On Tue, Mar 5, 2019 at 8:27 AM Peter Psenak  > <mailto:ppse...@cisco.com>> wrote:
> >
> > Hi Tony,
> >
> > On 05/03/2019 17:16 , tony...@tony.li <mailto:tony...@tony.li>
> > wrote:
> > >
> > > Peter,
> > >
> > >>>(a) Temporarily add all of the links that would appear to
> > remedy the partition. This has the advantage that it is very
> > likely to heal the partition and will do so in the minimal
> > amount of convergence time.
> > >>
> > >> I prefer (a) because of the faster convergence.
> > >> Adding all links on a single node to the flooding topology is
> > not going to cause issues to flooding IMHO.
> > >
> > >
> > > Could you (or John) please explain your rationale behind that?
> > It seems counter-intuitive.
> >
> > it's limited to the links on a single node. From all the
> practical
> > purposes I don't expect single node to have thousands of
> > adjacencies, at
> > least not in the DC topologies for which the dynamic flooding is
> > being
> > primary invented.
> >
> > In the environments with large number

Re: [Lsr] Open issues with Dynamic Flooding

[Robert Raszuk]

> we want to limit the flooding to minimum, which is 2.
>

Is that really a common agreement in the WG ? I have a feeling think this
is too restrictive for no valid technical reason.

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

Re: [Lsr] Open issues with Dynamic Flooding

[Robert Raszuk]

Tony-P,

I am not talking about LAGs but pure vanilla L3 ECMP paths in any DC.

Any node will be receiving at least two copies of flooded topology
(regardless in which direction you look up or down) so when one of the
links is broken which is used for actual flooding or peer sending link
state info goes down flooding graph can be repaired at its own pace while
data plane is not impacted as there are many more L3 paths still available.

That was my point.

Thx,
r.

On Tue, Mar 5, 2019 at 8:36 PM Tony Przygienda  wrote:

>
>
> On Tue, Mar 5, 2019 at 11:12 AM Robert Raszuk  wrote:
>
>>
>> > Slow convergence is obviously not a good thing
>>
>> Could you please kindly elaborate why ?
>>
>> With tons of ECMP in DCs or with number of mechanism for very fast data
>> plane repairs in WAN (well beyond FRR) IMHO any protocol *fast convergence*
>> is no longer a necessity. Yet many folks still talk about it like the only
>> possible rescue ...
>>
>>
>>
> Agree on FRR in WAN but it seems quite a complexity to drag that into DC
> fabrics (again, depeneding what topologies talk about) especially due to
> the effect I outline below.
>
> ECMP in DCs when used AFAIS is often caused by walking the 10G-50G curve
> where everybody has different economic sweet-spots AFAIS. Sometimes 100G.
> It's often LAG'ed (due to amount of control plane state AFAIU). LAG'ing
> generally creates interesting problems itself and I expect whole thing to
> settle somewhere with 20-50G to the server over either very short copper or
> multimode. I do not think it's a particularly cool architecture to suggest
> "LAG every link so it's 1:1 protected".
>
> Wide fanout is common & will get wider AFAIS. This is cool for failures in
> one direction but doesn't prevent you from blackholing on the "far end"
> until you get control plane reconvergence (or do FRR on a spine but
> honestly, how do you do that, bow-tieing over top of fabric or doing
> harmonica routing over multi-homed servers?)
>
> Then, slow convergence means that new stuff shows up slowly which is
> probably not very desirable and in case of failures that really need
> control plane rerouting causes longer duration blackholes as well. Both
> seem undesirable .. Not mentioning mobility even ...
>
> my
>
> [image: CodeCogsEqn(17).gif]   cents ;-)
>
> --- tony
>
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] draft-ketant-idr-bgp-ls-bgp-only-fabric

[Robert Raszuk]

Hi Ketan,

I have read your proposal of defining topology flooding in BGP with
interest.

It seems like a pretty brilliant twist to take pieces defined in other
documents with their original intention for sending IGP information (LSDB
or TED) over BGP extension and now use all of those without IGP at all :).

But I have just one question here perhaps to the WG or ADs.

Almost all normative references used in this draft clearly state that they
were defined for carrying information present in ISIS & OSPF protocols as
rather a courtesy of transporting them over TCP with BGP envelope between
network and controller.

Can we now just "reuse" verbatim all of those defined codepoints as well as
redefine use of BGP-LS SAFI as a new link state p2p network topology
transport just like that ?

At min I would like to see some analysis included in this draft of running
native link state protocol possibly with dynamic flooding optimization vs
running BGP as the only routing protocol with using BGP as topology
discovery transport before we proceed further on this document.

Kind regards,
Robert.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Clarification on co-existance of dynamic flooding aware and not aware nodes

[Robert Raszuk]

Hey Peter,

Yes I was not so much asking from the perspective of the node which does
not support it. I was more curious if his directly adj neighbor will be
smart enough to treat such node rigth.

And precisely to that point I have tried to indicate that if this is by
design there is no point of including those 100s of TORs in constructing
and distributing flooding graph.

But spec seems quite silent on such deployment model hence the post.

Thx,
R.


On Thu, Mar 7, 2019 at 12:11 PM Peter Psenak  wrote:

> Hi Robert,
>
> On 07/03/2019 12:00 , Robert Raszuk wrote:
> > Hi,
> >
> > My reading of draft-ietf-lsr-dynamic-flooding indicates that said
> > document in number of places rather assumes that entire topology (entire
> > instance) supports dynamic flooding (perhaps other then bootstrap phase).
> >
> > Let's observe that there can be lots of L3 TORs only dual attached to
> > access routers which will not benefit at all to be part of the game.
> > Moreover those TORs may be from different vendors and could support link
> > state protocols without any dynamic flooding extensions.
> >
> > So the question is if the proposal considers a case where only part of
> > the fabric in single topology, single area/level, single LSDB etc. is
> > aware about dynamic flooding protocol extensions ?
>
> sure, see section 5.1.2.
>
> If the node does not participate in dynamic flooding, it will use
> standard flooding mechanism. This means that the flooding may be less
> optimal, but nothing would break.
>
> If you wan to be extra smart, your algorithm can even take the node
> participation into account and compute the flooding topology with that
> in mind.
>
> thanks,
> Peter
>
>
> >
> > Let's also observe that In any deployment such state when some nodes are
> > enabled and some not for dynamic flooding can happen during migrating
> > phase or operator's errors which one would assumed must be handled
> > correctly by the protocol.
> >
> > Many thx,
> > R..
> >
> >
> > ___
> > 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] Clarification on co-existance of dynamic flooding aware and not aware nodes

[Robert Raszuk]

Hi,

My reading of draft-ietf-lsr-dynamic-flooding indicates that said document
in number of places rather assumes that entire topology (entire instance)
supports dynamic flooding (perhaps other then bootstrap phase).

Let's observe that there can be lots of L3 TORs only dual attached to
access routers which will not benefit at all to be part of the game.
Moreover those TORs may be from different vendors and could support link
state protocols without any dynamic flooding extensions.

So the question is if the proposal considers a case where only part of the
fabric in single topology, single area/level, single LSDB etc. is aware
about dynamic flooding protocol extensions ?

Let's also observe that In any deployment such state when some nodes are
enabled and some not for dynamic flooding can happen during migrating phase
or operator's errors which one would assumed must be handled correctly by
the protocol.

Many thx,
R.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] IS-IS lite (an aside)..

[Robert Raszuk]

Well I was actually not talking about homenet efforts, but any small/mid
size compute clusters.

See today it is very common for hosts to participate in dynamic routing -
simply due to a fact that VMs or PODs want to be dynamically IP reachable
when they are created by orchestration.

Moreover it is not that uncommon to see flat routing requirement too in
today's DC deployments. Systems folks just do not like the additional
protocol layers :)

So what options do we have - well BGP between TOR and compute seems to be
the only option. Then in fabric there is link state or oversold BGP.

Then in the former case you have to redistribute BGP to your underlay and
if have requirement to separate reachability then at best you need to map
communities to ISIS tags at redistribution. Of course for multi-tenancy
there is zoo of other hierarchical options.

That just brings an observation that if we are spending some effort to get
link state operate lighter in densely meshed environments perhaps it does
make sense to make it work end to end too. Not that hosts need to know
entire topology so they can be happily treated as stubs, but still single
protocol operation is a big OPEX advantage.

r.

On Fri, Mar 8, 2019 at 1:30 PM Acee Lindem (acee)  wrote:

>
>
> On 3/8/19, 7:22 AM, "Lsr on behalf of Christian Hopps" <
> lsr-boun...@ietf.org on behalf of cho...@chopps.org> wrote:
>
>
> tony...@tony.li writes:
> >Robert Raszuk  writes:
> >>
> >> See TORs are one case .. but there are ideas to run dynamic
> protocols to the hosts too. I have heard there was even a volunteer to
> write ISIS-lite to be used on hosts :)
> >
> > I would…. discourage that concept.
>
> Perhaps Robert is referring to when homenet was considering using
> IS-IS instead of a brand new protocol (babel) for use in the homenet. The
> proposed solution for very simple devices (e.g. thermostats or anything w/o
> much ram etc) was to use the overload bit. This wasn't just for hosts
> though, but for very small devices that could still serve as simple router
> for a network behind them.
>
>
> https://www.ietf.org/archive/id/draft-mrw-homenet-rtg-comparison-02.txt
>
> Christian Franke coded up "tinyisis" in 1500 lines of C code. :)
>
>
> https://git-us.netdef.org/projects/OSR/repos/tinyisis/browse/tinyisis.c
>
> We have " IS-IS Routing for Spine-Leaf Topology" to address resources on a
> TOR while still having multiple northbound links. At least in the context
> of flooding reduction, I don’t think we need anything IS-IS lite.
>
> Thanks,
> Acee
>
>
> Thanks,
> Chris.
>
>
> ___
> 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] Clarification on co-existance of dynamic flooding aware and not aware nodes

[Robert Raszuk]

> The upstream nodes do need to be told this.

Well unless they know by design to always flood when peer is not dynamic
flooding capable.

Yes today this seems to be consider transient and rather an exception
(example bootstraping or incremental deployment). My main point was should
this be also a valid and legal deployment model ? The draft is actually on
one hand says the above and on the other indicates that dynamic flooding
could be enabled and run only on part of the area:

   Flooding that is initiated by nodes that support Dynamic Flooding
   will remain within the flooding topology until it reaches a legacy
   node, which will resume legacy flooding.


See TORs are one case .. but there are ideas to run dynamic protocols to
the hosts too. I have heard there was even a volunteer to write ISIS-lite
to be used on hosts :)

However If you mandate that all of the members must be included in the
flooding graph the leaders may get a little bit busy from time to time.

Of course one option is to just split those into separate areas or levels,
but keeping it at single one could be considered attractive.

Robert.

On Thu, Mar 7, 2019 at 4:09 PM  wrote:

>
>
> On Mar 7, 2019, at 3:16 AM, Robert Raszuk  wrote:
>
> And precisely to that point I have tried to indicate that if this is by
> design there is no point of including those 100s of TORs in constructing
> and distributing flooding graph.
>
>
>
> And to the point of the algorithm, including those 100s of TORs in
> constructing the graph is absolutely necessary.  In the case where the
> TOR’s have a pair of upstream nodes, you want both of those upstream
> interfaces enabled for flooding. The upstream nodes do need to be told this.
>
> Tony
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]

[Robert Raszuk]

Hi Peter,

Many thx for your comment.

What I had in mind here was use of multi instance (=2) over very reach
physical topologies. So when we construct flooding graph for each such
instance - even in centralized mode - the intention was to avoid flooding
to take common links (just to reduce the impact of any failure to have
effect on both instances). Yes of course data paths are different from
flooding graph so I was just talking about the latter.

I know that perhaps this should be moved to a different thread - the only
reason why I mentioned about it here was that it is not immediately obvious
to me if extensions which we have today defined in draft-li will be
sufficient. Perhaps for centralized indeed they would be just fine as
central graph compute oracle could be smart enough to address it. For
distributed I am not sure.

I did not want to derail the main topic though so let's shift it for other
chat.

Kind regards,
Robert.

primary/backup topologies are used for transmitting user data, not
> necessarily the flooding data. I don't see how they are related to the
> flooding topology, which is used for flooding only.
>
> To the point, if a new distributed algorithm is defined that needs more
> data to be signaled, then we will extend the existing signaling. I don't
> see that being a problem. The way the signaling is defined in
> draft-li-lsr-dynamic-flooding does allow for such thing.
>
> thanks,
> Peter
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Call for draft-li-lsr-dynamic-flooding-02 + IPR poll.

[Robert Raszuk]

Support.

r.

On Mon, Feb 11, 2019 at 11:47 AM Christian Hopps  wrote:

>
> Hi Folks,
>
> We are starting a 2 week adoption call on draft-li-lsr-dynamic-flooding-02.
>
> The aim of this document is to describe the problem space and standardize
> a way to signal dynamic flooding information. It does not standardize any
> specific algorithm for flooding topology creation.
>
> Authors please respond indicating if you are aware of any IPR related to
> this work.
>
> We also have another draft (draft-cc-lsr-flooding-reduction-01) that
> started as a distributed flooding topology algorithm and morphed into that
> plus competing ideas on signaling of flooding topology information. The
> intent after adoption of draft-li-lsr-dynamic-flooding-02 is two-fold. One,
> the WG can discuss adding any signaling ideas from this work to the adopted
> signaling draft (with proper attribution given as appropriate), and two,
> for the authors of draft-cc-lsr-flooding-reduction-01 to publish a new
> document without the signaling portion and instead focus on their flooding
> topology algorithm. This new focused document can be considered in parallel
> along with the other algorithm work that has been proposed.
>
> Flooding topology creation is seen as a hard problem for which we don't
> expect a one-size-fits-all solution. Taking the steps outlined above will
> help us move forward on the solutions.
>
> Thanks,
> Chris & Acee.
> LSR WG Chairs.
> ___
> 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] Moving Forward [Re: Flooding Reduction Draft Redux]

[Robert Raszuk]

I fully agree and support proceeding with  draft-li-dyanmic-flooding and to
include protocol extensions in it for centralized topology propagation as
well as basic hooks like "execute dynamic protocol number X" for
distributed calculations.

However one may observe that separate distributed algorithms may define
their own protocol extensions and they should not break the above in any
way.

Then there is already some requirements of building two disjoined
topologies in any rich ECMP DC fabric one say for primary paths the other
for backup flows. (Case of active-active dual streaming applications).
Question arises if this would be addressed also as part of basic spec, be
combined with one or many of distributed algorithms or will require yet one
more document which in turn will "extend" all of the above ? And before
anyone suggests multi instance approach with logical or physical link
separation it is not the right direction here. If anything perhaps MTR or
SR come a bit closer.

Kind regards,
Robert.


On Sun, Feb 3, 2019 at 9:14 PM  wrote:

>
> I think that this discussion would be greatly clarified if we clearly
> separated the discussion between
>
> a) the algorithm for computing the flooding topology, and
> b) the signaling to indicate how to proceed.
>
> I think that we are all in agreement that the algorithms can and should be
> separated from the signaling.
>
> I think that we are all in agreement that each algorithm should be
> independent.
>
> I’m of the opinion that the centralized signaling is a bit more extensive
> than the signaling for the distributed mode, but that there is also
> considerable overlap and that things would
> be unnecessarily redundant if we were to separate them. I believe that we
> are not in disagreement about the basics for the distributed signaling.
>
> If you disagree with this, please clearly articulate why you feel the
> signaling should be separated.
>
> Regards,
> Tony
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]

[Robert Raszuk]

> The former will have all the good parts for the centralized solution, and
the latter will have all the good parts for the distributed solution.

And in your view which draft should contain required protocol extensions to
accommodate both solutions ?

Or are you suggesting that we should have completely different protocol
extensions for distribution of centralized computed graphs vs for
propagating parameters allowing customized distributed computation of
partial flooding topology ?

Thx,
R.


On Sun, Feb 3, 2019 at 5:44 PM Huaimo Chen  wrote:

> Hi Dave,
>
>
>
> There are two drafts containing the centralized solution and distributed
> solution already on the table too. If the two drafts are adopted, they need
> to be updated for one draft to focus on the centralized solution and the
> other on the distributed solution. The former will have all the good parts
> for the centralized solution, and the latter will have all the good parts
> for the distributed solution.
>
>
>
> Best Regards,
>
> Huaimo
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Working Group Last Call for "OSPF Link Traffic Engineering (TE) Attribute Reuse" - draft-ietf-ospf-te-link-attr-reuse-07.txt

[Robert Raszuk]

Peter,

IMO what Olivier has indicated is a practical and operational aspect. The
theoretical aspects of protocol operation is what this document is
extending. Those are two different things :)  And this is not the first
time where IETF is manufacturing specs without any serious input from folks
who actually need to use it. The co-authors of this very draft indicates it
quite clearly - all vendors !

It would be very operationally complex and completely bizarre to run N
different TE applications concurrently in any production network. The fact
that you could or can does not make it immediately a good idea. Perhaps
great exercise for the lab though.

Even with one such TE mechanism there is a lot of things to manage and that
is why very few networks run full 100% TE. Further more as you know TE
reservations are all in control plane so the moment you forward any
significant amount of non TE traffic (unicast or multicast) your entire TE
magic is over.

Last I was hoping someone will answer how for a given link of RTT 20 ms -
you could send different value per each application ? Or do you mean that
on any given link mpls RTT != IPv4 RTT != IPv6 RTT ?

Kind regards,
R.

On Mon, Apr 15, 2019 at 10:49 AM Peter Psenak  wrote:

> Hi Olivier,
>
> On 12/04/2019 16:26 , olivier.dug...@orange.com wrote:
> > Hello Peter,
> >
> >
> > Le 12/04/2019 à 15:27, Peter Psenak a écrit :
> >> Hi Oliver,
> >>
> >> There are two major purposes served by the drafts:
> >>
> >> 1)Support of incongruent topologies for different applications
> > Don't understand. What do you mean ?
>
> RFC3630 allows the traffic engineering topology to be incongruent with
> the regular routing topology. This means that the RSVP TE topology can
> only be a subset of the regular routing topology. If there is a need to
> advertise some link attribute for the purpose of the other application,
> the link would become part of the RSVP TE topology, something that may
> not be desired.
>
> >>
> >> 2)Advertisement of application specific values even on links that are in
> >> use by multiple applications
> > Hum. Do you think it makes sense to announce different TE metric for the
> > same link for different applications ? e.g. 10 ms delay for RSVP-TE, 20
> > ms for SR, 15 ms for LFA and 5 ms for Flex -Algo ? The link has a fix
> > delay propagation whatever the application.
> >
> > If the goal is to dedicated link per application, Resource Class/Color
> > attribute could be used. If you would advertised different metric per
> > CoS, then you need to dedicated metric per CoS like the unreserved
> > bandwidth.
>
> The goal is the allow the link to be used by multiple applications, but
> be advertised with application specific attributes.
>
> >>
> >> These issues are clearly articulated in the Introductions of both
> >> drafts. LSR WG acknowledged them a while back and decided to address
> >> them.
> >>
> >> Issue #1 has already had a significant impact on early deployments of
> >> SRTE in networks where there is partial deployment of SR in the presence
> >> of RSVP-TE.
> > Can you point me a concrete and detail example of the problem ? With a
> > PCE, there is no problem to manage both RSVP-TE and SR-TE in the same
> > network. And again, as already mention, if the problem come from
> > bandwidth reservation, the draft will not solve the issue.
>
> there is no way to advertise the link for the purpose of the SR-TE,
> without it becoming the part of the RSVP-TE using existing
> advertisements. Similarly applicable in the context of any other
> application.
>
> >>
> >> Issue #2 will be seen in deployments where Flex-Algo and SRTE (or
> >> RSVP-TE) are also present. Early implementers of Flex-Algo can attest to
> >> this.
> > Again, I don't see the problem. Can you explain in detail ? I already
> > implement SR in OSPF, starting playing with TE, and there is no problem
> > to get TE information from OSPF to tune some Segment Path. If it is an
> > implementation issue, it is not a new RFC that will solve the problem.
>
> we are not trying to solve the implementation issue. We are solving the
> protocol issue. Both protocols have defined many link attributes for the
> purpose of the RSVP-TE. Some of these are usable outside of the RSVP TE
> and we are extending the protocols to support that.
>
> Please read the discussion on the mailing list that happened prior to
> the WG adoption of these drafts.
>
> >>
> >> It is simply not possible to address these issues with the existing
> >> single set of application independent advertisements.
> > Why ? Again, explain in detail. I don't see a real use case that could
> > not be address with standard TE attributes.
>
> please see above.
>
> thanks,
> Peter
>
>
> >>
> >> The solutions we provide in both drafts allow to share the link
> >> attributes between application as well as keep them separate if that is
> >> what is required.
> >>
> >> thanks,
> >> Peter
> >
> > Regards
> >
> > Olivier
> >
> >>
> >> On 11/04/2019 19:43 , 

Re: [Lsr] draft-ietf-lsr-isis-srv6-extensions-00

[Robert Raszuk]

Hi Paul,

It has been pointed out about month ago :)

Ref:
https://mailarchive.ietf.org/arch/msg/lsr/hbmJqgpnfjcsxiD40AGaTMA2tic

Best,
R.


On Fri, May 31, 2019 at 11:41 PM Paul Mattes  wrote:

> I think there is a small issue with
> draft-ietf-lsr-isis-srvr-extensions-00. The title is:
>
>
>
> IS-IS Extensions to Support Routing over IPv6 Dataplane
>
>
>
> I suspect that IS-IS works just fine for routing IPv6. The title should
> probably be:
>
>
>
> IS-IS Extensions to Support Segment Routing over IPv6 Dataplane
>
>
>
>*pdm*
>
>
> ___
> 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] 答复: 答复: Option B from "Migration between normal flooding and flooding reduction"

[Robert Raszuk]

Hey Peter,


> > Is it more efficient that only one area leader indicates(according to
> the command from NMS) explicitly then the network will be back to normal
> flooding?
>
> yes and we have that in the draft:
>
> "When the Area Leader advertises algorithm 0 in its Area Leader Sub-
> TLV and does not advertise a flooding topology, Dynamic Flooding is
> disabled for the area.  Note this applies whether the Area Leader
> intends to operate in centralized mode or in distributed mode."
>

Two little questions ...

- I think to avoid potential ambiguity in implementations it would be worth
clarifying what "does not advertise" means ... does it mean that Area Node
IDs TLV is not present all together or does it mean that it MAY be present
but it is sufficient that it does not contain any Node ID .. or both ?

- how does this apply to distributed mode if flooding topology is to be
used only in centralized mode ? Isn't the quoted text from section 6.4 a
bit incorrect and requires a fix ?

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

Re: [Lsr] Working Group Adoption Call for "IS-IS Extensions to Support Routing over IPv6 Dataplane" - draft-bashandy-isis-srv6-extensions-05.txt

[Robert Raszuk]

Isn't the draft's name a bit misleading ?

"IS-IS Extensions to *Support* Routing over IPv6 Dataplane"

I think ISIS supports routing over IPv6 for some time now :) Maybe it would
be better to s/Support/Segment/ ?

In any case I support the adoption.

Thx,
R.

On Thu, May 9, 2019 at 3:50 PM Acee Lindem (acee)  wrote:

> We been holding off WG adoption until the base SRv6 draft was adopted in
> SPRING. Now that
> https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-network-programming/
> has been adopted, we are starting a two week LSR WG adoption poll for the
> subject draft. Please register your support or objection prior to 12:00 AM
> UTC, on May 25th, 2019.
>
>
>
> For your convenience, here is a URL for the draft:
>
>
>
> https://datatracker.ietf.org/doc/draft-bashandy-isis-srv6-extensions/
>
>
>
> Thanks,
>
> Acee
>
>
> ___
> 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] Migration between normal flooding and flooding reduction

[Robert Raszuk]

One may observe that the draft implicitly also supports already option A
too. If leader advertises full topology wouldn't it effectively disable
dynamic flooding automatically ?

At least no NMS or configuration push is required on all 1000s of nodes to
go back to full flooding say for the purpose of self distruction of your
fabric ;).

Thx,
R.

On Wed, May 22, 2019, 05:46 Les Ginsberg (ginsberg) 
wrote:

> Huaimo –
>
>
>
> The thread started with you defining multi-step processes for electing an
> area leader and enabling/disabling dynamic flooding – each of which
> involved multiple state changes on each node in the network. (Please scroll
> to the bottom to see your original post.)
>
>
>
> Both Tony and I responded by saying “no need for that”. Election of an
> Area Leader proceeds just like election of DIS on a LAN in IS-IS – totally
> event driven.
>
> Enabling/disabling of dynamic flooding happens based on what algorithm the
> Area Leader advertises and whether (in centralized mode) the Flooding
> Topology is advertised.
>
>
>
> Sections 6.4, 6.5, and 6.7 describe this.
>
>
>
> In response to my comment you have now changed the topic to discussing
> whether a config change is required on every node in order to
> enable/disable dynamic flooding.
>
> Different topic. It’s a bit hard to keep the thread focused when you
> change the topic.
>
> In brief, I do not see a problem supporting your “Option B” below – and
> the draft provides for that. We may want to make the wording more precise –
> I am certainly open to that – but the capability is already there..
>
>
>
>Les
>
>
>
>
>
> *From:* Huaimo Chen 
> *Sent:* Tuesday, May 21, 2019 3:13 PM
> *To:* Les Ginsberg (ginsberg) ; tony...@tony.li
> *Cc:* lsr@ietf.org
> *Subject:* RE: [Lsr] Migration between normal flooding and flooding
> reduction
>
>
>
> Hi Les,
>
>
>
> Consider the following options to transfer all nodes in an area from
> flooding reduction to normal flooding or from normal flooding to flooding
> reduction:
>
> Option A: Go to all the nodes (if there are thousands of nodes, go to all
> of them), execute “disable flooding reduction” or “enable flooding
> reduction” on all of them.
>
> Option B: Go to the leader (even if there are thousands of nodes, just go
> to the leader), execute “roll back to normal flooding” or “transfer to
> flooding reduction” on the leader.
>
>
>
> Option B should be supported. Option B provides a simpler and quicker way
> to transfer between flooding reduction and normal flooding.
>
>
>
> It seems that Option A is similar to going to all the nodes and
> configuring an algorithm to compute the FT for distributed mode; and Option
> B is similar to going to the leader and configuring an algorithm to compute
> the FT for distributed mode, which is used in
> draft-ietf-lsr-dynamic-flooding.
>
>
>
> Best Regards,
>
> Huaimo
>
> *From:* Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com
> ]
> *Sent:* Monday, May 20, 2019 4:39 PM
> *To:* Huaimo Chen ; tony...@tony.li
> *Cc:* lsr@ietf.org
> *Subject:* RE: [Lsr] Migration between normal flooding and flooding
> reduction
>
>
>
> Huaimo –
>
>
>
> I, like Tony, am wondering what problem you are trying to solve.
>
>
>
> Note that updated LSPs/LSAs which are received on an interface which the
> receiving node believes is NOT part of the flooding topology are NEVER
> discarded. They are processed and flooded on those interfaces which the
> receiver believes are part of the flooding topology.  So there is no need
> for the coordination you propose. The network can transition from no
> flooding optimizations to flooding optimizations – or vice versa – simply
> by enabling/disabling optimizations.
>
>
>
> The speed at which the migration occurs is not critical. What is critical
> is that correct flooding is not compromised during the migration and (as
> Tony has noted) based on testing that works without any issues.
>
>
>
>Les
>
>
>
>
>
> *From:* Lsr  *On Behalf Of *Huaimo Chen
> *Sent:* Monday, May 20, 2019 12:53 PM
> *To:* tony...@tony.li
> *Cc:* lsr@ietf.org
> *Subject:* Re: [Lsr] Migration between normal flooding and flooding
> reduction
>
>
>
> Hi Tony,
>
>
>
> For the case that the IGP running in an area has been doing the
> flooding reduction, in order to let the IGP on every node in the area roll
> back to the normal flooding quickly and easily, a procedure for migrating
> from the flooding reduction to normal flooding is needed. After back to
> normal flooding, if we want to let the IGP on every node do flooding
> reduction some time later, the procedure should be able to migrate from
> normal flooding to the flooding reduction quickly and easily.
>
>
>
> Best Regards,
>
> Huaimo
>
> *From:* Tony Li [mailto:tony1ath...@gmail.com ] *On
> Behalf Of *tony...@tony.li
> *Sent:* Saturday, May 18, 2019 1:17 PM
> *To:* Huaimo Chen 
> *Cc:* lsr@ietf.org
> *Subject:* Re: [Lsr] Migration between normal flooding and flooding
> reduction
>
>
>
>
>
> Hi Huaimo,
>
>
>
> 

Re: [Lsr] Summary of WGLC discussion about draft-ietf-isis-te-app-06.txt and draft-ietf-ospf-te-link-attr-reuse-07.txt

[Robert Raszuk]

> With respect to your comments on BGP-LS, this is out of scope for LSR.

During last IETF it has been communicated by IDR chairs that there is an
agreement that all IGP extensions in LSR WG will define in the same
document also extensions to BGP-LS so the work is not duplicated and that
IDR will stop dealing with IGP encoding.

Quote from minutes:

"Propose: one document to keep the encoding in both IGP and BGP-LS. asking
LSR to handle encoding in their document set "

Chair's slide 5:

"Propose asking LSR to handle encoding in their document set"

Putting aside to what I personally think about BGP-LS are you as LSR
co-chair not going to follow the above recommendation/proposal ?

Thx,
R.



On Fri, May 24, 2019 at 1:12 PM Acee Lindem (acee)  wrote:

> Hi Olivier,
> I think the WG's energy has been completely focused on the dynamic
> flooding and these WG last calls didn't get the deserved attention.
>
> As for as your comments, the first two were discussed for over a year and
> half. There were other advantages as well. For example, the link attribute
> encoding reduced (OSPFv2) or eliminated (OSPFv3) the need to correlate LSA
> attributes for a single link. We will note your objection in the shepherds
> report on the documents. We could even include a pointer to your quagga
> code that took a different approach if you wish to provide one.
>
> With respect to your comments on BGP-LS, this is out of scope for LSR.
> While I haven't seen NLRI that hits the limit, I'm confident that the IDR
> WG will come up with a solution.
>
> Thanks,
> Acee
>
> On 5/23/19, 5:57 AM, "Lsr on behalf of olivier.dug...@orange.com" <
> lsr-boun...@ietf.org on behalf of olivier.dug...@orange.com> wrote:
>
> Dear all
>
> As there is no more exchange about the two mentioned drafts since 3
> weeks, I'll try to summarize the exchange and
> the requested modifications.
>
> The drafts proposed to extended IS-IS respectively OSPF to advertise
> new TE parameters to overcome 2 issues:
>  1 - Topology incongruence between the IGP and TE
>  2 - Provide different parameters per application
>
> For the first point, topology incongruence is not due to the protocol
> itself but to the fact that an operator
> may activate or not TE information on all links of its network.
> Indeed, RFC3630 and RFC5305 precise that TE
> information are Optionals.
>
> However, in both drafts, the term RECOMMENDED is used, which IMHO not
> solve the problem. An operator keeps the choice
> to activate or not this new TE information leading again to an
> incongruence network topology. At least, wording
> need to be change to MUST or MANDATORY. But, why not just change the
> wording of RFC3630 and RFC5305 ?
>
> In addition, no operator express explicitly that their are concern by
> topology incongruence.
>
>  => Introduction sections should be improved to better justify why we
> need to modify TE link advertisement
>  => Wording must be revise to avoid incongruence topology
>
> For the second point, TE information are related to a link not an
> application even if at the origin, RFC3630 and RFC5305
> were design for RSVP-TE. It is not mention in the RFCs that they could
> not be applicable to other protocol / application.
>
> If the idea, in liaison to first point, it to determine is an
> application / protocol is enable / disable on a given link,
> even if their have been not selected, drafts
> draft-hegde-ospf-advertising-te-protocols-01.txt and
> draft-hegde-isis-advertising-te-protocols-03.txt are largely
> sufficient as it is not necessary to duplicate link TE
> information. In addition, Router Information already provides
> indication on the support of SR by this router (presence
> of SRGB) where all IGP links are de-facto SR enable.
>
> Then, GMPLS specific attributes are not taken into account in these
> drafts.
>
>  => GMPLS must be considered as another application and specific GMPLS
> attribute must be part of the drafts
>  => or standardised only SABML / UDABML flags without duplicating TE
> information
>
> Network operational transition issues are poorly address in these
> drafts. Indeed, router upgrade
> take time in large scale network (several weeks even several months)
> leading cohabitation of the 2 systems which
> introduce a large degree of complexity for operators for network
> management.
>
>  => Improve migration section to help operator during the transition
> phase
>
> And finally, if we go a bit further, dealing with SDN, all these new
> TE information need to be learnt by and SDN
> controller e.g. a PCE, which naturally conduct to use BGP-LS for this
> purpose. However, recent discussion in idr WG
> mention that there is already too many attributes that have been
> standardised dealing with problem with the maximum
> size of BGP message. These new TE information will also certainly
> appear as duplicate 

Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-crh-isis-extensions-00.txt

[Robert Raszuk]

Hi Ron,

Could you provide pointer to comparison of CRH vs SRH ? Do we really need
to standardize both ? Is this going to help any practical deployments ?

Very honestly when I read this draft I needed to check date as I though we
are back in 2002/2003 when CR-LDP was trying to compete with RSVP-TE :)

Cheers,
R.


On Tue, May 14, 2019 at 5:20 PM Ron Bonica  wrote:

> Folks,
>
> Please review and comment.
>
>Ron
>
>
> Juniper Public
>
> -Original Message-
> From: internet-dra...@ietf.org 
> Sent: Tuesday, May 14, 2019 11:14 AM
> To: Ron Bonica ; Shraddha Hegde ;
> Parag Kaneriya ; Rajesh M 
> Subject: New Version Notification for
> draft-bonica-lsr-crh-isis-extensions-00.txt
>
>
> A new version of I-D, draft-bonica-lsr-crh-isis-extensions-00.txt
> has been successfully submitted by Ron Bonica and posted to the IETF
> repository.
>
> Name:   draft-bonica-lsr-crh-isis-extensions
> Revision:   00
> Title:  IS-IS Extensions To Support The IPv6 Compressed Routing
> Header (CRH)
> Document date:  2019-05-14
> Group:  Individual Submission
> Pages:  13
> URL:
> https://www.ietf.org/id/draft-bonica-lsr-crh-isis-extensions-00.txt
>
> Status:
> https://datatracker.ietf.org/doc/draft-bonica-lsr-crh-isis-extensions/
>
> Htmlized:
> https://tools.ietf.org/html/draft-bonica-lsr-crh-isis-extensions-00
>
>
> Abstract:
>Source nodes can use the IPv6 Compressed Routing Header (CRH) to
>steer packets through a specified path.  This document defines IS-IS
>extensions that support the CRH.
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
>
> The IETF Secretariat
> ___
> 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] LSR Working Group Adoption Call for "Hierarchical IS-IS" - draft-li-lsr-isis-hierarchical-isis-01

[Robert Raszuk]

> lsr-isis-extended-hierarchy

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

Re: [Lsr] LSR Working Group Adoption Call for "Hierarchical IS-IS" - draft-li-lsr-isis-hierarchical-isis-01

[Robert Raszuk]

> What would you suggest?

How about:  draft-ietf-lsr-n-level-isis-00 ?

r.


On Tue, Aug 13, 2019 at 4:42 PM  wrote:

>
> Robert,
>
> Thank you for your support.  What would you suggest?
>
> Tony
>
>
> On Aug 13, 2019, at 6:40 AM, Robert Raszuk  wrote:
>
> Support.
>
> However assuming the draft will reach rough consensus of support I do
> recommend to change the title during the conversion to WG document. ISIS is
> already hierarchical today as even the abstract of the draft clearly says.
>
> Thx,
> R.
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] LSR Working Group Adoption Call for "Hierarchical IS-IS" - draft-li-lsr-isis-hierarchical-isis-01

[Robert Raszuk]

Hey Les,

Of course the objective of the draft is clear and I do not think anyone is
questioning that. There was however topic of data and control plane
congruence requirement and I think we all agreed by now that this is rather
required in link state protocol as it is defined today.

As to the overall direction which I think initial Aijun's mail brought up
was if hierarchy is actually best answer to scale a protocol.

Divide and conquer is great strategy, but as such it could be realized with
flat levels interconnected by ISIS LSP reflectors as pure control plane
scaling solution (still reusing most of today's machinery - leaking,
summarization etc ...) Some form of DIS analogy except here to interconnect
many flat levels.

So I think the overall point to the WG is if building additional data and
control plane levels is the most optimal solution to scale link state
protocols up. Sure it can be done and it will be one more optional tool in
the toolbox, but is this the right/best tool for the job ?

Thx,
R.


On Fri, Aug 16, 2019 at 8:08 PM Les Ginsberg (ginsberg) 
wrote:

> To expand on this a bit, the point of the draft extensions is to add
> additional levels of hierarchy and use existing mechanisms (leaking,
> summarization) to have traffic flow up/down the hierarchy.
>
> The intent is NOT to bypass the hierarchy.
>
>
>
> People can use multiple instances and redistribution to do whatever they
> may wish. In that context two instances of IS-IS are no different then one
> instance of two different protocols.
>
> But this is decidedly NOT the intent of the draft.
>
>
>
>Les
>
>
>
>
>
> *From:* Lsr  *On Behalf Of * tony...@tony.li
> *Sent:* Friday, August 16, 2019 11:01 AM
> *To:* Tony Li 
> *Cc:* lsr@ietf.org; Aijun Wang ; Robert Raszuk
> 
> *Subject:* Re: [Lsr] LSR Working Group Adoption Call for "Hierarchical
> IS-IS" - draft-li-lsr-isis-hierarchical-isis-01
>
>
>
>
>
> Hi Aijun,
>
>
>
> Les kindly points out that what I’ve suggested here is completely
> non-standard and requires multiple IS-IS instances.
>
>
>
> Tony
>
>
>
>
>
>
>
> On Aug 16, 2019, at 9:03 AM, tony...@tony.li wrote:
>
>
>
> Hi Aijun,
>
>
>
> If, as you stated,  we connect R1 and R7 via one link(although we will not
> do so, if we design the network hierarchically), how you flood the link
> information hierarchically but let the traffic between the two connected L1
> area bypass the L2 area?
>
>
>
>
>
> The link between R1 and R7 needs to belong to either the top area or the
> bottom area.  R1 or R7 needs to participate in two areas and leak routes
> between the two areas.
>
>
>
> Tony
>
>
>
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] 答复: LSR Working Group Adoption Call for "Hierarchical IS-IS" - draft-li-lsr-isis-hierarchical-isis-01

[Robert Raszuk]

Hi Tony,

> The hierarchical arrangement of the control plane does NOT imply that the
data plane is necessarily hierarchical.

Since Aijun posted his question I was trying to think of such model, but
failed.

While it is easy to envision this with DV protocols say BGP - do you have
any pointer to a link state protocol architecture where data plane is non
hierarchical (links do not belong to upper levels) while control plane used
traverses multiple levels ?

Thx,
R.

On Thu, Aug 15, 2019 at 4:40 PM  wrote:

>
> Hi Aijun,
>
> 1. The size of network is increasing, but it is becoming more flat. Is it
> the right direction to make the network more hierarchical?
>
>
>
> Well, given that we’re talking a link state protocol running SPF over a
> database in O(n log n) time, it’s pretty clear that we don’t want to scale
> the size of an area indefinitely. While modern processors are amazing
> (especially to those of us that started off with KHz 8080’s), it’s pretty
> clear that Moore’s law is over and that we cannot expect infinite compute
> power anytime in the future.  The alternative is to partition the network
> in some way.  Once partitioned, hierarchical arrangement seems like a
> natural fit. It’s been said that the only real tool that we have over scale
> is hierarchy.  Divide and conquer.
>
>
> 2. More hierarchical network means the traffic will also be traversed in
> hierarchical way, is it more efficient?
>
>
>
> The hierarchical arrangement of the control plane does NOT imply that the
> data plane is necessarily hierarchical.
>
>
> 3. Is there any other methods to scale out the IS-IS deployment?
>
>
>
> If you’ve been following along, Dynamic Flooding (
> https://tools.ietf.org/html/draft-ietf-lsr-dynamic-flooding-03) allows us
> to address the limitations that we have with flooding, allowing us to scale
> the size of an area. However, it does not address the O(n log n) cost of
> SPF that will still ultimately bound the growth of areas and in turn
> necessitate more hierarchy.
>
> Regards,
> Tony
>
>
> ___
> 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] LSR Working Group Adoption Call for "Hierarchical IS-IS" - draft-li-lsr-isis-hierarchical-isis-01

[Robert Raszuk]

Hi Huaimo,

Ad 1 - Let me observe that constructing hierarchy is not always driven by
number of nodes in a given level can safely support. One could indeed build
a global flat link state network in single level/area if only looking at
number of nodes. But in number of cases benefits from hierarchy could be
seen in reduced flooding radius and enforced summarization. Hint:  me why
my routers in Sydney have to be aware about link flap in POP in Toronto ?

Ad 6 - Interesting .. I asked the same question to authors offline :)

Thx,
R.




On Mon, Aug 19, 2019 at 4:27 PM Huaimo Chen 
wrote:

> Support and have the following comments:
>
>
>
>1. It seems not necessary to have 8 levels of hierarchies. 3 or at
>most 4 levels of hierarchies should be enough. IS-IS with 3 levels of
>hierarchies may support a network with 1k*1k*1k nodes, which is about 10^9
>= 1 billion nodes. IS-IS with 4 levels of hierarchies may support a network
>with 1k*1k*1k*1k nodes, which is about 10^12 = 1 trillion nodes.
>2. For PDU type, section 2.2 of the draft proposes to use 8 bits (all
>three reserved bits plus the 5 bits for the existing PDU type). It seems
>better to use 6 bits (one reserved bit plus the 5 bits for the existing PDU
>type). Adding one reserved bit into the PDU Type allows people to define 32
>new PDU types, which is enough for the new PDU types needed for new
>hierarchies.
>3. Section 3 “Additional PDUs” of the draft, defines 6 new PDU Types
>for ’Level n LAN IS to IS hello PDU’ (Ln-LAN-HELLO-PDU), where n is 3, 4,
>5, 6, 7, and 8. In addition, the following new PDU Types should be defined
>(considering at most 4 levels of hierarchies):
>   1. 2 new PDU Types for ‘’Level n LSP”, where n is 3, and 4
>   2. 2 new PDU Types for ‘’Level n CSNP”, where n is 3, and 4
>   3. 2 new PDU Types for ‘’Level n PSNP”, where n is 3, and 4
>4. On a broadcast interface, Level 1 LSPs are multicast through MAC
>0x0180.c200.0014 (which is called AllL1ISs), and Level 2 LSPs are multicast
>through MAC 0x0180.c200.0015 (which is called AllL2ISs). It seems that
>Level n LSPs should be multicast through AllLnISs, where n is 3, and 4
>(considering at most 4 levels of hierarchies), thus
>   1. 2 new MAC should be assigned to AllLnISs, where n is 3, and 4.
>5. The existing DIS for a broadcast interface periodically multicast
>through AllL1ISs and AllL2ISs a Complete SNP (CSNP). It seems that the DIS
>should be extended to periodically multicast a CSNP through AllLnISs, where
>n is 1, 2, 3, and 4 (considering at most 4 levels of hierarchies).
>6. When there may be 3 or more levels of hierarchies, is it allowed to
>have 3 or more levels (consecutive) configured on an interface? It seems
>that there is no description about this in the draft.
>
>
>
> Best Regards,
>
> Huaimo
>
>
>
> *From:* Lsr  *On Behalf Of *Acee Lindem (acee)
> *Sent:* Monday, August 12, 2019 10:33 AM
> *To:* lsr@ietf.org
> *Subject:* [Lsr] LSR Working Group Adoption Call for "Hierarchical IS-IS"
> - draft-li-lsr-isis-hierarchical-isis-01
>
>
>
> This begins a two week LSR Working Group Adoption Poll for the
> "Hierarchical IS-IS" - draft-li-lsr-isis-hierarchical-isis-01. The poll
> will end at 12:00 AM UTC on August 27th, 2019. Please indicate your
> support of objection on this list prior to the end of the adoption poll.
>
>
>
> Thanks,
>
> Acee
> ___
> 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] LSR Working Group Adoption Call for "Hierarchical IS-IS" - draft-li-lsr-isis-hierarchical-isis-01

[Robert Raszuk]

Support.

However assuming the draft will reach rough consensus of support I do
recommend to change the title during the conversion to WG document. ISIS is
already hierarchical today as even the abstract of the draft clearly says.

Thx,
R.

On Mon, Aug 12, 2019 at 11:57 PM Acee Lindem (acee)  wrote:

> This begins a two week LSR Working Group Adoption Poll for the
> "Hierarchical IS-IS" - draft-li-lsr-isis-hierarchical-isis-01. The poll
> will end at 12:00 AM UTC on August 27th, 2019. Please indicate your
> support of objection on this list prior to the end of the adoption poll.
>
>
>
> Thanks,
>
> Acee
> ___
> 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] Dynamic flow control for flooding

[Robert Raszuk]

Hi Tony,

Are you working on the assumption that there is no data link layer flow
control already which could signal the OS congestion on the receiving end ?

Are we also working on the assumptions that when ISIS PDUs are send in DCs
(unknown today case when out of the sudden 1000s of LSPs may need to get
flooded) use of some L4 fancy flow control is an overkill and we must
invent new essentially L2 flow control to cover this case to address
partition repair ?

Thx,
R.

On Tue, Jul 23, 2019 at 3:34 PM Tony Li  wrote:

>
> Hi all,
>
> I’d like to continue the discussion that we left off with last night.
>
> The use case that I posited was a situation where we had 1000 LSPs to
> flood. This is an interesting case that can happen if there was a large
> network that partitioned and has now healed.  All LSPs from the other side
> of the partition are going to need to be updated.
>
> Let’s further suppose that the LSPs have an average size of 1KB.  Thus,
> the entire transfer is around 1MB.
>
> Suppose that we’re doing this on a 400Gb/s link. If we were to transmit
> the whole batch of LSPs at once, it takes a whopping 20us.  Not
> milliseconds, microseconds.  2x10^-5s.  Clearly, we are not going to be
> rate limited by bandwidth.
>
> Note that 20us is an unreasonable lower bound: we cannot reasonably expect
> a node to absorb 1k PDUs back to back without loss today, in addition to
> all of it’s other responsibilities.
>
> At the opposite end of the spectrum, suppose we transmit one PDU every
> 33ms.  That’s then going to take us 33 seconds to complete. Unreasonably
> slow.
>
> How can we then maximize our goodput?  We know that the receiver has a set
> of buffers and a processing rate that it can support. The processing rate
> will vary, depending on other loads.
>
> What we would like the transmitter to do is to transmit enough to create a
> small processing queue on the receiver and then transmit at the receiver’s
> processing rate.
>
> Can we agree on this goal?
>
> Tony
>
> ___
> 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] Dynamic flow control for flooding

[Robert Raszuk]

Hi Tony,

> I am assuming that there is no link layer flow control.  I can’t recall
> working on a system that supports X.25 since about 1995, so I don’t think
> that’s a common use case today.
>

I was more thinking along the lines of leveraging IEEE 802.3x or 802.1Qbb
standard not necessarily suggest fancy X.25 or Frame Relay :)

 Henk proposed that we simply pick up TCP for this, but my concern with
> that is really about introducing a whole new dependency to the protocol.
> That’s a lot to chew.  Do we really need it all? I hope not.  Thus, Bruno’s
> original suggestion sparked my interest in doing something dynamic and
> simple.
>

The second part of the question was really about at what layer it makes
most sense to provide this control loop.

Options seems to be:

* Invent new or use existing link layer flow control (IEEE)
* Reuse existing transport layer (TCP)
* App layer (QUIC or QUIC like)

I guess it would be useful to up front list on what type of media this must
be supported as it may change the game drastically:

* directly connected fiber p2p
* p2mp (via switch)
* p2p over encapsulation
etc...

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

Re: [Lsr] Dynamic flow control for flooding

[Robert Raszuk]

Hey Henk & all,

If acks for 1000 LSPs take 16 PSNPs (max 66 per PSNP) or even as long as
Tony mentioned the full flooding as Tony said may take 33 sec - is this
really a problem ?

Remember we are not talking about protocol convergence after link flap or
node going down. We are talking about serious network partitioning which
itself may have lasted for minutes, hours or days. While just considering
absolute numbers yelds desire to go faster and faster, if we put things in
the overall perspective is there really a problem to be solved in the first
place ?

Would there still be a problem if LSR WG recommends faster acking maybe not
for each LSP but for say 20 or 30 max ?

Thx,
R.








On Wed, Jul 24, 2019 at 3:18 PM Henk Smit  wrote:

>
> Hello Les,
>
> Les Ginsberg (ginsberg) wrote on 2019-07-24 07:17:
>
> > If you accept that, then it makes sense to look for the simplest way
> > to do flow control and that is decidedly not from the RX side. (I
> > expect Tony Li to disagree with that  – but I have already
> > outlined why it is more complex to do it from the Rx side.)
>
> In your talk on Monday you called the idea in
> draft-decraene-lsr-isis-flooding-speed-01 "receiver driven flow
> control".
> You don't like that. You want "transmit based flow control".
> You argued that you can do "transmit based flow control" on the sender
> only.
> Therefor your algorithm is merely a "local trick".
> And "local tricks" don't need RFCs. I agree with that.
> But I don't agree that your algorithm is just a "local trick".
>
>
> In your algorithm, a "sender" sends a number of LSPs to a receiver.
> Without waiting for acks (PNSPs). Like in any sliding window protocol.
> The sending router keeps an eye on the number of unacked LSPs.
> And it determines how fast it can send more LSPs based on the current
> number of unacked LSPs. Every time the sender receives a PSNP, it
> knows the receiver got a number of LSPs, so it can increase its
> send-window again, and then send more LSPs.
> Correct ?
>
> I agree that the core idea of this algorithm makes sense.
> After all, it looks a lot like TCP.
> I believe the authors of draft-decraene-lsr-isis-flooding-speed were
> planning something like that for the next version of their draft.
>
>
> However, I do not agree with the name "tx driven flow control".
> I also do not agree that this algorithm is "a local trick".
> Therefor I also do not think this algorithm doesn't need to be
> documented (in an RFC).
>
> In your "tx based flow control", the sender (tx) sends LSPs at a rate
> that is derived from the rate at which it receives PSNPs. Therefor
> it is the sender of the PSNPs that sets the speed of transmission !
> So it is still the receiver (of LSPs) that controls the flow control.
> The name "tx based flow control" is a little misleading, imho.
>
>
> It is important to realize that the success of your algorithm actually
> depends on the behaviour of the receiver. How does it send PSNPs ?
> Does it send one PSNP per received LSP ? Or does it pack multiple acks
> in one PSNP ? Does it send a PSNP immediatly, or does it wait a short
> time ? Does it try to fill a PSNP to the max (putting ~90 acks in one
> PSNP) ? Does the receiver does something in between ? I don't think
> the behaviour is specified exactly anywhere.
>
> I know about an IS-IS implementation from the nineties. When a router
> would receive an LSP, it would a) set the SSN bit (for that
> LSP/interface),
> and b) start the psnp-timer for that interface (if not already running).
> The psnp-timer would expire 2 seconds later. The router would then walk
> the LSPDB, find all LSPs with the SSN-bit set for that interface. And
> then build a PSNP with acks for all those LSPs. The result would be
> that: a) the first PSNP would be send 2 seconds (+/- jitter) after
> receiving the first LSP, and b) the PSNP would include ~66 acks. (As
> a router receiving at full speed would have received 66 LSPs in 2
> seconds).
>
> For your "tx based flow control" algorithm to work properly, this has
> to change. The receiving router must send PSNPs more quickly and more
> aggressively. The result would be that there will be less acks in each
> PSNP. And thus more PSNPs will be sent.
>
> This makes us realize: in the current situation, if a router receives
> a 1000 LSPs, and sends those LSPs to 64 neighbors, it would receive:
> - the 1000 LSPs from an upstream neighbor, plus
> - 1000/66 = 16 PSNPs from each downstream neighbor = 64 * 16 = 1024
> PSNPs.
> This makes a total of ~2000K PDUs received.
>
> If routers would send one PSNP per LSP (to have faster flow control),
> then the router in this example would receive:
> - the 1000 LSPs from an upstream neighbor, plus
> - 1000 PSNPs from each downstream neighbor * 16 = 1600 PSNPs.
> This makes a total of ~17000 PDUs received.
>
> The total number of PDUs received on this router would go from 2K PDUs
> to 17K PDUs.
>
> Remember that the problem we're trying to solve here is to make sure
> 

Re: [Lsr] Dynamic flow control for flooding

[Robert Raszuk]

Hi,

Yes indeed while I was reading your richly connected node restart problem
use of overload-bit should be explored, proposed, implemented.

For the partition problem I have two general comments:

a) If network partitions is likely to happen more often in the case of
dynamic flooding perhaps as already said before we should increase the max
number of occurrences given LSP is to arrive at flooding optimized node.
Two may not be enough.

b)  If protocol extensions will help to mitigate effects of network
partition via much faster repair some folks may treat network partitions as
normal operational model and instead of re-architecting the network to make
sure network partition events are as rear as possible.

Thx,
R.

On Wed, Jul 24, 2019 at 4:12 PM Henk Smit  wrote:

>
> Hello Robert,
>
> Tony brought up the example of a partioned network.
> But there are more examples.
>
> E.g. in a network there is a router with a 1000 neighbors.
> (When discussing distributed vs centralized flooding-topology
>   reduction algorithms, I've been told these network designs exist).
> When such a router reboots/crashes/comes back up, all 1000 neighbors
> will create a new version of their own LSP. This causes a 1000 different
> LSPs to be flooded through the network at the same time. Impacting every
> router in the network.
>
> The case I was thinking of myself, was when a router in a large network
> boots. When it brings up a number of adjacencies, each neighbor will
> try to synchronize its LSPDB with the newly booted router. As the newly
> booted router will send emtpy CSNPs to each of its neighbors, each
> neighbor will start sending the full LSPDB. If such a network has 10k
> LSPs, and such a router has 100 neighbors, that router will receive 100
> * 10k
> is 1 million LSPs. Having a faster and more efficient flooding
> transport,
> with flow-control, will make a reboot in such a topology less painful.
>
> (In that last case, creative use of the overload-bit could prevent
> black-holing
> or microloops while ISIS synchronizes its LSPDB after a reboot. Just
> like we
> used the overload-bit to solve the problem of slow convergence of BGP
> after
> a reboot, 22 years ago. I have no idea if there are any implementations
> that
> use the overload-bit to alleviate slow convergence of IS-IS after a
> reboot).
>
> henk.
>
>
> Robert Raszuk schreef op 2019-07-24 15:33:
> > Hey Henk & all,
> >
> > If acks for 1000 LSPs take 16 PSNPs (max 66 per PSNP) or even as long
> > as Tony mentioned the full flooding as Tony said may take 33 sec - is
> > this really a problem ?
> >
> > Remember we are not talking about protocol convergence after link flap
> > or node going down. We are talking about serious network partitioning
> > which itself may have lasted for minutes, hours or days. While just
> > considering absolute numbers yelds desire to go faster and faster, if
> > we put things in the overall perspective is there really a problem to
> > be solved in the first place ?
> >
> > Would there still be a problem if LSR WG recommends faster acking
> > maybe not for each LSP but for say 20 or 30 max ?
> >
> > Thx,
> > R.
>
> ___
> 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] Dynamic flow control for flooding

[Robert Raszuk]

*[Les:] At the cost of convergence. Not a good tradeoff.*

Hi Les - why at the cost of convergence ? No one as I see it is proposing
the same rate to every peer. Quite contrary -- per peer rate of flooding.
So if you keep flooding high speed on fast links the convergence will not
be any slower with flow control.

Thx,
R.

On Wed, Jul 24, 2019 at 8:28 PM Les Ginsberg (ginsberg) 
wrote:

> Tony –
>
>
>
> Inline.
>
>
>
> *From:* Tony Li  *On Behalf Of *tony...@tony.li
> *Sent:* Tuesday, July 23, 2019 10:39 PM
> *To:* Les Ginsberg (ginsberg) 
> *Cc:* lsr@ietf.org
> *Subject:* Re: [Lsr] Dynamic flow control for flooding
>
>
>
>
>
>
>
> Les,
>
>
>
> I also think we all agree on the goal - which is to flood significantly
> faster than many implementations do today to handle deployments like the
> case you mention below.
>
>
>
>
>
> I agree with that, but you haven’t responded to the goal that I proposed:
> keep the receiver processing PDUs.
>
>
>
> *[Les:] My goals are:*
>
>
>
> *Optimize convergence.*
>
> *Minimize complexity.*
>
>
>
> *Optimizing the throughput through a slow receiver is pretty low on my
> list because the ROI is low.*
>
>
>
> Beyond this point, I have a different perspective.
>
>
>
> As network-wide convergence depends upon fast propagation of LSP changes –
> which in turn requires consistent flooding rates on all interfaces enabled
> for flooding – a properly provisioned network MUST be able to sustain a
> consistent flooding rate or the operation of the network will suffer. We
> therefore need to view flow control issues as indicative of a problem.
>
>
>
> It is a mistake to equate LSP flooding with a set of independent P2P
> “connections” – each of which can operate at a rate independent of the
> other.
>
>
>
> If we can agree on this, then I believe we will have placed the flow
> control problem in its proper perspective – in which case it will become
> easier to agree on the best way to implement flow control.
>
>
>
>
>
> I agree that we want network wide convergence.  However, I disagree that
> the right thing to do is to uniformly flood at the same rate on all
> interfaces.
>
>
>
> First, the rate that you select might be too fast for one neighbor and not
> for the others.  Real flow control would help address this.
>
>
>
> *[Les:] At the cost of convergence. Not a good tradeoff.*
>
> *I am arguing that we do want to flood at the same rate on all interfaces
> used for flooding. When we cannot, flow control does not help with
> convergence. It may decrease some wasted bandwidth – but as we all agree
> that bandwidth isn’t a significant limitation this isn’t a great concern.*
>
>
>
> *The same reasons that drive us to use same SPF delay and LSP Generation
> timers on all routers also apply to flooding rate.*
>
>
>
> Second, all flooding paths are not created equal.  You do not know, a
> priori, how to flood to get uniform network wide propagation.  The variance
> in CPU loading alone is going to cause different routers to flood at
> different rates, and so it may actaully be optimal to flood quickly down
> one path, knowing that the data will reach the other end of the network and
> flood back before the slow CPU can absorb and flood.
>
>
>
> *[Les:] I do not see how flow control improves things.*
>
> *If you have alternate flooding paths around the slow link(s) this argues
> more that you should not have the slow link in the flooding topology in the
> first place. But this heads off topic – I think we agree that dynamic
> flooding is a separate discussion which we don’t want to bring into this
> thread.*
>
>
>
> Dropping down to the least common denominator CPU speed in the entire
> network is going to be undoable without an oracle, and absurdly slow even
> with that.
>
>
>
> *[Les:] Never advocated that – please do not put those words in my mouth.*
>
>
>
> *   Les*
>
>
>
>
>
> Tony
>
>
> ___
> 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] [spring] IETF 106 - SPRING agenda

[Robert Raszuk]

*>   Once advertised in the network using a suitable link state protocol
>   (such as OSPF, ISIS or BGP-LS),*


Whow ... never imagined that BGP-LS would be called one day a "link
state protocol" and an equal sign would be made to OSPF and ISIS.


Best,
Robert.


PS. As to the proposal in draft itself it is clearly possible - but
then troubleshooting and operating such mixed network would be a
simple nightmare.



On Thu, Nov 7, 2019 at 3:25 AM Tarek Saad  wrote:

> Hi SPRING WG and Chairs,
>
>
>
> We would like to request a presentation time slot for
>
> - I-D: https://tools.ietf.org/html/draft-saad-sr-fa-link-00
>
> - Speaker: Tarek Saad
>
> - Desired time: 10 minutes
>
>
>
> Regards,
>
> Tarek
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

[Robert Raszuk]

Hi Les,

Yes this "small delay" of ACK aggregation is something which I am a bit
worried here from SNPs sender side.

Now as indeed draft mentioned prioritizing SNPs on reception let me
indicate that some platforms I have not so long ago dealt with do not even
prioritize any IGP packet over other packets at neither ingress LC nor
queue to RE/RP. If that channel takes 100s of ms within the box I am
afraid all bets for flooding improvement are off.

Thx
R,.


On Wed, Feb 19, 2020 at 6:48 PM Les Ginsberg (ginsberg) 
wrote:

> Robert –
>
>
>
> Thanx for your input.
>
>
>
> Note that one of the suggestions in
> https://datatracker.ietf.org/doc/draft-ginsberg-lsr-isis-flooding-scale/
>  is to prioritize the reception of SNPs over LSPs so that we are less
> likely to drop ACKs.
>
> It is not clear to me why you think SNP generation would be an issue.
>
> Once a received LSP is processed one of the outputs is to set a per
> interface flag indicating that an ACK (PSNP) needs to be sent (SSN flag).
> Implementations usually implement some small delay so that multiple ACKs
> can be sent in a single PSNP – but I do not see why this should be viewed
> as a bottleneck.
>
>
>
> If your concern is that we need to emphasize the importance of sending
> timely ACKs, I think we could look at text that makes that point.
>
>
>
>Les
>
>
>
>
>
> *From:* Lsr  *On Behalf Of * Robert Raszuk
> *Sent:* Wednesday, February 19, 2020 1:07 AM
> *To:* Les Ginsberg (ginsberg) 
> *Cc:* lsr@ietf.org
> *Subject:* Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed
>
>
>
> Hi Les & all,
>
>
>
> Watching this discussion I would like to state that IMO going with
> transmitter based rate limiting (I would not call it flow control) is much
> easier option to deploy and operate. It also has no dependency across other
> side of p2p adj which is a very important factor. The only issue here is if
> generation of [P|C]SNPs is fast enough.
>
>
>
> Receiver based flow control is simple in flow theory however I have a
> feeling that if we are to go that path we would be much better to actually
> run ISIS flooding over DC-TCP and avoid reinventing the wheel.
>
>
>
> Thx,
>
> Robert.
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Methods to label the passive interfaces within ISIS

[Robert Raszuk]

Hi Tony,

I agree with you that essentially this is a link property (hence my earlier
hint towards 5029) so it makes it at least two of us recommending direction
towards 5029 now ;)

While we are at this perhaps it would be also useful to be able to
differentiate reachability on stub links vs virtual local interfaces. Today
in some implementations they are advertised after marking them as passive
int.

Thx
R.


On Fri, Jan 10, 2020, 08:26  wrote:

>
> Hi Aijun,
>
>
> For the link attributes that defined in RFC5029, as that stated in
> https://tools.ietf.org/html/rfc5029#section-2, this sub-TLV is included
> in the TLV 22(Extended IS Reachability).
> As I read the IANA code point
> https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-22-23-25-141-222-223
> , it notes this sub-TLV can be included in all of these TLVs
> (22,23,25,141,222,223).
>
> But, when the interface is configured as passive/stub, it seems that the
> above TLVs will not be advertised, because there is no IS neighbor on this
> passive link.
>
>
>
> Fair point. Given that there is an IP address and prefix on that link, it
> would be very reasonable to advertise the Extended IP Reachability TLV
> (135). We would then need to make the link attributes sub-TLV applicable to
> this TLV (and it’s MT brother).
>
>
> TLV 141 “Inter-AS reachability information” seems be one appropriate TLV
> to include this sub-TLV, but it requires the IS-IS TE deployment, and is
> not suitable for describing the passive/stub link on edge router.
>
> In summary, it seems put this attribute into the “Prefix Attribute Flags”
> sub-TLV which can be included in TLV 135,235,236 and 237 (Extended IP
> reachability, MT IP. Reach, IPv6 IP. Reach, and MT IPv6 IP. Reach TLVs) is
> more applicable?
>
>
>
> It would seem to me that what you’re describing is an attribute of a link,
> not of a prefix, thus I would favor it remaining a link attribute.
>
> But that’s just me.  :-)
>
> Tony
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] 答复: Is it necessary to expand the IS-IS level to 8?

[Robert Raszuk]

Aijun,


> We just want to distinguish the passive interfaces from other normal
> interfaces within ISIS domain.  It seems that the “Attribute Flags” that
> described in https://tools.ietf.org/html/rfc7794#section-2.1 is the most
> appropriate place to extend to carry such information.
>

Really ?

IMO much better place is to define new sub-TLV of TLV-22 and mark it there
as passive link.

Ref: https://tools.ietf.org/html/rfc5029

Now more interesting perhaps is to find out how ISIS is supposed to react
to such information. Or is the intention to carry it just as an opaque info
say for show commands use only ?

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

Re: [Lsr] Methods to label the passive interfaces within ISIS

[Robert Raszuk]

Hi Aijun,

Right .. I took your email as an attempt/request to actually advertise
passive links in the first place.

May we know what difference does it make to you if reachable prefix is part
of an active vs passive interface from IGP point of view ?

Thx,
R.


On Tue, Jan 7, 2020 at 2:08 AM Aijun Wang  wrote:

> Hi, Robert:
>
>
>
> Thanks for your information.
>
> TLV-22 is used to describe the IS neighbor and the link between them. As
> for the passive interfaces, there may be no neighbor.
>
> It seems the sub-TLV within this TLV is not the appropriate place to put
> this information?
>
>
>
> P.S. I changed the thread to reflect the conversion topic.
>
>
>
> Best Regards.
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> *发件人:* lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] *代表 *Robert
> Raszuk
> *发送时间:* 2020年1月6日 18:58
> *收件人:* Aijun Wang
> *抄送:* Les Ginsberg (ginsberg); lsr@ietf.org
> *主题:* Re: [Lsr] 答复: Is it necessary to expand the IS-IS level to 8?
>
>
>
> Aijun,
>
>
>
> We just want to distinguish the passive interfaces from other normal
> interfaces within ISIS domain.  It seems that the “Attribute Flags” that
> described in https://tools.ietf.org/html/rfc7794#section-2.1 is the most
> appropriate place to extend to carry such information.
>
>
>
> Really ?
>
>
>
> IMO much better place is to define new sub-TLV of TLV-22 and mark it there
> as passive link.
>
>
>
> Ref: https://tools..ietf.org/html/rfc5029
> <https://tools.ietf.org/html/rfc5029>
>
>
>
> Now more interesting perhaps is to find out how ISIS is supposed to react
> to such information. Or is the intention to carry it just as an opaque info
> say for show commands use only ?
>
>
>
> Thx,
> R.
>
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02

[Robert Raszuk]

Hi Les,

Ok very well.

So till this draft provides a text or reference to some other document how
IGPs may use inband telemetry data for real path selection it does not fit
to LSR charter. Fair.

Hi Chris,

I am afraid we are looking at this from completely different perspectives.

I consider this data to be a necessity for routing and you simply treat it
as some opaque telemetry. If we would think of it in the latter sense sure
you would be right. IGP is not a configuration push protocol. Sufficient to
observe how BGP became one :)

Many thx,
R.


On Thu, Apr 2, 2020 at 8:46 AM Les Ginsberg (ginsberg) 
wrote:

> Robert -
>
> First, +1 to what Chris has said.
>
> There is nothing in the lfit-capability draft that defines any information
> that can be used by IGPs to do what you suggest.
> Perhaps it is possible that information gleaned via a telemetry
> application could be used by the IGPs to do something like what you suggest
> - but this draft is not discussing/defining that. It is simply proposing to
> advertise information about the capabilities of the lfit application on a
> given node.
>
>Les
>
> > -Original Message-
> > From: Christian Hopps 
> > Sent: Thursday, April 02, 2020 5:13 AM
> > To: Robert Raszuk 
> > Cc: Christian Hopps ; Les Ginsberg (ginsberg)
> > ; wangyali ; Acee Lindem
> > (acee) ; lsr@ietf.org; Tianran Zhou
> > 
> > Subject: Re: [Lsr] A new version of I-D,
> draft-liu-lsr-isis-ifit-node-capability-02
> >
> > We have defined a perfectly acceptable and quite powerful way to do query
> > and configuration for routers, it's YANG. I'd like to hear why the the
> IETF
> > standard mechanism for query and configuration can't work for this
> > application.
> >
> > Telemetry is important, I don't think anyone has said or would say that
> it isn't,
> > but that seems orthogonal to this discussion.
> >
> > Thanks,
> > Chris.
> > [as WG member]
> >
> >
> > > On Apr 2, 2020, at 5:17 AM, Robert Raszuk  wrote:
> > >
> > > Hi Les,
> > >
> > > I would like to respectfully disagree with your assessment.
> > >
> > > The fact that today's IGP (or for that matter BGP) routing is static
> from the
> > perspective of not taking into consideration real performance
> measurements
> > from the data plane to me is a bug not a feature.
> > >
> > > Building SPT based on static link metrics which in vast majority of
> cases
> > today are emulated circuits on someone else IP backbone. It was a great
> idea
> > when you constructed the network with connection oriented paradigm
> > (Sonet,SDH, dark fiber, TDM ...) not connection less often best effort
> one.
> > >
> > > So I find this proposal very useful and would vote for adopting it in
> LSR WG.
> > To me in-situ telemetry is not just some monitoring tool. It is an
> extremely
> > important element to influence how we compute reachability or at least
> how
> > we choose active forwarding paths from protocol RIBs to main RIB.
> > >
> > > If we extended IGPs to carry TE information, if we extended them to
> > enable flexible algorithm based path computation I fail to understand why
> > would we resist to natively enable all of the above with getting the
> inputs
> > from real networks to be used as to the parameters to the above mentioned
> > tools.
> > >
> > > Kind regards,
> > > R.
> > >
> > > On Thu, Apr 2, 2020 at 8:32 AM Les Ginsberg (ginsberg)
> >  wrote:
> > > Yali -
> > >
> > > There is a very significant difference between having IGPs advertise an
> > identifier for a service that they use as clients (BFD) and having IGPs
> > advertise a set of capabilities/options for a telemetry application
> which has
> > no direct bearing on the function of the routing protocol.
> > >
> > > You are not the first to find using IGPs to flood application
> information very
> > convenient.  But this is not the appropriate role for the IGPs and over
> the
> > years we have consistently resisted attempts to do so.
> > >
> > > Everything advertised in Router Capabilities today has some close
> > relationship with the operation of the protocol. Do some of the existing
> > advertisements "bend the rules" a bit more than I would prefer? Yes - but
> > there has always been at least a close relationship to routing protocol
> > function.
> > > Here there is none.
> > >
> > > If you feel compelled to use IGPs to advertise application
> information, you
>

Re: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02

[Robert Raszuk]

Jeff.

> The role of a routing protocol is to distribute: reachability (doh :-))
> *and any additional data that could influence routing decision wrt
reachability.  *

The bolded text is precisely the point here.

So let me provide a very simple example.

Today routers already compute CSPF. Moreover today routers are asked to use
custom/flexible algorithm to choose reachability paths.

So just imagine an operator who says:

Please compute my SPT with the consideration that end to end inband jitter
is not greater then 10 ms otherwise I do not want to see nodes which do not
meet that criteria in the reachability graph for application X.

or

Please compute my SPT with the consideration that end to end drop rate is
not greater then  5pps otherwise I do not want to see nodes which do not
meet that criteria in the reachability graph for application Y.

etc ...

If you consider such constrains to provide reachability for applications
you will likely see value that in-situ telemetry is your friend here.
Really best friend as without him you can not do the proper end to end path
exclusion for SPT computations.

Hint: All per link extensions which were added to IGPs are not going to
help here as drops or jitter may equally happen in the routers fabric on
fabric to LC boundaries or on the line cards and links. So you need end to
end test stream.

Many thx,
R.

PS. As we are talking LSR here it is strange that joining virtual LSR
meeting is not for everyone. I was waiting and tried three times today for
host approval to join which was not granted.

On Thu, Apr 2, 2020 at 11:00 PM Jeff Tantsura 
wrote:

> Robert,
>
> This is unnecessary leakage of management plane into control plane.
> The role of a routing protocol is to distribute: reachability (doh :-))
> and any additional data that could influence routing decision wrt
> reachability.
> There are precedences of using IGP’s for different tasks, e.g. RFC 5088
> and similar, however should we do it again?
>
> Specifically to use case described - I really don’t see how this
> information would be used in routing decisions (PCE computation). Moreover,
> if the end-goal is to build a connected graph of the devices that have a
> coherent iFIT feature set it would require reoptimization on every change
> and quite complex computation logic (talking SR - on top of regular
> constrains, MSD, etc).I’d also think that there’s mandatory configuration
> of name-spaces and features supported, in other words - autodiscovery is
> meaningless, it would still require as per device configuration (hello
> YANG). Most of telemetry solutions are designed to pass thought nodes that
> don’t support it transparently, so the real requirement is really to know
> the sink-node (the one that is egress of the telemetry domain and must
> remove all additional encapsulations).
>
> As to the last point - we already have a kitchen-sink routing protocol  ;-)
>
> Cheers,
> Jeff
> On Apr 2, 2020, 6:10 AM -0700, Robert Raszuk , wrote:
>
>
> Hi Les,
>
> Ok very well.
>
> So till this draft provides a text or reference to some other document how
> IGPs may use inband telemetry data for real path selection it does not fit
> to LSR charter. Fair.
>
> Hi Chris,
>
> I am afraid we are looking at this from completely different perspectives..
>
> I consider this data to be a necessity for routing and you simply treat it
> as some opaque telemetry. If we would think of it in the latter sense sure
> you would be right. IGP is not a configuration push protocol. Sufficient to
> observe how BGP became one :)
>
> Many thx,
> R.
>
>
> On Thu, Apr 2, 2020 at 8:46 AM Les Ginsberg (ginsberg) 
> wrote:
>
>> Robert -
>>
>> First, +1 to what Chris has said.
>>
>> There is nothing in the lfit-capability draft that defines any
>> information that can be used by IGPs to do what you suggest.
>> Perhaps it is possible that information gleaned via a telemetry
>> application could be used by the IGPs to do something like what you suggest
>> - but this draft is not discussing/defining that. It is simply proposing to
>> advertise information about the capabilities of the lfit application on a
>> given node..
>>
>>Les
>>
>> > -Original Message-
>> > From: Christian Hopps 
>> > Sent: Thursday, April 02, 2020 5:13 AM
>> > To: Robert Raszuk 
>> > Cc: Christian Hopps ; Les Ginsberg (ginsberg)
>> > ; wangyali ; Acee Lindem
>> > (acee) ; l...@ietf..org ; Tianran Zhou
>> > 
>> > Subject: Re: [Lsr] A new version of I-D,
>> draft-liu-lsr-isis-ifit-node-capability-02
>> >
>> > We have defined a perfectly acceptable and quite powerful way to do
>> query
>>

Re: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02

[Robert Raszuk]

Hi Joel,

> Robert, you seem to be asking that we pass full information about the
> dynamic network state to all routers

No not at all.

Only TE headends need this information.

To restate ... I am not asking to have a synchronized input to all routes
in the domain such that their computation would be consistent.

I am only asking for TE headends to be able to select end to end paths
based on the end to end inband telemetry data. I find this a useful
requirement missing from any of today's operational deployments.

Many thx,
R.






On Fri, Apr 3, 2020 at 12:59 AM Joel M. Halpern  wrote:

> Robert, you seem to be asking that we pass full information about the
> dynamic network state to all routers so that they can, if needed, serve
> as fully intelligent path computation engines.  If you want to do that,
> you will need more than just the telemetry.  You will need the demands
> that are coming in to all of those routers, so that you can make global
> decisions sensibly.
> Which is why we use quasi-centralized path computation engines.
>
> Yours,
> Joel
>
> On 4/2/2020 6:16 PM, Robert Raszuk wrote:
> >
> >  > If you consider such constrains to provide reachability for
> > applications you will likely see value that in-situ telemetry is
> > your friend here. Really best friend as without him you can not do
> > the proper end to end path exclusion for SPT computations..
> >
> > [as wg member] Are you thinking that shifting traffic to a router is
> > not going to affect it's jitter/drop rate?
> >
> >
> > Well this is actually the other way around.
> >
> > First you have your default topology. They you are asked to
> > construct new one based on applied constrains.
> >
> > So you create complete TE coverage and start running end to end data
> > plane probing over all TE paths (say SR-TE for specific example). Once
> > you start collecting the probe results you can start excluding paths
> > which do not meet your applied constraints. And that process continues.
> >
> > To your specific question - It is not that unusual where routers degrade
> > their performance with time and in many cases the traffic is not the
> > cause for it but internal bugs and malfunctions.
> >
> > Best,
> > R.
> >
> > ___
> > 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] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02

[Robert Raszuk]

> > If you consider such constrains to provide reachability for applications
> you will likely see value that in-situ telemetry is your friend here.
> Really best friend as without him you can not do the proper end to end path
> exclusion for SPT computations.
>
> [as wg member] Are you thinking that shifting traffic to a router is not
> going to affect it's jitter/drop rate?
>

Well this is actually the other way around.

First you have your default topology. They you are asked to construct new
one based on applied constrains.

So you create complete TE coverage and start running end to end data plane
probing over all TE paths (say SR-TE for specific example). Once you start
collecting the probe results you can start excluding paths which do not
meet your applied constraints. And that process continues.

To your specific question - It is not that unusual where routers degrade
their performance with time and in many cases the traffic is not the cause
for it but internal bugs and malfunctions.

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

Re: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02

[Robert Raszuk]

> collected only on active paths

Here we clearly diverge :)

The notion of default active paths in my view represents many more
alternative paths constructed based on the default topology while cspf or
flex algo products may consist only of subset of those per applied
constraints.

Thx,
Robert


On Fri, Apr 3, 2020 at 1:13 AM Greg Mirsky  wrote:

> And another note regarding the use of on-path collected telemetry
> information. I'd point that that information is collected only on active
> paths. Thus it characterizes the conditions experienced by already existing
> flows. Hence it might not be related to a path that the system intends to
> instantiate. One needs active OAM to collect such information.
>
> Regards,
> Greg
>
> On Thu, Apr 2, 2020 at 4:08 PM Greg Mirsky  wrote:
>
>> Hi Robert,
>> I think that there's no apparent requirement to collect performance
>> information form each node in the network in order to select a path with
>> bounded delay and packet loss. Would you agree?
>>
>> Regards,
>> Greg
>>
>> On Thu, Apr 2, 2020 at 4:03 PM Robert Raszuk  wrote:
>>
>>> Hi Joel,
>>>
>>> > Robert, you seem to be asking that we pass full information about the
>>> > dynamic network state to all routers
>>>
>>> No not at all.
>>>
>>> Only TE headends need this information.
>>>
>>> To restate ... I am not asking to have a synchronized input to all
>>> routes in the domain such that their computation would be consistent.
>>>
>>> I am only asking for TE headends to be able to select end to end paths
>>> based on the end to end inband telemetry data. I find this a useful
>>> requirement missing from any of today's operational deployments.
>>>
>>> Many thx,
>>> R.
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Fri, Apr 3, 2020 at 12:59 AM Joel M. Halpern 
>>> wrote:
>>>
>>>> Robert, you seem to be asking that we pass full information about the
>>>> dynamic network state to all routers so that they can, if needed, serve
>>>> as fully intelligent path computation engines.  If you want to do that,
>>>> you will need more than just the telemetry.  You will need the demands
>>>> that are coming in to all of those routers, so that you can make global
>>>> decisions sensibly.
>>>> Which is why we use quasi-centralized path computation engines.
>>>>
>>>> Yours,
>>>> Joel
>>>>
>>>> On 4/2/2020 6:16 PM, Robert Raszuk wrote:
>>>> >
>>>> >  > If you consider such constrains to provide reachability for
>>>> > applications you will likely see value that in-situ telemetry is
>>>> > your friend here. Really best friend as without him you can not do
>>>> > the proper end to end path exclusion for SPT computations..
>>>> >
>>>> > [as wg member] Are you thinking that shifting traffic to a router
>>>> is
>>>> > not going to affect it's jitter/drop rate?
>>>> >
>>>> >
>>>> > Well this is actually the other way around.
>>>> >
>>>> > First you have your default topology. They you are asked to
>>>> > construct new one based on applied constrains.
>>>> >
>>>> > So you create complete TE coverage and start running end to end data
>>>> > plane probing over all TE paths (say SR-TE for specific example).
>>>> Once
>>>> > you start collecting the probe results you can start excluding paths
>>>> > which do not meet your applied constraints. And that process
>>>> continues..
>>>> >
>>>> > To your specific question - It is not that unusual where routers
>>>> degrade
>>>> > their performance with time and in many cases the traffic is not the
>>>> > cause for it but internal bugs and malfunctions.
>>>> >
>>>> > Best,
>>>> > R.
>>>> >
>>>> > ___
>>>> > 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] problem joining interim [Re: A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02]

[Robert Raszuk]

Hi Chris,

I never noticed the password ...

Just few days back I participated in IDR and no password was needed or
perhaps webex invite link contained a token relaxing from needing one.

Cheers,
R.

On Fri, Apr 3, 2020 at 12:00 AM Christian Hopps  wrote:

>
>
> > On Apr 2, 2020, at 5:17 PM, Robert Raszuk  wrote:
> >
> > Many thx,
> > R.
> >
> > PS. As we are talking LSR here it is strange that joining virtual LSR
> meeting is not for everyone. I was waiting and tried three times today for
> host approval to join which was not granted.
> >
>
> I am very sorry to hear this! We had 64 participants, at least at one
> point that I saw. I set the meeting up, and I don't believe there is any
> way to exclude anyone in particular, I certainly would never have chosen to
> do that.
>
> However, Webex has a password requirement when setting up meetings (I
> guess, I tried to not have one, it wouldn't let me) which we included in
> all the details wherever the details were posted, it was "linkstate".
>
> I did notice an email, from webex, during the meeting about a request from
> Bruno to join as guest, but he was in the participant list when I then
> checked. I didn't receive any other emails like that (and FWIW I had 5
> windows over 2 monitors going at once trying to manage all this, so
> noticing the 1 email was lucky).
>
> Did it let you skip entering a password (or did it not offer the option in
> the first place)?
>
> It would be good to figure this out before the next interim.
>
> Thanks,
> Chris.
>
> ___
> 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] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02

[Robert Raszuk]

> "collected only on active paths" is not something I propose but is the
property of on-path
> telemetry collection method.

That is all fine. The point is that the notion of active paths in the
network may represent those in default topology over any path. That can be
computed by PCE.

So default topology may have N active paths while
application specific topologies M where M is a subset of N meeting required
end to end constraints.

Sure it is possible to discover if my tailends are capable of handling in
band telemetry by off line means. But what I am struggling to see why we
allowed so much TE stuff into IGPs and we do not want to make it easier for
headends to operate without PCE at all for the purpose of delivering
such type of services.

Kind regards,
R.

On Fri, Apr 3, 2020 at 1:22 AM Greg Mirsky  wrote:

> Hi Robert,
> "collected only on active paths" is not something I propose but is the
> property of on-path telemetry collection method.
>
> Regards,
> Greg
>
> On Thu, Apr 2, 2020 at 4:16 PM Robert Raszuk  wrote:
>
>> > collected only on active paths
>>
>> Here we clearly diverge :)
>>
>> The notion of default active paths in my view represents many more
>> alternative paths constructed based on the default topology while cspf or
>> flex algo products may consist only of subset of those per applied
>> constraints.
>>
>> Thx,
>> Robert
>>
>>
>> On Fri, Apr 3, 2020 at 1:13 AM Greg Mirsky  wrote:
>>
>>> And another note regarding the use of on-path collected telemetry
>>> information. I'd point that that information is collected only on active
>>> paths. Thus it characterizes the conditions experienced by already existing
>>> flows. Hence it might not be related to a path that the system intends to
>>> instantiate. One needs active OAM to collect such information.
>>>
>>> Regards,
>>> Greg
>>>
>>> On Thu, Apr 2, 2020 at 4:08 PM Greg Mirsky 
>>> wrote:
>>>
>>>> Hi Robert,
>>>> I think that there's no apparent requirement to collect performance
>>>> information form each node in the network in order to select a path with
>>>> bounded delay and packet loss. Would you agree?
>>>>
>>>> Regards,
>>>> Greg
>>>>
>>>> On Thu, Apr 2, 2020 at 4:03 PM Robert Raszuk  wrote:
>>>>
>>>>> Hi Joel,
>>>>>
>>>>> > Robert, you seem to be asking that we pass full information about the
>>>>> > dynamic network state to all routers
>>>>>
>>>>> No not at all.
>>>>>
>>>>> Only TE headends need this information.
>>>>>
>>>>> To restate ... I am not asking to have a synchronized input to all
>>>>> routes in the domain such that their computation would be consistent.
>>>>>
>>>>> I am only asking for TE headends to be able to select end to end paths
>>>>> based on the end to end inband telemetry data. I find this a useful
>>>>> requirement missing from any of today's operational deployments.
>>>>>
>>>>> Many thx,
>>>>> R.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Apr 3, 2020 at 12:59 AM Joel M. Halpern 
>>>>> wrote:
>>>>>
>>>>>> Robert, you seem to be asking that we pass full information about the
>>>>>> dynamic network state to all routers so that they can, if needed,
>>>>>> serve
>>>>>> as fully intelligent path computation engines.  If you want to do
>>>>>> that,
>>>>>> you will need more than just the telemetry.  You will need the
>>>>>> demands
>>>>>> that are coming in to all of those routers, so that you can make
>>>>>> global
>>>>>> decisions sensibly.
>>>>>> Which is why we use quasi-centralized path computation engines.
>>>>>>
>>>>>> Yours,
>>>>>> Joel
>>>>>>
>>>>>> On 4/2/2020 6:16 PM, Robert Raszuk wrote:
>>>>>> >
>>>>>> >  > If you consider such constrains to provide reachability for
>>>>>> > applications you will likely see value that in-situ telemetry is
>>>>>> > your friend here. Really best friend as without him you can not
>>>>>> do

Re: [Lsr] problem joining interim [Re: A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02]

[Robert Raszuk]

Well I did not knock (notify the host and politely ask to join) as I
assumed IETF WG meeting doors should be open. I figured maybe host just
does not like me to join the party :-)

I think my mistake was that I did not expect password to be needed. Learned
something new then !

Cheers,
R.

On Fri, Apr 3, 2020 at 12:22 AM Acee Lindem (acee)  wrote:

> As host of the meeting, I didn’t see any indication that you were waiting
> in the lobby.
>
> Thanks,
>
> Acee
>
>
>
> *From: *Robert Raszuk 
> *Date: *Thursday, April 2, 2020 at 6:10 PM
> *To: *Christian Hopps 
> *Cc: *"Les Ginsberg (ginsberg)" , "lsr@ietf.org" <
> lsr@ietf.org>, Jeff Tantsura , Tianran Zhou <
> zhoutian...@huawei.com>, Acee Lindem , wangyali <
> wangyal...@huawei.com>
> *Subject: *Re: [Lsr] problem joining interim [Re: A new version of I-D,
> draft-liu-lsr-isis-ifit-node-capability-02]
>
>
>
> Hi Chris,
>
>
>
> I never noticed the password ...
>
>
>
> Just few days back I participated in IDR and no password was needed or
> perhaps webex invite link contained a token relaxing from needing one.
>
>
>
> Cheers,
> R.
>
>
>
> On Fri, Apr 3, 2020 at 12:00 AM Christian Hopps  wrote:
>
>
>
> > On Apr 2, 2020, at 5:17 PM, Robert Raszuk  wrote:
> >
> > Many thx,
> > R.
> >
> > PS. As we are talking LSR here it is strange that joining virtual LSR
> meeting is not for everyone. I was waiting and tried three times today for
> host approval to join which was not granted.
> >
>
> I am very sorry to hear this! We had 64 participants, at least at one
> point that I saw. I set the meeting up, and I don't believe there is any
> way to exclude anyone in particular, I certainly would never have chosen to
> do that.
>
> However, Webex has a password requirement when setting up meetings (I
> guess, I tried to not have one, it wouldn't let me) which we included in
> all the details wherever the details were posted, it was "linkstate".
>
> I did notice an email, from webex, during the meeting about a request from
> Bruno to join as guest, but he was in the participant list when I then
> checked. I didn't receive any other emails like that (and FWIW I had 5
> windows over 2 monitors going at once trying to manage all this, so
> noticing the 1 email was lucky).
>
> Did it let you skip entering a password (or did it not offer the option in
> the first place)?
>
> It would be good to figure this out before the next interim.
>
> Thanks,
> Chris.
>
> ___
> 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] problem joining interim [Re: A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02]

[Robert Raszuk]

Ahh for the record I used that URL yesterday:

An email from the IESG secretary was sent on 2020-03-19, saying
"Information about remote participation: https://ietf.webex.com/meet/lsr "

On Fri, Apr 3, 2020 at 12:14 PM  wrote:

> Chris,
>
> Please see inline.
>
>
> > From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps
> > Sent: Friday, April 3, 2020 12:00 AM
> > To: Robert Raszuk
> >
> >
> >
> > > On Apr 2, 2020, at 5:17 PM, Robert Raszuk  wrote:
> > >
> > > Many thx,
> > > R.
> > >
> > > PS. As we are talking LSR here it is strange that joining virtual LSR
> meeting is not for everyone. I was waiting and tried three times today for
> host approval to join which was not granted.
> > >
> >
> > I am very sorry to hear this! We had 64 participants, at least at one
> point that I saw. I set the meeting up, and I don't believe there is any
> way to exclude anyone in particular, I certainly would never have chosen to
> do that.
> >
> > However, Webex has a password requirement when setting up meetings (I
> guess, I tried to not have one, it wouldn't let me) which we included in
> all the details wherever the details were posted, it was "linkstate".
> >
> > I did notice an email, from webex, during the meeting about a request
> from Bruno to join as guest, but he was in the participant list when I then
> checked.
> >
>
> So may be my experience may help for next time(s). See below.
>
> An email from the IESG secretary was sent on 2020-03-19, saying
> "Information about remote participation: https://ietf.webex.com/meet/lsr "
> Hence I used that URL.
> On this webex, the meeting did not start on time so I've waited for some
> time. Then 10-15 minutes past the start, I decided to 'notify the host',
> but never got accepted on the webex.
> At that point I assumed a technical issue with webex and monitored the
> mailing list, but no one was complaining, which is not inline with typical
> IETF reaction ;-) .
> So I assumed the error was only on my side and I searched for more emails
> and found one from Chris (2020-03-31) saying that the URL was
> https://ietf.webex.com/ietf/j.php?MTID=mbef20efa9e66c7e97f9d6b18ea84eca8
> And this one worked fine.
> My guess is that the 'interim' webex did not use the 'lsr' webex. Also the
> 'official' notification from the IESG secretary with the incorrect webex
> URL did not helped.
>
> --Bruno
>
> > I didn't receive any other emails like that (and FWIW I had 5 windows
> over 2 monitors going at once trying to manage all this, so noticing the 1
> email was lucky).
> >
> > Did it let you skip entering a password (or did it not offer the option
> in the first place)?
> >
> > It would be good to figure this out before the next interim.
> >
> > Thanks,
> > Chris.
> >
> > ___
> > Lsr mailing list
> > Lsr@ietf.org
> > https://www.ietf.org/mailman/listinfo/lsr
>
>
> _
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and
> delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02

[Robert Raszuk]

Hi Tony,

I think there is still some disconnect - so in an attempt to at least make
sure that we have difference of opinions let me try to restate what I was
suggesting.

IGP would only carry indication if tail can do inband telemetry or not - it
would *not* carry any telemetry data. IGP would not be running telemetry -
it will be just consumer of other subsystem product.
https://tools.ietf.org/html/draft-wang-lsr-ifit-node-capability-advertisement-00
just signals capability. It does not even have a trunk for any type of dump
:)

Global optimization makes a lot of sense for traffic spread across given
network - 100%. But it is not the best place to only select if one path is
eligible and the other is not in given topology. That decision should
happen on the headends and should be as much distributed as possible. And
the data here as input to the decision is only valid on specific headend
probes depart from. Besides it has usually a very short life.

Even if we move cspf to historic just very recently flexible algorithm was
proposed and I think is progressing fine. So my examples of use cases to
choose paths with min drops or bound jitter are real.

Hi Jeff,

If I look at one of the in situ data plane proposals it does send the
results to the sender/originator vs some
collector. draft-lapukhov-dataplane-probe-01 This is besides the point of
this discussion as we are not asking for IGP to carry the results. Hint:
Each headend can be a collector or nothing breaks in the design if headend
get's this data out of band from central collector.

Thx,
R.


On Fri, Apr 3, 2020 at 1:43 AM  wrote:

>
> Sure it is possible to discover if my tailends are capable of handling in
> band telemetry by off line means. But what I am struggling to see why we
> allowed so much TE stuff into IGPs and we do not want to make it easier for
> headends to operate without PCE at all for the purpose of delivering
> such type of services.
>
>
>
> AFAICT, we put a lot of effort into making headend path computation useful
> and, for the most part, it was and is not necessary.
>
> Even with legacy mechanisms, people decided that they need global
> optimization and that head-end path computation was Not That Interesting.
>
> It’s now 20 years later, the network is even more dynamic, the
> expectations about response time are that much higher, and concerns about
> link state database stability and scalability have increased.  Modern
> telemetry is definitely not suitable to be passed in the IGP anymore.
>
> Thus, it seems like the IGP can provide base topology information and
> traffic engineering constructs should leverage that and provide an
> independent telemetry collection plane. Within that plane, telemetry
> capabilities can and should be confined to the telemetry plane.
>
> As we’ve said many times before: BGP is not a dump truck. Analogously, the
> IGP isn’t even an SUV.
>
> ;-)
>
> Regards,
> Tony
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing basedVirtual Transport Network

[Robert Raszuk]

Hi,

Out of pure curiosity here - how are you going to stop any other traffic
(SR or non SR) to take as much as it likes of any link being part of the
default topology ?

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

Re: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02

[Robert Raszuk]

Hi Les,

I would like to respectfully disagree with your assessment.

The fact that today's IGP (or for that matter BGP) routing is static from
the perspective of not taking into consideration real performance
measurements from the data plane to me is a bug not a feature.

Building SPT based on static link metrics which in vast majority of cases
today are emulated circuits on someone else IP backbone. It was a great
idea when you constructed the network with connection oriented paradigm
(Sonet,SDH, dark fiber, TDM ...) not connection less often best effort one.

So I find this proposal very useful and would vote for adopting it in LSR
WG. To me in-situ telemetry is not just some monitoring tool. It is an
extremely important element to influence how we compute reachability or at
least how we choose active forwarding paths from protocol RIBs to main RIB.

If we extended IGPs to carry TE information, if we extended them to enable
flexible algorithm based path computation I fail to understand why would we
resist to natively enable all of the above with getting the inputs from
real networks to be used as to the parameters to the above mentioned tools.

Kind regards,
R.

On Thu, Apr 2, 2020 at 8:32 AM Les Ginsberg (ginsberg)  wrote:

> Yali -
>
> There is a very significant difference between having IGPs advertise an
> identifier for a service that they use as clients (BFD) and having IGPs
> advertise a set of capabilities/options for a telemetry application which
> has no direct bearing on the function of the routing protocol.
>
> You are not the first to find using IGPs to flood application information
> very convenient.  But this is not the appropriate role for the IGPs and
> over the years we have consistently resisted attempts to do so.
>
> Everything advertised in Router Capabilities today has some close
> relationship with the operation of the protocol. Do some of the existing
> advertisements "bend the rules" a bit more than I would prefer? Yes - but
> there has always been at least a close relationship to routing protocol
> function.
> Here there is none.
>
> If you feel compelled to use IGPs to advertise application information,
> you have RF6823 available (at least for IS-IS). But it is a "high bar"
> since it requires you also to use a separate IS-IS instance dedicated to
> advertising the application information (see RFC8202).
> I think Chris Hopps's suggestion to use Netconf/YANG to configure/retrieve
> what you need is most likely more attractive - but I will leave that for
> you to decide.
>
> Using IGP Router Capabilities here is wrong in my view.
>
>Les
>
>
> > -Original Message-
> > From: wangyali 
> > Sent: Wednesday, April 01, 2020 8:12 PM
> > To: Acee Lindem (acee) ; Les Ginsberg (ginsberg)
> > ; Christian Hopps 
> > Cc: lsr@ietf.org; Tianran Zhou 
> > Subject: 答复: [Lsr] A new version of I-D,
> draft-liu-lsr-isis-ifit-node-capability-
> > 02
> >
> > Hi Acee, Chris and Les,
> >
> > This is Yali. Many thanks for your kind comments and suggestion.
> >
> > Besides of signaling MSD by IGP node CAPABILITY TLV, we learned that
> > there's another RFC7883 that advertising S-BFD discriminators in IS-IS.
> In my
> > understand, BFD is a protocol to detect faults in the bidirectional path
> > between two forwarding engines, including interface, data links, etc.
> >
> > Similarly, IFIT provides a complete framework of a family of on-path
> > telemetry techniques, which are used to monitoring performance metrics of
> > service flows, e.g. packet loss, delay. So we consider there's a same
> > methodology with S-BFD that advertising IFIT node capabilities.
> >
> > Please let us know your comments and opinion. Thanks.
> >
> > Best regards,
> > Yali
> >
> > -邮件原件-
> > 发件人: Acee Lindem (acee) [mailto:a...@cisco.com]
> > 发送时间: 2020年4月1日 20:29
> > 收件人: Tianran Zhou ; Les Ginsberg (ginsberg)
> > ; Christian Hopps 
> > 抄送: lsr@ietf.org; wangyali 
> > 主题: Re: [Lsr] A new version of I-D,
> draft-liu-lsr-isis-ifit-node-capability-02
> >
> > Speak as WG Member...
> >
> > On 4/1/20, 8:08 AM, "Acee Lindem (acee)"  wrote:
> >
> > There is also a difference between some of the existing applications
> > advertised in IGP capabilities. For example, MSD is used with the routing
> > information to construct SR paths. The information for all these OAM
> > mechanisms doesn't share this affinity. Also, it seems like a slippery
> slope in
> > what is needed for each of the mechanism.
> > Thanks,
> > Acee
> >
> > On 4/1/20, 4:01 AM, "Lsr on behalf of Tianran Zhou" <
> lsr-boun...@ietf.org
> > on behalf of zhoutian...@huawei.com> wrote:
> >
> > Hi Les,
> >
> > Thanks very much for your suggestion. I have a quick look at
> rfc6823.
> > Sounds like a good idea. I will think about it.
> >
> > Cheers,
> > Tianran
> >
> > -Original Message-
> > From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
> > Sent: Wednesday, April 1, 

Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

[Robert Raszuk]

> Slow flooding increase the likelihood of multiple IGP SPF computations

True.

But if you keep your IGP nicely organized in area and levels, get rid of
flooding anything incl. /32s domain wide to address bugs in MPLS
architecture then your flooding radius is usually very small.

That in turn allows for both fast flooding and fast topology computation
while only dealing with few external summaries. I am yet to see a
practical case where a well designed network with today's ISIS requires
flooding speedup.

Best,
R.




On Mon, Apr 27, 2020 at 10:34 AM  wrote:

> Ø  ISIS flooding churn (and room for optimization) becomes a problem when
> node boots up (IMHO this is not a problem) and when node fails while having
> many neighbors attached. Yes maybe second case could be improved but well
> designed and operated network should have pre-programmed bypass paths
> against such cases so IMO stressing IGP to "converge" faster while great in
> principle may not be really needed in practice.
>
>
>
> I don’t think that FRR is a replacement for “fast” (I’d rather say
> adequate) IGP convergence & flooding.
>
> For multiple reasons such as:
>
> -  Multiple ‘things’ depends on the IGP, such as BGP best path
> selection, CSPF/TE/PCE computations, FRR computations
>
> -  Slow flooding increase the likelihood of multiple IGP SPF
> computations which is harmful for other computations which are typically
> heavier and manifolds (cf above)
>
> -  Multiple IGP SPF computations also create multiple transient
> forwarding loops. There are some techniques to remove forwarding loops but
> this is still an advanced topic and some implementations do not handle
> consecutives IGP SPF (with ‘overlapping’ convergences and combined
> distributed forwarding loops)
>
> -  For FRR, you mostly need to pre-decide/configure whether you
> want to protect link or node failures. Tradeoff are involved and given
> probability of events, link protection is usually enabled (hence not node
> protection)
>
> -  …
>
>
>
> Also, given the current “state of the art”, there is no stressing
> involved. Really. Using TCP, my 200€ mobile running on battery and over
> wifi+ADSL+Internet can achieve better communication throughput than a
> n*100k€ high end IS-IS router.
>
> I think many persons agree that IS-IS could do better in term of flooding..
> (possibly not as good as a brand new approach, but incremental improvement
> also have some benefits). Eventually, we don’t need everyone to agree on
> this.
>
>
>
> Ø  PS. Does anyone have a pointer to any real data showing that
> performance of real life WAN ISIS deployments is bad ?
>
>
>
> In some of our ASes, we do monitor IS-IS by listening to and recording
> flooded LSPs. I can’t share any data.
>
> Next question could be what is “good enough”. I guess this may depend on
> the size of your network, its topology, and your requirements.
>
>
>
> We also ran tests in labs. I may share some results during my
> presentation. (no names, possibly no KPI, but some high level outcomes).
>
>
>
> Regards,
>
> Bruno
>
>
>
>
>
> *From**:* Robert Raszuk [mailto:rob...@raszuk.net]
> *Sent:* Friday, April 24, 2020 12:42 PM
> *To:* DECRAENE Bruno TGI/OLN
> *Cc:* Tony Przygienda; Les Ginsberg (ginsberg); lsr@ietf.org
> *Subject:* Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed
>
>
>
> Hi Bruno  & all,
>
>
>
> [Bruno] On my side, I’ll try once and I think the LSR WG should also try
> to improve IS-IS performance. May be if we want to move, we should first
> release the brakes.
>
>
>
> Well from my observations releasing the breaks means increasing the risks..
>
>
>
> Take BGP - breaks are off and see what happens :)
>
>
>
> My personal observation is that ISIS implementations across vendors are
> just fine for vast majority of deployments today. That actually also
> includes vast majority of compute clusters as they consists of max 10s of
> racks.
>
>
>
> Of course there are larger clusters with 1000+ or 10K and above network
> elements itself and x 20 L3 computes, but is there really a need to stretch
> protocol to accommodate those ? Those usually run BGP anyway. And also
> there is DV+LS hybrid too now.
>
>
>
> ISIS flooding churn (and room for optimization) becomes a problem when
> node boots up (IMHO this is not a problem) and when node fails while having
> many neighbors attached. Yes maybe second case could be improved but well
> designed and operated network should have pre-programmed bypass paths
> against such cases so IMO stressing IGP to "converge" faster while great in
> p

Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

[Robert Raszuk]

> In both cases, this call, IMO a signaling capability from the receiver to
the sender.

So essentially you are asking for per peer flooding queue.

Now this get's a little bit of tricky (especially if you are dealing
with relatively small timers) if one peer sends you 1 ms, second 50 ms and
10th  250 ms.

Imagine that the LSP to be flooded to the 10th peer is already overwritten
due to new LSP but still sitting in the out queue ... do you drain that
queue and start over with new LSP or you in place replace the old one
keeping the running timer ?

I am just curious what will happen under the hood :)

Cheers,
R.




On Mon, Apr 27, 2020 at 3:02 PM  wrote:

> Hi Acee,
>
>
>
> Please see inline [Bruno2]
>
>
>
> *From:* Acee Lindem (acee) [mailto:a...@cisco.com]
> *Sent:* Monday, April 27, 2020 2:39 PM
> *To:* DECRAENE Bruno TGI/OLN; Robert Raszuk
> *Cc:* Les Ginsberg (ginsberg); lsr@ietf.org; Tony Przygienda
> *Subject:* Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed
>
>
>
> Hi Bruno,
>
>
>
> *From: *Lsr  on behalf of Bruno Decraene <
> bruno.decra...@orange.com>
> *Date: *Monday, April 27, 2020 at 8:15 AM
> *To: *Robert Raszuk 
> *Cc: *"Les Ginsberg (ginsberg)" , "
> lsr@ietf.org" , Tony Przygienda 
> *Subject: *Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed
>
>
>
> Robert,
>
>
>
> *From:* Robert Raszuk [mailto:rob...@raszuk.net]
> *Sent:* Monday, April 27, 2020 12:09 PM
> *To:* DECRAENE Bruno TGI/OLN
> *Cc:* Tony Przygienda; Les Ginsberg (ginsberg); lsr@ietf.org
> *Subject:* Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed
>
>
>
>
>
> > Slow flooding increase the likelihood of multiple IGP SPF computations
>
>
>
> True.
>
>
>
> But if you keep your IGP nicely organized in area and levels, get rid of
> flooding anything incl. /32s domain wide to address bugs in MPLS
> architecture then your flooding radius is usually very small.
>
> [Bruno] First of all, the use of areas/levels brings tradeoffs. Then,
> after their initial design, networks grow and change.
>
>
>
> Coming back to flooding, if you have a core router with 50 IGP neighbors,
> the failure of this neighbor requires flooding 50 LSPs. At 33ms pacing
> between LSPs that’s a 1.6s delay/tax, before any computation & FIB update.
> As you see, it’s not related to the number of /32 nor the network diameter.
>
> Some may be fine with this additional 1.6s. Some may not.
>
>
>
> I’m not nearly as familiar with IS-IS deployments as OSPF. Are there any
> implementations that don’t offer configuration to override the 33ms
> inter-LSP interval?
>
> [Bruno2] AFAIK, all implementations allow the configuration of the
> inter-LSP interval.
>
> The question is which value do you set while not risking to overload your
> IS-IS neighbor. Which brings two issues:
>
> -  This depends on the receiver. E.g. High end router vs low end;
> PE with only 2 high adjacencies vs P with 50 adjacencies, router
> generation… While this is currently configured on the sender on a per
> receiver basis
>
> -  Even though the vendor know the design and how it is
> implemented, some vendors may not commit on scaling values supported by a
> given receiver.
>
>
>
> So there are two options:
>
> -  Have the receiver advertise static values (default but
> according to its platform capability=
>
> -  Use dynamic values. Flow control is likely to also require
> some signaling from the receiver to the sender.
>
>
>
> In both cases, this call, IMO a signaling capability from the receiver to
> the sender. The same signaling may then be used to advertise either
> static/default or dynamic values, depending on what the receiver prefer
> (some tend to prefer static values, some tend to prefer dynamic values)
>
>
>
> Thanks,
>
> BR
>
> --Bruno
>
> At Redback (circa 2000), our OSPF implementation defaulted to fast
> flooding and for the MinLSInterval and MinLSArrival OSPF values, you had to
> explicitly remove the fast flooding default if  you wanted to follow RFC
> 2328. Thanks,
> Acee
>
>
>
> Best
>
> --Bruno
>
>
>
>
>
> That in turn allows for both fast flooding and fast topology computation
> while only dealing with few external summaries. I am yet to see a
> practical case where a well designed network with today's ISIS requires
> flooding speedup.
>
>
>
> Best,
>
> R.
>
>
>
>
>
>
>
>
>
> On Mon, Apr 27, 2020 at 10:34 AM  wrote:
>
> Ø  ISIS flooding churn (and room for optimization) becomes a problem when
> node boots up (IMHO this is not a pro

Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

[Robert Raszuk]

Hi Tony,


> You already have a per-interface flooding ‘queue' through the
> implementation of the SRM bit in the LSDB, which must be managed on a
> per-interface basis.
>

Today from what I see operators (if they even change the default) normally
apply same timer value on all interfaces. If the timer is static what would
be the incentive for any implementation not to group interfaces with
identical transmit delay ?

- - -

While this thread is very interesting I must observe that from my
experience the issue is usually on the receiver. If LSR would publish a one
page draft/rfc mandating that links state packets MUST or SHOULD be
recognized and separated from any other control plane traffic at the
ingress interface level (on their way to local RE/RP) we likely wouldn't be
having such debate.

Slowing senders just due to bad implementation of the receiving router is
IMHO a little suboptimal (not to say wrong) thing to do.

Kind regards,
R.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

[Robert Raszuk]

> Meanwhile, buffering is finite and control planes really can’t keep up.
> Forwarding is a parallel activity. The control plane is not.  This presents
> us with a situation where congestion is pretty much inevitable. We need to
> deal with it.


At least we are lucky that ISIS LSPs are produced by some other control
plane not by a silicon chip :)

If we have 1000 of interfaces and all peers *all in the same time* will
send us an LSP of max size of 1492 octets that our control plane buffer RAM
size required to store them would be as huge as 1.5 MB. And that assumes we
did not process any from arrival of the first to the arrival of the last
one.

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

Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

[Robert Raszuk]

Ahh ok.

I was under the assumption that flooding reduction is something we will
have sooner then LSP flow control. But maybe this was too optimistic.

- - -

For per peer flow control I do not get how receiver's ISIS process is to
come up with per peer timer if it may never see under congestion given
peer's LSPs (being dropped on the single RE cp queue or at the interface).

Perhaps such flag to "slow down guys" could be send by receiver uniformly
to all peers when under LSP flooding congestion ? And instead of
specifying an absolute number just mean: slow N times (ex: slow 2 times or
slow 4 times). Such timer could be either temporary with fixed duration or
in effect until relaxed explicitly.

LSP senders would still require to handle it on a per peer basis but as
indicated this is not an issue.

Thx.
R.

On Mon, Apr 27, 2020 at 8:57 PM  wrote:

>
> If we have 1000 of interfaces and all peers *all in the same time* will
> send us an LSP of max size of 1492 octets that our control plane buffer RAM
> size required to store them would be as huge as 1.5 MB. And that assumes we
> did not process any from arrival of the first to the arrival of the last
> one.
>
>
>
> And that’s only one LSP.  If they don’t stop there and each sends 1000
> LSPs, then you can have 10^6 incoming packets, requiring 1.6GB.
>
> Further, since the bottleneck is likely the queue of packet on the
> forwarding chip(s) to the CPU, this 1.6GB needs to exist on the forwarding
> silicon.  Needless to say, it doesn’t.
>
> Yes, the CPU can probably keep up with one of the peers. This implies that
> the forwarding plane queue grows at the rate that 999 peers are sending at.
> Thus, congestion.
>
> Tony
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

[Robert Raszuk]

>
> > Perhaps such flag to "slow down guys" could be send by receiver
> uniformly to all peers when under LSP flooding congestion ?
>
> That’s effectively what we’re proposing, tho it need not be a binary
> flag.  It allows us to do simpler things saying “we’re running out of
> buffer space, please slow down a bit”. Again the goal is to find the
> optimal goodput.  Granularity in the feedback will be helpful.
>

Apologies if I missed it but so far I understood that the new signalling
from the receiver could be different per each LSP sender (per each Hello).

Above I am suggesting that such signalling to be "global" per receiver
(ie.sent identical to all LSP senders) under moments of stress/congestion.

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

Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

[Robert Raszuk]

Hi Bruno  & all,

[Bruno] On my side, I’ll try once and I think the LSR WG should also try to
improve IS-IS performance. May be if we want to move, we should first
release the brakes.

Well from my observations releasing the breaks means increasing the risks.

Take BGP - breaks are off and see what happens :)

My personal observation is that ISIS implementations across vendors are
just fine for vast majority of deployments today. That actually also
includes vast majority of compute clusters as they consists of max 10s of
racks.

Of course there are larger clusters with 1000+ or 10K and above network
elements itself and x 20 L3 computes, but is there really a need to stretch
protocol to accommodate those ? Those usually run BGP anyway. And also
there is DV+LS hybrid too now.

ISIS flooding churn (and room for optimization) becomes a problem when node
boots up (IMHO this is not a problem) and when node fails while having many
neighbors attached. Yes maybe second case could be improved but well
designed and operated network should have pre-programmed bypass paths
against such cases so IMO stressing IGP to "converge" faster while great in
principle may not be really needed in practice.

Last I am worried that when IETF defines changes to core protocol behaviour
the quality of the implementations of those changes may really differ
across vendors overall resulting in much worse performance and stability as
compared to where we are today.

I am just not sure if possible gains for few deployments are greater
then risk for 1000s of today's deployments. Maybe one size does not fit all
and for massive scale ISIS we should define a notion of "ISIS-DC-PLUGIN"
which can be optionally in run time added when/if needed. If that requires
protocol changes to accommodate such dynamic plugins - that work should
take place.

Many thx,
R.

PS. Does anyone have a pointer to any real data showing that performance of
real life WAN ISIS deployments is bad ?


On Fri, Apr 24, 2020 at 11:26 AM  wrote:

> Tony
>
>
>
> *From:* Tony Przygienda [mailto:tonysi...@gmail.com]
> *Sent:* Thursday, April 23, 2020 7:29 PM
> *To:* DECRAENE Bruno TGI/OLN
> *Cc:* lsr@ietf.org; Les Ginsberg (ginsberg)
> *Subject:* Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed
>
>
>
> I was refering to RFC4960. Bruno, for all practical purposes I think that
> seems to go down the path of trying to reinvent RFC4960 (or ultimately use
> it).
>
> [Bruno] I don’t think that SCTP (RC4960) is a better fit than TCP.. Many
> more features and options than TCP, way more than needed given existing
> IS-IS flooding mechanism. Much less implementations experience and
> improvement than TCP.
>
> Or, changing the packet formats heavily to incorporate all the control
> loop data you need to the point you have a different control channel along
> those lines since you'll find most of the problems RFC4960 is describing
> (minus stuff like multiple paths).
>
> [Bruno] Really, adding one sub-TLV in IS-IS is not “changing the packet
> formats heavily”.
>
> Nothing wrong with that but it's ambitious on a 30 years old anitque
> artefact we're nursing forward here ;-)
>
> [Bruno] I’m perfectly fine with revolution approaches. I think that we can
> also provide incremental improvement to IS-IS.
>
> As entertaining footnote, I saw in last 20 years at least 3 attempts to
> allow multiple TCP sessions in BGP between peers to speed/prioritize things
> up. All failed, after the first one I helped to push I smarted up ;-)
>
>  [Bruno] On my side, I’ll try once and I think the LSR WG should also try
> to improve IS-IS performance. May be if we want to move, we should first
> release the brakes. I’m seen some progress, e.g., from “there is no need to
> improve flooding” to “we all agree to improve flooding”, or from “Network
> operator just need to configure existing CLI” to “We agree that we need
> something more automated/dynamic”. But this has been very slow progress
> over a year.
>
>
>
> --Bruno
>
>
>
> As another footnote: I looked @ all the stuff in RIFT (tcp, quic, 4960,
> more ephemeral stuff). I ended up adding to rift bunch very rudimentary
> things and do roughly what Les/Peter/Acee started to write (modulo algorith
> I contributed and bunch things that would be helpful but we can't fit into
> existing packet format). This was as much decision as to "what's available
> & well debugged" as well as "does it meet requirements" as "how complex is
> that vs. rtx in flooding architecture  we have today + some feedback". Not
> on powerpoint, in real production code ;-) rift draft shows you the outcome
> of that as IMO best trade-off to achieve high flooding speeds ;-)
>
>
>
> my 2c
>
>
>
> -- tony
>
>
>
> On Thu, Apr 23, 2020 at 10:15 AM  wrote:
>
> Tony,
>
> Thanks for engaging.
>
> Please inline [Bruno2]
>
>
>
>
>
>
>
> *From:* Tony Przygienda [mailto:tonysi...@gmail.com]
> *Sent:* Wednesday, April 22, 2020 9:25 PM
> *To:* DECRAENE Bruno TGI/OLN
> *Cc:* lsr@ietf.org; Les 

Re: [Lsr] Flooding across a network

[Robert Raszuk]

Hi Les,

A side comment but your example shows another - one may say even much more
serious issue.

Assume we have LFA/TI-LFA enabled in the network and precomputed on B which
get's activated and shifts traffic to E when detects that C is down.
Detection is fast .. 10s-100s of milliseconds.

Now if B converges fast and recomputes topology much faster then D it may
remove protection and send packets to D natively. Well clearly as we
established D is slow and will loop it back.

That is why I mentioned the other day that a fast control plane is not
always a good thing (I am sure many will say the opposite - but it is ok
;).

But this proves that consistent convergence time in a domain is rather a
good thing regardless if it takes 2 sec or 50 sec on all nodes.

Best,
Robert.



On Wed, May 6, 2020 at 1:35 AM Les Ginsberg (ginsberg)  wrote:

> Bruno -
>
>
>
> Seems like it was not too long ago that we were discussing this in
> person.  Ahhh...the good old days...
>
>
>
> First, let's agree that the interesting case does not involve 1 or even a
> small number of LSPs. For those cases flooding speed does not matter.
>
> The interesting cases involve a large number of LSPs (hundreds or
> thousands). And in such cases LFA/microloop avoidance techniques are not
> applicable.
>
>
>
> Take the following simple topology:
>
>
>
> *   |  | ... ||*
>
> * +---+ +---+*
>
> * | C | | E |*
>
> * +---+ +---+*
>
> *   | | 1000*
>
> * +---+ +---+*
>
> * | B |-| D |*
>
> * +---+   1000  +---+*
>
> *   | |*
>
> *   | |*
>
> *\   /*
>
> * \/*
>
> *  \ /*
>
> *   \  /*
>
> * +---+*
>
> * | A |*
>
> * +---+*
>
>
>
> There is a topology northbound of C and E (not shown) and a topology
> southbound of A (not shown).
>
> Cost on all links is 10 except B-D and D-E where cost is high.
>
>
>
> C is a node with 1000 neighbors.
>
> When all links are up, shortest path for all northbound destinations is
> via C.
>
> All nodes in the network support fast flooding except for Node D.
>
> Let’s say fast flooding is 500 LSPs/second and slow flooding (Node D) is
> 20 LSPs/seconds.
>
> If  Node C fails we have 1000 LSPs to flood.
>
> All nodes except for D can receive these in 2 seconds (plus internode
> delay time).
>
> D can receive LSPs in 50 seconds.
>
>
>
> When A and B and all southbound nodes receive/process the LSP updates they
> will start sending traffic to Northbound destinations via D.
>
> But for the better part of 50 seconds, Node D has yet to receive all LSP
> updates and still believes that shortest path is via B-C. It will loop
> traffic.
>
>
>
> Had all nodes used slow flooding, it still would have taken 50 seconds to
> converge, but there would be significantly less looping. There could be a
> good amount of blackholing, but this is preferable to looping.
>
>
>
> One can always come up with examples – based on a specific topology and a
> specific failure - where things might be better/worse/unchanged in the face
> of inconsistent flooding speed support.
>
> But I hope this simple example illustrates the pitfalls.
>
>
>
> Les
>
>
>
> > -Original Message-
>
> > From: bruno.decra...@orange.com 
>
> > Sent: Tuesday, May 05, 2020 8:28 AM
>
> > To: Les Ginsberg (ginsberg) ; lsr@ietf.org
>
> > Subject: Flooding across a network
>
> >
>
> > Les,
>
> >
>
> > > From: Lsr [mailto:lsr-boun...@ietf.org ] On
> Behalf Of Les Ginsberg
>
> > (ginsberg)
>
> > > Sent: Monday, May 4, 2020 4:39 PM
>
> > [...]
>
> > > when only some nodes in the network support faster flooding the
> behavior
>
> > of the whole network may not be "better" when faster flooding is enabled
>
> > because it prolongs the period of LSDB inconsistency.
>
> >
>
> > 1) Do you have data on this?
>
> >
>
> > 2) If not, can you provide an example where increasing the flooding rate
> on
>
> > one adjacency prolongs the period of LSDB inconsistency across the
>
> > network?
>
> >
>
> > 3) In the meantime, let's try the theoretical analysis on a simple
> scenario
>
> > where a single LSP needs to be flooded across the network.
>
> >
>
> > - Let's call Dij the time needed to flood the LSP from node i to the
> adjacent
>
> > node j. Clearly Dij>0.
>
> > - Let's call k the node originating this LSP at t0=0s
>
> >
>
> > >From t0, the LSDB is inconsistent across the network as all nodes but k
> are
>
> > missing the LSP and hence only know about the 'old' topology.
>
> >
>
> > Let's call  SPT(k) the SPT rooted on k, using Dij as the metric between
>
> > adjacent nodes i and j. Let's call SP(k,i) the shortest path from k to
> i; and
>
> > D(k,i) the shortest distance between k and i..
>
> >
>
> > It seems that the time needed:
>
> > - for node j to learn about the LSP, and get in sync with k, is D(k,j)
>
> > - for all 

Re: [Lsr] Flooding across a network

[Robert Raszuk]

Hey Jeff,

What if in your analysis A-D link metric is 1500 ? Still A will send to B !

See in all of this discussion from my pov it is not really about danger of
making LSDB inconsistent for much longer.

It is however about operator upgrading to new release a router, maybe even
reading release notes stating that flooding speed optimizations defined in
RFC ZZZ are implemented and final effect he sees are microloops lasting 10s
of seconds for his traffic.

Yes some vendors have good tools to protect from microloops, but those must
be enabled. Moreover those still require manual timer configuration how
long to keep loop free protection in place. And I am not aware any vendor
has a cli command showing how long it took in all routers in my area/level
to install in FIB result of various levels/cases of topology changes.

So I am not saying faster is not good. I am saying if you make car faster
do not forget to equip it with seat belts and make enough of warnings that
driver will actually fasten them.

Best,
R.

On Thu, May 7, 2020 at 6:41 AM Jeff Tantsura 
wrote:

> Robert,
>
> Assuming C and E provide access to the same set of destinations, that are
> closer of further away from C and E.
> B (which is fast), after it notifies A that it can’t reach C directly will
> cause A to send traffic to D. D - dependent on total cost would start
> happily sending some traffic towards destinations behind C to B so LFA on B
> wouldn’t really help.
>
> Cheers,
> Jeff
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Flooding across a network

[Robert Raszuk]

Christian,

It is not about "hand-wringing and theorizing about being too-successful".

It is about impact to the overall network service when you make ISIS
convergence not consistent across nodes of the topology, I think our goal
is not to converge ISIS faster by improving flooding speed ... it is much
more about how to deliver user packets with minimal disruption upon
topology changes.

Best,
R.

On Wed, May 6, 2020 at 5:48 AM Christian Hopps  wrote:

> [as WG member]
>
> I think it would be more productive if we stay focused on trying to
> improve flooding speed/efficiency here. How about let's get some of the
> proposals being mulled over actually written, and provide some data, and
> leave all the hand-wringing and theorizing about being too-successful for
> after we've shown we could be? :)
>
> Thanks,
> Chris.
>
>
> > On May 5, 2020, at 8:03 PM, Robert Raszuk  wrote:
> >
> > But this proves that consistent convergence time in a domain is rather a
> good thing regardless if it takes 2 sec or 50 sec on all nodes.
> >
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

[Robert Raszuk]

> people need to spend their time in deciding where is the boundary between
the two areas

Oh then I perhaps completely missed the value and power of TTZ.

It seems that in TTZ instead of careful planning of your abstractions the
plan is to randomly create zones and see what happens - is this right
reading of your explanation ?

Many thx,
R.

On Wed, Sep 2, 2020 at 6:58 AM Huaimo Chen 
wrote:

> Hi Tony,
>
> It seems that splitting L1 area A1 into two L1 areas A11 and A12
> cannot be automated without people's planning. Some people need to spend
> their time in deciding where is the boundary between the two areas and
> selecting a router in the backbone domain for Attach bit for one of the two
> areas. These corresponds to step 1) and 3) for using Areas.
>
> Best Regards,
> Huaimo
> --
> *From:* Tony Li  on behalf of tony...@tony.li <
> tony...@tony.li>
> *Sent:* Wednesday, September 2, 2020 12:09 AM
> *To:* Huaimo Chen 
> *Cc:* Les Ginsberg ; Les Ginsberg (ginsberg)
> ; Acee Lindem (acee)  40cisco@dmarc.ietf.org>; lsr@ietf.org 
> *Subject:* Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent
> Zone" - draft-chen-isis-ttz-11.txt
>
>
> Hi Huaimo,
>
> Assume that a big L1 area (say Area A1) is connected to backbone
> domain.
> Let us compare TTZ and Areas for scalability.
>
> Using TTZ, we need two steps below:
> 1) configure a piece of Area A1, named P1, as a zone; and
> 2) transfer P1 to a virtual node using one command or two.
>
> Using Areas, we need four steps below to split Area A1 into two L1
> areas A11 and A12:
> 1) configure the edges between A11 and A12 as L2/L1 to backbone domain;
> 2) add/configure a new area address on the routers in target Area A12;
> 3) configure Attach bit for A11 or A12; and
> 4) delete the old area address from the routers in Area A12.
>
> Using TTZ is simpler than using Areas.
>
>
>
> I’m not quite sure I follow you.  Are you arguing that simplicity is
> achieved through the minimum number of configuration steps?
>
> If so, I’d like to introduce you to Arista CVP, our management platform,
> where all of this can be easily automated: 1 step.
>
> Tony
>
>
> ___
> 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] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

[Robert Raszuk]

>  acknowledged problem (IGP scalability)

Great so we see the problem description. This is progress !

Allow me to observe two points:

* IGP scalability can be easily solved with the additional levels of
current abstraction instead of introducing new types of abstraction into
it. Ref: draft-ietf-lsr-isis-extended-hierarchy

* Most scaling aspects I have seen in practical deployments with IGPs are
not caused by the suboptimal protocol design. Those are caused by
requirements introduced by some transport technologies which (at least
originally) required flooding of host routes domain wide for exact match of
FECs to prefixes. I do not see how TTZs would address that aspect in any
better way than areas can.

Thx,
R.


On Wed, Sep 2, 2020 at 10:00 AM Gengxuesong (Geng Xuesong) <
gengxues...@huawei.com> wrote:

> Hi Tony,
>
>
>
> My intension was not to talk about math/engineering/marketing or compare
> the size of marketing department. Them are not relevant to this thread.
>
> I want to make clear about IETF process. In my understanding the document
> does not need to be perfect at this stage, as long as it is in the right
> direction to solve some acknowledged problem( IGP scalability). Comments
> will be helpful if it could provide ideas about how to improve.
>
> But IMO the discussion in the mailing list about this draft has gone off
> the rails of technology, including keeping challenging tradeoff between
> value and complexity, which seems reasonable at the first sight, but at
> this stage, has turned out to be a question with no right answer and may
> bring endless argument.
>
>
>
>
>
> Thanks
>
> Xuesong
>
>
>
> *From:* Tony Li [mailto:tony1ath...@gmail.com] *On Behalf Of *
> tony...@tony.li
> *Sent:* Wednesday, September 2, 2020 12:07 PM
> *To:* Gengxuesong (Geng Xuesong) 
> *Cc:* Huaimo Chen ; Les Ginsberg (ginsberg)
> ; Les Ginsberg ;
> Acee Lindem (acee) ; lsr@ietf.org
> *Subject:* Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent
> Zone" - draft-chen-isis-ttz-11.txt
>
>
>
>
>
> Hi Xuesong,
>
>
>
> Apologies first if I have missed any history of this discussion. But I’m
> not sure that we have to evaluate whether a method is “optimal” before WG
> adoption. Why not adopt some alternative solutions and leave the choice to
> industry/market?
>
>
>
>
>
> First off, this is engineering, not theoretical math.  Optimal is not the
> issue. Heck, optimal isn’t even a goal.
>
>
>
> What we are looking for is value and value that outweighs the complexity.
>
>
>
> Leaving the choice to the market is a bad idea. The market does NOT make
> sound technical decisions. It makes pseudo-random decisions not based on
> technical merits. The canonical example here is VHS vs Betamax. Better
> technology lost.
>
>
>
> Second, the market is unduly influenced by marketing. The size of your
> marketing department exceeds the size of my entire (not tiny) company. And
> it’s still second to that of Cisco.
>
>
>
> Marketing does not make good technical and architectural decisions. That’s
> our job.
>
>
>
> Tony
>
>
> ___
> 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] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

[Robert Raszuk]

> - The transition mechanisms

Hmmm maybe I missed some explanations by authors, but to me concept of
zones is positioned as an addition to the concept of areas or levels - not
a replacement of those.

So when you say "transition" means that something existing no longer would
be in place after successful deployment of a new thing.

Here I am actually not sure if IGP domain could be only constructed with
zones without areas ?

Of course said all of the above I am still not seeing any value in the
proposed new abstraction regardless if such abstraction would be positioned
to exist in parallel to areas/levels or by definition be nested within the
area/level.

r.

On Wed, Sep 2, 2020 at 4:48 PM  wrote:

>
> Hi Xueson,
>
> My intension was not to talk about math/engineering/marketing or compare
> the size of marketing department. Them are not relevant to this thread.
>
>
>
> You are the one who suggested we leave it up to the market…
>
> I want to make clear about IETF process. In my understanding the document
> does not need to be perfect at this stage, as long as it is in the right
> direction to solve some acknowledged problem( IGP scalability). Comments
> will be helpful if it could provide ideas about how to improve.
>
>
>
> That’s what we’ve been trying to tell you all along:
>
> - If there is a benefit to zones, it’s not clear to us.  You need to do a
> better job articulating that.
>
> - The transition mechanisms seem awkward and painful. Can you reduce the
> complexity?
>
> But IMO the discussion in the mailing list about this draft has gone off
> the rails of technology, including keeping challenging tradeoff between
> value and complexity, which seems reasonable at the first sight, but at
> this stage, has turned out to be a question with no right answer and may
> bring endless argument.
>
>
>
> Technology is all about maximizing benefits while minimizing costs.  This
> is why we don’t wire houses using gold and silver.
>
> Yes, this does seem to be an endless argument.  Welcome to the IETF.
>
> Regards,,
> Tony
>
> ___
> 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] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

[Robert Raszuk]

Hi Aijun,

> *[WAJ] If necessary, we can advertise the MAX_T_PUA(configurable time for
> the hold of PUA information on the nodes) among the area.*
>
> *If one node connect to the network after the disappearance of the PUA
> destination,  there will be no services can be established/run on these
> failure node/link prefix. *
>
> *It’s the same as the beginning, as not all of the prefixes can be
> reachable within the summary address.*
>
>
>From my pov the only advantage of negative routes in IGP would be to very
quickly invalidate service routes (within the IGP domain) typically carried
by BGP.

When this is accomplished the PUA can indeed time out with no harm.

Said this - now considering tools like next hop tracking which can trigger
withdraw or aggregated withdraw(*) proposal in src area I am  really
curious how much (if anything) we would be gaining here.

(*) The original proposal for this was written over 15 years ago:
https://tools.ietf.org/html/draft-raszuk-aggr-withdraw-00  We could extend
it with next hop which would be the same as IGP PUA prefix.

Kind regards,
Robert
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

[Robert Raszuk]

Hi Aijun,

> the BGP next-hop is reachable

Nope you missed the crux of the message.

The next hop will be unreachable in the *source area/level. *That would be
where the BGP service route withdraw or aggregate withdraw would originate
at. Same as PUA.

Best,
Robert.


On Mon, Sep 7, 2020 at 11:31 AM Aijun Wang 
wrote:

> Hi, Robert:
>
> For BGP next-hop tracking, it will help when the BGP next-hop is
> unreachable. But in our situation, the BGP next-hop is reachable, but
> should pass another ABR.
>
> Then, in such situation, the mechanism of BGP next-hop tracking will not
> take effect?
>
> And thanks for your draft information, maybe we can refer to it later J
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
>
>
> *From:* lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] *On Behalf Of 
> *Robert
> Raszuk
> *Sent:* Monday, September 7, 2020 4:54 PM
> *To:* Aijun Wang 
> *Cc:* Les Ginsberg (ginsberg) ; Gyan Mishra <
> hayabusa...@gmail.com>; Peter Psenak ;
> Huzhibo ; Aijun Wang ; lsr <
> lsr@ietf.org>; Acee Lindem (acee) ; Xiaoyaqun <
> xiaoya...@huawei.com>; Tony Przygienda 
> *Subject:* Re: [Lsr] New Version Notification for
> draft-wang-lsr-prefix-unreachable-annoucement-03.txt
>
>
>
> Hi Aijun,
>
> *[WAJ] If necessary, we can advertise the MAX_T_PUA(configurable time for
> the hold of PUA information on the nodes) among the area.*
>
> *If one node connect to the network after the disappearance of the PUA
> destination,  there will be no services can be established/run on these
> failure node/link prefix. *
>
> *It**’s the same as the beginning, as not all of the prefixes can be
> reachable within the summary address.*
>
>
>
> From my pov the only advantage of negative routes in IGP would be to very
> quickly invalidate service routes (within the IGP domain) typically carried
> by BGP.
>
>
>
> When this is accomplished the PUA can indeed time out with no harm.
>
>
>
> Said this - now considering tools like next hop tracking which can trigger
> withdraw or aggregated withdraw(*) proposal in src area I am  really
> curious how much (if anything) we would be gaining here.
>
>
>
> (*) The original proposal for this was written over 15 years ago:
> https://tools.ietf.org/html/draft-raszuk-aggr-withdraw-00  We could
> extend it with next hop which would be the same as IGP PUA prefix.
>
>
>
> Kind regards,
> Robert
>
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

[Robert Raszuk]

Hi Huaimo,


> > Users can define a zone (a block of an area) and the zone can be any
> block of the area that users decide. Thus, using TTZ seems simpler than
> using Areas for scalability. It uses less planning effort and less
> configurations.
>
>
Q1 - Can zones overlap ? IE. can any node be in the same time in
multiple zones ?

Q2 - Can zones be nested ?

Q3 - Can zone boundary span across two or more areas ?

> [HC]:  The requirement for flooding of host routes domain wide is
considered in section 4.1.3 of TTZ draft.

Well all it says that loopbacks can be included. That in no way addresses
the scalability aspect if those loopbacks are to be flooded domain wide
anyway.

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

Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

[Robert Raszuk]

>
> [HC]: IS-IS TTZ or say Zone is one of a few drafts which
> experiment/explore new ways for scalability. These new ways may be simpler
> and have some other features.
>

While Tony very well explained the "may" part let me ask the "simpler"
part.

Simpler then what ?

Simpler when combined with existing levels of abstraction or when
taken alone in vaccume ?

The draft in question defines a new abstraction. But I would like to go
back to a very basic question:

What problem(s) are you solving ?

You say "new ways for scalability" - can you enumerate what is unscalable
in current areas or levels ?

Many thx,
Robert
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

[Robert Raszuk]

Hi,

Intra area ?

If we are flooding host routes I have never seen a case where intra area
those are not flooded.

Where would you summarise ? On a node within area ?

Very unreal scenario IMHO.

Thx
R.

On Wed, Sep 9, 2020, 03:22 Aijun Wang  wrote:

> Hi, Robert:
>
>
>
> PUA covers both the intra-area and inter-area scenarios.
>
> For inter-area scenario, it covers the situation that the next-hop is
> reachable via one ABR but unreachable via another ABR.
>
> For such situation, BGP nexthop tracking, route withdraw or aggregate
> withdraw will not work.
>
>
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> *From:* lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] *On Behalf Of 
> *Robert
> Raszuk
> *Sent:* Monday, September 7, 2020 5:36 PM
> *To:* Aijun Wang 
> *Cc:* Les Ginsberg (ginsberg) ; Gyan Mishra <
> hayabusa...@gmail.com>; Peter Psenak ;
> Huzhibo ; Aijun Wang ; lsr <
> lsr@ietf.org>; Acee Lindem (acee) ; Xiaoyaqun <
> xiaoya...@huawei.com>; Tony Przygienda 
> *Subject:* Re: [Lsr] New Version Notification for
> draft-wang-lsr-prefix-unreachable-annoucement-03.txt
>
>
>
> Hi Aijun,
>
>
>
> > the BGP next-hop is reachable
>
>
>
> Nope you missed the crux of the message.
>
>
>
> The next hop will be unreachable in the *source area/level. *That would
> be where the BGP service route withdraw or aggregate withdraw would
> originate at. Same as PUA.
>
>
>
> Best,
>
> Robert.
>
>
>
>
>
> On Mon, Sep 7, 2020 at 11:31 AM Aijun Wang 
> wrote:
>
> Hi, Robert:
>
> For BGP next-hop tracking, it will help when the BGP next-hop is
> unreachable. But in our situation, the BGP next-hop is reachable, but
> should pass another ABR.
>
> Then, in such situation, the mechanism of BGP next-hop tracking will not
> take effect?
>
> And thanks for your draft information, maybe we can refer to it later J
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
>
>
> *From:* lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] *On Behalf Of 
> *Robert
> Raszuk
> *Sent:* Monday, September 7, 2020 4:54 PM
> *To:* Aijun Wang 
> *Cc:* Les Ginsberg (ginsberg) ; Gyan Mishra <
> hayabusa...@gmail.com>; Peter Psenak ;
> Huzhibo ; Aijun Wang ; lsr <
> lsr@ietf.org>; Acee Lindem (acee) ; Xiaoyaqun <
> xiaoya...@huawei.com>; Tony Przygienda 
> *Subject:* Re: [Lsr] New Version Notification for
> draft-wang-lsr-prefix-unreachable-annoucement-03.txt
>
>
>
> Hi Aijun,
>
> *[WAJ] If necessary, we can advertise the MAX_T_PUA(configurable time for
> the hold of PUA information on the nodes) among the area.*
>
> *If one node connect to the network after the disappearance of the PUA
> destination,  there will be no services can be established/run on these
> failure node/link prefix. *
>
> *It**’s the same as the beginning, as not all of the prefixes can be
> reachable within the summary address.*
>
>
>
> From my pov the only advantage of negative routes in IGP would be to very
> quickly invalidate service routes (within the IGP domain) typically carried
> by BGP.
>
>
>
> When this is accomplished the PUA can indeed time out with no harm.
>
>
>
> Said this - now considering tools like next hop tracking which can trigger
> withdraw or aggregated withdraw(*) proposal in src area I am  really
> curious how much (if anything) we would be gaining here.
>
>
>
> (*) The original proposal for this was written over 15 years ago:
> https://tools.ietf.org/html/draft-raszuk-aggr-withdraw-00  We could
> extend it with next hop which would be the same as IGP PUA prefix.
>
>
>
> Kind regards,
> Robert
>
>
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt

[Robert Raszuk]

Hey Peter,

To me the application here is "avoid red links" regardless of choice of
encap in the data plane.

Does it really make sense to separate advertisements of SR flex-algo vs IP
flex-algo into separate TLVs ?

Along the same linkes even for SR data plane can be SR-MPLS or SRv6. So in
the network running all three data planes you will need to compute SPT for
each flex-algo three times which may or may not be desired especially if
each algorithm would be as simple as to avoid certain link color.

That goes to the point can dataplanes interwork in flex algo and it seems
that currently they can not if section 10.2 is interpreted as application
to be a tuple of data plane + topological constraints (instead of only
topological constraints).

Thx,
R.







On Mon, Oct 12, 2020 at 10:47 AM Peter Psenak  wrote:

> Hi Jimmy.
>
> On 12/10/2020 09:12, Dongjie (Jimmy) wrote:
> > Hi Jeff,
> >
> > Thanks for your explanation. I understand that for different data plane
> the SIDs or IP addresses have different scope, and will not conflict in
> normal cases.
> >
> > My question is more about whether a computation node needs to know and
> check which data plane is used by the intermediate nodes to bind to the
> Flex-Algo? In another word, can an SR path computed using Flex-Algo 128 go
> through an intermediate node which bind Flex-Algo 128 to IP data plane?
>
> computation node MUST check the application specific participation in
> flex-algo and participation advertisement is application specific. SR
> and IP are different applications from flex-algo perspective.
>
>
> draft-ietf-lsr-flex-algo-12, section 10.2:
>
>
> Application-specific advertisement for Flex-Algorithm participation
> MUST be defined for each application
>
> thanks,
> Peter
>
> >
> > Best regards,
> > Jie
> >
> >> -Original Message-
> >> From: Jeff Tantsura [mailto:jefftant.i...@gmail.com]
> >> Sent: Sunday, October 11, 2020 3:14 AM
> >> To: Ron Bonica 
> >> Cc: Dongjie (Jimmy) ; Peter Psenak
> >> ; Yingzhen Qu ; Gyan
> >> Mishra ; lsr@ietf.org
> >> Subject: Re: [Lsr] FW: New Version Notification for
> >> draft-bonica-lsr-ip-flexalgo-00.txt
> >>
> >> Jie,
> >>
> >> The scoop is different, for SR data plane entry uniqueness is in
> context of SR
> >> domain (SID = value + context), while for IP it is global to the
> routing domain,
> >> FIB entry is a destination, nothing more.
> >>
> >> Regards,
> >> Jeff
> >>
> >>> On Oct 10, 2020, at 05:47, Ron Bonica  wrote:
> >>>
> >>> Hi Jimmie,
> >>>
> >>> Inline.
> >>>
> >>> Ron
> >>>
> >>>
> >>> Juniper Business Use Only
> >>>
> >>> -Original Message-
> >>> From: Dongjie (Jimmy) 
> >>> Sent: Friday, October 9, 2020 11:06 PM
> >>> To: Peter Psenak ; Ron Bonica
> >>> ; Yingzhen Qu ; Gyan
> >>> Mishra 
> >>> Cc: lsr@ietf.org; Jeff Tantsura 
> >>> Subject: RE: [Lsr] FW: New Version Notification for
> >>> draft-bonica-lsr-ip-flexalgo-00.txt
> >>>
> >>> [External Email. Be cautious of content]
> >>>
> >>>
> >>> Hi Peter,
> >>>
> >>> Thanks for your reply. It aligns with my understanding of FAD, which
> is just a
> >> set of constraints for path computation. Thus one Flex-Algo ID could be
> used
> >> with multiple different data planes. Is this understanding correct?
> >>>
> >>> [RB] I never thought about this. Is there a use-case? I think that it
> will work,
> >> but I would have to try it before saying for sure.
> >>>
> >>> If so, my question is about the scenario below:
> >>>
> >>> A group of nodes in a network support FA-128, a sub-group of them bind
> >> FA-128 to SR SIDs, another sub-group of them bind FA-128 to IP address.
> When
> >> one node compute an SR path to a destination, can it compute the path
> to only
> >> pass the nodes which bind FA-128 to SR SIDs, and avoid the nodes which
> bind
> >> FA-128 to IP address?
> >>>
> >>> [RB] I don't think so. However, you could achieve the same outcome
> using link
> >> colors.
> >>>
> >>> If so, how could this node know the binding of FA to different data
> planes on
> >> other nodes?
> >>>
> >>> Best regards,
> >>> Jie
> >>>
>  -Original Message-
>  From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak
>  Sent: Friday, October 9, 2020 11:58 PM
>  To: Dongjie (Jimmy) ; Ron Bonica
>  ; Yingzhen Qu
>  ; Gyan Mishra 
>  Cc: lsr@ietf.org; Jeff Tantsura 
>  Subject: Re: [Lsr] FW: New Version Notification for
>  draft-bonica-lsr-ip-flexalgo-00.txt
> 
>  Hi Jimmy,
> 
> 
> >   On 09/10/2020 04:59, Dongjie (Jimmy) wrote:
> > Hi Ron,
> >
> > Thanks for explaining the difference between IP Flex-Algo and SR
> > Flex-algo. As
>  you said, the major difference is the data plane.
> >
> > If my understanding is correct, for one Flex-Algo to be used
> > correctly, the set
>  of nodes need to apply consistent constraints in computation, and
>  bind the FAD to the same data plane.
> >
> > Is it possible that 

Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt

[Robert Raszuk]

Peter,

If this is per app how are the constraints shared across apps ?

See we have single physical resources (for example links) and single
interface outbound queues. If I use per app flex-algo and do not have
central controller how is this going to work in practice for any network
which attempts to use more then one forwarding schema with dynamic
constraints ?

Many thx,
R.



On Tue, Oct 13, 2020 at 10:52 AM Peter Psenak  wrote:

> Hi Jimmy,
>
> On 13/10/2020 10:02, Dongjie (Jimmy) wrote:
> > Hi Peter,
> >
> > Thanks for your reply. Please see further inline:
> >
> >> -Original Message-
> >> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak
> >> Sent: Monday, October 12, 2020 4:39 PM
> >> To: Dongjie (Jimmy) ; Ron Bonica
> >> ; Yingzhen Qu ; Gyan
> >> Mishra 
> >> Cc: lsr@ietf.org; Jeff Tantsura 
> >> Subject: Re: [Lsr] FW: New Version Notification for
> >> draft-bonica-lsr-ip-flexalgo-00.txt
> >>
> >> Hi Jimmy,
> >>
> >> On 10/10/2020 05:05, Dongjie (Jimmy) wrote:
> >>> Hi Peter,
> >>>
> >>> Thanks for your reply. It aligns with my understanding of FAD, which
> is just a
> >> set of constraints for path computation. Thus one Flex-Algo ID could be
> used
> >> with multiple different data planes. Is this understanding correct?
> >>
> >> correct.
> >>
> >>>
> >>> If so, my question is about the scenario below:
> >>>
> >>> A group of nodes in a network support FA-128, a sub-group of them bind
> >> FA-128 to SR SIDs, another sub-group of them bind FA-128 to IP address.
> >>
> >> just to use the correct terminology, we should use "participate"
> instead of
> >> "support".
> >
> > Agree.
> >
> >>
> >>> When one node compute an SR path to a destination, can it compute the
> path
> >> to only pass the nodes which bind FA-128 to SR SIDs, and avoid the
> >> nodes >which bind FA-128 to IP address? If so, how could this node know
> the
> >> binding of FA to different data planes on other nodes?
> >>
> >> again, it is the participation problem.
> >>
> >> Nodes that participate in the SR Flex-algo 128 will advertise the
> participation
> >> using the SR-Algorithm Sub-TLV. Only these nodes will be used during
> the SR
> >> flex-algo computation for algo 128.
> >>
> >> Nodes that participate in IP flex-algo 128 will advertise the
> participation using
> >> the IGP Algorithm Sub-TLV. Only these nodes will be used during the IP
> flex-algo
> >> computation for algo 128.
> >
> > Agree that if participation to Flex-Algo is advertised in a data plane
> specific manner, then path computation with Flex-Algo constraints could be
> done only using nodes which bind the Flex-Algo to the same data plane.
>
> it's per app, not per data plane, but yes, that is what the base
> flex-algo spec mandates.
>
> >
> > As Robert asked and you confirmed, this implies each data plane needs to
> be treated as an independent application of Flex-Algo. We have SR-Algorithm
> sub-TLV and IP Algorithm sub-TLV, while there are actually more data planes
> to be considered: SR-MPLS, SRv6, IPv4, IPv6, etc., does this mean that
> Flex-Algo participation needs to be advertised for SR-MPLS, SRv6, IPv4,
> IPv6, etc. separately?
>
> yes, it needs to be advertised per app. We have SR specific algo
> participation, we need one for IP as proposed in Ron's draft.
>
> Regarding IPv4 vs IPv6, it's up to the authors whether they want to make
> the participation for IP flex-algo topology specific or topology
> independent, both could work.
>
> Here's the text from the base flerx-algo draft:
>
> 10.2.  Advertisement of Node Participation for Other Applications
>
> This section describes considerations related to how other
> applications can advertise their participation in a specific Flex-
> Algorithm.
>
> Application-specific Flex-Algorithm participation advertisements MAY
> be topology specific or MAY be topology independent, depending on the
> application itself.
>
> Application-specific advertisement for Flex-Algorithm participation
> MUST be defined for each application and is outside of the scope of
> this document.
>
> thanks,
> Peter
>
>
> >
> > Best regards,
> > Jie
> >
> >>
> >> thanks,
> >> Peter
> >>
> >>>
> >>> Best regards,
> >>> Jie
> >>>
>  -Original Message-
>  From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak
>  Sent: Friday, October 9, 2020 11:58 PM
>  To: Dongjie (Jimmy) ; Ron Bonica
>  ; Yingzhen Qu
>  ; Gyan Mishra 
>  Cc: lsr@ietf.org; Jeff Tantsura 
>  Subject: Re: [Lsr] FW: New Version Notification for
>  draft-bonica-lsr-ip-flexalgo-00.txt
> 
>  Hi Jimmy,
> 
> 
>  On 09/10/2020 04:59, Dongjie (Jimmy) wrote:
> > Hi Ron,
> >
> > Thanks for explaining the difference between IP Flex-Algo and SR
> > Flex-algo. As
>  you said, the major difference is the data plane.
> >
> > If my understanding is correct, for one Flex-Algo to be used
> > correctly, the set
>  of nodes 

Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

[Robert Raszuk]

Aijun,

Regarding your appendix A -

* How can we "rebuild" topology based on comparison of prefixes and rtr-id
?

* If link between S1 & S2 is not in LSDB there may be a valid operational
reasons for it. "Rebuilding it" will be actually harmful from all points of
view.

* You should be exporting topology from all areas not just from backbone
and guessing the topology based on the prefix to rtr_id associations

* Imaging someone is using multiaccess in areas. Are you also going to
rebuild DR & BDR ?

I must agree with comments from Peter & Les here.

Cheers,
R.





On Mon, Oct 19, 2020 at 12:11 PM Aijun Wang  wrote:

> Hi. Peter, Les:
>
> We have defined many extensions for protocol, but only a small part of
> them are deployed. Have you ever considered the reason?
>
> Adding more contents for their  potential usages can certainly be helpful
> for their influences, or else, they will just stay at the IETF repository.
>
> More replies inline below.
>
>
>
> Aijun Wang
> China Telecom
>
> > On Oct 19, 2020, at 17:14, Peter Psenak  40cisco@dmarc.ietf.org> wrote:
> >
> > Aijun,
> >
> >> On 19/10/2020 09:32, Les Ginsberg (ginsberg) wrote:
> >> Aijun -
> >> I am not going to continue these side discussions with you.
> >> The primary purpose of the protocol extensions are as stated in the
> draft Introduction. This is analogous to the use cases for the equivalent
> extensions for IS-IS already approved in RFC 7794. We need the equivalent
> in OSPF.
> >> You can show that you are listening to the concerns of WG members by
> removing the Appendices - in which case you have (I believe) broad support
> for moving the draft forward.
> >
> > I agree with Les.
> >
> > As a co-author, I have asked you several times to get rid of the use
> case described in appendix.
> [WAJ] Moving the expansion of this use case from body part of this draft
> to its appendix is our initial consensus, not remove it totally. We have
> discussed intensely for its application in vary situations. The discussion
> results are stated clearly in the appendix.
> Wish to hear more technical analysis/comments for the current statements
> of this part from other experts, or from you if you have fresh
> consideration.
>
> > Trying to use prefix advertisement to derive topological data is simply
> broken. The reason we are adding the prefix originator extension to OSPF is
> NOT the broken use case in the appendix of the draft.
> >
> > thanks,
> > Peter
> >
> >
> >
> >> You can then write a separate draft to discuss other use cases and
> allow the WG to discuss those other use cases w/o preventing the extensions
> from being approved and deployed for the use cases which have already been
> demonstrated as useful by IS-IS.
> >> If you remove the Appendices I can support the draft.
> >> If you do not remove the Appendices I cannot support the draft.
> >> Please discuss this with your co-authors and come to consensus on your
> next step.
> >>Les
> >>> -Original Message-
> >>> From: Aijun Wang 
> >>> Sent: Monday, October 19, 2020 12:06 AM
> >>> To: Les Ginsberg (ginsberg) ; 'Christian Hopps'
> >>> 
> >>> Cc: 'John E Drake' ; lsr-cha...@ietf.org;
> lsr@ietf.org;
> >>> 'Jeff Tantsura' ; draft-ietf-lsr-ospf-prefix-
> >>> origina...@ietf.org; lsr-...@ietf.org
> >>> Subject: RE: [Lsr] WG Last Call
> draft-ietf-lsr-ospf-prefix-originator-06
> >>>
> >>> Hi, Les:
> >>>
> >>> As I stated clearly before, the appendix described in the draft is not
> the new
> >>> use case. It is the start point of this draft.
> >>> Have you noticed that the introduction part is not the final usage of
> such
> >>> protocol extension information?
> >>> Certainly, we will not expand all the possible use cases in very
> detail, but
> >>> putting some of them(some interesting, prominent use cases) in the
> >>> appendix will not hamper the protocol extension itself.
> >>>
> >>> If the statements/descriptions in the appendix are not correct, we can
> fix it,
> >>> or remove it finally.  If not, why not let it be for reference to the
> user of such
> >>> protocol extension?
> >>> For the body part of this draft, we are also welcome comments.
> >>>
> >>> More replies inline below[WAJ]
> >>>
> >>> Best Regards
> >>>
> >>> Aijun Wang
> >>> China Telecom
> >>>
> >>> -Original Message-
> >>> From: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] On Behalf Of
> Les
> >>> Ginsberg (ginsberg)
> >>> Sent: Monday, October 19, 2020 2:15 PM
> >>> To: Aijun Wang ; 'Christian Hopps'
> >>> 
> >>> Cc: 'John E Drake' ; lsr-cha...@ietf.org; 'Les
> Ginsberg
> >>> (ginsberg)' ; lsr@ietf.org; 'Jeff
> >>> Tantsura' ; draft-ietf-lsr-ospf-prefix-
> >>> origina...@ietf.org; lsr-...@ietf.org
> >>> Subject: Re: [Lsr] WG Last Call
> draft-ietf-lsr-ospf-prefix-originator-06
> >>>
> >>> Aijun -
> >>>
> >>> The "use case" for the protocol extensions is clearly stated in the
> >>> Introduction:
> >>>
> >>> "The primary use case for the extensions proposed in this document is
> >>>to be able 

Re: [Lsr] Fwd: I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

[Robert Raszuk]

Hi Tony & WG,

The changes which went into sections 4.3.2 & 4.4.13 do address my
suggestions made earlier to the list. So I do support the current version.

With the option of having a configurable area prefix this delivers quite a
powerful extension.

Also the current text says:

"Other uses of the Area SID are outside the scope of this document. "

Maybe we could state instead:

Other uses of the Area SID and area prefix are outside the scope of this
document.

Many thx,
R.


On Mon, Aug 24, 2020 at 7:02 PM  wrote:

>
> Hi folks,
>
> This updated draft has been published for a few weeks now.  We would like
> to solicit your opinion on this.  In particular, we have changed the
> encoding of the Area SID.  Do you find this encoding adequate and
> appropriate?
>
> Thanks,
> Tony
>
>
> Begin forwarded message:
>
> *From: *internet-dra...@ietf.org
> *Subject: **I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt*
> *Date: *August 5, 2020 at 1:17:39 PM PDT
> *To: *
> *Cc: *lsr@ietf.org
> *Reply-To: *internet-dra...@ietf.org, lsr@ietf.org
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Link State Routing WG of the IETF.
>
>Title   : Area Proxy for IS-IS
>Authors : Tony Li
>  Sarah Chen
>  Vivek Ilangovan
>  Gyan S. Mishra
> Filename: draft-ietf-lsr-isis-area-proxy-03.txt
> Pages   : 19
> Date: 2020-08-05
>
> Abstract:
>   Link state routing protocols have hierarchical abstraction already
>   built into them.  However, when lower levels are used for transit,
>   they must expose their internal topologies to each other, leading to
>   scale issues.
>
>   To avoid this, this document discusses extensions to the IS-IS
>   routing protocol that would allow level 1 areas to provide transit,
>   yet only inject an abstraction of the level 1 topology into level 2.
>   Each level 1 area is represented as a single level 2 node, thereby
>   enabling greater scale.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-area-proxy/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-03
> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-area-proxy-03
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-isis-area-proxy-03
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
> ___
> I-D-Announce mailing list
> i-d-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> ___
> 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] WG Last Call for draft-ietf-lsr-flex-algo

[Robert Raszuk]

Les,

I think this is not very obvious as Tony is pointing out.

See RFC 8570 says:

  TypeDescription
  
   33 Unidirectional Link Delay

   34 Min/Max Unidirectional Link Delay


That means that is someone implementing it reads text in this draft
literally (meaning Minimum value of Unidirectional Link Delay) it may pick
minimum value from ULD type 33 :)

If you want to be precise this draft may say minimum value of Min/Max
Unidirectional Link Delay (34) and be done.

That's all.

Cheers,
R.



On Tue, Aug 18, 2020 at 6:04 PM Les Ginsberg (ginsberg)  wrote:

> Tony –
>
>
>
> As an author of both RFC 8570 and I-D.ietf-isis-te-app, I am not sure why
> you are confused – nor why you got misdirected to code point 33.
>
>
>
> RFC 8570 (and its predecessor RFC 7810) define:
>
>
>
> 34   Min/Max Unidirectional Link Delay
>
>
>
> This sub-TLV contains two values:
>
>
>
> “Min Delay:  This 24-bit field carries the minimum measured link delay
>
>   value (in microseconds) over a configurable interval, encoded as
>
>   an integer value.
>
>
>
>Max Delay:  This 24-bit field carries the maximum measured link delay
>
>   value (in microseconds) over a configurable interval, encoded as
>
>   an integer value.”
>
>
>
> It seems clear to me that the flex-draft is referring to Min
> Unidirectional Link Delay in codepoint 34.
>
>
>
> I agree it is important to be unambiguous in specifications, but I think
> Peter has been very clear.
>
> Please explain how you managed to end up at code point 33??
>
>
>
>Les
>
>
>
>
>
>
>
> *From:* Lsr  *On Behalf Of * tony...@tony.li
> *Sent:* Tuesday, August 18, 2020 7:44 AM
> *To:* Peter Psenak (ppsenak) 
> *Cc:* lsr@ietf.org; lsr-...@ietf.org; Christian Hopps ;
> Acee Lindem (acee) ; draft-ietf-lsr-flex-algo@ietf.org
> *Subject:* Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo
>
>
>
>
>
> Hi Peter,
>
>
>
>
>
> section 5.1 of the draft-ietf-lsr-flex-algo says:
>
>
> Min Unidirectional Link Delay as defined in [I-D.ietf-isis-te-app].
>
> We explicitly say "Min Unidirectional Link Delay", so this cannot be mixed
> with other delay values (max, average).
>
>
>
>
>
> The problem is that that does not exactly match “Unidirectional Link
> Delay” or “Min/Max Unidirectional Link Delay”, leading to the ambiguity.
> Without a clear match, you leave things open to people guessing. Now, it’s
> a metriic, so of course, you always want to take the min.  So type 33 seems
> like a better match.
>
>
>
>
>
> section 7.3. of ietf-isis-te-app says:
>
> Type   Description  Encoding
>Reference
> -
> 34  Min/Max Unidirectional Link DelayRFC8570
>
>
>
>
>
> And it also says:
>
>
>
> 33  Unidirectional Link DelayRFC8570 
> 
>
>
>
>
>
> This does not help.
>
>
>
>
>
> So, IMHO what we have now is correct and sufficient, but I have no issue
> adding the text you proposed below.
>
>
>
>
>
> What you have now is ambiguous. We have a responsibility, as writers of
> specifications, to be precise and clear.  We are not there yet.
>
>
>
>
>
> BTW, before I posted 09 version of flex-algo draft, I asked if you were
> fine with just referencing ietf-isis-te-app in 5.1. I thought you were, as
> you did not indicate otherwise.
>
>
>
>
>
> My bad, I should have pressed the issue.
>
>
>
>
>
> Anyway, I consider this as a pure editorial issue and hopefully not
> something that would cause you to object the WG LC of the flex-algo draft..
>
>
>
>
>
> I’m sorry, I think that this is trivially resolved, but important
> clarification.
>
>
>
> You also have an author’s email that is bouncing, so at least one more
> spin is required.
>
>
>
> Sorry,
>
> Tony
>
>
> ___
> 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] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

[Robert Raszuk]

Dear WG,

The draft in question does not describe even a single practical use case.

While it describes the mechanics on how to construct the new model of the
abstraction it fails to prove we need it.

Not everything which can be invented should be standardized or implemented
therefore until the document extensively describes the real use cases with
justification why use of areas may not be sufficient for such use cases I
don't think LSR WG should adopt it.

Regards,
Robert.

On Tue, Aug 18, 2020 at 4:17 PM Acee Lindem (acee)  wrote:

>
>
> Based on the discussions in the last meeting and on the mailing list
> regarding draft-chen-isis-ttz-11, the chairs feel that there are enough
> differences with draft-ietf-lsr-isis-area-proxy-03 and in the community to
> consider advancing it independently on the experimental track.
>
>
>
> These differences include abstraction at arbitrary boundaries and IS-IS
> extensions for smooth transition to/from zone abstraction.
>
>
>
> We are now starting an LSR WG adoption call for
> draft-chen-isis-ttz-11.txt. Please indicate your support or objection to
> adoption prior to Tuesday, September 2nd, 2020.
>
>
>
> Thanks,
>
> Acee and Chris
>
>
> ___
> 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] WG Last Call for draft-ietf-lsr-flex-algo

[Robert Raszuk]

Hi Tony,

I am not sure what the deal is :)

But fact is that we never defined a type which this draft is referring to

"Min Unidirectional Link Delay" just does not exist in any IANA registry so
even any search for that will fail.

Perhaps authors assumed that:

Min/Max Unidirectional Link Delay means both "Min Unidirectional Link
Delay" & "Max Unidirectional Link Delay" but this is just asking
for ambiguity.

Cheers,
R.

On Tue, Aug 18, 2020 at 7:02 PM  wrote:

>
> Robert,
>
> Thank you, exactly.
>
> We just need a clarification of the document.  I don’t understand why this
> is such a big deal.
>
> Tony
>
>
> On Aug 18, 2020, at 9:22 AM, Robert Raszuk  wrote:
>
> Les,
>
> I think this is not very obvious as Tony is pointing out.
>
> See RFC 8570 says:
>
>   TypeDescription
>   
>33 Unidirectional Link Delay
>
>34 Min/Max Unidirectional Link Delay
>
>
> That means that is someone implementing it reads text in this draft
> literally (meaning Minimum value of Unidirectional Link Delay) it may pick
> minimum value from ULD type 33 :)
>
> If you want to be precise this draft may say minimum value of Min/Max
> Unidirectional Link Delay (34) and be done.
>
> That's all.
>
> Cheers,
> R.
>
>
>
> On Tue, Aug 18, 2020 at 6:04 PM Les Ginsberg (ginsberg)  40cisco@dmarc.ietf.org> wrote:
>
>> Tony –
>>
>>
>>
>> As an author of both RFC 8570 and I-D.ietf-isis-te-app, I am not sure why
>> you are confused – nor why you got misdirected to code point 33.
>>
>>
>>
>> RFC 8570 (and its predecessor RFC 7810) define:
>>
>>
>>
>> 34   Min/Max Unidirectional Link Delay
>>
>>
>>
>> This sub-TLV contains two values:
>>
>>
>>
>> “Min Delay:  This 24-bit field carries the minimum measured link delay
>>
>>   value (in microseconds) over a configurable interval, encoded as
>>
>>   an integer value.
>>
>>
>>
>>Max Delay:  This 24-bit field carries the maximum measured link delay
>>
>>   value (in microseconds) over a configurable interval, encoded as
>>
>>   an integer value.”
>>
>>
>>
>> It seems clear to me that the flex-draft is referring to Min
>> Unidirectional Link Delay in codepoint 34.
>>
>>
>>
>> I agree it is important to be unambiguous in specifications, but I think
>> Peter has been very clear.
>>
>> Please explain how you managed to end up at code point 33??
>>
>>
>>
>>Les
>>
>>
>>
>>
>>
>>
>>
>> *From:* Lsr  *On Behalf Of * tony...@tony.li
>> *Sent:* Tuesday, August 18, 2020 7:44 AM
>> *To:* Peter Psenak (ppsenak) 
>> *Cc:* lsr@ietf.org; lsr-...@ietf.org; Christian Hopps ;
>> Acee Lindem (acee) ;
>> draft-ietf-lsr-flex-algo@ietf.org
>> *Subject:* Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo
>>
>>
>>
>>
>>
>> Hi Peter,
>>
>>
>>
>>
>>
>> section 5.1 of the draft-ietf-lsr-flex-algo says:
>>
>>
>> Min Unidirectional Link Delay as defined in [I-D.ietf-isis-te-app].
>>
>> We explicitly say "Min Unidirectional Link Delay", so this cannot be
>> mixed with other delay values (max, average).
>>
>>
>>
>>
>>
>> The problem is that that does not exactly match “Unidirectional Link
>> Delay” or “Min/Max Unidirectional Link Delay”, leading to the ambiguity.
>> Without a clear match, you leave things open to people guessing. Now, it’s
>> a metriic, so of course, you always want to take the min.  So type 33 seems
>> like a better match.
>>
>>
>>
>>
>>
>> section 7.3. of ietf-isis-te-app says:
>>
>> Type   Description  Encoding
>>Reference
>> -
>> 34  Min/Max Unidirectional Link DelayRFC8570
>>
>>
>>
>>
>>
>> And it also says:
>>
>>
>>
>> 33  Unidirectional Link DelayRFC8570 
>> <https://tools.ietf..org/html/rfc8570>
>>
>>
>>
>>
>>
>> This does not help.
>>
>>
>>
>>
>>
>> So, IMHO what we have now is correct and sufficient, but I have no issue
>> adding the text you proposed below.
>>
>&g

Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

[Robert Raszuk]

Les,

> and conclude that this is really “Unidirectional Link Delay” is a leap
that I cannot follow.

I would never suggest to do that.

My suggestion was to rename "Min Unidirectional Link Delay" to "minimum
value of Min/Max Unidirectional Link Delay" and move on.

Cheers,
R.



On Tue, Aug 18, 2020 at 9:18 PM Les Ginsberg (ginsberg) 
wrote:

> Tony/Robert –
>
>
>
> Whatever clarification Peter may choose to make would be fine – but I do
> question your casual ignoring of adjectives. 
>
>
>
> There are three values being advertised:
>
>
>
> 33 - Unidirectional Link Delay
>
> 34 – Min/Max Unidirectional Link Delay
>
>  Meaning two values are advertised in this codepoint:
>
>  Min Unidirectional Link Delay
>
>  Max Unidirectional Link Delay
>
>
>
> Now, the flex algo draft states: Min Unidirectional Link Delay
>
>
>
> If you want to argue that “Min Unidirectional Link Delay” != “Min/Max
> Unidirectional Link Delay” – I think you are pedantically correct.
>
>
>
> But how that leads you to simply truncate “Min” and conclude that this is
> really “Unidirectional Link Delay” is a leap that I cannot follow.
>
>
>
> Perhaps you don’t really like the fact that RFC 8570 encoding combined
> Min/Max in a single codepoint – but that ship sailed years ago.
>
>
>
> Given that RFC 8570 is very clear in showing that the encoding includes:
>
>
>
> 
>
>0   1   2   3
>
>  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> |   Type| Length|
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> |A| RESERVED|   Min Delay   |
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> |   RESERVED|   Max Delay   |
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> 
>
>
>
> my ability to see your POV is somewhat limited.
>
>
>
> Perhaps you could own that a more careful reading is possible?
>
>
>
>Les
>
>
>
>
>
> *From:* Lsr  *On Behalf Of * tony...@tony.li
> *Sent:* Tuesday, August 18, 2020 10:03 AM
> *To:* Robert Raszuk 
> *Cc:* Christian Hopps ;
> draft-ietf-lsr-flex-algo@ietf.org; Les Ginsberg (ginsberg)  40cisco@dmarc.ietf.org>; lsr@ietf.org; lsr-...@ietf.org; Acee Lindem
> (acee) ; Peter Psenak (ppsenak) 
> *Subject:* Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo
>
>
>
>
>
> Robert,
>
>
>
> Thank you, exactly.
>
>
>
> We just need a clarification of the document.  I don’t understand why this
> is such a big deal.
>
>
>
> Tony
>
>
>
>
>
> On Aug 18, 2020, at 9:22 AM, Robert Raszuk  wrote:
>
>
>
> Les,
>
>
>
> I think this is not very obvious as Tony is pointing out.
>
>
>
> See RFC 8570 says:
>
>
>
>   TypeDescription
>
>   
>
>33 Unidirectional Link Delay
>
>
>
>34 Min/Max Unidirectional Link Delay
>
>
>
> That means that is someone implementing it reads text in this draft
> literally (meaning Minimum value of Unidirectional Link Delay) it may pick
> minimum value from ULD type 33 :)
>
>
>
> If you want to be precise this draft may say minimum value of Min/Max
> Unidirectional Link Delay (34) and be done.
>
>
>
> That's all.
>
>
>
> Cheers,
> R.
>
>
>
>
>
>
>
> On Tue, Aug 18, 2020 at 6:04 PM Les Ginsberg (ginsberg)  40cisco@dmarc.ietf.org> wrote:
>
> Tony –
>
>
>
> As an author of both RFC 8570 and I-D.ietf-isis-te-app, I am not sure why
> you are confused – nor why you got misdirected to code point 33.
>
>
>
> RFC 8570 (and its predecessor RFC 7810) define:
>
>
>
> 34   Min/Max Unidirectional Link Delay
>
>
>
> This sub-TLV contains two values:
>
>
>
> “Min Delay:  This 24-bit field carries the minimum measured link delay
>
>   value (in microseconds) over a configurable interval, encoded as
>
>   an integer value.
>
>
>
>Max Delay:  This 24-bit field carries the maximum measured link delay
>
>   value (in microseconds) over a configurable interval, encoded as
>
>   an integer value.”
>
>
>
> It seems clear to me that the flex-draft is referring to Min
> Unidirectional Link Delay in codepoint 34.
>
>
>
> I agree it is

Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

[Robert Raszuk]

Hi Richard,

I understand that these days you say "5G" and you are done for any use
case. :)

So I read this paper:
https://www.etsi.org/images/files/ETSIWhitePapers/etsi_wp28_mec_in_5G_FINAL..pdf

There is nothing there which would indicate a need for zone or even area
separation to effectively deploy MEC. To me MEC data path can be
constructed with a form of encapsulation in an arbitrary fashion. In fact I
could say the more underlay walls you implement the harder it becomes to
construct arbitrary MEC mesh.

At least for LSR WG if I were to justify any work here like TTZ I would
explain why Multi access edge computing requires IGP/underlay type of
separation and moreover why such separation can not be constructed with
areas or levels.

Thx,
R.

On Wed, Aug 19, 2020 at 5:18 AM Richard Li  wrote:

> This is a use case:
>
>
>
> The user plane of 5G is distributed, and MEC is deployed as part of the
> user plane to provide some functions at Access Aggregation Ring or Regional
> Aggregation Ring or at the border between Regional Aggregation Ring and the
> National Core. Using TTZ, MEC or part of it can be virtualized and
> topologically simplified. Note that the outside really doesn’t care about
> the internals of MEC.
>
>
>
>
>
> Thanks,
>
>
>
> Richard
>
>
>
>
>
>
>
> *From:* Lsr  *On Behalf Of * Robert Raszuk
> *Sent:* Tuesday, August 18, 2020 2:25 PM
> *To:* Acee Lindem (acee) 
> *Cc:* lsr@ietf.org
> *Subject:* Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent
> Zone" - draft-chen-isis-ttz-11.txt
>
>
>
> Dear WG,
>
>
>
> The draft in question does not describe even a single practical use case.
>
>
>
> While it describes the mechanics on how to construct the new model of the
> abstraction it fails to prove we need it.
>
>
>
> Not everything which can be invented should be standardized or implemented
> therefore until the document extensively describes the real use cases with
> justification why use of areas may not be sufficient for such use cases I
> don't think LSR WG should adopt it.
>
>
>
> Regards,
> Robert.
>
>
>
> On Tue, Aug 18, 2020 at 4:17 PM Acee Lindem (acee)  40cisco@dmarc.ietf.org> wrote:
>
>
>
> Based on the discussions in the last meeting and on the mailing list
> regarding draft-chen-isis-ttz-11, the chairs feel that there are enough
> differences with draft-ietf-lsr-isis-area-proxy-03 and in the community to
> consider advancing it independently on the experimental track.
>
>
>
> These differences include abstraction at arbitrary boundaries and IS-IS
> extensions for smooth transition to/from zone abstraction.
>
>
>
> We are now starting an LSR WG adoption call for
> draft-chen-isis-ttz-11.txt. Please indicate your support or objection to
> adoption prior to Tuesday, September 2nd, 2020.
>
>
>
> Thanks,
>
> Acee and Chris
>
>
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr=02%7C01%7Crichard.li%40futurewei..com%7Ccfd66b6c7fc54591ec0408d843bd4046%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637333827425070909=UgI0%2Bd6TyQtenEEoyU97R2qQJBlzRYuqS4XxhFjjcYA%3D=0>
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt

[Robert Raszuk]

Hi,

> It uses the HBH option

Currently Ron's proposal seems to work well for both IPv4 and IPv6
addresses. I hope this discussion will not try to derail it to IPv6 only
track.

I see no issue with loopback to flexible algorithm mapping in 1:1 fashion.

I do however see some issues in deploying such technology as it will only
work well if *all* nodes in the network support this new functionality. In
contrast in SR world or control plane based TE I proposed or any
encapsulation based proposal only anchor nodes need to support the new
functionality while rest of the network does not need to be even aware
about it.

Many thx,
R.


On Wed, Sep 30, 2020 at 6:10 AM Huzhibo  wrote:

> Hi Joel:
>
> For details about the method defined in RFC 6550. It uses the HBH
> option to carry the RPLInstaceID. The RPLInstaceID and FlexAlgoID are
> similar.
>
> Thanks
>
> Zhibo
>
> -Original Message-
> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Joel M. Halpern
> Sent: Wednesday, September 30, 2020 12:05 PM
> Cc: lsr@ietf.org
> Subject: Re: [Lsr] New Version Notification for
> draft-bonica-lsr-ip-flexalgo-00.txt
>
> I am missing something in this discussion of multiple algorithms.
>
> My understanding of flex-algo whether for MPLS, SRv6, SRH, or IPv6, is
> that you need to associated a forwarding label (e.g. MPLS label or IPv6
> address) with a specific algorithm so that you can compute the next hope
> for the forwarding label using the proper algorithm.  Then when a packet
> arrives, it is simply forwarded according to the forwarding table (e.g.
> FIB, LIB, ..)
>
> If that is so, then I do not understand how a given prefix can be safely
> associated with more than one algorithm.  I could imagine doing several
> calculations according to different algorithms.  But how do you decide
> which one applies to the packet?  As far as I know, flex-algo does not look
> at the QoS/CoS/ToS bits.
>
> Yours,
> Joel
>
> PS: I will admit that it took until  an operator described some
> "interesting" constraints before I understood why one would even do this.
>
> On 9/29/2020 11:50 PM, Huzhibo wrote:
> > Hi.
> >
> > Associating multiple algorithms with a given prefix is an interesting
> topic, and I think this can simplify the complexity of FlexAlgo. I wonder
> if the author would consider using cases with multiple algorithms with a
> given prefix.
> >
> > Thanks
> >
> > ZHibo
> >
> > -Original Message-
> > From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of tony...@tony.li
> > Sent: Tuesday, September 29, 2020 10:05 PM
> > To: Ron Bonica 
> > Cc: lsr@ietf.org
> > Subject: Re: [Lsr] New Version Notification for
> > draft-bonica-lsr-ip-flexalgo-00.txt
> >
> >
> > Ron,
> >
> > This is nice. It makes it clear that constraint based path computation
> need not have MPLS overhead for those that don’t want it.
> >
> > One thing that you don’t talk about is how this gets used, tho that may
> be blindingly obvious: you’ll need all nodes placing their prefixes in the
> RIB/FIB, where it will need to be selected over other path computation for
> the same prefixes.  This somewhat precludes the possibility of a given
> prefix being useful in multiple flex-algos.
> >
> > More text on application would be most welcome, just to ensure that
> we’re on the same page.
> >
> > Tony
> >
> >
> >> On Sep 29, 2020, at 6:37 AM, Ron Bonica  40juniper@dmarc.ietf.org> wrote:
> >>
> >>
> >> Please review and comment
> >>
> >>Ron
> >>
> >>
> >>
> >> Juniper Business Use Only
> >>
> >>> -Original Message-
> >>> From: internet-dra...@ietf.org 
> >>> Sent: Tuesday, September 29, 2020 9:36 AM
> >>> To: Parag Kaneriya ; Shraddha Hegde
> >>> ; Ron Bonica ; Rajesh M
> >>> ; William Britto A J 
> >>> Subject: New Version Notification for
> >>> draft-bonica-lsr-ip-flexalgo-00.txt
> >>>
> >>> [External Email. Be cautious of content]
> >>>
> >>>
> >>> A new version of I-D, draft-bonica-lsr-ip-flexalgo-00.txt
> >>> has been successfully submitted by Ron Bonica and posted to the IETF
> >>> repository.
> >>>
> >>> Name:   draft-bonica-lsr-ip-flexalgo
> >>> Revision:   00
> >>> Title:  IGP Flexible Algorithms (Flexalgo) In IP Networks
> >>> Document date:  2020-09-29
> >>> Group:  Individual Submission
> >>> Pages:  14
> >>> URL:
> https://urldefense.com/v3/__https://www.ietf.org/id/draft-bonica-
> >>> lsr-ip-flexalgo-00.txt__;!!NEt6yMaO-gk!X7PVDP-
> >>> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck80Zbjoij$
> >>> Status:
> >>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-b
> >>> o
> >>> nica-lsr-
> >>> ip-flexalgo/__;!!NEt6yMaO-gk!X7PVDP-
> >>> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck8x7e5ZqI$
> >>> Htmlized:
> >>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/dr
> >>> a
> >>> ft-
> >>> bonica-lsr-ip-flexalgo__;!!NEt6yMaO-gk!X7PVDP-
> >>> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck82w_6CyU$
> >>> Htmlized:
> 

Re: [Lsr] New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt

[Robert Raszuk]

Peter,

Granted - you can do this with MPLS encapsulation.

But if you are doing native IP forwarding or SRv6 I am still unclear.

Imagine you get allocated by RIR say IPv4 /16 or IPv6  /32.

So you take some part of that block and use it for flex algo next hops ..
flood it via IGP and have flex algo F1 running/enabled on some nodes. So
far so good.

But what prevents the non enabled nodes to still use for those next hops
less specific say /8 from someone else in the Internet ?

Sure in some implementations (we both are a bit familiar with) we have a
way to track that next hop is declared unreachable if it was learned from
prefix shorter then /X. But this constrain seems to be not documented
anywhere in respect to flex algo. At min I think IP flex algo use should
make it clear and make it also a MUST.

So my point is that for SRv6 or Ron's proposal next hop MUST be only
learned via local IGP or be of no less then /X to be used for BGP next hop
resolution.

Many thx,
R,







On Wed, Sep 30, 2020 at 5:18 PM Peter Psenak  wrote:

> Robert,
>
> On 30/09/2020 16:28, Robert Raszuk wrote:
> > Peter,
> >
> > Let's see if we are talking about the same thing ...
> >
> > Take SRv6 as example ... You can run flex algorithm only on selected
> > segment endpoints as you do encap and dst rewrite. So rest of the
> > network (P/transit routers) do not need to have a clue about any
> > flex-algo other then plain old SPF.
>
> if all transit nodes do not participate/understand flex-algo, you will
> not be able to route the traffic between the segment endpoints based on
> the flex-algo, in other words algo specific locators will not be reachable.
>
> >
> > Now in Ron's case where there is no encap and you are applying flex-algo
> > to naked packets don't you think there is a difference and a bit of
> > deployment difficulty to make it work ?
>
> it is the same as with SRv6 locator - prefix associated with algorithm,
> with some additional SRv6 data. From the flex-algo calculation and
> forwarding perspective there is no difference.
>
> >
> > So assume one P node will not support it. This is native IP switching so
> > BGP advertises routes with new flex-algo next hop. If that next hop is
> > unreachable as signalling to that flex algo loopback was not understood
> > by P (new signalling extension) packets will be dropped.
>
> such P node would never ever be in the flex-algo forwarding path for
> prefix associated with flex-algo. We are talking underlay here, not BGP.
> BGP service allocates the SRV6 SID from the algo specific locator in
> case of SRv6. It can pick the NH as algo specific prefix I assume and
> the rest is the same.
>
> >
> > But what if that next hop would happen to be covered by some aggregate
> > route not subject perhaps to intended IP TE ?
>
> aggregation needs to be algo aware for it to work.
>
> thanks,
> Peter
>
>
> >
> > Cheers,
> > R.
> >
> >
> >
> > On Wed, Sep 30, 2020 at 2:11 PM Peter Psenak  > <mailto:ppse...@cisco.com>> wrote:
> >
> > Hi Robert,
> >
> > On 30/09/2020 09:28, Robert Raszuk wrote:
> >  > Hi,
> >  >
> >  >  > It uses the HBH option
> >  >
> >  > Currently Ron's proposal seems to work well for both IPv4 and IPv6
> >  > addresses. I hope this discussion will not try to derail it to
> > IPv6 only
> >  > track.
> >  >
> >  > I see no issue with loopback to flexible algorithm mapping in 1:1
> > fashion.
> >  >
> >  > I do however see some issues in deploying such technology as it
> will
> >  > only work well if *all* nodes in the network support this new
> >  > functionality. In contrast in SR world or control plane based TE I
> >  > proposed or any encapsulation based proposal only anchor nodes
> > need to
> >  > support the new functionality while rest of the network does not
> > need to
> >  > be even aware about it.
> >
> > above is not really true.
> >
> > Algo participation needs to be signaled, one way or the other. It's
> > done
> > for SR as well. There is no need for all routers to understand
> > flex-algo, as only those that participate (and as a result also
> > understand it) will be used during the flex-algo path computation and
> > consequently flex-algo specific forwarding. This applies to
> > flex-algo in
> > general, regardless of the data plane being used.
> >
> > thanks,
> > Peter
> >
>

Re: [Lsr] New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt

[Robert Raszuk]

Peter,

Let's see if we are talking about the same thing ...

Take SRv6 as example ... You can run flex algorithm only on selected
segment endpoints as you do encap and dst rewrite. So rest of the network
(P/transit routers) do not need to have a clue about any flex-algo
other then plain old SPF.

Now in Ron's case where there is no encap and you are applying flex-algo to
naked packets don't you think there is a difference and a bit of deployment
difficulty to make it work ?

So assume one P node will not support it. This is native IP switching so
BGP advertises routes with new flex-algo next hop. If that next hop is
unreachable as signalling to that flex algo loopback was not understood by
P (new signalling extension) packets will be dropped.

But what if that next hop would happen to be covered by some aggregate
route not subject perhaps to intended IP TE ?

Cheers,
R.



On Wed, Sep 30, 2020 at 2:11 PM Peter Psenak  wrote:

> Hi Robert,
>
> On 30/09/2020 09:28, Robert Raszuk wrote:
> > Hi,
> >
> >  > It uses the HBH option
> >
> > Currently Ron's proposal seems to work well for both IPv4 and IPv6
> > addresses. I hope this discussion will not try to derail it to IPv6 only
> > track.
> >
> > I see no issue with loopback to flexible algorithm mapping in 1:1
> fashion.
> >
> > I do however see some issues in deploying such technology as it will
> > only work well if *all* nodes in the network support this new
> > functionality. In contrast in SR world or control plane based TE I
> > proposed or any encapsulation based proposal only anchor nodes need to
> > support the new functionality while rest of the network does not need to
> > be even aware about it.
>
> above is not really true.
>
> Algo participation needs to be signaled, one way or the other. It's done
> for SR as well. There is no need for all routers to understand
> flex-algo, as only those that participate (and as a result also
> understand it) will be used during the flex-algo path computation and
> consequently flex-algo specific forwarding. This applies to flex-algo in
> general, regardless of the data plane being used.
>
> thanks,
> Peter
>
>
> >
> > Many thx,
> > R.
> >
> >
> > On Wed, Sep 30, 2020 at 6:10 AM Huzhibo  > <mailto:huzh...@huawei.com>> wrote:
> >
> > Hi Joel:
> >
> >  For details about the method defined in RFC 6550. It uses the
> > HBH option to carry the RPLInstaceID. The RPLInstaceID and
> > FlexAlgoID are similar.
> >
> > Thanks
> >
> > Zhibo
> >
> > -Original Message-
> > From: Lsr [mailto:lsr-boun...@ietf.org
> > <mailto:lsr-boun...@ietf.org>] On Behalf Of Joel M. Halpern
> > Sent: Wednesday, September 30, 2020 12:05 PM
> > Cc: lsr@ietf.org <mailto:lsr@ietf.org>
> > Subject: Re: [Lsr] New Version Notification for
> > draft-bonica-lsr-ip-flexalgo-00.txt
> >
> > I am missing something in this discussion of multiple algorithms.
> >
> > My understanding of flex-algo whether for MPLS, SRv6, SRH, or IPv6,
> > is that you need to associated a forwarding label (e.g. MPLS label
> > or IPv6
> > address) with a specific algorithm so that you can compute the next
> > hope for the forwarding label using the proper algorithm.  Then when
> > a packet arrives, it is simply forwarded according to the forwarding
> > table (e.g.
> > FIB, LIB, ..)
> >
> > If that is so, then I do not understand how a given prefix can be
> > safely associated with more than one algorithm.  I could imagine
> > doing several calculations according to different algorithms.  But
> > how do you decide which one applies to the packet?  As far as I
> > know, flex-algo does not look at the QoS/CoS/ToS bits.
> >
> > Yours,
> > Joel
> >
> > PS: I will admit that it took until  an operator described some
> > "interesting" constraints before I understood why one would even do
> > this.
> >
> > On 9/29/2020 11:50 PM, Huzhibo wrote:
> >  > Hi.
> >  >
> >  > Associating multiple algorithms with a given prefix is an
> > interesting topic, and I think this can simplify the complexity of
> > FlexAlgo. I wonder if the author would consider using cases with
> > multiple algorithms with a given prefix.
> >  >
> >  > Thanks
> >  >
> >  > ZHibo
> >  >
> >  > -Original Message-
> >  > Fro

Re: [Lsr] New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt

[Robert Raszuk]

Hi Les,

Well I am talking about IP routable identifier which I can place on the
front of the packet and which can assure that the packet will arrive at
given area.

Then Area SID becomes analogy of Node SID :)

Thx

On Mon, Aug 3, 2020 at 7:40 PM Les Ginsberg (ginsberg) 
wrote:

> Robert –
>
>
>
> Both OSPF and IS-IS have area identifiers which are advertised.
>
> Why would we need to invent another identifier for an area?
>
>
>
>    Les
>
>
>
>
>
> *From:* Robert Raszuk 
> *Sent:* Monday, August 03, 2020 10:31 AM
> *To:* Les Ginsberg (ginsberg) 
> *Cc:* bruno.decra...@orange.com; tony...@tony.li; lsr@ietf.org
> *Subject:* Re: [Lsr] New Version Notification for
> draft-ietf-lsr-isis-area-proxy-02.txt
>
>
>
> *Les,*
>
>
>
> *> But currently the draft is defining a SID which is NOT associated with
> a prefix.*
>
> +
>
> > *But if the proposal is to use a SID associated with a prefix then I
> see no need to invent a new SID advertisement.*
>
>
>
> How about we first define an "Area Prefix" (IP address being a property of
> an area) then assign SID to it ?
>
>
>
> - - -
>
>
>
> How odd it may sound I would like to still be able to direct traffic (read
> ip tunnel) traffic to an area without any SID.
>
>
>
> Thx,
> R.
>
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt

[Robert Raszuk]

*Les,*

*> But currently the draft is defining a SID which is NOT associated with a
prefix.*
+
> *But if the proposal is to use a SID associated with a prefix then I see
no need to invent a new SID advertisement.*

How about we first define an "Area Prefix" (IP address being a property of
an area) then assign SID to it ?

- - -

How odd it may sound I would like to still be able to direct traffic (read
ip tunnel) traffic to an area without any SID.

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

Re: [Lsr] New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt

[Robert Raszuk]

Les,

>  You need to allow that not everything in the world is identified by an
IP/IPv6 address.

Thought we are talking about WAN networks here and not about the world :)

>  assign a common anycast address on all nodes.

First not all nodes need to participate here. At most ABRs.

Then if you already have a summary route from a given area - you do not
need to invent anything else - area summary routes are effectively area
prefixes. And in fact last time I checked routable too.

>  I can associate the SID with an identifier

Do you ping SID or IP address ?

Maybe time for examples.

What would be your MPLS area SID format ? How about SRv6 SID format for the
same ?

Bottom line I think we must not lock ourselves into single transport
technology - that's all I am after here.

Thx,
Robert.


On Mon, Aug 3, 2020 at 7:56 PM Les Ginsberg (ginsberg) 
wrote:

> Robert –
>
>
>
> You need to allow that not everything in the world is identified by an
> IP/IPv6 address.
>
>
>
> If you want an IP address shared by all nodes in an area there is already
> a mean of doing that: assign a common anycast address on all nodes.
>
>
>
> The value add (if there is any) of an Area SID is that I don’t have to
> assign an anycast address to all nodes. I can associate the SID with an
> identifier that is already shared and known by all nodes in the area.
>
> If you don’t see that as worthwhile, fine, let’s abandon the Area SID idea.
>
>
>
>Les
>
>
>
>
>
>
>
> *From:* Robert Raszuk 
> *Sent:* Monday, August 03, 2020 10:47 AM
> *To:* Les Ginsberg (ginsberg) 
> *Cc:* bruno.decra...@orange.com; tony...@tony.li; lsr@ietf.org
> *Subject:* Re: [Lsr] New Version Notification for
> draft-ietf-lsr-isis-area-proxy-02.txt
>
>
>
> Hi Les,
>
>
>
> Well I am talking about IP routable identifier which I can place on the
> front of the packet and which can assure that the packet will arrive at
> given area.
>
>
>
> Then Area SID becomes analogy of Node SID :)
>
>
>
> Thx
>
>
>
> On Mon, Aug 3, 2020 at 7:40 PM Les Ginsberg (ginsberg) 
> wrote:
>
> Robert –
>
>
>
> Both OSPF and IS-IS have area identifiers which are advertised.
>
> Why would we need to invent another identifier for an area?
>
>
>
>Les
>
>
>
>
>
> *From:* Robert Raszuk 
> *Sent:* Monday, August 03, 2020 10:31 AM
> *To:* Les Ginsberg (ginsberg) 
> *Cc:* bruno.decra...@orange.com; tony...@tony.li; lsr@ietf.org
> *Subject:* Re: [Lsr] New Version Notification for
> draft-ietf-lsr-isis-area-proxy-02.txt
>
>
>
> *Les,*
>
>
>
> *> But currently the draft is defining a SID which is NOT associated with
> a prefix.*
>
> +
>
> > *But if the proposal is to use a SID associated with a prefix then I
> see no need to invent a new SID advertisement.*
>
>
>
> How about we first define an "Area Prefix" (IP address being a property of
> an area) then assign SID to it ?
>
>
>
> - - -
>
>
>
> How odd it may sound I would like to still be able to direct traffic (read
> ip tunnel) traffic to an area without any SID.
>
>
>
> Thx,
> R.
>
>
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr