Re: [Lsr] Comments on Requested Codepoints for draft-li-lsr-isis-area-proxy

[tony . li]

Les,

> We don’t have to resolve this now.
> One of my motivations for sending this was related to Early Allocation of 
> code points. Since you have already asked once, I am assuming that if WG 
> adoption is achieved it will be swiftly followed by an early allocation 
> request – and as one of the Designated Experts I wanted to share my concerns 
> sooner rather than later.


I appreciate that.  Do others share Les’ perspective on the relative tradeoffs? 
 Especially our other Desginated Experts?


> Would this argue for advertising “this is a boundary circuit” in pseudo-node 
> LSPs for boundary circuits rather than advertising “inside” on all inside 
> pseudo-nodes?
>   
> You could do it that way.  It inverts the semantics and inverts the 
> deployment.  Logically, it should have the same effect.  However, it then is 
> seen by outside nodes.  Since they need not support Area Proxy, this seemed 
> like a riskier approach, thus we opted for marking inside pseudonodes.
>  
> [Les:] My point was largely motivated by the statement in the draft:
>  
> “Area Proxy Boundary multi-access circuits (i.e.  Ethernets in LAN
>mode) with multiple Inside Edge Routers on them are not supported.”
>  
> So it seems advantageous to be able to prevent this from happening – which 
> requires some signaling on the circuit in question.



I think that the case that you’re concerned about is already easily detected.  
Recall that an Inside Edge router will generate IIH’s onto a boundary circuit 
using the Proxy system ID.  Thus, if an Inside Edge router receives an IIH with 
a source address of it’s own proxy system id, then it has encountered this 
issue.

Tony


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

Re: [Lsr] WG adoption call for draft-przygienda-lsr-flood-reflection-01

[tony . li]

Hi Les,


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


I think that there’s some confusion here. The point is very much to have a 
hierarchical design.  The key point is that the IGP hierarchy must not require 
a hierarchical data plane.  While a hierarchical data plane may suffice in a 
WAN topology, imposing that restriction on mega-scale multi-dimensional Clos 
fabrics simply doesn’t fly.  

We want the hierarchy provided by the IGP.  We need tools for extreme scaling. 
We need the IGP abstractions decoupled from the data plane architecture.

Looked at sideways, we’re simply trying to generalize the IS-IS area mechanism. 
We need transit areas that do not impact the scale of L2.

Apologies if I’m simply restating what Tony P. has already said.

Regards,
Tony


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

Re: [Lsr] WG adoption call for draft-przygienda-lsr-flood-reflection-01

[Tony Przygienda]

thanks Les, albeit the authors got already lots of helpful comments from
you and Peter over beers in a bar I hope for further discussions.
Especially your opinion on

a) special case where FR is 1-hop away from the leafs should not need a
tunnel. I think most people would agree it's a good thing
b) some example/better text on the computation as John poked at
c) to give no favorite treatment to either data-tunnels or no-data-tunnels
shortcutting since both of those variants have its own camp of non-likers
;-) ; both shall be equally documented over time I think.
d) some people pine for FR hierarchy which would have the advantage of
being "future-proof" while I fear the rathole involved when looking @ my
RR-hierarchy-deployment-scar-tissues. Maybe we can cook something up that
buys us an option to add it in the future in backwards compatible fashion
without doing work now. I didn't think through the issue though.

Ultimately, and in the danger of sounding a bit like a broken record, your
view on hierarchy is IMO bitsy sideways. Customer would do like a generic,
summarizing, self-building, non-looping hierarchy (i.e. not forced to be
star-like) but as I think became obvious, only realistic distributed option
without connection setup and crank-back is unfortunately a rather rigidly
configured star without sideways transits (or high instability in hierarchy
if arbitrary edges are introduced and hierarchy is 'renegotiated'). And
it's not even protocol mechanics, it's fairly grounded in graph theory (if
you summarize, i.e. information flow is only partial). Another way to think
about it that Clos is actually nothing but such a
star-no-horizontal-transit networks (well, to an extent, this discussion
leads into ABR alternate behavior and shortcuts we lived and was "solved"
for 2 levels only as well) and hence automatically building hierarchy from
the defined center out is safe (just as RPL [which forces basically a CLOS
and would be possibly an option for ISIS but don't forget that RPL to work
needs arc-direction packet format change to prevent looping so that would
need looking at] or RIFT [which largely assumes CLOS with some variants so
is basically only good in discovering automatically a constraint it already
posed ;-) ]).  We may evolve over time to all networks topologies being
Banyan-variants exclusively (well, where locality is given, we already do)
but I consider that unlikely in generic WANs hence sprung the need for this
draft.

thanks

--- tony

On Sun, Jun 21, 2020 at 7:37 AM Les Ginsberg (ginsberg)  wrote:

> I support WG adoption of
> https://datatracker.ietf.org/doc/draft-przygienda-lsr-flood-reflection ..
>
>
>
> (I also support the WG adoption of
> https://datatracker.ietf.org/doc/draft-li-lsr-isis-area-proxy/ )
>
>
>
> 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:29 PM
>
> > To: lsr@ietf.org
>
> > Cc: lsr-cha...@ietf.org; lsr-...@ietf.org; Christian Hopps
>
> > 
>
> > Subject: [Lsr] WG adoption call for
> draft-przygienda-lsr-flood-reflection-01
>
> >
>
> > This begins a 2 week WG adoption call for the following draft:
>
> >
>
> >   https://datatracker.ietf.org/doc/draft-przygienda-lsr-flood-reflection
>
> >
>
> > 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-przygienda-lsr-flood-reflection-01

[Les Ginsberg (ginsberg)]

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



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



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:29 PM

> To: lsr@ietf.org

> Cc: lsr-cha...@ietf.org; lsr-...@ietf.org; Christian Hopps

> 

> Subject: [Lsr] WG adoption call for draft-przygienda-lsr-flood-reflection-01

>

> This begins a 2 week WG adoption call for the following draft:

>

>   https://datatracker.ietf.org/doc/draft-przygienda-lsr-flood-reflection

>

> 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] Comments on Requested Codepoints for draft-li-lsr-isis-area-proxy

[Les Ginsberg (ginsberg)]

Tony –

We don’t have to resolve this now.
One of my motivations for sending this was related to Early Allocation of code 
points. Since you have already asked once, I am assuming that if WG adoption is 
achieved it will be swiftly followed by an early allocation request – and as 
one of the Designated Experts I wanted to share my concerns sooner rather than 
later.

A few more responses inline.

From: Tony Li  On Behalf Of tony...@tony.li
Sent: Saturday, June 20, 2020 5:13 PM
To: Les Ginsberg (ginsberg) 
Cc: draft-li-lsr-isis-area-proxy.auth...@ietf.org; lsr@ietf.org
Subject: Re: Comments on Requested Codepoints for draft-li-lsr-isis-area-proxy


Hi Les,

Putting the Inside Node TLV aside for the moment, it would seem to me to be 
advantageous (in a modest way) to have all information relating to Area Proxy 
contained in one advertisement. Using Router Capabilities TLV would accomplish 
that.


I agree that the information should be contained, this is why we opted to put 
it all into one top level TLV.  Recall that only the Area Leader is advertising 
the Area Proxy TLV, while all inside nodes need the capability.

[Les:] My proposal does not alter what information is sent by Area 
leaders/non-Area leaders – just the container in which the information appears.


Your concern about “burdening” the Router Capabilities TLV seems unwarranted.


Given that we have 64k top level code points, I’m equally confused about your 
concern.

[Les:] Today, we only have 255 top level codepoints.
64K codepoints will only become available when the industry moves to RFC 7356 
based implementations and includes the 16 bit TLV Type/Length option.
While I would obviously like to see this happen, as it isn’t backwards 
compatible I expect we are still some years away from a “tectonic shift”.
And your draft does not propose moving to RFC 7356 as part of the feature (and 
I am not suggesting that it should).

At least part of the reason we still have sufficient available top level code 
points is that we do our collective best to use them judiciously.


Multiple Router Capability TLVs are allowed (indeed even required to support 
different flooding scopes) – so TLV space is not limited.


I expect that we will have numerous bug reports when we start to cross the TLV 
boundary.  I’m not in favor of pushing this.

 [Les:] We already enough info to advertise that one Router Capability TLV is 
not enough. Implementations that cannot handle multiple Router Capability TLVs 
are already busted.
Area Proxy by itself won’t force this to be exposed.

Returning to Inside Node TLV, I share your concern about advertising Router 
Capabilities TLV in pseudo-node LSP. But what does it mean to advertise the 
Inside Node TLV in a pseudo-node LSP?


It’s a clear indication that the pseudonode is intended to be inside.



Presumably you need some capability indicator because even on boundary circuits 
the DIS will use the native systemid rather than the proxy systemid and 
therefore you cannot tell based on pseudonode-id alone what type of circuit 
this is.


Correct. The DIS would have a very difficult time using the proxy systemid and 
assigning a unique circuit id for the pseduonode.  Some other system on the 
other side of the area could be making exactly the same choice, leading to a 
collision.  Thus, it seems simpler to use the native system id and explicitly 
signal that the pseudonode is inside.  I’ve become a pretty big fan of explicit 
signaling, as it’s more robust.

[Les:] Yes, I understand  and agree with your choice. There is no good way to 
manage the pseudo-node ID space in a distributed manner.


Would this argue for advertising “this is a boundary circuit” in pseudo-node 
LSPs for boundary circuits rather than advertising “inside” on all inside 
pseudo-nodes?


You could do it that way.  It inverts the semantics and inverts the deployment. 
 Logically, it should have the same effect.  However, it then is seen by 
outside nodes.  Since they need not support Area Proxy, this seemed like a 
riskier approach, thus we opted for marking inside pseudonodes.

[Les:] My point was largely motivated by the statement in the draft:

“Area Proxy Boundary multi-access circuits (i.e.  Ethernets in LAN
   mode) with multiple Inside Edge Routers on them are not supported.”

So it seems advantageous to be able to prevent this from happening – which 
requires some signaling on the circuit in question.


And do you need the “boundary circuit” indication in L2 IIHs (and perhaps P2P 
IIH as well??) as protection against improperly forming adjacencies on boundary 
circuits?


Not required if there is consistent configuration.  All inside nodes will be 
using the proxy system ID in their IIH.  If a node is inconsistently 
configured, then it is difficult to prevent at least one side from trying to 
form the adjacency.

[Les:] Yes – the key point here is “consistent configuration”. It seems useful 
to be able to detect/report mismatched configurations –