Re: [Lsr] WG adoption call for draft-li-lsr-isis-area-proxy-06

[Christian Hopps]

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:
> 
>  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 whether you are aware of any 
> IPR that applies to this draft.
> 
> Thanks,
> Chris and Acee.
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
> 



signature.asc
Description: Message signed with OpenPGP
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG adoption call for draft-li-lsr-isis-area-proxy-06

[Susan Hares]

I support adoption on experimental track. 

Sue Hares 

-Original Message-
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Saturday, June 13, 2020 4:12 PM
To: Christian Hopps; lsr@ietf.org
Cc: lsr-cha...@ietf.org; lsr-...@ietf.org
Subject: Re: [Lsr] WG 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, "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 objection by June 24, 2020.

Authors, please respond to the list indicating whether you are aware of any 
IPR that applies to this draft.

Thanks,
Chris and 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] WG adoption call for draft-li-lsr-isis-area-proxy-06

[Les Ginsberg (ginsberg)]

I support the WG adoption of  
https://datatracker.ietf.org/doc/draft-li-lsr-isis-area-proxy/ .

(I also support WG adoption of 
https://datatracker.ietf.org/doc/draft-przygienda-lsr-flood-reflection )

I believe the problem space addressed by these two drafts warrants attention.

I am not yet overly enthused about approaches which promote non-hierarchical 
network architectures. But it seems clear that there is interest in deploying 
non-hierarchical solutions and both drafts present solutions
which merit further evaluation.

The easy road for the WG to take would be to simply allow both drafts to 
proceed to Experimental RFCs, but I hope we are able to do more than this. 
Multiple solutions place undesirable burdens on vendors and providers alike.

To the extent they feel comfortable, I encourage folks who wish to deploy such 
solutions to share their requirements and discuss how each of the solutions
address their requirements/fall short of addressing their requirements. I think 
this would help the WG discover better ways forward.

   Les

> -Original Message-
> From: Lsr  On Behalf Of Christian Hopps
> Sent: Wednesday, June 10, 2020 12:28 PM
> To: lsr@ietf.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/
> 
> 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 whether you are aware of any
> IPR that applies to this draft.
> 
> Thanks,
> Chris and 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] WG adoption call for draft-li-lsr-isis-area-proxy-06

[Gyan Mishra]

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
> controller to do all the FIB work and hence discussions like high
> hierarchies or anisotropic routing are largely superfluous me thinks ;-)
>
>
>
> A fair point that many seem to agree with. The IGP provides topology for
> the controller and it simply dominates the control plane. The issue, of
> course, is recovery.  The IGP is still a necessity to provide reachability
> to the controller and to deal with failure recovery.
>
> I agree that people who do go down the controller path may avoid certain
> issues. It also seems to be true that folks who avoid the controller path
> avoid other issues.
>
> Choose your battles…
>
> T
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
-- 



*Gyan Mishra*

*Network Solutions A**rchitect *



*M 301 502-134713101 Columbia Pike *Silver Spring, MD
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG adoption call for draft-li-lsr-isis-area-proxy-06

[tony . li]

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 thinks ;-) 



A fair point that many seem to agree with. The IGP provides topology for the 
controller and it simply dominates the control plane. The issue, of course, is 
recovery.  The IGP is still a necessity to provide reachability to the 
controller and to deal with failure recovery. 

I agree that people who do go down the controller path may avoid certain 
issues. It also seems to be true that folks who avoid the controller path avoid 
other issues.

Choose your battles…

T

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

Re: [Lsr] WG adoption call for draft-li-lsr-isis-area-proxy-06

[Robert Raszuk]

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 is a servant to the application/service which is
BGP. So removal of BGP service routes in a topology independent fashion can
be really fast and take one or two hops. Assume we detect failure of a
remote node - I am not sure if BGP will withdraw service routes faster
across two RRs or IGP will remove next hop by flooding via area over N
nodes then crossing ABR or ASBR and flooding again over N nodes will be any
faster.

Last time I measured the speed of BGP transit of withdraw message via
control plane only RR with decent BGP implementation it was in ranges of
ms.

