Re: [Lsr] Using L1 for Transit Traffic in IS-IS

[Gyan Mishra]

Les

As co-author of the Area Proxy solution I support progressing Area Proxy
and can give some of my un-biased  reasons why Area Proxy would be more
beneficial over Flood Reflection from an operators POV.

Area proxy does provide a very elegant and simple easily deployable
solution to scale the backbone by providing a complete abstraction of the
Level 1 area topology within the Level 2 topology.

Flood Reflection tunneling hints at RFC 9012 BGP Tunnel encapsulation
attribute but is agnostic to tunnel type for the control plane flooding or
no tunneling with flood scoping to cut down on the flood adjacencies in the
backbone.

>From an Operators POV, in general are not fond of tunneling as being part
of the solution unless its a a bandaid patch to solve a problem, having to
account now for MTU packet transport  overhead. Another caveat with tunnels
is sub optimal routing and possible 1 hop short cuts that may not be
desirable which is described in the draft that could result in routing
loops.  Costing up the flood Reflection path is a workaround.

BGP Free MPLS / SR core where the RR sits in control plane outside of the
E2E data plane forwarding plane is a BGP free core design requirement and
as well for BGP MVPN, EVPN procedures which the control plane is separate
from the data plane, so is a inherent requirement for BGP.  Separation of
the IGP flooding function from the forwarding plane is quite a change to
normal IGP operation where the control plane and forwarding plane paths are
the same.

The flood reflectors can sit in the control plane so not in the forwarding
plane or can be in the forwarding plane with L1 or L2 shortcut.  So all
paths including the flood Reflector path can be used for forwarding,
however do to 1 hop L1 and L2 shortcut the flood reflector path can be
bumped up in coast so not preferred to prevent choking the flood reflectors
similar to issue where we exclude the BGP RR from forwarding plane so we
don’t choke the RR. My worry is the sub optimal routing from the 1 hop
tunnels could lead to routing loops of which as mentioned the workaround is
to cost high  the flood reflector path so it’s only used for control plane
flooding.


Responses in-line

Kind Regards

Gyan


On Sat, Dec 11, 2021 at 10:43 AM Les Ginsberg (ginsberg) 
wrote:

> Gyan –
>
>
>
> Both drafts have been adopted as WG documents and been provided with early
> allocation of codepoints.
>
Gyan> As co-author I am aware

> So there is nothing preventing implementations/deployments from proceeding
> and doing so without fear that if/when the documents proceed to become RFCs
> that there will be backwards compatibility issues because of codepoint
> changes.
>
> My concern is that there is no effort underway since WG adoption to use
> implementation experience to compare/contrast the solutions and determine
> whether one is better and/or if there really is a need for multiple
> solutions. That seemed to me to be the point of adopting both.
>
   Gyan>  In my response here I tried to  provide an unbiased compare and
contrast of the two solutions.

> I do not see the need to progress either document to RFC at this time –
and I am concerned that in doing so we make it even less likely that such a
comparison will ever be made.

 Gyan> I did the comparison above and I can further elaborate

I had hoped – as you are a representative of one of the potential users of
this technology and you had suggested that there might be reasons why you
were interested in both – that you could provide some input into when one
solution was more desirable than another.

 Gyan> Just to clarify that as an operator this is scalability issue is a
real world problem that needs to be solved.  As I am Co-Author of the Area
Proxy draft I truly believe that is a better solution, however this is a
solution that definitely needs solved..

The value add provided by a standards organization is that it allows the
industry to converge on an interoperable solution. If we simply become a
means of allocating codepoints in support of multiple non-interoperable
solutions then I think we as an organization have failed.
Gyan> Agreed.  Interoperability is critical for all 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 solution and then progress that solution as
standards track

>Les
>
>
>
> *From:* Gyan Mishra 
> *Sent:* Friday, December 10, 2021 10:56 PM
> *To:* Les Ginsberg (ginsberg) 
> *Cc:* Acee Lindem (acee) ; Muthu Arul Mozhi Perumal <
> muthu.a...@gmail.com>; Tony Li ; Tony Przygienda <
> tonysi...@gmail.com>; lsr@ietf.org
> *Subject:* Re: [Lsr] Using L1 for Transit Traffic in IS-IS
>
>
>
>
>
> Hi Les
>
>
>
> My thoughts are that as both of these drafts are experimental, if both get
> published we can let the industry decide which is to be the p

Re: [Lsr] WG Last Call fo "IS-IS Flood Reflection" -draft-ietf-lsr-isis-flood-reflection-05

[Tony Przygienda]

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 it's not different than
traversing L1 today by means of L1/L2 routers and losing all such routers.
if you have FRs you have all the IGP properties.


> But from your explanation below, there are situations that the draft
> doesn’t covered for the possible loop scenarios. Additional route compare
> rules or configuration requirements needed to be added when such thing
> happens. Then can we call the current solution is not final?
>

nothing needs be added except what the draft describes unless you have
real, concrete examples where the draft rules are not enough assuming a
correctly working implementation.


> And, if we lack one trust theory to avoid the loop, we will be stuck in
> the emerged loop situations.
>

I cannot control what you trust or don't trust based simply on an opinion
you harbor without concrete technical arguments or operational experience.
And unfortunately I am of a distinct "opinion" that whatever technical
explanation I gi8ve you will not change your "opinion" here anyway.


>
> let's be more precise beyond sensationalist headlines ... Though it's nice
> you found our documentation and based on that make first technical argument
> ;-)
>
> a) transitory loops during convergence/tunnel setup may exist, those also
> exist during normal ISIS convergence. Simple implementation techniques used
> in other contexts since many years exist like e.g. holding the router in
> overload until converged. That can be also easily implemented if e.g. a FR
> client has no FR tunnel established. A draft/spec is not an implementation
> description however so techniques deployed can be very different and
> starting to put that in will lead to overspecification.
>
>
> [WAJ] From the example that illustrated in the mentioned example, it seems
> the loop is not transient. It seems when R1 is not act as FR client, the
> loop will occur then?
>

