The work is adopted.
Authors, please resubmit with new name draft-ietf-lsr-isis-area-proxy and
updating the track to experimental.
Thanks,
Chris.
> On Jun 10, 2020, at 3:27 PM, Christian Hopps wrote:
>
> This begins a 2 week WG adoption call for the following draft:
>
>
adoption call for draft-li-lsr-isis-area-proxy-06
Speaking as WG member:
I support WG adoption of this draft on the experimental track. I think it is
better for the WG to move forward and get some data points on these competing
solutions than to be gridlocked.
Thanks,
Acee
On 6/10/20, 3:28 PM
etf.org
> Cc: lsr-cha...@ietf.org; lsr-...@ietf.org; Christian Hopps
>
> Subject: [Lsr] WG adoption call for draft-li-lsr-isis-area-proxy-06
>
> This begins a 2 week WG adoption call for the following draft:
>
> https://datatracker.ietf.org/doc/draft-li-lsr-isis-area-proxy
I support WG adoption of this draft as experimental track.
Kind regards
Gyan
On Mon, Jun 15, 2020 at 2:32 PM wrote:
>
> Tony,
>
> > If we rely on controller fixing LPM as well under failures then really,
> who needs IGPs anymore anyway except for bunch of loopbacks and SPF for the
>
Tony,
> If we rely on controller fixing LPM as well under failures then really, who
> needs IGPs anymore anyway except for bunch of loopbacks and SPF for the
> controller to do all the FIB work and hence discussions like high hierarchies
> or anisotropic routing are largely superfluous me
Tony P,
> or black-holing on aggregates since we cannot "back-off" generic LPM
packet forwarding when we
> realize we're @ a dead end due to aggregation.
I hope you are not stating that aggregation is a bad thing here and all we
should be distributing are host routes :)
But to your point - IGP
yepp, it's one philosophy and design point which I'm quite well aware off
;-) and it's feasible of course that instead of a signalling protocol or
even SR the controller provisions all paths via e.g. PCE of course if one
can live with the delay and implications of large scale failures. If we
rely
> 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, this is not fashionable right now. Unfortunately,
>
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
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 them and between them.
The very pragmatic
Hi Henk,
> It's not so clear to me, sorry.
> Does anyone have an example (link or jpg) of a (sensible) topology
> that would not work with multiple levels of hierarchy, but works
> nicely/better with area-proxies (or FRs) ? Just curious.
Certainly. Draw a 3x3 grid with nodes at each
Hi Tony,
> 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 them and between them.
To my original question - how many levels
It’s very clear that this is inadequate.
It's not so clear to me, sorry.
Does anyone have an example (link or jpg) of a (sensible) topology
that would not work with multiple levels of hierarchy, but works
nicely/better with area-proxies (or FRs) ? Just curious.
The structure of legacy
IS-IS
> On Jun 15, 2020, at 3:45 AM, Henk Smit wrote:
>
> BTW, personally I think the proper solution to scale IS-IS to larger
> networks is 8 levels of hierarchy. Too bad that idea gets so little
> push from vendors and operators.
Hi Henk,
It’s very clear that this is inadequate. The structure
I support the area-proxy draft.
I think both the area-proxy draft and the flood-reflection drafts are
a bit hacky. However, the result of the area-proxy draft has a certain
elegance: only one L2 LSP per area in the backbone.
The flood-reflection draft is just messy, imho.
1) The edge-routers
Speaking as WG member:
I support WG adoption of this draft on the experimental track. I think it is
better for the WG to move forward and get some data points on these competing
solutions than to be gridlocked.
Thanks,
Acee
On 6/10/20, 3:28 PM, "Christian Hopps" wrote:
This begins a 2
t;
> *From: *Sarah Chen
> *Date: *Thursday, June 11, 2020 at 2:34 PM
> *To: *Robert Raszuk
> *Cc: *Christian Hopps , "lsr@ietf.org" ,
> "lsr-...@ietf.org" , "lsr-cha...@ietf.org" <
> lsr-cha...@ietf.org>
> *Subject: *Re: [Lsr] WG ad
Thanks Sarah – as a co-author, please state your awareness of IPR.
Acee
From: Sarah Chen
Date: Thursday, June 11, 2020 at 2:34 PM
To: Robert Raszuk
Cc: Christian Hopps , "lsr@ietf.org" ,
"lsr-...@ietf.org" , "lsr-cha...@ietf.org"
Subject: Re: [Lsr] WG adoption c
Support, as co-author.
Thanks,
Sarah
On Thu, Jun 11, 2020 at 2:33 AM Robert Raszuk wrote:
> Support.
>
> Thx,
> R.
>
> On Wed, Jun 10, 2020 at 9:28 PM Christian Hopps wrote:
>
>> This begins a 2 week WG adoption call for the following draft:
>>
>>
Support.
Thx,
R.
On Wed, Jun 10, 2020 at 9:28 PM Christian Hopps wrote:
> This begins a 2 week WG adoption call for the following draft:
>
> https://datatracker.ietf.org/doc/draft-li-lsr-isis-area-proxy/
>
> The draft would be adopted on the Experimental track.
>
> Please indicate your
-...@ietf.org; Christian Hopps
Subject: [Lsr] WG adoption call for draft-li-lsr-isis-area-proxy-06
This begins a 2 week WG adoption call for the following draft:
https://datatracker.ietf.org/doc/draft-li-lsr-isis-area-proxy/
The draft would be adopted on the Experimental track.
Please indicate
> On Jun 10, 2020, at 12:27 PM, Christian Hopps wrote:
>
> This begins a 2 week WG adoption call for the following draft:
>
> https://datatracker.ietf.org/doc/draft-li-lsr-isis-area-proxy/
>
> The draft would be adopted on the Experimental track.
>
> Please indicate your support or
This begins a 2 week WG adoption call for the following draft:
https://datatracker.ietf.org/doc/draft-li-lsr-isis-area-proxy/
The draft would be adopted on the Experimental track.
Please indicate your support or objection by June 24, 2020.
Authors, please respond to the list indicating
23 matches
Mail list logo