Thx,
R.

On Mon, Jun 15, 2020 at 7:57 PM Tony Przygienda  wrote:

>
>
> 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 them and between them.
>>
>>
>> The very pragmatic viewpoint is that network architects will construct
>> the physical topology that best suits their traffic pattern and that trying
>> to contort that physical topology into some kind of hierarchy will create
>> additional (and perhaps significant) cost.  People don’t want to do that.
>> They want scalable networks that match their physical topology.  For this
>> to work, our hierarchical abstractions need to be independent of the
>> topology and that forces us into having transit areas.
>>
>>
>>
> 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, generic hierarchy with reachability summarization ends up
> with very sub-optimal routing 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. To prevent bi-furcation of topology or transit
> horizontals several solutions exist, one of which (configure hierarchy
> statically everywhere) the current draft has in now but alas, the topology
> is star of stars (you can actually see CLOS conceptually as something like
> this as well ;-)
>
> my meta 2c
>
> -- tony
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG adoption call for draft-li-lsr-isis-area-proxy-06

[Tony Przygienda]

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 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 thinks ;-)

-- 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 setups but alas, this is not fashionable right now.
> Unfortunately, generic hierarchy with reachability summarization ends up
> with very sub-optimal routing 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. To prevent bi-furcation of topology or transit
> horizontals several solutions exist, one of which (configure hierarchy
> statically everywhere) the current draft has in now but alas, the topology
> is star of stars (you can actually see CLOS conceptually as something like
> this as well ;-)
>
>
>
> Hi Tony,
>
> The modern solution of choice is to relegate all of the traffic
> engineering to an out-of-band controller that no longer operates in
> real-time and has the scale to span levels and areas.
>
> Tony
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG adoption call for draft-li-lsr-isis-area-proxy-06

[tony . li]

> 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, 
> generic hierarchy with reachability summarization ends up  with very 
> sub-optimal routing 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. To prevent bi-furcation of topology or transit horizontals 
> several solutions exist, one of which (configure hierarchy statically 
> everywhere) the current draft has in now but alas, the topology is star of 
> stars (you can actually see CLOS conceptually as something like this as well 
> ;-)


Hi Tony,

The modern solution of choice is to relegate all of the traffic engineering to 
an out-of-band controller that no longer operates in real-time and has the 
scale to span levels and areas.

Tony

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

Re: [Lsr] WG adoption call for draft-li-lsr-isis-area-proxy-06

[Tony Przygienda]

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 them and between them.
>
>
> The very pragmatic viewpoint is that network architects will construct the
> physical topology that best suits their traffic pattern and that trying to
> contort that physical topology into some kind of hierarchy will create
> additional (and perhaps significant) cost.  People don’t want to do that.
> They want scalable networks that match their physical topology.  For this
> to work, our hierarchical abstractions need to be independent of the
> topology and that forces us into having transit areas.
>
>
>
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, generic hierarchy with reachability summarization ends up
with very sub-optimal routing 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. To prevent bi-furcation of topology or transit
horizontals several solutions exist, one of which (configure hierarchy
statically everywhere) the current draft has in now but alas, the topology
is star of stars (you can actually see CLOS conceptually as something like
this as well ;-)

my meta 2c

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

Re: [Lsr] WG adoption call for draft-li-lsr-isis-area-proxy-06

[tony . li]

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 viewpoint is that network architects will construct the 
physical topology that best suits their traffic pattern and that trying to 
contort that physical topology into some kind of hierarchy will create 
additional (and perhaps significant) cost.  People don’t want to do that.  They 
want scalable networks that match their physical topology.  For this to work, 
our hierarchical abstractions need to be independent of the topology and that 
forces us into having transit areas.


> To my original question - how many levels can you run on the physical box ? 
> And can levels be locally and logically interconnected ? 


The constraint on a physical box is the amount of memory and CPU.  Running 8 
levels, each with 1000 LSPs per level is not out of the realm of doable within 
the next decade.

Yes, levels can be logically interconnected through higher levels.