sigh, now I start to explain documentation instead of you reading &
understanding the draft and that's not really the purpose of this list. The
condition can be only transitory or otherwise R1 is separate from R0 in L1
(if it is not then it will form the tunnel to FR via R0 [and there is also
a very weird case of R0 being in overload which however also works]). If
it's separated from R0 in L1 R0 will not see the leaked route and hence
cannot loop via leaked L2->L1. If you have an implementation that is a
client but will not form the FR tunnel persistently despite being L1
connected to FR while nevertheless leaking L2->L1 then it's simply a buggy
implementation and nothing can prevent anything from happening then.

I wish personally this doc section was never written or published BTW
though it was surely well-meant as "operational help".


>
> b) let's split the rest assuming full convergence scenario into tunnel;
> and no L1 tunnels case
> ib.) L1 tunnel case when all tunnels in place/converged is simple, it's
> identical really to any shortcut forwarding where the next hop is a tunnel,
> the packet just shows up magically @ the egress. this is AFAIS simpler
> option to understand and deploy correctly. If you harbor fears and doubts
> about the whole thing or looping potential, just use this.
>
>
> [WAJ] Then the merit that you compared with TTZ will go away?
>

 no, FR does NOT expose the L1 tunnel mesh if you have it in L2 contrary to
TTZ (which floods equivalent of a full tunnel mesh to the outside).
Actually the mesh does not even have to be flooded in L1 in flood
reflection case so ISIS is stable (but it can depending on e.g. liveliness
requirements and so on). I have to remark frankly, it seems to me your
grasp of even the most fundamental properties of the different
solutions/trade-offs in all those drafts is tenuous.


> b.ii) no tunnel case is more delicate (but hotly desired by many [arguably
> sophisticated] customers hence the work). If the SPF is implemented
> correctly no routing loops exist when converged.
>
> This preconditions  also correct leaking of L1 into L2 (hence the "all
> egress MUST be clients", it could work with a mix but the draft gets
> unnecessarily complex) and section 5.2 of the draft provides the necessary
> implementation on SPF to prevent loops in every case.
>
> [WAJ] As Acee pointe out also, this section is harder to understand and
> not in clear logic. I doubt and am unconvinced that it can cover every case.
>

this is a spec and not a story except the introduction section maybe. Specs
are written by defining rules. The section gives all the rules SPF needs to
implement for the solution to work correctly.


>
> However, as the documentation you found says it is easier to ensure that
> L1 metrics when deployed are shorter than L2 metrics s

Re: [Lsr] IPR Poll for "IS-IS Flood Reflection" -draft-ietf-lsr-isis-flood-reflection-05 (WG Last Call Iteration)

[Acee Lindem (acee)]

Hi Alankar,
Please reply to this IPR poll now that we have your correct contact information.
Thanks,
Acee

From: Lsr  on behalf of "Acee Lindem (acee)" 

Date: Monday, November 22, 2021 at 2:52 PM
To: "draft-ietf-lsr-isis-flood-reflect...@ietf.org" 

Cc: "lsr@ietf.org" 
Subject: [Lsr] IPR Poll for "IS-IS Flood Reflection" 
-draft-ietf-lsr-isis-flood-reflection-05 (WG Last Call Iteration)

Authors, Contributors,

Are you aware of any IPR that applies to 
draft-ietf-lsr-isis-flood-reflection-05?

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as a document author or contributor please respond
to this email regardless of whether or not you are aware of any
relevant IPR. *The response needs to be sent to the LSR WG mailing
list.* The document will not advance to the next stage until a
response has been received from each author and contributor.

If you are on the LSR WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of
any IPR that has not yet been disclosed in conformance with IETF rules.

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

Re: [Lsr] Using L1 for Transit Traffic in IS-IS

[Robert Raszuk]

Hey Les,

I think you are making a very valid point. Especially important in
the context of link state protocols.

To illustrate perhaps even better your point, let's assume there is a
customer who is not a single vendor one. So assume he is using vendor J
with reflection and vendor's A with proxy. And now he comes to vendor C and
is asking to implement both solutions for him.

Well you can say no.

But if you really want to grab some business from this customer your folks
selling stuff may say yes (without even asking for opinion) and then you
are stuck with implementing both which in spite of solving the same problem
makes the complexity to translate or at least interact with each
other exponentially more complex if at all possible.

Of course you can also invent your own third one and push to RFC status as
experimental.

But none of this actually helps the protocol.

Best,
R.





On Sat, Dec 11, 2021 at 4:43 PM Les Ginsberg (ginsberg)  wrote:

