Robert, sigh, the specs, especially on ISIS cannot be written to the lowest
common denominator implementation out there.
And otherwise I can only TonyL last email +1 and refer to 1925 #4 while
outlining mildy the reality of things.
the whole "disable per mp-tlv" is valid and yang/vendor knob ter
s are filled to
> the discretion of the implementation and move on ... Forget about any
> normative language.
>
> Cheers,
> R,
>
> On Mon, Sep 9, 2024 at 10:52 PM Tony Przygienda
> wrote:
>
>> I wrote it already once, I repeat, if you ever implemented large scale
>> ISI
I wrote it already once, I repeat, if you ever implemented large scale ISIS
you will understand that due to sliding a MUST cannot be enforced without
actually breaking other protocol guidelines and generate possibly tons
unnecessary fragments and transitory flooding bleeps due to unnecessary
shifti
On Tue, Sep 3, 2024 at 8:36 PM Yingzhen Qu wrote:
> Speaking as a WG member.
>
> The following text is in section 7.3:
> "
>
>Implementations SHOULD NOT send
>multiple TLVs unless MP-TLV is applicable to the TLV and the amount
>of information which is required to be sent exceeds the c
First, thanks e'one on this thread for their comments.
Discussion is ongoing with the authors of the draft on feedback provided by
many operators of ISIS network large enough to be interested in the
technology as well as different flavors of feedback provided in this
thread. The next version will
(as independent tests have shown) across
vendors with serious investment in silicon.
-- tony
On Mon, Aug 19, 2024 at 10:46 AM Tony Przygienda
wrote:
> Hey Les, weekend over, quick inlines ;-)
>
> On Sat, Aug 17, 2024 at 8:17 PM Les Ginsberg (ginsberg) <
> ginsb...@cisco.com>
Hey Les, weekend over, quick inlines ;-)
On Sat, Aug 17, 2024 at 8:17 PM Les Ginsberg (ginsberg)
wrote:
> Tony –
>
>
>
> The points you raise are worthy of discussion in the WG – but they are not
> the subject of this thread.
>
agreed. I personally would further suggest actually that in the nam
First, let's observe precisely that the framework does not mandate in any
way multiple algorithms, it just allows them. the draft does not in any way
suggest that presence of multiple algorithms is desirable or recommended.
If clarifying text is needed, it can be easily added.
Second, contrary to
yes, and given how complex and costly (in terms of calculation but also
flooding) the sliding/repacking of TLVs is an implementation may end up in
this very case intentionally though this should be discouraged by a SHOULD
as Les says
On Fri, Aug 9, 2024 at 7:44 PM Les Ginsberg (ginsberg) wrote:
I had some discussions around it and I think next version will be something
along 5 bytes unix timestamp and millisec resolution.
I look for reasonable input on what kind of precision scale we're looking
for clock precision. anything under 1msec makes no sense for a routing
protocol, anything abov
Wang
wrote:
> Hi, Tony:
>
> Would you like to provide some detail explanations to support your asserts?
>
> Aijun Wang
> China Telecom
>
> On Jul 15, 2024, at 20:23, Tony Przygienda wrote:
>
>
> proxy purges was one of the worst ideas in IGP operationally speaking
should not define a complete solution.
>
> If you, as a vendor, choose not to implement SA because you consider the
> cost/benefit ratio unappealing – that is your choice. So long as you and
> your customers are satisfied …
>
>
>
> But our mission here is to defin
on little to no implementation/operational experience and will
have at best zero effect except adding complexity, in worst case lead to
lots of headache for no gain on the substrate.
Point made, I'm out of this thread ...
-- tony
>
>
> But our mission here is to define a solution –
twork-wide.
> That is why the restarting router cannot do this without help from the
> neighbors.
>
> Hope this is clear.
>
> Les
>
>
> *From:* Acee Lindem
> *Sent:* Friday, July 12, 2024 7:55 AM
> *To:* Les Ginsberg (ginsberg)
> *Cc:* Liyan Gong ; Aijun Wang <
does not work for unplanned restart.
>
> thanks,
> Peter
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> *发件人:* forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org
> ] *代表 *Acee Lindem
> *发送时间:* 2024年7月9日 3:
support, not aware of any undisclosed IPR
On Tue, Jul 2, 2024 at 8:30 AM Tony Li wrote:
>
> Support, as co-author.
>
> I am unaware of any IPR that pertains to this document.
>
> T
>
>
> On Jul 1, 2024, at 11:07 PM, Yingzhen Qu wrote:
>
> Hi,
>
> This email begins a 2 week WG Last Call for the
Les, thanks for reading the draft. To start, I see no technical objections
or suggestions from your side I could address. And what you ask
for/claim/object to is WG chair/AD scope AFAIU so I just keep the answer
short as WG participant from my side.
First, dynamic-flooding draft you mention is e
Draft
https://datatracker.ietf.org/doc/draft-ietf-bier-frr
passed all the BIER review process steps and due to possible interactions
with IGP LSR I would ask LSR to do a quick review for any possible things
we missed here
thanks
-- tony
___
Lsr mailing
bly there are some differences
>
>
>
>
>
> “The prefix may be configured as anycast”
>
> Putting the burden on the network operator is not helping clarifying the
> semantic. We need the receivers/consumers and the network operators to have
> the same understanding of
dresses.
>
> 2. Your application want to use only anycast addresses - inter-domain SRTE
> with anycast address for ASBRs. SRTE is using the IGP topology provided by
> BGP-LS.
>
> BTW, the A-bit exists in ISIS and OSPFv3. We are just filling the gap with
> this draft.
>
>
I think the draft is somewhat superfluous and worse, can generate
completely unclear semantics
1) First, seeing the justification I doubt we need that flag. if the only
need is for the SR controller to know it's anycast since it computes some
paths this can be done by configuring the prefix on the
standard I don’t think is a good idea.
>
> Kind Regards
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
> *Email gyan.s.mis...@verizon.com *
>
>
>
> *M 301 502-1347*
>
>
>
> On Fri, Mar 1, 2024 at 2:3
this class of
> comment, Alvaroisms.😎
>
> Thanks and have a Great Weekend,
> Acee
>
> > On Feb 29, 2024, at 2:05 PM, Tony Przygienda
> wrote:
> >
> > sure, on the tags given how some people start to abuse4 those in
> interesting ways now ;-) I'm pipin
oles then I just pipe out of course ...
-- tony
On Thu, Feb 29, 2024 at 8:01 PM Les Ginsberg (ginsberg)
wrote:
> Tony –
>
>
>
> In the spirit of a friendly discussion…
>
>
>
> *From:* Lsr *On Behalf Of * Tony Przygienda
> *Sent:* Thursday, February 29, 2024 10:33
is sub-TLV being empty is NOT specified
(i.e. behavior is undefined) if anyone sends such a thing
-- tony
On Wed, Feb 28, 2024 at 7:13 PM Acee Lindem wrote:
> Hi Tony,
>
> > On Feb 28, 2024, at 2:01 AM, Tony Przygienda
> wrote:
> >
> > hey Acee, inline
> >
> >
hey Acee, inline
On Wed, Feb 28, 2024 at 3:30 AM Acee Lindem wrote:
> Hi Tony,
>
> Thanks for the review.
>
> On Feb 27, 2024, at 04:51, Tony Przygienda wrote:
>
> Reading the draft quickly, here's bunch of observations
>
> "
>
>An OSPF router su
Reading the draft quickly, here's bunch of observations
"
An OSPF router supporting this specification MUST be able to
advertise and interpret at least one 32-bit tag for all type of
prefixes. An OSPF router supporting this specification MAY be able
to advertise and propagate multipl
Huaimo, first, I fail to see how 8202 has anything to do with this
discussion.
Did you try to implement and deploy 5311 in real networks and seen the
operational impact ? and are you suggesting that we need to have that
deployed as precondition for big-tlv idea ?
'nuff said ...
-- tony
On Thu,
On Thu, Dec 7, 2023 at 7:52 AM Gyan Mishra wrote:
> ...
> Gyan> What Bruno is trying to provide I think strengthens the draft
> with the MUST normative language for enable/disable configuration
> controls. As this is pre standard implementation if the devices go out of
> compliance immediate
practically speaking "backwards compatibility" here is restricted by the
fact that
1) we have in most largest networks de facto mp-tlv deployed and relied on
for operations implemented by all major vendors.
2) we cannot encode mp-tlv deployed in parallel with "something new that we
flip over once
per TLV may not be particularly good in lots of cases
1) some TLVs contain tons stuff which triggers all kind of "does that
support this" variants
2) most operators do not know ISIS TLV by heart but RFPs are basically
structured along RFCs so that's the resoluton I'm most concerned with
Generally
operational points to understand what support is in network duly noted and
yes, yang is probably best angle for now to include the capability per tlv
however, some observations below ...
On Tue, Nov 28, 2023 at 2:18 PM wrote:
> Hi,
>
>
>
> This draft proposes advertisements which are out of spe
yeah, that's roughly the reality though you yourself basically say
link-state is being run now out of need/desperation ;-) (whether it's
open/r or bgp-ls hacks to generate equivalent of link-state, BGP is a
diffused computation and not distributed and hence will only provide you
topology if you eng
ave it
and dragging things into the future.
On Wed, Nov 22, 2023 at 1:00 PM Shraddha Hegde wrote:
> Support the adoption as co-author of this draft.
>
>
>
> Juniper Business Use Only
>
> *From:* Les Ginsberg (ginsberg)
> *Sent:* Saturday, November 18, 2023 12:01 AM
> *
+1, support adoptoinb as co-author
On Fri, Nov 17, 2023 at 6:58 PM Tony Li wrote:
>
> I support adoption as co-author.
>
> T
>
>
> On Nov 17, 2023, at 9:23 AM, Yingzhen Qu wrote:
>
> Hi,
>
> This begins a WG adoption call for draft-pkaneria-lsr-multi-tlv:
> draft-pkaneria-lsr-multi-tlv-04
> -
errata is _not_ precise enough and the errata as proposed will cause more
problems than it solves from my experience
1. what is the semantics of 0 here? Don't care? Then 0 can be sent on
tunnel MTU and tunnel must stay up if one side sends "don't care"? If
semantics of 0 is "no value" then same c
for what's it worth I +1 here Les & Tony obviously
-- tony
On Wed, Mar 29, 2023 at 5:30 PM Les Ginsberg (ginsberg) wrote:
> Chris -
>
> > -Original Message-
> > From: Christian Hopps
> > Sent: Tuesday, March 28, 2023 11:40 PM
> > To: Les Ginsberg (ginsberg)
> > Cc: Christian Hopps ; H
rting router and the updated Router LSA on
> the neighbor there is still some risk.
>
>Les
>
> > -Original Message-
> > From: Acee Lindem
> > Sent: Tuesday, March 28, 2023 2:19 PM
> > To: Les Ginsberg (ginsberg)
> > Cc: Liyan Gong ; Tony
ok yes, I didn't think through the step 3 ...
thanks Les
-- tony
On Tue, Mar 28, 2023 at 11:44 AM Les Ginsberg (ginsberg)
wrote:
> Tony -
>
>
>
> *From:* Tony Przygienda
> *Sent:* Monday, March 27, 2023 5:11 PM
> *To:* Les Ginsberg (ginsberg)
> *Cc:* Acee L
uter. Otherwise other routers in
> the network may prematurely think that two-way connectivity to the
> restarting router has been restored sooner than it actually has been.
> Neither the draft nor Acee’s alternative explicitly address this point.
> Proper use of the SA bit can address
thought about it. there are also other solutions to the problem (or rather
to make it significantly less likely/shorter duration since perfect
solution given we don't purge DB of an adjacenct router when we lose
adjacency to it do not exist) such as e.g. choosing seqnr# on startup in a
way that min
Robert, thanks for the review
* tunnel level, ok, I clarify that it means "by some mechanism the tunnel
type supports"
* good catch on 01/02, it's actually R10 and R11
-- tony
On Tue, Nov 29, 2022 at 5:32 PM Robert Wilton via Datatracker <
nore...@ietf.org> wrote:
> Robert Wilton has entered t
>
>
>
> I would caution regarding periodic CSNPs on P2P networks. Yes – many
> implementations support this – but not all do so by default. So assuming
> that periodic CSNPs are sent on P2P circuits and therefore nothing needs to
> be said in this regard isn’t justified.
>
>
&
rovide a more robust description of how they should be used in the
> draft and an analysis of the benefits under some realistic flooding
> scenarios.
>
we omitted the CSNP since nothing changes. And yes, we can say CSNPs stay
of course and we should say please, please send CSNP on p
On Mon, Nov 28, 2022 at 6:22 PM Les Ginsberg (ginsberg)
wrote:
> Hi Russ!
>
> > -Original Message-
> > From: r...@riw.us
> > Sent: Monday, November 28, 2022 4:56 AM
> > To: Les Ginsberg (ginsberg) ; Tony Przygienda
> >
> > Cc: draft-white-lsr-d
Les, bits delay since I had to think a bits about your comment to do it
justice and it's bit long'ish
1. So, to start with a cut and dry summary and reasoning for it, I am
firmly against adding signaling to the whole thing by some means (or rather
any procedures to act upon distribution of info ab
as co-author support adoption.
draft is a derivation of well-known MANET techniques used before
successfully. The twists improving it (balancing of flooding across
downstream nodes in addition to reduction) has been used in RIFT already as
well, implemented and works "fine" [without further defini
incorporated and new version pushed
many thanks for careful review
-- tony
On Tue, Sep 20, 2022 at 10:16 PM John Scudder wrote:
> WG,
>
> I’d like to highlight that I’ve filled in (what I believe was) a missing
> registry creation in the IANA Considerations section, and proposed that the
> re
Given the realities of deploying something like this I am all for
advertisement of what I'll call here the "multi-TLV-compliance" flag
(assuming we agree that capability implies a change in procedures on
reception from other nodes which this draft does not). Being able to see
that a customer netwo
which as proposal actually looks IMO more interesting than IMP thingy ...
_IF_ we want to do such a thing
As to IMP itself very terse
a) configuration is already standardized via NETCONF WG/channels/methods.
pulling it via this seems redundant.
b) YANG is already pulled via other channels so I se
basis down the line.
>
> Thanks,
> Ketan
>
>
> On Fri, Jun 24, 2022 at 11:43 PM Tony Przygienda
> wrote:
>
>>
>>
>> On Fri, Jun 24, 2022 at 6:43 PM Ketan Talaulikar
>> wrote:
>>
>>> Hi Tony,
>>>
>>> Please check inli
On Fri, Jun 24, 2022 at 6:43 PM Ketan Talaulikar
wrote:
> Hi Tony,
>
> Please check inline below.
>
> On Wed, Jun 22, 2022 at 9:41 PM Tony Przygienda
> wrote:
>
>> hey Ketan, since as you know ;-) BGP-LS is not really IGP 1:1 translation
>> we try to put into B
while the ISIS Flood Reflection TLV has support for
> sub-TLVs, its corresponding BGP-LS ISIS Flood Reflection TLV does not allow
> for sub-TLVs. The encoding needs to be consistent. That is a show-stopper
> in my opinion.
>
> Thanks,
> Ketan
>
>
> On Wed, Jun 22, 2022 at 7
there should be a preso this ietf in rtg wg showing a framework that can be
used to evaluate such questions. if time permits (per Jeff). tony
On Mon, Jun 13, 2022 at 5:43 PM tom petch wrote:
> From: Lsr on behalf of Acee Lindem (acee) 40cisco@dmarc.ietf.org>
> Sent: 10 June 2022 15:10
>
>
Right, I also saw req' up to 0.5M nodes in flat IGP core by some customers
thinking they'll have the money & need for such things (though I know only
one company in the world right now that runs anything deployed of this
scale give it 2-3 multiplier of total networking devices including switches
;-
On Mon, Jan 24, 2022 at 5:43 AM Gyan Mishra wrote:
>
>
> Hi Chris
>
>
> Just about every vendor out there recommended best practice is to layout
> address plan to take advantage of summarization wherever possible and that
> as well includes PE loopback next hop attribute to limit the router load
there
> already as we are not talking about any reachability distribution hence I
> am not sure where is the chicken-egg dilemma ?
>
> Would you mind clarifying ?
>
> Thx,
> R.
>
> On Wed, Jan 19, 2022 at 8:38 PM Tony Przygienda
> wrote:
>
>> yupp, if we wan
yupp, if we want IGP involved this is definitely a much more sane
alternative than the ones proposed. Use IGP only to advertise the SSAP of
such "notification service" rather than abuse it as a broadcast mechanism.
And for all practical purposes we can simply advertise something like kafka
channels
than
> simply that you don’t like it or you think it is complex.
>
>
>
> Thanks,
> Acee
>
>
>
> *From: *Tony Przygienda
> *Date: *Monday, January 10, 2022 at 2:36 PM
> *To: *Acee Lindem
> *Cc: *Aijun Wang , Christian Hopps <
> cho...@chopps.org>, "
the standardized and widely deployed BGP route
> reflection) I see no need to differentiate to stall advancement.
> >
> > Thanks,
> > Acee
> >
> > On 1/3/22, 7:05 AM, "Christian Hopps" wrote:
> >
> >
Chris, I stand accused ;-) and you're correct, flag day is a better term
for the discussions we had recently around different technologies to
flag-day the protocol ;-) ...
-- tony
On Mon, Jan 3, 2022 at 12:55 PM Christian Hopps wrote:
>
> On a lighter note..
>
> Forklift upgrades imply a requi
tack that once the specs
have moved to publication.
-- tony
On Mon, Jan 3, 2022 at 1:05 PM Christian Hopps wrote:
>
> Tony Przygienda writes:
>
> > One thing Les is missing here is that proxy & reflection present in
> > terms of deployment requirements and ultimate proper
On Sun, Dec 12, 2021 at 6:22 PM Tony Li wrote:
>
> Tony,
>
>
> > The new LSP seems to imply a forklift of the whole network which area
> proxy does not require, in fact flood reflection has been carefully
> constructed to touch minimum possible amount of nodes in the network and
> additionally al
l operators and is
> what makes SDOs so valuable
>
>> This does not mean that we should not support experimentation – and in
> this case I think we are doing so.
>
> Gyan> Agreed. And be able to progress both experimental to RFC and let
> the industry decide on the best
inline. last email from my side in this thread.
On Sat, Dec 11, 2021 at 3:47 PM Aijun Wang
wrote:
> Hi, Tony:
>
> The advantage of IGP is that it can cure itself when there is any topology
> change, no additional operator intervention involved.
>
neither is it in FR case. if you lose all FRs
id the loop, we will be stuck in
> the emerged loop situations.
>
> Some additional replies inline.
>
> Aijun Wang
> China Telecom
>
> On Dec 11, 2021, at 20:08, Tony Przygienda wrote:
>
>
> let's be more precise beyond sensationalist headlines ... Thoug
t;
>>> I think you can appreciate that implementation of either solution is
>>> non-trivial – as is insuring interoperability – as is the actual deployment.
>>>
>>> What justifies doubling that effort?
>>>
>>>
>>>
>>> Thanx.
>
plications.
>
> The overall routing path for L2 topologies that connected by several L1 is
> not determined by one L2 SPF algorithm, how can you assure no loop occur?
>
> Is it nightmare or mess for the operator to run its network in such
> challenges situations?
>
>
What you describe is not technical reality when you're dealing with SPF in
L2 ... You seem to be deeply confused (but honestly, I have a hard time to
even figure out what kind of assumptions you're making about all kind of
things in all those threads about IGPs these days and on what but personal
p
On Thu, Dec 9, 2021 at 8:05 PM Les Ginsberg (ginsberg)
wrote:
> ...
>
> I don’t believe the WG has reached consensus that the IGPs should be
> extended to address the problem.
>
AFAI the process for that is an adoption call. And with a quick look I see
you on
Sun, Jun 21, 2020
supporting the ad
comments addressed and new version posted
-- tony
On Tue, Dec 7, 2021 at 7:24 AM Shraddha Hegde wrote:
> This is a very useful feature for large L2 networks and I support the
> publication of this
>
> document.
>
>
>
>
>
> I have below nits/suggestions on the document.
>
>
>
>
>
> 1. Figure 1:
Les, all sounds to me unfortunately like a gripe (and a late one @ that now
that things were worked on in WG for years & are ready to RFC being
customer deployed, @ least flood reflection is).
Plus, unless you have a dramatically better idea than the drafts extended
I fail to understand what your
On Tue, Dec 7, 2021 at 11:53 PM Tony Li wrote:
>
> Les,
>
Les,
> And in response to Tony Li’s statement: “…the IETF is at its best when it
> is documenting de facto standards”
>
> 1) I fully believe that our customers understand their requirements(sic)
> better than we (vendors) do. But that
One thing Les is missing here is that proxy & reflection present in terms
of deployment requirements and ultimate properties very different
engineering & operational trade-offs. Different customers follow different
philosophies here IME
So we are not strictly standardizing here 2 solutions for the
On Tue, Dec 7, 2021 at 7:24 AM Shraddha Hegde wrote:
> This is a very useful feature for large L2 networks and I support the
> publication of this
>
> document.
>
>
>
>
>
> I have below nits/suggestions on the document.
>
>
>
>
>
> 1. Figure 1: Example Topology of L1 with L2 Borders
>
> The diagr
On Mon, Dec 6, 2021 at 4:42 PM Aijun Wang wrote:
> Do not support its publication.
>
> Very curious which operator will have such network design that the L1
> routers locate in the middle but the L2 routers sits around them.
>
Do read the draft carefully to understand that this is an evolution
On Thu, Dec 2, 2021 at 2:03 PM Peter Psenak wrote:
> Tony,
>
> On 02/12/2021 11:49, Tony Przygienda wrote:
> > Idly thinking about the stuff more and more issues pop up that confirm
> > my initial gut feeling that the pulse stuff is simply not what IGP can
> > do
ble system-wide through it even
when IGP lost _reachability_.
And yes, before we go there, I know that with enough "limited domain" and
"limited scale" and "limited use case" arguments anything one can imagine
"works" ...
--- tony
On Wed, Dec 1, 2021 at 8:13 PM Les
ady
-- tony
On Wed, Dec 1, 2021 at 5:52 PM Les Ginsberg (ginsberg)
wrote:
> Tony –
>
>
>
>
>
> *From:* Tony Przygienda
> *Sent:* Wednesday, December 1, 2021 7:58 AM
> *To:* Peter Psenak (ppsenak)
> *Cc:* Les Ginsberg (ginsberg) ; Hannes Gredler <
> han...@gredler.at
hrough the other L1/L2. I assume that
parses for the connoscenti ...
-=--- tony
On Wed, Dec 1, 2021 at 4:00 PM Peter Psenak wrote:
> Tony,
>
> On 01/12/2021 15:31, Tony Przygienda wrote:
>
> >
> > Or maybe I missed something in the draft or between the lines in the
>
the
> summary must be just static to null int.
>
> Thx,
> R.
>
> On Wed, Dec 1, 2021 at 3:32 PM Tony Przygienda
> wrote:
>
>> having thought through that a bit more I think it's a significantly worse
>> idea than I actually thought. You are requesting a node
having thought through that a bit more I think it's a significantly worse
idea than I actually thought. You are requesting a node to basically save a
possibly very large amount of state between reboots in transitive fashion
for this to even have a chance to work half-way reliably (assuming
signalli
+1 as co-author
On Tue, Nov 23, 2021 at 5:42 PM Acee Lindem (acee) wrote:
> Speaking as a WG member:
>
>
>
> I support publication of this experimental extension to IS-IS.
>
> Thanks,
>
> Acee
>
>
>
> *From: *Lsr on behalf of "Acee Lindem (acee)"
>
> *Date: *Monday, November 22, 2021 at 2:48 P
Yes, support, experimental. It would be beneficial for the authors taking
IPR here to explain in few words what we're protecting here that is not
covered by TCP & million other congestion things out there already
-- tony
On Tue, Nov 23, 2021 at 4:20 AM Jeff Tantsura
wrote:
> Acee,
>
> I support
On Tue, Nov 23, 2021 at 9:30 AM Peter Psenak wrote:
> Hi Chris,
>
> On 22/11/2021 22:29, Christian Hopps wrote:
> >
> > Gyan Mishra writes:
> >
> >> +1
> >>
> >> As I mentioned the requirements for E2E LSP with seamless MPLS or
> >> SR-MPLS requires domain wide flooding of host routes.
> >>
> >>
Just to prop a voice of support to Tony Li's arguments which I have nothing
further to add really. He basically elucidated ;-) with flourishes what I
wrote in my short, terse email I think.
As he says "you either make easy choices and get an operationally unstable
environment at scale/large distur
Agreeing with T. Li here (i.e. BFD next-hops) and let me add that AFAIS the
confusion here is that a presence of a /32 route is used as SSAP liveliness
AFAIS and that's simply not what IGPs are here for if you consider their
main job to be fastest possible convergence in network _reachability_ only
proposed new “A-bit” format)*
>
> That to me is ambiguous as it sort of means that 0 length ABM flags may be
> defined as any application.
>
it's not a good suggestion AFAIS, a natural semantics for 0 length ABM is
realy "_no_ application"
>
> If that would be the
My quick take:
1. yes, A bit will necessitate being either deployed in a well understood
part of the network (because as Les says old nodes will basically see _no_
application [which seems desirable, they basically take themselves out]) or
forklifting. Not that different from flex-algo being same
speaking of which, can I have 5 mins on the agenda for update flood
reflection draft v2/v3? earlier in the session would be merciful since it's
1am-3am session on Fri for me. thx. tony
On Fri, Jul 9, 2021 at 7:26 AM Tony Przygienda wrote:
> Dear chairs, flood reflection is implemented
Dear chairs, flood reflection is implemented/shipped and deploying and
we’re on early alloc codepoints that expire start Aug’. No further
discussions on the list happened.
As far as we see as authors stuff looks shaken out, all things that were
found in implementation/use are in the latest draft v
MT RIB topologies and which scales better.
>
> Much appreciated your MT & MI experiences and real world feedback.
>
>
> Kind Regards
>
> Gyan
>
> On Sat, Mar 27, 2021 at 6:59 AM Tony Przygienda
> wrote:
>
>> Having had a long history with RFC5120 (and with
Having had a long history with RFC5120 (and with the concept before IETF
was even afoot really) and their deployment in its time I cannot resist
finally chiming in a bit ;-)
Well, first, it seems there is agreement that the drafts state fairly
straightforward things but as informational probably n
ope ... I meant ZeroMQ message bus as underlaying pub-sub transport for
> service related info.
>
> Thx,
> R.,
>
>
> On Wed, Mar 10, 2021 at 11:41 AM Tony Przygienda
> wrote:
>
>> ? Last time I looked @ it (and it's been a while) Open-R had nothing of
>> tha
? Last time I looked @ it (and it's been a while) Open-R had nothing of
that sort, it was basically KV playing LSDB (innovative and clever in
itself). You think Kafka here? Which in turn needs underlying IGP however
and is nothing but BGP problems in new clothes having looked @ their
internal archi
something bitsy new if that gives you the "slice" definition @ maximum
scale you look for.
-- tony
On Tue, Mar 9, 2021 at 3:47 PM Gyan Mishra wrote:
> Tony,
>
> In-line
>
> On Tue, Mar 9, 2021 at 5:55 AM Tony Przygienda
> wrote:
>
>> and replying to myself,
I know it's not fashionable (yet) but put multipoint BFD on BIER & run 2
subdomains and you got 10K. Add subdomains to taste which will also allow
to partition it across chips easily. Yepp, needs silicon that will sustain
reasonable rates but you have a pretty good darn' solution. IGP gives you
rea
n terms of SLAs and then swallow the
trade-offs. that may not be a single data point and multiple solutions may
be necessary.
--- tony
On Tue, Mar 9, 2021 at 11:47 AM Tony Przygienda wrote:
> Gyan, you are confusing RIB with LSDB. It is absolutely feasible and
> normal to generate multipl
Gyan, you are confusing RIB with LSDB. It is absolutely feasible and normal
to generate multiple RIBs/FIBs from a single LSDB and that has been done
for about forever
problem with lots of those proposals and assertions here is that powerpoint
and rfc text always compiles no matter what you put int
t; chosen as it can provide the required functionality with less overhead.
>
>
>
> Hope this helps.
>
>
>
> Best regards,
>
> Jie
>
>
>
> *From:* Lsr [mailto:lsr-boun...@ietf.org] *On Behalf Of *Gyan Mishra
> *Sent:* Monday, March 8, 2021 7:29 AM
> *T
1 - 100 of 171 matches
Mail list logo