I don’t understand what you mean by ‘locally interconnected’.


> Then of course if you have applications (MPLS exact FEC match or SR-MPLS with 
> SRLBs) which do not allow any aggregation you are pretty much stuck no matter 
> what :).


Broken architectures are everywhere. Folks that have solutions that do not 
allow for a hierarchical control plane are necessarily going to have issues. 
Hierarchy is the only tool that we have to fight scalability.

Tony


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

Re: [Lsr] WG adoption call for draft-li-lsr-isis-area-proxy-06

[tony . li]

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 intersection.

Replace each node with an L1 area.

Image: 
https://upload.wikimedia.org/wikipedia/commons/0/0f/Figure_11-_a_three_by_three_grid.png


>> The structure of legacy
>> IS-IS areas effectively precludes a scalable network for using lower
>> levels for transit. This constrains ISPs to ‘cauliflower’ topology
>> where you have L1 on the outside, L2 just inside of L1, L3 inside of
>> L2, etc.
> 
> I understand. L1-8 forces a hierarchical network designs.
> But even if one would have the tools to design a non-hierarchical
> network, that doesn't mean one should do so. :-)


Hierarchical abstraction is a fine thing, but traffic cannot be constrained to 
be hierarchical. Doing so forces the top of the hierarchy to have capacity that 
is greater than lower levels. Pragmatically, we can’t build things that have 
infinite capacity, so we have to make do with finite sized switching elements. 
Fortunately Clos taught us how to do this. :-)

The result is that we need to have transit areas.


> If there are spots in the network where the hierarchical constraints
> are a problem in the real world, indeed it would be nice to have tools
> like area-proxies in the tool-set, to help solve those problems.
> 
> I would like to have both tools.
> I think you do too (as you are author of both drafts).


I concur.

Tony

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

Re: [Lsr] WG adoption call for draft-li-lsr-isis-area-proxy-06

[Robert Raszuk]

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 can you run on the physical box ?
And can levels be locally and logically interconnected ?

Then of course if you have applications (MPLS exact FEC match or SR-MPLS
with SRLBs) which do not allow any aggregation you are pretty much stuck no
matter what :).

Rgs,
R.

On Mon, Jun 15, 2020 at 5:12 PM  wrote:

>
>
> 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 of legacy IS-IS
> areas effectively precludes a scalable network for using lower levels for
> transit. This constrains ISPs to ‘cauliflower’ topology where you have L1
> on the outside, L2 just inside of L1, L3 inside of L2, etc.
>
> We already see networks who are unwilling to use the two levels that we
> have today due to this constraint.
>
> 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] WG adoption call for draft-li-lsr-isis-area-proxy-06

[Henk Smit]

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 areas effectively precludes a scalable network for using lower
levels for transit. This constrains ISPs to ‘cauliflower’ topology
where you have L1 on the outside, L2 just inside of L1, L3 inside of
L2, etc.


I understand. L1-8 forces a hierarchical network designs.
But even if one would have the tools to design a non-hierarchical
network, that doesn't mean one should do so. :-)


We already see networks who are unwilling to use the two levels that
we have today due to this constraint.


I think L1-8 levels would be a good starting principle for designing 
large networks.

If there are spots in the network where the hierarchical constraints
are a problem in the real world, indeed it would be nice to have tools
like area-proxies in the tool-set, to help solve those problems.

I would like to have both tools.
I think you do too (as you are author of both drafts).

henk.

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

Re: [Lsr] WG adoption call for draft-li-lsr-isis-area-proxy-06

[tony . li]

> 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 of legacy IS-IS areas 
effectively precludes a scalable network for using lower levels for transit. 
This constrains ISPs to ‘cauliflower’ topology where you have L1 on the 
outside, L2 just inside of L1, L3 inside of L2, etc.  

We already see networks who are unwilling to use the two levels that we have 
today due to this constraint.

Regards,
Tony

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

Re: [Lsr] WG adoption call for draft-li-lsr-isis-area-proxy-06