> Gyan –
>
>
>
> Both drafts have been adopted as WG documents and been provided with early
> allocation of codepoints. So there is nothing preventing
> implementations/deployments from proceeding and doing so without fear that
> if/when the documents proceed to become RFCs that there will be backwards
> compatibility issues because of codepoint changes.
>
> My concern is that there is no effort underway since WG adoption to use
> implementation experience to compare/contrast the solutions and determine
> whether one is better and/or if there really is a need for multiple
> solutions. That seemed to me to be the point of adopting both.
>
> I do not see the need to progress either document to RFC at this time –
> and I am concerned that in doing so we make it even less likely that such a
> comparison will ever be made.
>
>
>
> I had hoped – as you are a representative of one of the potential users of
> this technology and you had suggested that there might be reasons why you
> were interested in both – that you could provide some input into when one
> solution was more desirable than another.
>
>
>
> The value add provided by a standards organization is that it allows the
> industry to converge on an interoperable solution. If we simply become a
> means of allocating codepoints in support of multiple non-interoperable
> solutions then I think we as an organization have failed.
>
> This does not mean that we should not support experimentation – and in
> this case I think we are doing so.
>
>
>
>Les
>
>
>
> *From:* Gyan Mishra 
> *Sent:* Friday, December 10, 2021 10:56 PM
> *To:* Les Ginsberg (ginsberg) 
> *Cc:* Acee Lindem (acee) ; Muthu Arul Mozhi Perumal <
> muthu.a...@gmail.com>; Tony Li ; Tony Przygienda <
> tonysi...@gmail.com>; lsr@ietf.org
> *Subject:* Re: [Lsr] Using L1 for Transit Traffic in IS-IS
>
>
>
>
>
> Hi Les
>
>
>
> My thoughts are that as both of these drafts are experimental, if both get
> published we can let the industry decide which is to be the preferred
> solution which can then progress as standards track to address
> interoperability issues with a single solution implemented by vendors.
>
>
>
> I think by picking one now over the other we are not letting the cards
> fall on the table and prematurely making a decision and not letting things
> naturally play out.
>
>
>
> I agree the implementation of each is non trivial however the router
> configuration could boil down to a simple knob similar to fast flooding.
> As an example there maybe use cases that for a DC CLOS topology where area
> proxy with n-way ECMP paths leaf to scale out spine maybe better suited,
> however in a core or aggregation domain maybe flood reflection maybe
> preferred from a topological perspective  during the study phase.
>
>
>
> I don’t have a crystal ball but it’s possible just as winning the lottery
> is possible that both drafts garnish industry support and from a sales and
> marketing perspective vendors can still have their cake and eat it too by
> solving a major backbone scalability issue win win for all and so
> developing both solutions that become standards track and implemented by
> all vendors.  No interoperability issues.
>
>
>
> I am in agreement on implementation that in the end having a single
> solution is most desirable to avoid interoperability.
>
>
>
> Kind Regards
>
>
>
> Gyan
>
>
>
> On Sat, Dec 11, 2021 at 12:24 AM Les Ginsberg (ginsberg) <
> ginsb...@cisco.com> wrote:
>
> Gyan –
>
>
>
> I am interested in your perspective – but could you provide more details?
>
> What deployment scenarios do you have in mind where one solution is
> advantageous over the other? And why are both scenarios likely to be seen
> in the real world?
>
>
>
> 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.
>
>
>
> Les
>
>
>
> *From:* Gyan Mishra 
> *Sent:* Friday, December 10, 2021 5:46 PM
> *To:* Muthu Aru

Re: [Lsr] Using L1 for Transit Traffic in IS-IS

[Les Ginsberg (ginsberg)]

Gyan –

Both drafts have been adopted as WG documents and been provided with early 
allocation of codepoints. So there is nothing preventing 
implementations/deployments from proceeding and doing so without fear that 
if/when the documents proceed to become RFCs that there will be backwards 
compatibility issues because of codepoint changes.
My concern is that there is no effort underway since WG adoption to use 
implementation experience to compare/contrast the solutions and determine 
whether one is better and/or if there really is a need for multiple solutions. 
That seemed to me to be the point of adopting both.
I do not see the need to progress either document to RFC at this time – and I 
am concerned that in doing so we make it even less likely that such a 
comparison will ever be made.

I had hoped – as you are a representative of one of the potential users of this 
technology and you had suggested that there might be reasons why you were 
interested in both – that you could provide some input into when one solution 
was more desirable than another.

The value add provided by a standards organization is that it allows the 
industry to converge on an interoperable solution. If we simply become a means 
of allocating codepoints in support of multiple non-interoperable solutions 
then I think we as an organization have failed.
This does not mean that we should not support experimentation – and in this 
case I think we are doing so.

   Les

From: Gyan Mishra 
Sent: Friday, December 10, 2021 10:56 PM
To: Les Ginsberg (ginsberg) 
Cc: Acee Lindem (acee) ; Muthu Arul Mozhi Perumal 
; Tony Li ; Tony Przygienda 
; lsr@ietf.org
Subject: Re: [Lsr] Using L1 for Transit Traffic in IS-IS


Hi Les

My thoughts are that as both of these drafts are experimental, if both get 
published we can let the industry decide which is to be the preferred solution 
which can then progress as standards track to address interoperability issues 
with a single solution implemented by vendors.

I think by picking one now over the other we are not letting the cards fall on 
the table and prematurely making a decision and not letting things naturally 
play out.

I agree the implementation of each is non trivial however the router 
configuration could boil down to a simple knob similar to fast flooding.  As an 
example there maybe use cases that for a DC CLOS topology where area proxy with 
n-way ECMP paths leaf to scale out spine maybe better suited, however in a core 
or aggregation domain maybe flood reflection maybe preferred from a topological 
perspective  during the study phase.

I don’t have a crystal ball but it’s possible just as winning the lottery is 
possible that both drafts garnish industry support and from a sales and 
marketing perspective vendors can still have their cake and eat it too by 
solving a major backbone scalability issue win win for all and so developing 
both solutions that become standards track and implemented by all vendors.  No 
interoperability issues.

I am in agreement on implementation that in the end having a single solution is 
most desirable to avoid interoperability.

Kind Regards

Gyan

On Sat, Dec 11, 2021 at 12:24 AM Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>> wrote:
Gyan –

I am interested in your perspective – but could you provide more details?
What deployment scenarios do you have in mind where one solution is 
advantageous over the other? And why are both scenarios likely to be seen in 
the real world?

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.

Les

