Robert ruminated:
>
> That said I think perhaps we are indeed missing LROW WG (Local Routing
> Operations WG) where just like in GROW WG where mainly (Global) BGP
> operational aspects are discussed there could be good place to discuss
> operational aspects of link state protocols deployment and u
the pesky operational issue of those computations to suddenly partition the
graph (if used with dynamic resource updates) or otherwise pile everything
on the same link that led to RFC5120 being built the way it is. It is one
thing to get from RSVP-TE a "no resources to get there" indication and
ano
dyanmic queue lengths are still poor indicators of delay (in routing
network wide sense @ realistic routing flood/processing resolution),
nothing changed much since 1980 AFAIK
https://www.cs.yale.edu/homes/lans/readings/routing/mcquillan-darpa_routing-1980.pdf
delay/jitter can be talked about mea
On Sat, Feb 27, 2021 at 2:56 AM Tony Li wrote:
>
> Hi William & co-authors,
>
> Thank you for your contribution. It’s definitely interesting. As bandwidth
> management is one area where FlexAlgo lags legacy traffic engineering, this
> is definitely one small step in the right direction.
>
> But I
ane to for example invalidate BGP next hops or other overlay
> service routes the disaggregation piece does not apply.
>
> Cheers,
> R.
>
>
>
>
>
> On Fri, Nov 20, 2020 at 9:09 PM Tony Przygienda
> wrote:
>
>>
>>
>> On Fri, Nov 20, 2020 at 6:27 A
On Fri, Nov 20, 2020 at 6:27 AM Aijun Wang
wrote:
> Hi, Tony:
>
> Aijun Wang
> China Telecom
>
> On Nov 20, 2020, at 17:45, Tony Przygienda wrote:
>
>
> Yes, acknowledging the idea of negative disaggregation is inspired by RIFT
> work is fine (and normally, whe
Yes, acknowledging the idea of negative disaggregation is inspired by RIFT
work is fine (and normally, when inspired by an idea at least in research
cycles it is considered basic courtesy to refer to the according source,
something has been lost more and more in IETF over time I dare to observe
whi
I read the draft since the longish thread triggered my interest. As Peter
said very thin ice walking with magic soft-state-timers for (to me)
entirely unclear benefit and lots of interesting questions completely
omitted like e.g. what will happen if a mix of old and new routers are in
the network.
thanks Les, albeit the authors got already lots of helpful comments from
you and Peter over beers in a bar I hope for further discussions.
Especially your opinion on
a) special case where FR is 1-hop away from the leafs should not need a
tunnel. I think most people would agree it's a good thing
b)
On Fri, Jun 19, 2020 at 12:43 PM John Scudder wrote:
> Hi All,
>
> I just did a full read-through of -01. Without denigrating any other
> solutions, I support adoption of this one.
>
> I do have a few comments and nits, below.
>
> - Paragraph 2 of section 9 is unclear, IMO; I hope this can be imp
support as co-author. not aware of any additional IPR beside the one
disclosed on the tracker already
thx
== t
On Wed, Jun 10, 2020 at 12:29 PM Christian Hopps wrote:
> This begins a 2 week WG adoption call for the following draft:
>
> https://datatracker.ietf.org/doc/draft-przygienda-lsr-fl
tony
On Mon, Jun 15, 2020 at 11:01 AM wrote:
>
>
> On Jun 15, 2020, at 10:56 AM, Tony Przygienda wrote:
>
> PNNI had transit areas in hierarchy working but the trick was connection
> setup cranck-back. Such a thing would work for RSVP or any of the stateful
> connection setu
On Mon, Jun 15, 2020 at 10:37 AM wrote:
>
> Hi Robert,
>
>
> > > It’s very clear that this is inadequate.
> >
> > Doesn't this really depend how you architect multiple levels ? Sure you
> have some physical topology - but it seems to me that the trick is in
> properly laying out levels on top of
JNPR holds relevant IPR on the draft. We are in the process of disclosing
it ASAP
thanks
-- tony
On Wed, Jun 10, 2020 at 12:29 PM Christian Hopps wrote:
> This begins a 2 week WG adoption call for the following draft:
>
> https://datatracker.ietf.org/doc/draft-przygienda-lsr-flood-reflection
Christian, thanks much for that. As there were already two different
threads over last months where a good amount of people/companies expressed
their support for the draft to progress as WG item, I don't expect to need
to pester them again but maybe more will chime in here ...
thanks
-- tony
On
On Wed, Jun 10, 2020 at 11:04 AM Christian Hopps wrote:
>
> ...
>
>
> > I also suggest to look up why in PNNI we ended up introducing a special
> "L1 equivalent" computation to the peer group leader to validate that it
> was actually reachable for correct operation (especially hierarchy
> negotia
On Wed, Jun 10, 2020 at 10:29 AM Christian Hopps wrote:
>
>
>
> >
> >
> > Hmmm, AFAIR the implementation of OSPF virtual links was having no
> tunnel at all (and that's how I remember I implemented it then). I cite
>
> Correct, that's why I'm suggesting that any solution without tunnels is
> goin
ok, let's not drag vendor specific stuff in. I shouldn't have brought it up
I guess, outside the scope of IETF threads ...
thanks
--- tony
On Wed, Jun 10, 2020 at 10:23 AM wrote:
>
> Tony,
>
>
> On Jun 10, 2020, at 9:40 AM, Tony Przygienda wrote:
>
> You do see
On Wed, Jun 10, 2020 at 4:27 AM Christian Hopps wrote:
>
>
> > On Jun 9, 2020, at 10:01 PM, Tony Przygienda
> wrote:
> >
> > Chris (addressing in WG member context you declared), I reply tersely
> since we will put more work into the draft once it's adopted
Chris (addressing in WG member context you declared), I reply tersely since
we will put more work into the draft once it's adopted (for which I think
you saw a good amount of support in two threads already).
I deferred from your email since the chain-terrasteam topology you're
showing is simply no
I would like to officially call out for adoption of
https://tools.ietf.org/html/draft-przygienda-lsr-flood-reflection-01 as WG
document
At this point in time flood reflection has been implemented and works
meeting use case requirements of multiple customers which neither TTZ nor
draft-proxy is add
Since stuff seems to develop its own dynamics obviously I will start
another thread for official adoption by WG for
https://tools.ietf.org/html/draft-przygienda-lsr-flood-reflection-01 in
this thread as well.
Further comments below
On Thu, Jun 4, 2020 at 9:43 AM wrote:
>
> ...
>
> In IS-IS Floo
On Tue, Jun 2, 2020 at 10:59 AM Loa Andersson wrote:
>
>
> For your draft the registries should be called:
>
> Sub-TLVs for TLV 242 (IS-IS Router CAPABILITY TLV); and
> Sub-TLVs for TLVs 22, 23, 25, 141, 222, and 223 (Extended IS
> reachability, IS Neighbor Attribute, L2 Bundle Member Attributes,
Loa, fair points though I would say adoption is kind of a different kettle
of fish than early allocation.
RFC7120 does not seem to apply given ISIS registries are under expert
review (largely due to historical reasons AFAIS).
I watch that with lots of interest since due to customer
discussions/(d
This is not a simple let's-build-a-better-mechanism problem, this is an
epistemology problem and uneven information diffusion cannot be fixed by
magic when dealing with total distributed computation. Traditional
Link-state basically only works because we assume an epsilon consistently
(correct term
, 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 Gin
On Wed, Apr 22, 2020 at 11:03 AM wrote:
> Tony, all,
>
>
>
> Thanks Tony for the technical and constructive feedback.
>
> Please inline [Bruno]
>
>
>
> *From:* Tony Przygienda [mailto:tonysi...@gmail.com]
> *Sent:* Wednesday, April 22, 2020 1:19 AM
&
neither am I aware of anything like this (i.e. per platform/product
flooding rate constants) in any major vendor stack for whatever that's
worth. It's simply unmaintanable, point. All major vendors have extensive
product lines over so many changing hardware configuration/setups it is
simply not via
roughly same experience over couple commercial, heavy-lifting vendors on my
side. modulo that implementation in user space internally sometimes manages
queues per interface & different queues in/out per ISIS packet types +
plays with size of socket buffers across interfaces (don't forget, that's
no
+1
IGP is NOT an AD scope generic L3 broadcast mechanism ;-)
BGP is NOT an world scope generic L3 broadcast mechanism ;-)
--- tony
On Mon, Apr 6, 2020 at 8:06 AM Les Ginsberg (ginsberg) wrote:
> This discussion is interesting, but please do not ignore the considerable
> feedback from multiple
peng.sha...@zte.com.cn; Dongjie (Jimmy) ;
> > xie...@chinatelecom.cn; Les Ginsberg (ginsberg)
> > ; lsr@ietf.org; Tony Przygienda
> >
> > Subject: Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing
> > basedVirtual Transport Network
> >
&
changed to include sub-TLV 25.*
On Sat, Mar 28, 2020 at 5:52 PM Tony Przygienda wrote:
>
>
> On Sat, Mar 28, 2020 at 4:01 PM Les Ginsberg (ginsberg) <
> ginsb...@cisco.com> wrote:
>
>> Tony –
>>
>>
>>
>> There are a few misunderstandings in your
On Sat, Mar 28, 2020 at 4:01 PM Les Ginsberg (ginsberg)
wrote:
> Tony –
>
>
>
> There are a few misunderstandings in your post.
>
> Let me try to correct them.
>
>
>
> RFC 8668 defines a new top-level TLV (25). This is NOT a sub-TLV(sic) of
> TLVs 22,23,141,222,223.
>
ack, forgot how l2-bundle w
I'm surprised by where this discussion is heading, what prevents you from
sticking TLV25 into MT TLVs or actually aren't you contradicting existing
standards RFC?
First, an L2 link bundle (I assume we talk about 8668 here) is a L3 concept
in ISIS since you run an adjacency over it and obviously fw
s 10pm Japan/Korea time). Is that too early?
>
> Thanks,
> Chris.
>
> > On Mar 25, 2020, at 5:56 PM, Tony Przygienda
> wrote:
> >
> > yepp, most appreciated ... I will judiciously put a reject filter on
> anything coming from Acee or may automatically script tex
ever, given the
> paucity of support, I think the direction on flooding parameters is much
> more pressing and deserves more time. At the same time, I don’t see a
> problem with updates on the drafts as long as the drafts themselves have
> been updated.
>
>
>
> Thanks,
>
&
yepp, most appreciated ... I will judiciously put a reject filter on
anything coming from Acee or may automatically script text'ing him back if
such a message arrives 18 hours later precisely (which should hit his deep
sleep timezone nicely) ...
if you schedule us into 2nd session that's humanly p
any chance people can post invite.ics I cn import into my agenda? it's
really tedious with the timezones & every group announcing the time in
different way ;-)
Having said that, if we present this topic we could plug in
draft-przygienda-lsr-flood-reflection
update preso in case Chris wants to do i
39 PM Christian Hopps wrote:
>
>
> > On Mar 10, 2020, at 11:22 AM, Tony Przygienda
> wrote:
> >
> > Hey Christian, MaxTX is not that hard to derive since it's basically
> limited by the local system and its CPU/prioritization/queing architecture.
>
> Well s
On Tue, Mar 10, 2020 at 9:43 AM wrote:
> With regards to punting to TCP, I think that TCP (stacks) enforce packet
> ordering.
>
> i.e. if you receive packets 1, 3,4, …,N, then you can only use packet 1
> until you receive packet 2. In the meantime, you cannot use the (N-2)
> packets that you did
to. The correct value for
> Usafe seems very much dependent on the receivers partialSNPInterval. It's
> so dependent that one might imagine it would be smart for the receiver to
> signal the value to the transmitter so that the transmitter can set Usafe
> correctly.
>
> Thanks,
>
> The proposal in the draft is just a suggestion.
>
> As this is a local matter there is no interoperability issue, but
> certainly documenting a better algorithm is worthwhile.
>
>
>
>Les (claws in check 😊 )
>
>
>
>
>
> *From:* Tony Przygienda
> *Sen
Having worked for last couple of years on implementation of flooding speeds
that converge LSDBs some order of magnitudes above today's speeds ;-)
here's a bunch of observations
1. TX side is easy and useful. My observation having gone quickly over the
-ginsberg- draft is that you really want a be
please do not co-mingle hierarchical ISIS and flood reduction drafts into
this discussion. Albeit seemingly related the ttz/abstract/flood-reflector
drafts solve a different, valid problem of multiple large operators that
hierachical,flood-reduce cannot solve albeit they can be used @ the same
time
We posted updated
https://datatracker.ietf.org/doc/draft-przygienda-lsr-flood-reflection/
replacing the previous version without -lsr- in it and will present in
Singapore.
thanks
--- tony
Abstract:
This document provides specification of an optional ISIS extension
that allows to create l2
15 mins for
https://tools.ietf.org/html/draft-przygienda-flood-reflector-00
please
it's new stuff, I expect it to generate good amount of discussion on the
mike possibly
we'll post an update before cut-off as well
thanks
--- tony
On Wed, Oct 23, 2019 at 9:44 AM Yingzhen Qu wrote:
> Hi Pete
I'm under the impression the whole discussion got triggered by my rather
loose remark during the dinner based on, admittedly, my quite dated
implementation experience (with 2 disjoint distributed SPTs to reduce
flooding). I realized it seems not clearly spelled out on the thread. So to
hopefully cl
I read quickly through it, very readable plain narrative explanation of the
IMO best-in-class flood reduction we've in RIFT, implemented and operating
today so I'm fwd'ing through to LSR given the lively discussions around the
topic these days there as well ... Understandably, the spec is dense and
ted an acerbic, terse style ;-)
>
> *From:* Tony Przygienda
> *Sent:* Tuesday, July 23, 2019 1:56 PM
> *To:* Les Ginsberg (ginsberg)
> *Cc:* Tony Li ; lsr@ietf.org
> *Subject:* Re: [Lsr] Dynamic flow control for flooding
>
>
>
>
>
>
>
> It is a mistake to e
>
>
> 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.
>
>
>
>
At least my experience much disagrees with that and such a proposal seems
to steer towards slowest receiver in the whole network probl
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 config
On Tue, Apr 2, 2019 at 4:41 PM wrote:
>
> Hi Tony,
>
>
> > 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.
>
>
> Ok, I didn’t read that into it and I disagree. There are many topologies
> wher
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
On Fri, Mar 8, 2019 at 11:00 AM Christian Hopps wrote:
>
> I think my email is being taken way too seriously. Please note it was "an
> aside"
>
> Also I feel the need to defend Christian's code here. Did you check the
> code prior to the comments? I don't see a lot of obfuscation, in fact I see
>
Somewhat Apple & Kiwi comparisons all over the place here a bit IMO.
Assuming we seem to be talking about ROTH in IP fabrics mainly ...
a) Babel was solving wireless mesh problem, extremely different from wired
fabrics and Babel as solution was IMO fully justified and superior to
suggested ISIS st
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 conver
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 convergen
I read it during some mildly boring phone conference here ;-) I do
(unsuprisingly) tend to agree with Mr. Ginsberg here. Putting originator on
prefix, well, ok, I understand how people got there instead of having a
clean router LSA with its loopback hanging of it (which would be IMO the
right abstr
Cross-post to other groups given today's RIFT discussion:
Despite my long resistance to introduce native multicast into RIFT based on
M-OSPF scar tissue ;-) it seems it falls out almost naturally along the
lines of RPL after having pushed on it today with Pascal. We would end up
with a single (*,*
>
> 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 s
funny enough,
https://tools.ietf.org/html/draft-shen-isis-spine-leaf-ext-06#page-12 by
the overlaping author set seems already to circumvent this ;-)
On Thu, Oct 4, 2018 at 10:37 AM Barry Leiba wrote:
> Reviewer: Barry Leiba
> Review result: Ready
>
> This document is well written and seems read
Gave it a read (markedly improved on -03 I think I read last), had chat
with authors, rough summary for the list so we keep track:
a) As overall observation the disaggregation via leafs requesting from
spines (more about that later ;-) is a very important rewrite in this
version to ensure correctn
On Mon, Aug 27, 2018 at 9:41 AM 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
> n
On Fri, Aug 24, 2018 at 1:36 PM wrote:
>
> Tony,
>
> as to miscabling: yepp, the protocol has either to prevent adjacencies
> coming up or one has to deal with generic topologies. If you don't want to
> design miscabling prevention/topology ZTP into protocol (like ROLL or RIFT
> did) you have to
Hey Tony,
as to miscabling: yepp, the protocol has either to prevent adjacencies
coming up or one has to deal with generic topologies. If you don't want to
design miscabling prevention/topology ZTP into protocol (like ROLL or RIFT
did) you have to deal with generic graph as you say. I think that i
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 comp
On Thu, Aug 23, 2018 at 2:05 AM Peter Psenak wrote:
> ...
> And to be
> completely honest, the requirements are pretty straightforward for
> anyone that is familiar with the protocols' operation.
>
>
The signalling is quite simple as often the case, good quality algorithms,
especially distribut
I do think it is a good idea in a sense to somehow outline WHAT problem is
being solved via some write-down or mind-melt
a) I hope it's captured in the meeting notes but otherwise running the
danger of repeating myself, the problem splits along the line of "directed
graphs" (basically lattices) wh
pretty obvious +1 here
--- tony
On Tue, Jul 24, 2018 at 3:41 AM Rob Shakir wrote:
> +1 to Peter. We should not define fragile solutions within the IETF.
>
> There are also a multitude of other solutions here already:
>
> 1) IGP adjacency with one router in each area (at a minimum - probably two
On Thu, Apr 12, 2018 at 2:52 AM, Acee Lindem (acee) wrote:
> Hi Peter,
>
> Ok - we'll decide during whether to merge during the WG adoption call. It
> would be a good LSR experiment for a combined draft if there are no
> significant differences between the protocols that would make a combined
> d
Given Les chimed in I can't resist either now ;-) Individual musings a bit
having done some of the stuff in the past ;-)
On Fri, Apr 6, 2018 at 1:06 PM, Les Ginsberg (ginsberg)
wrote:
> I think this discussion has already gone much too far in the direction of
> customized flooding optimizations
101 - 171 of 171 matches
Mail list logo