[Henk Smit]

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 of each area are still visible in L2.
Making the L2 scaling benefits a factor less, compared to area-proxy.
2) You need a new tunneling technology to flood LSPs between
edge-routers and the flood-reflector. Even when you simply use TCP,
this adds new and unnecessary complexity.
3) You either need to tunnel user-traffic between edge-routers.
Or you redistribute all L2 prefixes into L1. Negating the benefit of
having L1-only routers in your transit area. I don't like either option.


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.

henk.


Christian Hopps schreef op 2020-06-10 21:27:

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 whether you are aware
of any IPR that applies to this draft.

Thanks,
Chris and 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] WG adoption call for draft-li-lsr-isis-area-proxy-06

[Acee Lindem (acee)]

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 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 whether you are aware of any 
IPR that applies to this draft.

Thanks,
Chris and Acee.


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

Re: [Lsr] WG adoption call for draft-li-lsr-isis-area-proxy-06

[Sarah Chen]

I am not aware of any other related IPR, except for the one Tony mentioned:
https://datatracker.ietf.org/ipr/4016/ .

Thanks,
Sarah

On Thu, Jun 11, 2020 at 12:46 PM Acee Lindem (acee)  wrote:

> 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" <
> lsr-cha...@ietf.org>
> *Subject: *Re: [Lsr] WG adoption call for draft-li-lsr-isis-area-proxy-06
> *Resent-From: *
> *Resent-To: *Christian Hopps , Acee Lindem <
> a...@cisco.com>, Yingzhen Qu 
> *Resent-Date: *Thursday, June 11, 2020 at 2:33 PM
>
>
>
> 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:
>
>   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 whether you are aware of
> any IPR that applies to this draft.
>
> Thanks,
> Chris and 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
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG adoption call for draft-li-lsr-isis-area-proxy-06

[Acee Lindem (acee)]

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 call for draft-li-lsr-isis-area-proxy-06
Resent-From: 
Resent-To: Christian Hopps , Acee Lindem , 
Yingzhen Qu 
Resent-Date: Thursday, June 11, 2020 at 2:33 PM

Support, as co-author.

Thanks,
Sarah

On Thu, Jun 11, 2020 at 2:33 AM Robert Raszuk 
mailto:rob...@raszuk.net>> wrote:
Support.

Thx,
R.

On Wed, Jun 10, 2020 at 9:28 PM Christian Hopps 
mailto:cho...@chopps.org>> 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 objection by June 24, 2020.

Authors, please respond to the list indicating whether you are aware of any IPR 
that applies to this draft.

Thanks,
Chris and Acee.

___
Lsr mailing list
Lsr@ietf.org<mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org<mailto: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 adoption call for draft-li-lsr-isis-area-proxy-06

[Sarah Chen]

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:
>>
>>   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 whether you are aware of
>> any IPR that applies to this draft.
>>
>> Thanks,
>> Chris and 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
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG adoption call for draft-li-lsr-isis-area-proxy-06

[Robert Raszuk]

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 support or objection by June 24, 2020.
>
> Authors, please respond to the list indicating whether you are aware of
> any IPR that applies to this draft.
>
> Thanks,
> Chris and 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] WG adoption call for draft-li-lsr-isis-area-proxy-06

[bruno.decraene]

Hi Chris, Acee,

I support adoption.
I've provided comments on the draft a couple of days ago.

Regards,
--Bruno

-Original Message-
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps
Sent: Wednesday, June 10, 2020 9:28 PM
To: lsr@ietf.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/

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 whether you are aware of any IPR 
that applies to this draft.

Thanks,
Chris and Acee.

___
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] WG adoption call for draft-li-lsr-isis-area-proxy-06

[Tony Li]

> 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 objection by June 24, 2020.
> 
> Authors, please respond to the list indicating whether you are aware of any 
> IPR that applies to this draft.


Support, as author.

IPR has been filed: https://datatracker.ietf.org/ipr/4016/ 


Tony

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

[Lsr] WG adoption call for draft-li-lsr-isis-area-proxy-06

[Christian Hopps]

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 whether you are aware of any IPR 
that applies to this draft.

Thanks,
Chris and Acee.

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