From: Gyan Mishra mailto:hayabusa...@gmail.com>>
Sent: Friday, December 10, 2021 5:46 PM
To: Muthu Arul Mozhi Perumal mailto:muthu.a...@gmail.com>>
Cc: Acee Lindem (acee) mailto:a...@cisco.com>>; Les Ginsberg 
(ginsberg) mailto:ginsb...@cisco.com>>; Tony Li 
mailto:tony...@tony.li>>; Tony Przygienda 
mailto:tonysi...@gmail.com>>; 
lsr@ietf.org
Subject: Re: [Lsr] Using L1 for Transit Traffic in IS-IS

All

As Acee mentioned per the subject of this thread “Using L1 for transit traffic 
in IS-IS” is supported today and is deployed by operators with large backbones 
as well today, and both solutions,  area proxy and flood reflection now allows 
the L1 transit solution  to scale.

Speaking from an operators perspective we are in favor of multiple solutions as 
their maybe use cases where one applies better then the other and vice versa.  
Flexibility is a good thing.

Kind Regards

Gyan

On Fri, Dec 10, 2021 at 1:54 AM Muthu Arul Mozhi Perumal 
mailto:muthu.a...@gmail.com>> wrote:
Hi,

It is possible to designate experimental RFCs as historic if there is no 
evidence of widespread use over a period of time, as is currently being done 
for HTTP-related experimental RFCs:
https://datatracker.ietf.org/doc/status-change-http-experiments-to-historic/

Hence, I think ha

Re: [Lsr] WG Last Call fo "IS-IS Flood Reflection" -draft-ietf-lsr-isis-flood-reflection-05

[Tony Przygienda]

sorry, seems you didn't parse what I wrote in previous email and keep on
generating FUD. The solution is loop free if the draft is correctly
implemented in both tunnel and no-tunnel scenario. The rest is subtlety of
how you deploy it (and implementation choices) that I tried to explain. I
cannot put it more simply than that ...

-- tony

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.
> But from your explanation below, there are situations that the draft
> doesn’t covered for the possible loop scenarios. Additional route compare
> rules or configuration requirements needed to be added when such thing
> happens. Then can we call the current solution is not final?
> And, if we lack one trust theory to avoid 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 nice
> you found our documentation and based on that make first technical argument
> ;-)
>
> a) transitory loops during convergence/tunnel setup may exist, those also
> exist during normal ISIS convergence. Simple implementation techniques used
> in other contexts since many years exist like e.g. holding the router in
> overload until converged. That can be also easily implemented if e.g. a FR
> client has no FR tunnel established. A draft/spec is not an implementation
> description however so techniques deployed can be very different and
> starting to put that in will lead to overspecification.
>
>
> [WAJ] From the example that illustrated in the mentioned example, it seems
> the loop is not transient. It seems when R1 is not act as FR client, the
> loop will occur then?
>
> b) let's split the rest assuming full convergence scenario into tunnel;
> and no L1 tunnels case
> ib.) L1 tunnel case when all tunnels in place/converged is simple, it's
> identical really to any shortcut forwarding where the next hop is a tunnel,
> the packet just shows up magically @ the egress. this is AFAIS simpler
> option to understand and deploy correctly. If you harbor fears and doubts
> about the whole thing or looping potential, just use this.
>
>
> [WAJ] Then the merit that you compared with TTZ will go away?
>
> b.ii) no tunnel case is more delicate (but hotly desired by many [arguably
> sophisticated] customers hence the work). If the SPF is implemented
> correctly no routing loops exist when converged.
>
> This preconditions  also correct leaking of L1 into L2 (hence the "all
> egress MUST be clients", it could work with a mix but the draft gets
> unnecessarily complex) and section 5.2 of the draft provides the necessary
> implementation on SPF to prevent loops in every case.
>
> [WAJ] As Acee pointe out also, this section is harder to understand and
> not in clear logic. I doubt and am unconvinced that it can cover every case.
>
> However, as the documentation you found says it is easier to ensure that
> L1 metrics when deployed are shorter than L2 metrics so the L1->L2 route
> always takes preference towards the egress and not rely on the correct SPF
> preferece outside metric comparison.
>
>
> [WAJ] To achieve this, the design should be verified by manual carefully?
>
> As footnote: redistributing prefixes in ISIS is always delicate, nothing
> new here, L1->L2->L1 was originally forbidden and only works with the RFC
> and lots of tightly kept pref rules. With enough inventive re-distribution
> on a system around the RFC and fiddiling via policy with redistributed
> route properties you can loop up normal ISIS as well BTW.
>
>
> [WAJ] Can I say that your solution is based on the original forbidden
> design? To explore the forbidden, you introduce the additional SPF rules.
> When the topology or interconnection scenario become complex, will the SPF
> rules complex also?
>
> c) ECMP, yes, as our doc says it's not looping but it can be changed when
> using b.ii) unless whole network is forklifted to flood reflection and e.g.
> omits ECMP computed over FR adjacencies which again, is an implementation
> technique that is optional complexity since FR adjacencies are not
> forwarding (one could make them taht and stuff would still work but then we
> would have all kind of restrictions on tunnels like e.g. XoUDP to ECMP
> inside L1 and ultimately shove e'thing though FRs, most customers think
> that doing L2 hot potato forwarding out the area is actually far preferred
> IME).
>
> And no, you will never achieve the same "globally optimal" routing through
> the whole topology in L2 when abstracting some L1 things except when you
> advertise a full mesh of links reflecting all ingress-egress metrics in L2
> being basically L1 shortest path (or assume that all ingress/egress
> connections have infinite/same metric, it's cal

Re: [Lsr] Using L1 for Transit Traffic in IS-IS

[Tony Przygienda]

it's a circular argument to an extent (though I'm sympathetic with the
thought). Unless a draft is an experimental RFC there is no real stable
point to implement & deploy so it's hard these days to get 2
implementations unless one sponsors an open source one (and nature of ISIS
is that there is barely any open source given that it runs normally @ scale
& feature count that open source is simply not efficient enough though I
admit it maybe just my lens to an extent).

