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
>
>
>
>
>
> “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 the semantic. (not to mention
lication 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.
>
> thanks,
> Peter
>
>
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
ard 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:39 PM
gt; 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 piping in here since
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 AM
> *To:* Acee Lindem
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 supp
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
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
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
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
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
as we have 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
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 ;
d 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 Przygienda
>
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 Lindem
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 this aspect.
&
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
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
>
>
> 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.
>
>
>
&
ion 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 p2p even if 10589
doesn't say so (bu
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
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
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
>
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
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
need 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 pu
> 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:29 PM Tony Przygienda
> wrote:
>
>> Ketan
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 want IGP
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
ather 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>
d 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:
> >
> >
> >To
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
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
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 solution and then progress that solu
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
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 ... Though it's nic
ink 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.
>>>
>>&g
ting 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?
>
> Aijun Wang
> China Telecom
>
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
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
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
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
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
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
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
t 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 Ginsberg (ginsberg)
wrot
c 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>; lsr ; Tony Li ; Aij
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
> > whol
at 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 nod
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
+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
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
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
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_
-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 case (which I
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/ship
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
es 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 the c
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
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
>> that sort, it w
? 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
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, as w
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
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 multiple RIBs/FIBs from a s
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
e 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
> *To:* Tony Przygienda
> *Cc:
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
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
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
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
ate 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 AM Aijun Wang
>> wrote:
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
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
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
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:
>
>
, 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 setups but alas, th
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:
>
>
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
>
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
>
1 - 100 of 148 matches
Mail list logo