So having nothing experimental and nevertheless deployed generates then
de-facto proprietary stuff since deployed solutions become pretty immovable
targets as we all know.

So, take your pick but it's hard to have it both ways these days IMO ...

-- tony

On Sat, Dec 11, 2021 at 4:14 PM Robert Raszuk  wrote:

>
> Well WFIW IDR solved this dilemma by mandating at least two documented
> implementations before proceeding with any proposal to IESG (irrespective
> of the RFC document type).
>
> After all nothing stops anyone from implementing an idea described in the
> WG document using if needed early code point allocations.
>
> On the other hand having RFC experimental status of any proposal ensures
> it has been reviewed by a number of people and that at least no major
> issues have been found during the review.
>
> Of course IGP is not BGP though both use multiple vendors network
> elements, but I guess that would narrow the gates of single vendors pushing
> their own proprietary solutions via IETF.
>
> Kind regards,
> Robert
>
> On Sat, Dec 11, 2021 at 7:56 AM Gyan Mishra  wrote:
>
>>
>> Hi Les
>>
>> My thoughts are that as both of these drafts are experimental, if both
>> get published we can let the industry decide which is to be the preferred
>> solution which can then progress as standards track to address
>> interoperability issues with a single solution implemented by vendors.
>>
>> I think by picking one now over the other we are not letting the cards
>> fall on the table and prematurely making a decision and not letting things
>> naturally play out.
>>
>> I agree the implementation of each is non trivial however the router
>> configuration could boil down to a simple knob similar to fast flooding.
>> As an example there maybe use cases that for a DC CLOS topology where area
>> proxy with n-way ECMP paths leaf to scale out spine maybe better suited,
>> however in a core or aggregation domain maybe flood reflection maybe
>> preferred from a topological perspective  during the study phase.
>>
>> I don’t have a crystal ball but it’s possible just as winning the lottery
>> is possible that both drafts garnish industry support and from a sales and
>> marketing perspective vendors can still have their cake and eat it too by
>> solving a major backbone scalability issue win win for all and so
>> developing both solutions that become standards track and implemented by
>> all vendors.  No interoperability issues.
>>
>> I am in agreement on implementation that in the end having a single
>> solution is most desirable to avoid interoperability.
>>
>> Kind Regards
>>
>> Gyan
>>
>> On Sat, Dec 11, 2021 at 12:24 AM Les Ginsberg (ginsberg) <
>> ginsb...@cisco.com> wrote:
>>
>>> Gyan –
>>>
>>>
>>>
>>> I am interested in your perspective – but could you provide more details?
>>>
>>> What deployment scenarios do you have in mind where one solution is
>>> advantageous over the other? And why are both scenarios likely to be seen
>>> in the real world?
>>>
>>>
>>>
>>> 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.
>>>
>>>
>>>
>>> Les
>>>
>>>
>>>
>>> *From:* Gyan Mishra 
>>> *Sent:* Friday, December 10, 2021 5:46 PM
>>> *To:* Muthu Arul Mozhi Perumal 
>>> *Cc:* Acee Lindem (acee) ; Les Ginsberg (ginsberg) <
>>> ginsb...@cisco.com>; Tony Li ; Tony Przygienda <
>>> tonysi...@gmail.com>; lsr@ietf.org
>>> *Subject:* Re: [Lsr] Using L1 for Transit Traffic in IS-IS
>>>
>>>
>>>
>>> All
>>>
>>>
>>>
>>> As Acee mentioned per the subject of this thread “Using L1 for transit
>>> traffic in IS-IS” is supported today and is deployed by operators with
>>> large backbones as well today, and both solutions,  area proxy and flood
>>> reflection now allows the L1 transit solution  to scale.
>>>
>>>
>>>
>>> Speaking from an operators perspective we are in favor of multiple
>>> solutions as their maybe use cases where one applies better then the other
>>> and vice versa.  Flexibility is a good thing.
>>>
>>>
>>>
>>> Kind Regards
>>>
>>>
>>>
>>> Gyan
>>>
>>>
>>>
>>> On Fri, Dec 10, 2021 at 1:54 AM Muthu Arul Mozhi Perumal <
>>> muthu.a...@gmail.com> wrote:
>>>
>>> Hi,
>>>
>>>
>>>
>>> It is possible to designate experimental RFCs as historic if there is no
>>> evidence of widespread use over a period of time, as is currently being
>>> done for HTTP-related experimental RFCs:
>>>
>>>
>>> https://datatracker.ie

Re: [Lsr] Using L1 for Transit Traffic in IS-IS

[Robert Raszuk]

Well WFIW IDR solved this dilemma by mandating at least two documented
implementations before proceeding with any proposal to IESG (irrespective
of the RFC document type).

After all nothing stops anyone from implementing an idea described in the
WG document using if needed early code point allocations.

On the other hand having RFC experimental status of any proposal ensures it
has been reviewed by a number of people and that at least no major issues
have been found during the review.

Of course IGP is not BGP though both use multiple vendors network elements,
but I guess that would narrow the gates of single vendors pushing their own
proprietary solutions via IETF.

Kind regards,
Robert

On Sat, Dec 11, 2021 at 7:56 AM Gyan Mishra  wrote:

>
> Hi Les
>
> My thoughts are that as both of these drafts are experimental, if both get
> published we can let the industry decide which is to be the preferred
> solution which can then progress as standards track to address
> interoperability issues with a single solution implemented by vendors.
>
> I think by picking one now over the other we are not letting the cards
> fall on the table and prematurely making a decision and not letting things
> naturally play out.
>
> I agree the implementation of each is non trivial however the router
> configuration could boil down to a simple knob similar to fast flooding.
> As an example there maybe use cases that for a DC CLOS topology where area
> proxy with n-way ECMP paths leaf to scale out spine maybe better suited,
> however in a core or aggregation domain maybe flood reflection maybe
> preferred from a topological perspective  during the study phase.
>
> I don’t have a crystal ball but it’s possible just as winning the lottery
> is possible that both drafts garnish industry support and from a sales and
> marketing perspective vendors can still have their cake and eat it too by
> solving a major backbone scalability issue win win for all and so
> developing both solutions that become standards track and implemented by
> all vendors.  No interoperability issues.
>
> I am in agreement on implementation that in the end having a single
> solution is most desirable to avoid interoperability.
>
> Kind Regards
>
> Gyan
>
> On Sat, Dec 11, 2021 at 12:24 AM Les Ginsberg (ginsberg) <
> ginsb...@cisco.com> wrote:
>
>> Gyan –
>>
>>
>>
>> I am interested in your perspective – but could you provide more details?
>>
>> What deployment scenarios do you have in mind where one solution is
>> advantageous over the other? And why are both scenarios likely to be seen
>> in the real world?
>>
>>
>>
>> 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.
>>
>>
>>
>> Les
>>
>>
>>
>> *From:* Gyan Mishra 
>> *Sent:* Friday, December 10, 2021 5:46 PM
>> *To:* Muthu Arul Mozhi Perumal 
>> *Cc:* Acee Lindem (acee) ; Les Ginsberg (ginsberg) <
>> ginsb...@cisco.com>; Tony Li ; Tony Przygienda <
>> tonysi...@gmail.com>; lsr@ietf.org
>> *Subject:* Re: [Lsr] Using L1 for Transit Traffic in IS-IS
>>
>>
>>
>> All
>>
>>
>>
>> As Acee mentioned per the subject of this thread “Using L1 for transit
>> traffic in IS-IS” is supported today and is deployed by operators with
>> large backbones as well today, and both solutions,  area proxy and flood
>> reflection now allows the L1 transit solution  to scale.
>>
>>
>>
>> Speaking from an operators perspective we are in favor of multiple
>> solutions as their maybe use cases where one applies better then the other
>> and vice versa.  Flexibility is a good thing.
>>
>>
>>
>> Kind Regards
>>
>>
>>
>> Gyan
>>
>>
>>
>> On Fri, Dec 10, 2021 at 1:54 AM Muthu Arul Mozhi Perumal <
>> muthu.a...@gmail.com> wrote:
>>
>> Hi,
>>
>>
>>
>> It is possible to designate experimental RFCs as historic if there is no
>> evidence of widespread use over a period of time, as is currently being
>> done for HTTP-related experimental RFCs:
>>
>>
>> https://datatracker.ietf.org/doc/status-change-http-experiments-to-historic/
>>
>>
>>
>> Hence, I think having multiple experimental publications for a problem is
>> ok..
>>
>>
>>
>> Regards,
>>
>> Muthu
>>
>>
>>
>> On Fri, Dec 10, 2021 at 6:08 AM Les Ginsberg (ginsberg) > 40cisco@dmarc.ietf.org> wrote:
>>
>> Acee –
>>
>>
>>
>> Thanx for responding while you are on vacation.
>>
>>
>>
>> While it is true I am not enthusiastic about any of the solutions, my
>> point of emphasis is that it’s a failure of WG process to simply move
>> forward with all solutions – which it seems to me is what is about to
>> happen.
>>
>>
>>
>> Note that this is completely consistent with what I said back when WG
>> adoption for the drafts was being discussed (thanx to Tony P for pointing
>> me back to that time (June 21, 2020)):
>>
>>
>>
>> **
>>
>> *I support the WG adoption of
>> https://datatracker.ietf.org/doc/draft-li-lsr-isis-area-proxy/
>> 

Re: [Lsr] WG Last Call fo "IS-IS Flood Reflection" -draft-ietf-lsr-isis-flood-reflection-05

[Aijun Wang]

Hi, Tony:

The advantage of IGP is that it can cure itself when there is any topology 
change, no additional  operator intervention involved.
But from your explanation below, there are situations that the draft doesn’t 
covered for the possible loop scenarios. Additional route compare rules or 
configuration requirements needed to be added when such thing happens. Then can 
we call the current solution is not final?
And, if we lack one trust theory to avoid 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 nice 
> you found our documentation and based on that make first technical argument 
> ;-) 
> 
> a) transitory loops during convergence/tunnel setup may exist, those also 
> exist during normal ISIS convergence. Simple implementation techniques used 
> in other contexts since many years exist like e.g. holding the router in 
> overload until converged. That can be also easily implemented if e.g. a FR 
> client has no FR tunnel established. A draft/spec is not an implementation 
> description however so techniques deployed can be very different and starting 
> to put that in will lead to overspecification. 

[WAJ] From the example that illustrated in the mentioned example, it seems the 
loop is not transient. It seems when R1 is not act as FR client, the loop will 
occur then?

> b) let's split the rest assuming full convergence scenario into tunnel; and 
> no L1 tunnels case 
> ib.) L1 tunnel case when all tunnels in place/converged is simple, it's 
> identical really to any shortcut forwarding where the next hop is a tunnel, 
> the packet just shows up magically @ the egress. this is AFAIS simpler option 
> to understand and deploy correctly. If you harbor fears and doubts about the 
> whole thing or looping potential, just use this. 

[WAJ] Then the merit that you compared with TTZ will go away?

> b.ii) no tunnel case is more delicate (but hotly desired by many [arguably 
> sophisticated] customers hence the work). If the SPF is implemented correctly 
> no routing loops exist when converged.
> This preconditions  also correct leaking of L1 into L2 (hence the "all egress 
> MUST be clients", it could work with a mix but the draft gets unnecessarily 
> complex) and section 5.2 of the draft provides the necessary implementation 
> on SPF to prevent loops in every case.
[WAJ] As Acee pointe out also, this section is harder to understand and not in 
clear logic. I doubt and am unconvinced that it can cover every case.

> However, as the documentation you found says it is easier to ensure that L1 
> metrics when deployed are shorter than L2 metrics so the L1->L2 route always 
> takes preference towards the egress and not rely on the correct SPF preferece 
> outside metric comparison.

[WAJ] To achieve this, the design should be verified by manual carefully?

> As footnote: redistributing prefixes in ISIS is always delicate, nothing new 
> here, L1->L2->L1 was originally forbidden and only works with the RFC and 
> lots of tightly kept pref rules. With enough inventive re-distribution on a 
> system around the RFC and fiddiling via policy with redistributed route 
> properties you can loop up normal ISIS as well BTW. 

[WAJ] Can I say that your solution is based on the original forbidden design? 
To explore the forbidden, you introduce the additional SPF rules. When the 
topology or interconnection scenario become complex, will the SPF rules complex 
also?

> c) ECMP, yes, as our doc says it's not looping but it can be changed when 
> using b.ii) unless whole network is forklifted to flood reflection and e.g. 
> omits ECMP computed over FR adjacencies which again, is an implementation 
> technique that is optional complexity since FR adjacencies are not forwarding 
> (one could make them taht and stuff would still work but then we would have 
> all kind of restrictions on tunnels like e.g. XoUDP to ECMP inside L1 and 
> ultimately shove e'thing though FRs, most customers think that doing L2 hot 
> potato forwarding out the area is actually far preferred IME).
> 
> And no, you will never achieve the same "globally optimal" routing through 
> the whole topology in L2 when abstracting some L1 things except when you 
> advertise a full mesh of links reflecting all ingress-egress metrics in L2 
> being basically L1 shortest path (or assume that all ingress/egress 
> connections have infinite/same metric, it's called a chassis or more 
> precisely a switching fabric then ;-). Beside scaling very poorly as the 
> draft explains this can also cause a single link failing in L1 to cause a 
> havoc of advertisements in L2 and if you are experienced in operational 
> matters this is the last things you desire. In more abstract control theory 
> terms you are building with such a solution a negatively stable system of 
> c

Re: [Lsr] WG Last Call fo "IS-IS Flood Reflection" -draft-ietf-lsr-isis-flood-reflection-05

[Tony Przygienda]

let's be more precise beyond sensationalist headlines ... Though it's nice
you found our documentation and based on that make first technical argument
;-)

a) transitory loops during convergence/tunnel setup may exist, those also
exist during normal ISIS convergence. Simple implementation techniques used
in other contexts since many years exist like e.g. holding the router in
overload until converged. That can be also easily implemented if e.g. a FR
client has no FR tunnel established. A draft/spec is not an implementation
description however so techniques deployed can be very different and
starting to put that in will lead to overspecification.
b) let's split the rest assuming full convergence scenario into tunnel; and
no L1 tunnels case
ib.) L1 tunnel case when all tunnels in place/converged is simple, it's
identical really to any shortcut forwarding where the next hop is a tunnel,
the packet just shows up magically @ the egress. this is AFAIS simpler
option to understand and deploy correctly. If you harbor fears and doubts
about the whole thing or looping potential, just use this.
b.ii) no tunnel case is more delicate (but hotly desired by many [arguably
sophisticated] customers hence the work). If the SPF is implemented
correctly no routing loops exist when converged. This preconditions  also
correct leaking of L1 into L2 (hence the "all egress MUST be clients", it
could work with a mix but the draft gets unnecessarily complex) and section
5.2 of the draft provides the necessary implementation on SPF to prevent
loops in every case. However, as the documentation you found says it is
easier to ensure that L1 metrics when deployed are shorter than L2 metrics
so the L1->L2 route always takes preference towards the egress and not rely
on the correct SPF preferece outside metric comparison. As footnote:
redistributing prefixes in ISIS is always delicate, nothing new here,
L1->L2->L1 was originally forbidden and only works with the RFC and lots of
tightly kept pref rules. With enough inventive re-distribution on a system
around the RFC and fiddiling via policy with redistributed route properties
you can loop up normal ISIS as well BTW.
c) ECMP, yes, as our doc says it's not looping but it can be changed when
using b.ii) unless whole network is forklifted to flood reflection and e.g.
omits ECMP computed over FR adjacencies which again, is an implementation
technique that is optional complexity since FR adjacencies are not
forwarding (one could make them taht and stuff would still work but then we
would have all kind of restrictions on tunnels like e.g. XoUDP to ECMP
inside L1 and ultimately shove e'thing though FRs, most customers think
that doing L2 hot potato forwarding out the area is actually far preferred
IME).

And no, you will never achieve the same "globally optimal" routing through
the whole topology in L2 when abstracting some L1 things except when you
advertise a full mesh of links reflecting all ingress-egress metrics in L2
being basically L1 shortest path (or assume that all ingress/egress
connections have infinite/same metric, it's called a chassis or more
precisely a switching fabric then ;-). Beside scaling very poorly as the
draft explains this can also cause a single link failing in L1 to cause a
havoc of advertisements in L2 and if you are experienced in operational
matters this is the last things you desire. In more abstract control theory
terms you are building with such a solution a negatively stable system of
control loops or in simpler terms an invisible big blast radius. Good for
fighter planes, very bad for networking if you experienced those effects.

hope that's enough details, none of this is BTW pure speculation but output
of implemenation and extensive testing.

--- tony

On Sat, Dec 11, 2021 at 8:48 AM Aijun Wang 
wrote:

> Please refer to “Routing Loops” section that described in your company’s
> documents:
>
> https://www.juniper.net/documentation/en_US/junos/topics/concept/understanding-isis-flood-reflectors.html#jd0e162
>
> This is just the simplest transit scenario. I am worrying for its further
> applications.
>
> 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?
>
> Aijun Wang
> China Telecom
>
> On Dec 11, 2021, at 02:02, Tony Przygienda  wrote:
>
> 
> 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
> preferences all those claims of "better" things are based) by the simple
> fact that there is only a single connected L2 area ever in ISIS, if you
> partition L2 you do not run ISIS within its viable envelope anymore, with
> or

[Lsr] I-D Action: draft-ietf-lsr-yang-isis-reverse-metric-05.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Link State Routing WG of the IETF.

Title   : YANG Module for IS-IS Reverse Metric
Author  : Christian Hopps
Filename: draft-ietf-lsr-yang-isis-reverse-metric-05.txt
Pages   : 15
Date: 2021-12-11

Abstract:
   This document defines a YANG module for managing the reverse metric
   extension to the Intermediate System to Intermediate System intra-
   domain routeing information exchange protocol (IS-IS).


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lsr-yang-isis-reverse-metric/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-lsr-yang-isis-reverse-metric-05.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-yang-isis-reverse-metric-05


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


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

Re: [Lsr] Alvaro Retana's No Objection on draft-ietf-lsr-yang-isis-reverse-metric-04: (with COMMENT)

[Christian Hopps]

Alvaro Retana via Datatracker  writes:


Alvaro Retana has entered the following ballot position for
draft-ietf-lsr-yang-isis-reverse-metric-04: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lsr-yang-isis-reverse-metric/



--
COMMENT:
--

whole-lan is only applicable to multi-access interfaces.  I was expecting
something similar to how "priority" is defined (in the main module), but I
can't find that here.  Am I missing something?


Do you mean to make it conditional based on the interface type? I looked at 
doing this and I believe it would involve breaking apart the groupings, then 
duplicating that grouping data into received in TLV vs configuration, then 
leaving out the W flag bit config from the configuration grouping, and then 
conditionally augmenting that W bit config back in at each of the three 
locations under the interface.

This seems like a lot of "inelegant" changes to add this automated check to the 
YANG. The implementations are already bound by RFC8500 to DTRT WRT the W bit and 
LAN/Non-LAN interfaces. I think perhaps that's enough.

Thanks,
Chris.





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




signature.asc
Description: PGP signature
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Benjamin Kaduk's No Objection on draft-ietf-lsr-yang-isis-reverse-metric-04: (with COMMENT)

[Christian Hopps]

Benjamin Kaduk via Datatracker  writes:


Benjamin Kaduk has entered the following ballot position for
draft-ietf-lsr-yang-isis-reverse-metric-04: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lsr-yang-isis-reverse-metric/



--
COMMENT:
--

Thanks for the simple and easy-to-read document!
My comments are pretty minor.

Section 2.2

 grouping reverse-metric-if-config-data {
   description "IS-IS reverse metric config data.";
   container reverse-metric {
 description "IS-IS reverse metric data.";
 uses reverse-metric-data;
 leaf exclude-te-metric {
   type boolean;
   default false;
   description
 "If true and there is a TE metric defined for this
  interface then do not send the TE metric sub-TLV in the
  reverse metric TLV.";
   reference "RFC8500, Section 3.5";
 }
   }
 }

 grouping tlv16-reverse-metric {
   description "IS-IS reverse metric TLV data.";
   container reverse-metric {
 description "IS-IS reverse metric TLV data.";
 uses reverse-metric-data;
 leaf te-metric {
   type uint32;
   description
 "The TE metric value from the sub-TLV if present.";
   reference "RFC8500, Section 3.5";
 }
   }
 }

Please confirm that Section 3.5 of RFC 8500 is the right reference for
both of these; I didn't really see much there that lined up well with
these descriptions.


I've changed them to match the ones above and point to section 2.


   container reverse-metric {
 description "Announce a reverse metric to neighbors.";
 uses reverse-metric-if-config-data;
 container level-1 {
   description
 "Announce a reverse metric to level-1 neighbors.";
   uses reverse-metric-if-config-data;
 }
 container level-2 {
   description
 "Announce a reverse metric to level-2 neighbors.";
   uses reverse-metric-if-config-data;
 }
   }

Are the interactions between the toplevel
"reverse-metric-if-config-data" and the per-level uses of that grouping
adequately specified by the core draft-ietf-isis-yang-isis-cfg such that
we don't need to repeat them here?  (I think it probably is.)


Yes.


Section 4

   These are the subtrees and data nodes and their sensitivity/
   vulnerability:

I think the intent of the security considerations template is that we
specifically talk about what bad things would happen if some
unauthorized entity was writing values to the ("config true") nodes, or
reading values from the ("config false") nodes.  The current text here
seems to just be listing the nodes without saying what happens if
they're misconfigured or the contents are leaked to an unauthorized
party.  (On first glance, it seems like the security considerations of
RFC 8500 basically cover everything that we would need to say.  It's
short, so we could repeat the content, or we could say that these YANG
nodes correspond directly to the RFC 8500 functionality and the
considerations of the functionality are described in RFC 8500.)


Added "These YANG nodes correspond directly to the RFC 8500 functionality and the 
security considerations of the functionality are described in RFC 8500." to text 
describing the nodes


Section 5

The core NETCONF/RESTCONF RFCs may not need to be classified as
normative (we only reference them from the security considerations
boilerplate), but there's not much harm in leaving them here.


Moved them to informative.


Appendix A

Thank you for including the examples!


NP. :)

Thanks,
Chris.





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


k


signature.asc
Description: PGP signature
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr