Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[Aijun Wang]

Hi, Tony:

We are trying to reuse the existing mechanism to solve such problem, but as 
mentioned in 
https://mailarchive.ietf.org/arch/msg/lsr/kTWLct7VgEfOxexdwzwcFS3Ctqc/:

"[WAJ] Reuse the Link TLV that defined in inter-AS-TE-v2/v3 to contain such 
information is possible, but we should still to define the link type(as that in 
RFC3630) to identify the stub-link, also the prefixes related sub-TLV.  
Comparing the two different approaches, we select to define one new sub-TLV to 
contain the above information in one place together."

And as mentioned in Les, there are strict requirement for the inclusion of 
"Remote-AS", "IPv4/IPv6 Remote ASBR ID" sub-TLV in RFC5316(similar for 
RFC5292). In almost all of the inter-AS scenario(numbered inter-as links), 
these information needn't be configured and transferred.

Then redefine the new stub-link TLV is the reasonable way, it also provides the 
container for other possible information.


Best Regards

Aijun Wang
China Telecom


-Original Message-
From: lsr-boun...@ietf.org  On Behalf Of Tony Li
Sent: Tuesday, January 11, 2022 2:39 PM
To: Aijun Wang 
Cc: lsr ; lsr-...@ietf.org; Christian Hopps ; 
lsr-cha...@ietf.org; draft-wang-lsr-stub-link-attribu...@ietf.org
Subject: Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02


Hi Aijun,

> For the AS boundary use case, do you have other better solution? 


Is there some way that this could be modeled as a normal link instead of a stub 
link?  In any case, I am not responsible for coming up with a better solution. 
The onus is on you to convince us that this is a Good Thing to do.


> I have responded to Les for his mentioned/insisted unnumbered link scenario. 
> if it is acceptable, is it the general design then?


I don’t understand this comment. I agree with Les that unnumbered links are 
important.

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] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

[Tony Li]

Hi Aijun,

> Just because some mechanism wants to use toplogy information does NOT imply 
> that it should be part of the routing protocol.
>  
> In this case, load balancing should be an independent mechanism.  If it wants 
> to peek into the LSDB, that would be perfectly acceptable, IMHO.
> [WAJ] Current LSDB doesn’t include the aggregated cost that can be used to 
> select the optimal application server.


So please feel free to add whatever costs you want to circulate to whatever 
other load balancing protocol you come up with.


> If they are separated, the router should do the SPF calculation twice. Using 
> the constrained SPF/flexalgo to achieve such optimal goal is certainly better 
> than calculate twice.


I don’t understand or believe this.  We have been running multiple SPFs since 
the early days of TE. This is Not A Big Deal.

Tony

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

Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

[Aijun Wang]

Hi, Tony:

 

From: lsr-boun...@ietf.org  On Behalf Of Tony Li
Sent: Tuesday, January 11, 2022 4:20 AM
To: Aijun Wang 
Cc: Les Ginsberg (ginsberg) ; lsr
; Linda Dunbar 
Subject: Re: [Lsr] Seeking feedback to the revised
draft-dunbar-lsr-5g-edge-compute

 

 





On Jan 10, 2022, at 9:05 AM, Aijun Wang mailto:wangai...@tsinghua.org.cn> > wrote:

 

[WAJ] Selecting the most appropriate/optimized application server should
base on the topology information which is routing protocol related.

 

 

Just because some mechanism wants to use toplogy information does NOT imply
that it should be part of the routing protocol.

 

In this case, load balancing should be an independent mechanism.  If it
wants to peek into the LSDB, that would be perfectly acceptable, IMHO.

[WAJ] Current LSDB doesn't include the aggregated cost that can be used to
select the optimal application server.

If they are separated, the router should do the SPF calculation twice. Using
the constrained SPF/flexalgo to achieve such optimal goal is certainly
better than calculate twice.

 

Tony

 

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

Re: [Lsr] BGP vs PUA/PULSE

[Tony Li]

Les,

> [LES:] I believe some of the alternate proposals are tractable – which is not 
> to say that I prefer them.
> But I don’t want to ask questions like “How do you do this…?” in the absence 
> of a writeup.  I am assuming that if we had a writeup the authors would have 
> done their best to define a complete solution and then we could meaningfully 
> review and comment. But without a writeup it is hard for me to say – “Oh yes 
> – this is much better. Let’s abandon the IGP approach and go this way.”


Well, you’re free to do that of course.  And I’m free to object to your draft.

Here we sit, stuck.


> [LES:] We have responded positively to comments about our solution – 
> particularly in the area of scale. (Next version of pulse draft will be out 
> soon – we preferred to enjoy the holidays. 😊)


No one will begrudge you some recreation. :)

The proposals approach to handling scale issues is to sweep things under the 
rug, which is very unsatisfying.

Tony

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

Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

[Aijun Wang]

Hi, Les:

 

From: Les Ginsberg (ginsberg)  
Sent: Tuesday, January 11, 2022 4:55 AM
To: Aijun Wang ; Les Ginsberg (ginsberg) 

Cc: lsr@ietf.org; Linda Dunbar 
Subject: RE: [Lsr] Seeking feedback to the revised 
draft-dunbar-lsr-5g-edge-compute

 

Aijun –

 

Top posting here.

 

I think what is desired is load balancing at the application layer – coupled 
with persistence of a given flow (AKA client-server connection). You aren’t 
going to achieve that by dynamically adjusting IGP costs.

And you are likely to get oscillation – which is undesirable.

[WAJ] The IGP costs that related to the application layer is at the stub end of 
the link. It is not the transit link that other pairs of services will also 
use. \

Then adjust such costs on demand doesn’t influence any transit traffic, the 
oscillation that you are worrying will not happen.

 

As regards the relationship between draft-dunbar-lsr-5g-edge-compute and 
draft-wang-lsr-stub-link-attributes, I noted that in my reading but chose not 
to discuss it as my concerns with each draft are more fundamental and I did not 
want to distract.

But since you mention this, draft-dunbar-lsr-5g-edge-compute is proposing to 
advertise new prefix related information. 

draft-wang-lsr-stub-link-attributes is proposing to advertise new link related 
information.

This difference matters to me – though it seems it does not to you.

One reason why we will never agree about this. 😊

[WAJ] Actually, I prefer to advertise such information with the link, not the 
prefixes.  The application prefixes should also be the attributes of the 
link(specially, stub link). This is the consistent way.

 

As regards the IS-IS encoding, please look at the equivalent proposed OSPF 
encoding in the previous section and ask yourself why they are different. 😊

[WAJ] I think you can refer to 
https://datatracker.ietf.org/doc/html/draft-dunbar-lsr-5g-edge-compute-03#section-7.
  
In this section, we have illustrate that “It would be better if the aggregated 
cost could be advertised (in) the same way, regardless of OSPFv2, OSPFv3, or 
ISIS.“

 

   Les

 

 

From: Lsr mailto:lsr-boun...@ietf.org> > On Behalf Of 
Aijun Wang
Sent: Monday, January 10, 2022 9:05 AM
To: Les Ginsberg (ginsberg) mailto:ginsberg=40cisco@dmarc.ietf.org> >
Cc: lsr@ietf.org  ; Linda Dunbar 
mailto:linda.dun...@futurewei.com> >
Subject: Re: [Lsr] Seeking feedback to the revised 
draft-dunbar-lsr-5g-edge-compute

 

Hi, Les:

Aijun Wang

China Telecom

 

On Jan 10, 2022, at 23:48, Les Ginsberg (ginsberg) 
mailto:ginsberg=40cisco@dmarc.ietf.org> > wrote:

 

Linda –

 

I believe the most valuable feedback you received during your presentation at 
IETF 112 is that using IGPs likely will not meet the deployment requirements.

In particular, persistence of a given client session with a given application 
server is likely a requirement which will not be achieved using an IGP based 
solution.

[WAJ] The main aim of draft is to how assist the router to select the most 
appropriate application servers, with regards to the metrics that is not 
limited to the link cost.

Also, the modification of IGP metrics will likely introduce unwanted 
oscillation in traffic flows.


[WAJ] These metrics are associated with the links that doesn’t participate in 
the IGP, that is, they are the characteristics of the “Stub-Link”, then only 
the application that utilize such information will be influenced, or optimized.

 

 

I suggest you start with a clean slate – focus on defining what all the 
requirements are without regard to what mechanism/protocol might be used – and 
then think about defining a solution which meets these requirements.

I think you will end up NOT using routing protocols at all


[WAJ] Selecting the most appropriate/optimized application server should base 
on the topology information which is routing protocol related.

 

On a more mundane note, the section describing the new IS-IS advertisement 
(https://datatracker.ietf.org/doc/html/draft-dunbar-lsr-5g-edge-compute-03#section-6
 ) is – to put it bluntly – a mess! 😊

TLVs 128 and 130 are legacy TLVs which don’t support sub-TLVs – they should not 
be mentioned at all.

And the encoding diagram shows a “prefix” being advertised in the new sub-TLV 
when it should not. The prefix has already been advertised in the parent TLV.

 

[WAJ] Actually, the most appropriate place to convey such information is via 
the Stub-Link TLV/Sub-TLV that defined in 
https://datatracker.ietf.org/doc/html/draft-wang-lsr-stub-link-attributes-02

 

 

   Les

 

 

From: Lsr mailto:lsr-boun...@ietf.org> > On Behalf Of 
Linda Dunbar
Sent: Friday, January 7, 2022 11:29 AM
To: lsr@ietf.org  
Subject: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

 

LSR experts, 

 

We have revised the draft-dunbar-lsr-5g-edge-compute to address the comments 
and feedback from IETF 112. 

https://datatracker.ietf.org/doc/draft-dunb

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[Tony Li]

Hi Aijun,

> For the AS boundary use case, do you have other better solution? 


Is there some way that this could be modeled as a normal link instead of a stub 
link?  In any case, I am not responsible for coming up with a better solution. 
The onus is on you to convince us that this is a Good Thing to do.


> I have responded to Les for his mentioned/insisted unnumbered link scenario. 
> if it is acceptable, is it the general design then?


I don’t understand this comment. I agree with Les that unnumbered links are 
important.

Tony

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

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[Aijun Wang]

Hi, Tony:

For the AS boundary use case, do you have other better solution? 
I have responded to Les for his mentioned/insisted unnumbered link scenario. if 
it is acceptable, is it the general design then?

Best Regards

Aijun Wang
China Telecom

-Original Message-
From: lsr-boun...@ietf.org  On Behalf Of Tony Li
Sent: Tuesday, January 11, 2022 4:38 AM
To: Christian Hopps 
Cc: lsr ; lsr-...@ietf.org; 
draft-wang-lsr-stub-link-attribu...@ietf.org; lsr-cha...@ietf.org
Subject: Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02


I object to the adoption of this draft. 

I don’t think that it’s fundamentally a correct approach.

One of the important things that we’ve learned over the years is that we need 
to build general designs and not simply add new elements and mechanisms for 
each use case that we think of.

I understand the AS boundary use case. I agree that’s worthy of consideration. 
Not so much the others.

I would suggest that the authors spend a bit more time cogitating.

Regards,
Tony


> On Jan 3, 2022, at 10:58 PM, Christian Hopps  wrote:
> 
> Hi Folks,
> 
> This begins a 2 week WG Adoption Call for the following draft:
> 
> https://datatracker.ietf.org/doc/draft-wang-lsr-stub-link-attributes/
> 
> Please indicate your support or objections by January 18th, 2022.
> 
> Authors, please respond to the list indicating whether you are aware of any 
> IPR that applies to these drafts.
> 
> Thanks,
> Chris.
> 
> ___
> 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-wang-lsr-stub-link-attributes-02

[Aijun Wang]

Hi, Les:

There is the way to solve your concern.
1. 
https://datatracker.ietf.org/doc/html/draft-wang-lsr-stub-link-attributes-02#section-4.1
 and 
https://datatracker.ietf.org/doc/html/draft-wang-lsr-stub-link-attributes-02#section-4.2
 includes also the sub-TLVs field, which is pointed to the corresponding part 
for TE-Link TLV(for OSPF) and Inter-AS Reachability TLV (TLV 141).
  That is to say, the draft doesn't preclude the inclusion of Remote-AS, 
IPv4/IPv6 remote ASBR Identifier sub TLV.
  So, if you insist that the unnumbered link will be used between the ASes, 
then for such stub-link type(we can add one new stub link type), the operator 
should configure the remote information manually. And for such stub link type, 
the Remote-AS/IPv4/IPv6 Identifier sub TLV MUST be included(same as the rules 
defined in RFC5316).
  For other numbered interface, such information needn't be manually 
configured. This can certainly save the cost for management of the network, and 
also meet your mentioned scenario.
  Is it OK for you?

2. For the consideration of current extension violate the rules defined in 
RFC5316, I have proposed another solution at 
https://mailarchive.ietf.org/arch/msg/lsr/kTWLct7VgEfOxexdwzwcFS3Ctqc/ upon the 
comments from Peter. That is to say:
  "[WAJ] It seems to define one new TLV that at the same level of “Inter-AS 
reachability TLV”, for example “Stub-Link reachability TLV” is better. If 
acceptable, will update the draft."

For the above two proposals, do you have other comments? If not, will update 
the draft to reflect it.


Best Regards

Aijun Wang
China Telecom

-Original Message-
From: Les Ginsberg (ginsberg)  
Sent: Tuesday, January 11, 2022 3:50 AM
To: Aijun Wang 
Cc: Christian Hopps ; lsr@ietf.org; lsr-cha...@ietf.org; 
lsr-...@ietf.org; draft-wang-lsr-stub-link-attribu...@ietf.org
Subject: RE: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

Aijun -

Please see inline.

> -Original Message-
> From: Aijun Wang 
> Sent: Monday, January 10, 2022 8:34 AM
> To: Les Ginsberg (ginsberg) 
> Cc: Christian Hopps ; lsr@ietf.org; 
> lsr-cha...@ietf.org; lsr-...@ietf.org; 
> draft-wang-lsr-stub-link-attribu...@ietf.org
> Subject: Re: [Lsr] WG Adoption Call for 
> draft-wang-lsr-stub-link-attributes-02
> 
> Hi, Les:
> 
> Wish the below explanation can correct your understanding of this 
> draft, and also your conclusions.
> 
> Aijun Wang
> China Telecom
> 
> > On Jan 10, 2022, at 23:13, Les Ginsberg (ginsberg)
>  wrote:
> >
> > I oppose WG adoption of this draft.
> >
> > In addition to my comments below, I am in agreement with the points
> made by Peter and Shraddha previously in this thread.
> >
> > My comments below are in the context of IS-IS/RFC5316, but I believe 
> > are
> equally valid in the context of OSPF/RFC5392.
> >
> > There are two types of new information the draft proposes to 
> > advertise
> under TLV 141:
> >
> > 1)Identifying a link by the prefix locally configured on the link 
> > rather than by
> the local/remote addresses.
> >
> > The motivation for this addition seems to be to avoid the need for 
> > the
> operator to locally configure the remote address.
> [WAJ] For inter-AS stub link type, it is. For other stub link type, it isn’t.
> 
> > But I think this is not a desirable change.
> >
> > As pointed out by Peter, this does not work for unnumbered links. 
> > (It also
> would not work for Pt-2-MP links). The authors assert that it is 
> unlikely that unnumbered links would be used in the expected use cases 
> - but I do not find this argument convincing.
> [WAJ] Is there any operator adopt unnumbered link at its boundary 
> network? There is even very rare case for the unnumbered interface be 
> used within the operator network. And, with the IPv6 deployment, what 
> is the usages of unnumbered interface? Won’t it be depreciated in future?
> Very curious you and Peter stick to this point, but not considering 
> its wider use scenarios.
> 
[LES:] Aijun - Unnumbered links are in common usage today. We should not define 
extensions which do not allow support for this.

> > Even if unnumbered links are not currently being used, the 
> > restriction that
> they could not be used in the future seems highly undesirable.
> 
> [WAJ] Would like to hear the reason and scenarios that the unnumbered 
> interface will be used in future. I think it should be deprecated instead.

[LES:] Deprecating the use of unnumbered is outside the scope of this 
specification - and I would argue is not something we (the WG) should be 
advocating in any case.

> 
> > It would put us in the position of having to revise this 
> > functionality in the
> future in an incompatible way in order to add such support. This is a 
> bad design choice.
> 
> [WAJ] We should keep the trend, not stick to the obsolete obstacles.

[LES:] Unnumbered is not obsolete - it is only you who have arbitrarily decided 
that it is no longer needed.

> 
> >
> > Aside: The assertion tha

Re: [Lsr] BGP vs PUA/PULSE

[Les Ginsberg (ginsberg)]

Tony –

Probably too many emails in one day on this – but did want to respond to a few 
points.
Inline.

From: Tony Li  On Behalf Of Tony Li
Sent: Monday, January 10, 2022 5:35 PM
To: Les Ginsberg (ginsberg) 
Cc: Christian Hopps ; Peter Psenak (ppsenak) 
; Robert Raszuk ; Shraddha Hegde 
; Aijun Wang ; Hannes Gredler 
; lsr 
Subject: Re: [Lsr] BGP vs PUA/PULSE


Les,

I could be more specific regarding my opinion about various alternatives that 
have been mentioned (BFD, OAM, BGP, pub-sub) – but it doesn’t make sense to me 
to comment on proposals which have not actually been defined.


The proposals have been put forth in adequate detail for a preliminary 
discussion. They appear to be tractable and implementable and thus seem like 
feasible alternatives.

[LES:] I believe some of the alternate proposals are tractable – which is not 
to say that I prefer them.
But I don’t want to ask questions like “How do you do this…?” in the absence of 
a writeup.  I am assuming that if we had a writeup the authors would have done 
their best to define a complete solution and then we could meaningfully review 
and comment. But without a writeup it is hard for me to say – “Oh yes – this is 
much better. Let’s abandon the IGP approach and go this way.”




In the meantime, we started with the IGPs because:

a)IGPs have the raw reachability info – they don’t have to get it from some 
other entity
b)IGPs have the reliable flooding mechanism

Given that we want to address a real deployment issue in a timely manner, we 
want to move forward.


You want to move forward.  Not the rest of us.



 We – meaning the WG/IETF – are tasked with defining practical solutions to 
real problems.


No. Our job is standardizing solutions. We are not tasked with defining them. 
Proof: you can unilaterally go off and define, implement, and deploy whatever 
solution you like today. We cannot stop you.  In fact, it’s none of our 
business.

However, when it comes to standardizing it, that’s when we (the IETF WG) get 
involved. At that point, the bar is somewhat raised. That’s when you have to 
convince the rest of us that you have a good solution to the problem.

[LES:] Agreed – and that is what we are trying to do.

We are in no rush to move forward with a bad solution. Especially at scale. :-)



It’s fine to object to a proposal – but that doesn’t get us to a solution.
I am not saying that you specifically are responsible for defining an alternate 
solution – but if “we” are to progress then we either need to accept an IGP 
solution or define an alternative.

Now, if you are saying the problem doesn’t need to be solved – then we just 
disagree.


The problem needs to be solved.  No question. It doesn’t need to be solved with 
a rush to a bad solution. Architecturally, putting liveness reporting into the 
IGP is just a bad idea, for all of the reasons that we’ve already articulated, 
repeatedly. Our arguments have met with stubborn and somewhat disrespectful 
rejection without clear rationale about why our arguments are incorrect. This 
does not build consensus.

[LES:] We have responded positively to comments about our solution – 
particularly in the area of scale. (Next version of pulse draft will be out 
soon – we preferred to enjoy the holidays. 😊)
And I apologize if anything I said was seen as disrespectful. I have tried very 
hard to confine my responses to technical issues.  We do disagree on some 
things – but I don’t see that as disrespect.

   Les

Tony


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

Re: [Lsr] BGP vs PUA/PULSE

[Gyan Mishra]

Hi Greg

Thanks for the reference.

Agreed on the different UDP port 3784 and 4784 to differentiate the single
hop and multi hop sessions respectively.

In the multi hop BFD scenario to monitor the egress PE loopbacks in the
case where an RR exists and all PEs are Route-Reflector Clients, the BFD
multi hop BFD session would monitor PE to RR iBGP peering underlay path,
however how would an ingress PE monitor the liveliness of egress PE.

Also as best practice is to keep the RR out of the forwarding plane not
in-line - off to the side a as the RR is meant to handle control plane only
and not data plane traffic as it maybe on a different lower end  platform
type then the P and PE nodes such as  a NFV VNF VM virtualized box.  So it
would be difficult for the multi hop BFD PE to RR to be able to monitor the
PE to PE LSP forwarding plane failure path.

Kind Regards

Gyan

On Mon, Jan 10, 2022 at 8:50 PM Greg Mirsky  wrote:

> Hi Gyan,
> thank you for sharing the operator's perspective and experience on using
> the multi-hop BFD. Thinking of additional challenges, I may add the
> authentication of BFD Control packets. But the extra-processing can be
> significantly reduced by draft-ietf-bfd-optimizing-authentication-13 -
> Optimizing BFD Authentication
> .
> As for using single- and multi-hop BFD sessions simultaneously, that should
> not present any problem as each type uses a different assigned destination
> UDP port number.
>
> Regards,
> Greg
>
> On Mon, Jan 10, 2022 at 5:36 PM Gyan Mishra  wrote:
>
>>
>> Greg
>>
>> I believe the scalability context for multi hop BFD is the operational
>> complexity introduced with the number of sessions especially  within very
>> large domains with inordinate number of routers. Single hop BFD is more
>> manageable and is predominately user by operators for underlay failure
>> detection.  Also in a case where single hop BFD by an operators for failure
>> detection does that preclude the use of multi hop BFD as well and any
>> caveats with using both simultaneously.
>>
>> Kind Regards
>>
>> Gyan
>>
>> On Mon, Jan 10, 2022 at 8:28 PM Greg Mirsky 
>> wrote:
>>
>>> Hi Les,
>>> do you see anything that requires further specification in addition to
>>> RFC 5883?
>>>
>>> Regards
>>> Greg
>>>
>>> On Mon, Jan 10, 2022, 17:14 Les Ginsberg (ginsberg) >> 40cisco@dmarc.ietf.org> wrote:
>>>
 Tony –



 I could be more specific regarding my opinion about various
 alternatives that have been mentioned (BFD, OAM, BGP, pub-sub) – but it
 doesn’t make sense to me to comment on proposals which have not actually
 been defined.

 If someone (not necessarily you) wants to write up any of these
 proposals then we (the WG/Routing Area) could have a meaningful discussion
 about such alternatives.



 In the meantime, we started with the IGPs because:



 a)IGPs have the raw reachability info – they don’t have to get it from
 some other entity

 b)IGPs have the reliable flooding mechanism



 Given that we want to address a real deployment issue in a timely
 manner, we want to move forward.



 We – meaning the WG/IETF – are tasked with defining practical solutions
 to real problems. It’s fine to object to a proposal – but that doesn’t get
 us to a solution.

 I am not saying that you specifically are responsible for defining an
 alternate solution – but if “we” are to progress then we either need to
 accept an IGP solution or define an alternative.



 Now, if you are saying the problem doesn’t need to be solved – then we
 just disagree.



Les





 *From:* Tony Li  *On Behalf Of *Tony Li
 *Sent:* Monday, January 10, 2022 4:43 PM
 *To:* Les Ginsberg (ginsberg) 
 *Cc:* Christian Hopps ; Peter Psenak (ppsenak) <
 ppse...@cisco.com>; Robert Raszuk ; Shraddha Hegde <
 shrad...@juniper.net>; Aijun Wang ; Hannes
 Gredler ; lsr 
 *Subject:* Re: [Lsr] BGP vs PUA/PULSE





 Les,





 And if customers could do what he suggested then they would not have an
 issue.



 But there are deployments where what he suggested is not possible –
 largely I think because the set of “prefixes of interest” is in itself
 large.





 Well, the alleged customers have not come forward to explain the
 situation. I would welcome more specifics, even under NDA. It’s hard to
 relate to allegations of scale without specifics. If the area has that many
 PEs in it, then is really too large to be a single area in the first place?





  So while not all customers have an issue, some customers do and we are
 trying to find a way to address those deployments.



 A

Re: [Lsr] BGP vs PUA/PULSE

[Greg Mirsky]

Hi Gyan,
thank you for sharing the operator's perspective and experience on using
the multi-hop BFD. Thinking of additional challenges, I may add the
authentication of BFD Control packets. But the extra-processing can be
significantly reduced by draft-ietf-bfd-optimizing-authentication-13 -
Optimizing BFD Authentication
.
As for using single- and multi-hop BFD sessions simultaneously, that should
not present any problem as each type uses a different assigned destination
UDP port number.

Regards,
Greg

On Mon, Jan 10, 2022 at 5:36 PM Gyan Mishra  wrote:

>
> Greg
>
> I believe the scalability context for multi hop BFD is the operational
> complexity introduced with the number of sessions especially  within very
> large domains with inordinate number of routers. Single hop BFD is more
> manageable and is predominately user by operators for underlay failure
> detection.  Also in a case where single hop BFD by an operators for failure
> detection does that preclude the use of multi hop BFD as well and any
> caveats with using both simultaneously.
>
> Kind Regards
>
> Gyan
>
> On Mon, Jan 10, 2022 at 8:28 PM Greg Mirsky  wrote:
>
>> Hi Les,
>> do you see anything that requires further specification in addition to
>> RFC 5883?
>>
>> Regards
>> Greg
>>
>> On Mon, Jan 10, 2022, 17:14 Les Ginsberg (ginsberg) > 40cisco@dmarc.ietf.org> wrote:
>>
>>> Tony –
>>>
>>>
>>>
>>> I could be more specific regarding my opinion about various alternatives
>>> that have been mentioned (BFD, OAM, BGP, pub-sub) – but it doesn’t make
>>> sense to me to comment on proposals which have not actually been defined.
>>>
>>> If someone (not necessarily you) wants to write up any of these
>>> proposals then we (the WG/Routing Area) could have a meaningful discussion
>>> about such alternatives.
>>>
>>>
>>>
>>> In the meantime, we started with the IGPs because:
>>>
>>>
>>>
>>> a)IGPs have the raw reachability info – they don’t have to get it from
>>> some other entity
>>>
>>> b)IGPs have the reliable flooding mechanism
>>>
>>>
>>>
>>> Given that we want to address a real deployment issue in a timely
>>> manner, we want to move forward.
>>>
>>>
>>>
>>> We – meaning the WG/IETF – are tasked with defining practical solutions
>>> to real problems. It’s fine to object to a proposal – but that doesn’t get
>>> us to a solution.
>>>
>>> I am not saying that you specifically are responsible for defining an
>>> alternate solution – but if “we” are to progress then we either need to
>>> accept an IGP solution or define an alternative.
>>>
>>>
>>>
>>> Now, if you are saying the problem doesn’t need to be solved – then we
>>> just disagree.
>>>
>>>
>>>
>>>Les
>>>
>>>
>>>
>>>
>>>
>>> *From:* Tony Li  *On Behalf Of *Tony Li
>>> *Sent:* Monday, January 10, 2022 4:43 PM
>>> *To:* Les Ginsberg (ginsberg) 
>>> *Cc:* Christian Hopps ; Peter Psenak (ppsenak) <
>>> ppse...@cisco.com>; Robert Raszuk ; Shraddha Hegde <
>>> shrad...@juniper.net>; Aijun Wang ; Hannes
>>> Gredler ; lsr 
>>> *Subject:* Re: [Lsr] BGP vs PUA/PULSE
>>>
>>>
>>>
>>>
>>>
>>> Les,
>>>
>>>
>>>
>>>
>>>
>>> And if customers could do what he suggested then they would not have an
>>> issue.
>>>
>>>
>>>
>>> But there are deployments where what he suggested is not possible –
>>> largely I think because the set of “prefixes of interest” is in itself
>>> large.
>>>
>>>
>>>
>>>
>>>
>>> Well, the alleged customers have not come forward to explain the
>>> situation. I would welcome more specifics, even under NDA. It’s hard to
>>> relate to allegations of scale without specifics. If the area has that many
>>> PEs in it, then is really too large to be a single area in the first place?
>>>
>>>
>>>
>>>
>>>
>>>  So while not all customers have an issue, some customers do and we are
>>> trying to find a way to address those deployments.
>>>
>>>
>>>
>>> As far as the alternative proposals, I will comment on them if/when
>>> there is something visible – but I think they will all suffer from scale
>>> issues.
>>>
>>>
>>>
>>>
>>>
>>> They have been proposed here and have not been refuted.
>>>
>>>
>>>
>>> Everything always suffers from scale issues, so that’s not exactly
>>> constructive.
>>>
>>>
>>>
>>> I would be more than happy to write up the pub-sub proposal, but … it’s
>>> not my customer and it’s not in my charter to contribute to your revenue. :)
>>>
>>>
>>>
>>> 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
>>
> --
>
> 
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
> *Email gyan.s.mis...@verizon.com *
>
>
>
> *M 301 502-1347*
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] BGP vs PUA/PULSE

[Christian Hopps]

I think the point is that just saying:
 
>> And if customers could do what he suggested then they would not have an 
>> issue.
>>  
>> But there are deployments where what he suggested is not possible – largely 
>> I think because the set of “prefixes of interest” is in itself large.

maybe isn't saying nearly enough.

"Large" of course is too imprecise. But, more importantly, how do we know that 
this "large" amount hasn't arisen from bad network design choices.

Thanks,
Chris.
[as wg member]


> Well, the alleged customers have not come forward to explain the situation. I 
> would welcome more specifics, even under NDA. It’s hard to relate to 
> allegations of scale without specifics. If the area has that many PEs in it, 
> then is really too large to be a single area in the first place?

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

Re: [Lsr] BGP vs PUA/PULSE

[Gyan Mishra]

Greg

I believe the scalability context for multi hop BFD is the operational
complexity introduced with the number of sessions especially  within very
large domains with inordinate number of routers. Single hop BFD is more
manageable and is predominately user by operators for underlay failure
detection.  Also in a case where single hop BFD by an operators for failure
detection does that preclude the use of multi hop BFD as well and any
caveats with using both simultaneously.

Kind Regards

Gyan

On Mon, Jan 10, 2022 at 8:28 PM Greg Mirsky  wrote:

> Hi Les,
> do you see anything that requires further specification in addition to RFC
> 5883?
>
> Regards
> Greg
>
> On Mon, Jan 10, 2022, 17:14 Les Ginsberg (ginsberg)  40cisco@dmarc.ietf.org> wrote:
>
>> Tony –
>>
>>
>>
>> I could be more specific regarding my opinion about various alternatives
>> that have been mentioned (BFD, OAM, BGP, pub-sub) – but it doesn’t make
>> sense to me to comment on proposals which have not actually been defined.
>>
>> If someone (not necessarily you) wants to write up any of these proposals
>> then we (the WG/Routing Area) could have a meaningful discussion about such
>> alternatives.
>>
>>
>>
>> In the meantime, we started with the IGPs because:
>>
>>
>>
>> a)IGPs have the raw reachability info – they don’t have to get it from
>> some other entity
>>
>> b)IGPs have the reliable flooding mechanism
>>
>>
>>
>> Given that we want to address a real deployment issue in a timely manner,
>> we want to move forward.
>>
>>
>>
>> We – meaning the WG/IETF – are tasked with defining practical solutions
>> to real problems. It’s fine to object to a proposal – but that doesn’t get
>> us to a solution.
>>
>> I am not saying that you specifically are responsible for defining an
>> alternate solution – but if “we” are to progress then we either need to
>> accept an IGP solution or define an alternative.
>>
>>
>>
>> Now, if you are saying the problem doesn’t need to be solved – then we
>> just disagree.
>>
>>
>>
>>Les
>>
>>
>>
>>
>>
>> *From:* Tony Li  *On Behalf Of *Tony Li
>> *Sent:* Monday, January 10, 2022 4:43 PM
>> *To:* Les Ginsberg (ginsberg) 
>> *Cc:* Christian Hopps ; Peter Psenak (ppsenak) <
>> ppse...@cisco.com>; Robert Raszuk ; Shraddha Hegde <
>> shrad...@juniper.net>; Aijun Wang ; Hannes
>> Gredler ; lsr 
>> *Subject:* Re: [Lsr] BGP vs PUA/PULSE
>>
>>
>>
>>
>>
>> Les,
>>
>>
>>
>>
>>
>> And if customers could do what he suggested then they would not have an
>> issue.
>>
>>
>>
>> But there are deployments where what he suggested is not possible –
>> largely I think because the set of “prefixes of interest” is in itself
>> large.
>>
>>
>>
>>
>>
>> Well, the alleged customers have not come forward to explain the
>> situation. I would welcome more specifics, even under NDA. It’s hard to
>> relate to allegations of scale without specifics. If the area has that many
>> PEs in it, then is really too large to be a single area in the first place?
>>
>>
>>
>>
>>
>>  So while not all customers have an issue, some customers do and we are
>> trying to find a way to address those deployments.
>>
>>
>>
>> As far as the alternative proposals, I will comment on them if/when there
>> is something visible – but I think they will all suffer from scale issues.
>>
>>
>>
>>
>>
>> They have been proposed here and have not been refuted.
>>
>>
>>
>> Everything always suffers from scale issues, so that’s not exactly
>> constructive.
>>
>>
>>
>> I would be more than happy to write up the pub-sub proposal, but … it’s
>> not my customer and it’s not in my charter to contribute to your revenue. :)
>>
>>
>>
>> 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
>
-- 



*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mis...@verizon.com *



*M 301 502-1347*
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] BGP vs PUA/PULSE

[Tony Li]

Les,

> I could be more specific regarding my opinion about various alternatives that 
> have been mentioned (BFD, OAM, BGP, pub-sub) – but it doesn’t make sense to 
> me to comment on proposals which have not actually been defined.


The proposals have been put forth in adequate detail for a preliminary 
discussion. They appear to be tractable and implementable and thus seem like 
feasible alternatives.


> In the meantime, we started with the IGPs because:
>  
> a)IGPs have the raw reachability info – they don’t have to get it from some 
> other entity
> b)IGPs have the reliable flooding mechanism
>  
> Given that we want to address a real deployment issue in a timely manner, we 
> want to move forward.


You want to move forward.  Not the rest of us.


>  We – meaning the WG/IETF – are tasked with defining practical solutions to 
> real problems.


No. Our job is standardizing solutions. We are not tasked with defining them. 
Proof: you can unilaterally go off and define, implement, and deploy whatever 
solution you like today. We cannot stop you.  In fact, it’s none of our 
business.

However, when it comes to standardizing it, that’s when we (the IETF WG) get 
involved. At that point, the bar is somewhat raised. That’s when you have to 
convince the rest of us that you have a good solution to the problem.

We are in no rush to move forward with a bad solution. Especially at scale. :-)


> It’s fine to object to a proposal – but that doesn’t get us to a solution.
> I am not saying that you specifically are responsible for defining an 
> alternate solution – but if “we” are to progress then we either need to 
> accept an IGP solution or define an alternative.
>  
> Now, if you are saying the problem doesn’t need to be solved – then we just 
> disagree.


The problem needs to be solved.  No question. It doesn’t need to be solved with 
a rush to a bad solution. Architecturally, putting liveness reporting into the 
IGP is just a bad idea, for all of the reasons that we’ve already articulated, 
repeatedly. Our arguments have met with stubborn and somewhat disrespectful 
rejection without clear rationale about why our arguments are incorrect. This 
does not build consensus.

Tony


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

Re: [Lsr] BGP vs PUA/PULSE

[Greg Mirsky]

Hi Les,
do you see anything that requires further specification in addition to RFC
5883?

Regards
Greg

On Mon, Jan 10, 2022, 17:14 Les Ginsberg (ginsberg)  wrote:

> Tony –
>
>
>
> I could be more specific regarding my opinion about various alternatives
> that have been mentioned (BFD, OAM, BGP, pub-sub) – but it doesn’t make
> sense to me to comment on proposals which have not actually been defined.
>
> If someone (not necessarily you) wants to write up any of these proposals
> then we (the WG/Routing Area) could have a meaningful discussion about such
> alternatives.
>
>
>
> In the meantime, we started with the IGPs because:
>
>
>
> a)IGPs have the raw reachability info – they don’t have to get it from
> some other entity
>
> b)IGPs have the reliable flooding mechanism
>
>
>
> Given that we want to address a real deployment issue in a timely manner,
> we want to move forward.
>
>
>
> We – meaning the WG/IETF – are tasked with defining practical solutions to
> real problems. It’s fine to object to a proposal – but that doesn’t get us
> to a solution.
>
> I am not saying that you specifically are responsible for defining an
> alternate solution – but if “we” are to progress then we either need to
> accept an IGP solution or define an alternative.
>
>
>
> Now, if you are saying the problem doesn’t need to be solved – then we
> just disagree.
>
>
>
>Les
>
>
>
>
>
> *From:* Tony Li  *On Behalf Of *Tony Li
> *Sent:* Monday, January 10, 2022 4:43 PM
> *To:* Les Ginsberg (ginsberg) 
> *Cc:* Christian Hopps ; Peter Psenak (ppsenak) <
> ppse...@cisco.com>; Robert Raszuk ; Shraddha Hegde <
> shrad...@juniper.net>; Aijun Wang ; Hannes
> Gredler ; lsr 
> *Subject:* Re: [Lsr] BGP vs PUA/PULSE
>
>
>
>
>
> Les,
>
>
>
>
>
> And if customers could do what he suggested then they would not have an
> issue.
>
>
>
> But there are deployments where what he suggested is not possible –
> largely I think because the set of “prefixes of interest” is in itself
> large.
>
>
>
>
>
> Well, the alleged customers have not come forward to explain the
> situation. I would welcome more specifics, even under NDA. It’s hard to
> relate to allegations of scale without specifics. If the area has that many
> PEs in it, then is really too large to be a single area in the first place?
>
>
>
>
>
>  So while not all customers have an issue, some customers do and we are
> trying to find a way to address those deployments.
>
>
>
> As far as the alternative proposals, I will comment on them if/when there
> is something visible – but I think they will all suffer from scale issues.
>
>
>
>
>
> They have been proposed here and have not been refuted.
>
>
>
> Everything always suffers from scale issues, so that’s not exactly
> constructive.
>
>
>
> I would be more than happy to write up the pub-sub proposal, but … it’s
> not my customer and it’s not in my charter to contribute to your revenue. :)
>
>
>
> 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] BGP vs PUA/PULSE

[Les Ginsberg (ginsberg)]

Tony –

I could be more specific regarding my opinion about various alternatives that 
have been mentioned (BFD, OAM, BGP, pub-sub) – but it doesn’t make sense to me 
to comment on proposals which have not actually been defined.
If someone (not necessarily you) wants to write up any of these proposals then 
we (the WG/Routing Area) could have a meaningful discussion about such 
alternatives.

In the meantime, we started with the IGPs because:

a)IGPs have the raw reachability info – they don’t have to get it from some 
other entity
b)IGPs have the reliable flooding mechanism

Given that we want to address a real deployment issue in a timely manner, we 
want to move forward.

We – meaning the WG/IETF – are tasked with defining practical solutions to real 
problems. It’s fine to object to a proposal – but that doesn’t get us to a 
solution.
I am not saying that you specifically are responsible for defining an alternate 
solution – but if “we” are to progress then we either need to accept an IGP 
solution or define an alternative.

Now, if you are saying the problem doesn’t need to be solved – then we just 
disagree.

   Les


From: Tony Li  On Behalf Of Tony Li
Sent: Monday, January 10, 2022 4:43 PM
To: Les Ginsberg (ginsberg) 
Cc: Christian Hopps ; Peter Psenak (ppsenak) 
; Robert Raszuk ; Shraddha Hegde 
; Aijun Wang ; Hannes Gredler 
; lsr 
Subject: Re: [Lsr] BGP vs PUA/PULSE


Les,


And if customers could do what he suggested then they would not have an issue.

But there are deployments where what he suggested is not possible – largely I 
think because the set of “prefixes of interest” is in itself large.


Well, the alleged customers have not come forward to explain the situation. I 
would welcome more specifics, even under NDA. It’s hard to relate to 
allegations of scale without specifics. If the area has that many PEs in it, 
then is really too large to be a single area in the first place?


 So while not all customers have an issue, some customers do and we are trying 
to find a way to address those deployments.

As far as the alternative proposals, I will comment on them if/when there is 
something visible – but I think they will all suffer from scale issues.


They have been proposed here and have not been refuted.

Everything always suffers from scale issues, so that’s not exactly constructive.

I would be more than happy to write up the pub-sub proposal, but … it’s not my 
customer and it’s not in my charter to contribute to your revenue. :)

Tony

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

Re: [Lsr] BGP vs PUA/PULSE

[Greg Mirsky]

Hi Les,
in this case, using multi-hop BFD will add, in my estimation, 10 Mbyte/sec
of extra traffic if the network is IPv4. Is it a real scaling concern these
days?

Regards,
Greg

On Mon, Jan 10, 2022 at 4:44 PM Les Ginsberg (ginsberg) 
wrote:

> Some comments from Robert offline cause me to issue a correction.
>
> As BFD sessions are bidirectional we are talking about a Combination of
> (n,2) – so in the case of 500 nodes the actual number of BFD sessions
> network-wide is 124750.
>
>
>
>Les
>
>
>
>
>
> *From:* Lsr  *On Behalf Of * Les Ginsberg (ginsberg)
> *Sent:* Monday, January 10, 2022 4:34 PM
> *To:* Robert Raszuk 
> *Cc:* Greg Mirsky ; Christian Hopps <
> cho...@chopps.org>; Aijun Wang ; Shraddha
> Hegde ; Tony Li ; Hannes Gredler <
> han...@gredler.at>; lsr ; Peter Psenak (ppsenak) <
> ppse...@cisco.com>
> *Subject:* Re: [Lsr] BGP vs PUA/PULSE
>
>
>
> Robert –
>
>
>
> The numbers are network-wide – not per node.
>
> And no one has mentioned config as an issue in this thread – though no
> doubt some operators might have concerns in that area.
>
>
>
>   Les
>
>
>
>
>
> *From:* Robert Raszuk 
> *Sent:* Monday, January 10, 2022 4:30 PM
> *To:* Les Ginsberg (ginsberg) 
> *Cc:* Greg Mirsky ; Tony Li ;
> Christian Hopps ; Aijun Wang ;
> Shraddha Hegde ; Hannes Gredler ;
> lsr ; Peter Psenak (ppsenak) 
> *Subject:* Re: [Lsr] BGP vs PUA/PULSE
>
>
>
> Hi Les,
>
>
>
> *[LES:] Even a modest sized N = 100 (which is certainly not a high number)
> leads to 1 BFD sessions. N= 500 => 250,000 sessions. Etc.*
>
>
>
> Are you doing N^2 ? Why ? All you need to keep in mind is number of those
> sessions per PE so in worst case (N-1) - here 99 and 499.
>
>
>
> And as we already established, configuration is optional as you can use
> auto config.
>
>
>
> Thx,
>
> R.
>
>
>
> *[LES:] Nodes which can support thousands of BFD sessions are likely
> already using many BFD sessions for other purposes. In particular, fast
> detection of local failures is always going to be a priority – so if a node
> has thousands of neighbors – it will likely have thousands of single hop
> BFD sessions. Not to mention the plethora of other OAM uses cases being
> defined. And the network-wide traffic impact as these new BFD sessions are
> largely multi-hop. Are you really arguing that the introduction of many
> thousands of BFD sessions is something we should not be concerned about? *
>
> *   Les*
>
>
>
>Les
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] BGP vs PUA/PULSE

[Tony Li]

> On Jan 10, 2022, at 4:44 PM, Les Ginsberg (ginsberg)  
> wrote:
> 
> As BFD sessions are bidirectional we are talking about a Combination of (n,2) 
> – so in the case of 500 nodes the actual number of BFD sessions network-wide 
> is 124750.


Which sounds terrifying until you realize that it’s 499 per node.

Tony


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

Re: [Lsr] BGP vs PUA/PULSE

[Les Ginsberg (ginsberg)]

Some comments from Robert offline cause me to issue a correction.
As BFD sessions are bidirectional we are talking about a Combination of (n,2) – 
so in the case of 500 nodes the actual number of BFD sessions network-wide is 
124750.

   Les


From: Lsr  On Behalf Of Les Ginsberg (ginsberg)
Sent: Monday, January 10, 2022 4:34 PM
To: Robert Raszuk 
Cc: Greg Mirsky ; Christian Hopps ; 
Aijun Wang ; Shraddha Hegde ; 
Tony Li ; Hannes Gredler ; lsr 
; Peter Psenak (ppsenak) 
Subject: Re: [Lsr] BGP vs PUA/PULSE

Robert –

The numbers are network-wide – not per node.
And no one has mentioned config as an issue in this thread – though no doubt 
some operators might have concerns in that area.

  Les


From: Robert Raszuk mailto:rob...@raszuk.net>>
Sent: Monday, January 10, 2022 4:30 PM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Cc: Greg Mirsky mailto:gregimir...@gmail.com>>; Tony Li 
mailto:tony...@tony.li>>; Christian Hopps 
mailto:cho...@chopps.org>>; Aijun Wang 
mailto:wangai...@tsinghua.org.cn>>; Shraddha Hegde 
mailto:shrad...@juniper.net>>; Hannes Gredler 
mailto:han...@gredler.at>>; lsr 
mailto:lsr@ietf.org>>; Peter Psenak (ppsenak) 
mailto:ppse...@cisco.com>>
Subject: Re: [Lsr] BGP vs PUA/PULSE

Hi Les,

[LES:] Even a modest sized N = 100 (which is certainly not a high number) leads 
to 1 BFD sessions. N= 500 => 250,000 sessions. Etc.

Are you doing N^2 ? Why ? All you need to keep in mind is number of those 
sessions per PE so in worst case (N-1) - here 99 and 499.

And as we already established, configuration is optional as you can use auto 
config.

Thx,
R.

[LES:] Nodes which can support thousands of BFD sessions are likely already 
using many BFD sessions for other purposes. In particular, fast detection of 
local failures is always going to be a priority – so if a node has thousands of 
neighbors – it will likely have thousands of single hop BFD sessions. Not to 
mention the plethora of other OAM uses cases being defined. And the 
network-wide traffic impact as these new BFD sessions are largely multi-hop. 
Are you really arguing that the introduction of many thousands of BFD sessions 
is something we should not be concerned about?
   Les

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

Re: [Lsr] BGP vs PUA/PULSE

[Robert Raszuk]

The point I am making is that the total number of BFD sessions in the
entire network is irrelevant.

While looking scary (even if divided by 2) those numbers should not be
even exposed to operators or used as counterargument. What may matter is a
hypothetical scale on a per smallest PE * number of bytes each session
consumes in the control plane. Rest is offloaded to the data plane.

Bottom line is that I prefer to see this problem be addressed in the
service layer - but will defend BFD alternative based on practical view and
facts.

Cheers,
Robert


On Tue, Jan 11, 2022 at 1:34 AM Les Ginsberg (ginsberg) 
wrote:

> Robert –
>
>
>
> The numbers are network-wide – not per node.
>
> And no one has mentioned config as an issue in this thread – though no
> doubt some operators might have concerns in that area.
>
>
>
>   Les
>
>
>
>
>
> *From:* Robert Raszuk 
> *Sent:* Monday, January 10, 2022 4:30 PM
> *To:* Les Ginsberg (ginsberg) 
> *Cc:* Greg Mirsky ; Tony Li ;
> Christian Hopps ; Aijun Wang ;
> Shraddha Hegde ; Hannes Gredler ;
> lsr ; Peter Psenak (ppsenak) 
> *Subject:* Re: [Lsr] BGP vs PUA/PULSE
>
>
>
> Hi Les,
>
>
>
> *[LES:] Even a modest sized N = 100 (which is certainly not a high number)
> leads to 1 BFD sessions. N= 500 => 250,000 sessions. Etc.*
>
>
>
> Are you doing N^2 ? Why ? All you need to keep in mind is number of those
> sessions per PE so in worst case (N-1) - here 99 and 499.
>
>
>
> And as we already established, configuration is optional as you can use
> auto config.
>
>
>
> Thx,
>
> R.
>
>
>
> *[LES:] Nodes which can support thousands of BFD sessions are likely
> already using many BFD sessions for other purposes. In particular, fast
> detection of local failures is always going to be a priority – so if a node
> has thousands of neighbors – it will likely have thousands of single hop
> BFD sessions. Not to mention the plethora of other OAM uses cases being
> defined. And the network-wide traffic impact as these new BFD sessions are
> largely multi-hop. Are you really arguing that the introduction of many
> thousands of BFD sessions is something we should not be concerned about? *
>
> *   Les*
>
>
>
>Les
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] BGP vs PUA/PULSE

[Tony Li]

Les,


> And if customers could do what he suggested then they would not have an issue.
>  
> But there are deployments where what he suggested is not possible – largely I 
> think because the set of “prefixes of interest” is in itself large.


Well, the alleged customers have not come forward to explain the situation. I 
would welcome more specifics, even under NDA. It’s hard to relate to 
allegations of scale without specifics. If the area has that many PEs in it, 
then is really too large to be a single area in the first place?


>  So while not all customers have an issue, some customers do and we are 
> trying to find a way to address those deployments.
>  
> As far as the alternative proposals, I will comment on them if/when there is 
> something visible – but I think they will all suffer from scale issues.


They have been proposed here and have not been refuted.

Everything always suffers from scale issues, so that’s not exactly constructive.

I would be more than happy to write up the pub-sub proposal, but … it’s not my 
customer and it’s not in my charter to contribute to your revenue. :)

Tony

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

Re: [Lsr] BGP vs PUA/PULSE

[Les Ginsberg (ginsberg)]

Robert –

The numbers are network-wide – not per node.
And no one has mentioned config as an issue in this thread – though no doubt 
some operators might have concerns in that area.

  Les


From: Robert Raszuk 
Sent: Monday, January 10, 2022 4:30 PM
To: Les Ginsberg (ginsberg) 
Cc: Greg Mirsky ; Tony Li ; Christian 
Hopps ; Aijun Wang ; Shraddha 
Hegde ; Hannes Gredler ; lsr 
; Peter Psenak (ppsenak) 
Subject: Re: [Lsr] BGP vs PUA/PULSE

Hi Les,

[LES:] Even a modest sized N = 100 (which is certainly not a high number) leads 
to 1 BFD sessions. N= 500 => 250,000 sessions. Etc.

Are you doing N^2 ? Why ? All you need to keep in mind is number of those 
sessions per PE so in worst case (N-1) - here 99 and 499.

And as we already established, configuration is optional as you can use auto 
config.

Thx,
R.

[LES:] Nodes which can support thousands of BFD sessions are likely already 
using many BFD sessions for other purposes. In particular, fast detection of 
local failures is always going to be a priority – so if a node has thousands of 
neighbors – it will likely have thousands of single hop BFD sessions. Not to 
mention the plethora of other OAM uses cases being defined. And the 
network-wide traffic impact as these new BFD sessions are largely multi-hop. 
Are you really arguing that the introduction of many thousands of BFD sessions 
is something we should not be concerned about?
   Les

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

Re: [Lsr] BGP vs PUA/PULSE

[Robert Raszuk]

Hi Les,

*[LES:] Even a modest sized N = 100 (which is certainly not a high number)
> leads to 1 BFD sessions. N= 500 => 250,000 sessions. Etc.*
>
>
Are you doing N^2 ? Why ? All you need to keep in mind is number of those
sessions per PE so in worst case (N-1) - here 99 and 499.

And as we already established, configuration is optional as you can use
auto config.

Thx,
R.

*[LES:] Nodes which can support thousands of BFD sessions are likely
> already using many BFD sessions for other purposes. In particular, fast
> detection of local failures is always going to be a priority – so if a node
> has thousands of neighbors – it will likely have thousands of single hop
> BFD sessions. Not to mention the plethora of other OAM uses cases being
> defined. And the network-wide traffic impact as these new BFD sessions are
> largely multi-hop. Are you really arguing that the introduction of many
> thousands of BFD sessions is something we should not be concerned about? *
>
> *   Les*
>
>
>
>Les
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] BGP vs PUA/PULSE

[Les Ginsberg (ginsberg)]

Greg –

Inline.

From: Greg Mirsky 
Sent: Monday, January 10, 2022 3:36 PM
To: Les Ginsberg (ginsberg) 
Cc: Tony Li ; Christian Hopps ; Robert 
Raszuk ; Aijun Wang ; Shraddha 
Hegde ; Hannes Gredler ; lsr 
; Peter Psenak (ppsenak) 
Subject: Re: [Lsr] BGP vs PUA/PULSE

Hi Les,
thank you for the detailed clarifications. Please find my follow-up notes 
in-lined below under the GIM>> tag.

Regards,
Greg

On Mon, Jan 10, 2022 at 3:19 PM Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>> wrote:
Greg –

The obvious issue is scale. Since you need a full mesh you are talking about 
N**2 behavior – so it doesn’t take many nodes to require thousands of BFD 
sessions.
GIM>> If I understand the scenario correctly, N represents the number of PEs, 
not the number of routers in ASes. If that is the case, what could be a good 
estimate for N?

[LES:] Even a modest sized N = 100 (which is certainly not a high number) leads 
to 1 BFD sessions. N= 500 => 250,000 sessions. Etc.

In terms of detect time, we are trying to get an order of magnitude improvement 
from normal BGP session timers – so we are aiming for a modest number of 
seconds.
GIM>> That is very helpful information, thank you. Then, we can expect that a 
one-second interval for the transmission of a BFD Control packet would be 
acceptable and guarantee failure detection within three seconds. If that is the 
case, I'll note that many platforms support thousands of BFD sessions at 3.3 
msec intervals. It appears to me that the case we're discussing 
produces/processes 330 times fewer BFD packets per session. Should somewhat 
help with the scaling, would you agree?

[LES:] Nodes which can support thousands of BFD sessions are likely already 
using many BFD sessions for other purposes. In particular, fast detection of 
local failures is always going to be a priority – so if a node has thousands of 
neighbors – it will likely have thousands of single hop BFD sessions. Not to 
mention the plethora of other OAM uses cases being defined. And the 
network-wide traffic impact as these new BFD sessions are largely multi-hop. 
Are you really arguing that the introduction of many thousands of BFD sessions 
is something we should not be concerned about?
   Les

   Les


From: Greg Mirsky mailto:gregimir...@gmail.com>>
Sent: Monday, January 10, 2022 1:30 PM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Cc: Tony Li mailto:tony...@tony.li>>; Christian Hopps 
mailto:cho...@chopps.org>>; Robert Raszuk 
mailto:rob...@raszuk.net>>; Aijun Wang 
mailto:wangai...@tsinghua.org.cn>>; Shraddha Hegde 
mailto:shrad...@juniper.net>>; Hannes Gredler 
mailto:han...@gredler.at>>; lsr 
mailto:lsr@ietf.org>>; Peter Psenak (ppsenak) 
mailto:ppse...@cisco.com>>
Subject: Re: [Lsr] BGP vs PUA/PULSE

Hi Les,
thank you for bringing the real-life scenarios to the discussion. In your 
opinion, what prevents an operator from monitoring a remote PE using a 
multi-hop BFD? Do you have an estimated number of such sessions each PE must 
handle? What could be the required guaranteed failure detection time?

Best regards,
Greg

On Mon, Jan 10, 2022 at 1:08 PM Les Ginsberg (ginsberg) 
mailto:40cisco@dmarc.ietf.org>> wrote:
Chris/Tony –

We have received requests from real customers who both need to summarize AND 
would like better response time to loss of reachability to individual nodes.
If they could operate at the necessary scale without summarizing they would 
have already – so telling customers to simply make sure they don’t use 
summaries isn’t helpful.

There are then two ways to respond:

1)Sorry, when you use summaries you lose the ability to receive state 
information about individual prefixes covered by the summary. There is nothing 
we can do to help you.

This seems to be what the two of you are saying.

2)We can provide a way to improve response time for the loss of reachability to 
individual destinations covered by a summary, but its use will be limited to 
isolated failures. Failures which affect a significant number of destinations 
at the same time will realize no benefit from the solution. If this limitation 
is acceptable then we have proposals that we think will be useful.

That’s what we are trying to do.

   Les



From: Tony Li mailto:tony1ath...@gmail.com>> On Behalf 
Of Tony Li
Sent: Monday, January 3, 2022 1:09 PM
To: Christian Hopps mailto:cho...@chopps.org>>
Cc: Peter Psenak (ppsenak) mailto:ppse...@cisco.com>>; Les 
Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; Robert 
Raszuk mailto:rob...@raszuk.net>>; Shraddha Hegde 
mailto:shrad...@juniper.net>>; Aijun Wang 
mailto:wangai...@tsinghua.org.cn>>; Hannes Gredler 
mailto:han...@gredler.at>>; lsr 
mailto:lsr@ietf.org>>
Subject: Re: [Lsr] BGP vs PUA/PULSE



On Jan 3, 2022, at 11:23 AM, Christian Hopps 
mailto:cho...@chopps.org>> wrote:

And I'm saying if a prefix is important enough to merit a bunch of new protocol 
extensions and state, then it's important enough to simply be left out of the 
summarization in the

Re: [Lsr] BGP vs PUA/PULSE

[Robert Raszuk]

Hi Les,

*> You seem focused on the notification delivery mechanism only.*

Not really. For me, an advertised summary is like a prefix when you are
dialing a country code. Call signaling knows to go north if you are calling
a crab shop in Alaska.

Now such direction does not indicate if the shop is open or has crabs.

That info you need to get over the top as a service. So I am much more in
favor to make the service to tell you directly or indirectly that it is
available.

Best,
R.





On Tue, Jan 11, 2022 at 1:07 AM Les Ginsberg (ginsberg) 
wrote:

> Robert -
>
>
>
> *From:* Robert Raszuk 
> *Sent:* Monday, January 10, 2022 2:56 PM
> *To:* Les Ginsberg (ginsberg) 
> *Cc:* Tony Li ; Christian Hopps ;
> Peter Psenak (ppsenak) ; Shraddha Hegde <
> shrad...@juniper.net>; Aijun Wang ; Hannes
> Gredler ; lsr 
> *Subject:* Re: [Lsr] BGP vs PUA/PULSE
>
>
>
> Les,
>
>
>
> We have received requests from real customers who both need to summarize
> AND would like better response time to loss of reachability to individual
> nodes.
>
>
>
> We all agree the request is legitimate.
>
>
>
> *[LES:] It does not seem to me that everyone does agree on that – but I
> appreciate that you agree.*
>
>
>
> But do they realize that to practically employ what you are proposing (new
> PDU flooding) requires 100% software upgrade to all IGP nodes in the entire
> network ? Do they also realize that to effectively use it requires data
> plane change (sure software but data plane code is not as simple as PI) on
> all ingress PEs ?
>
>
>
> *[LES:] As far as forwarding, as Peter has indicated, we have a POC and it
> works fine. And there are many possible ways for implementations to go.*
>
> *It may or may not require 100% software upgrade – but I agree a
> significant number of nodes have to be upgraded to at least support pulse
> flooding.*
>
>
>
>
>
> And with scale requirements you are describing it seems this would be
> 1000s of nodes (if not more). That's massive if compared to
> alternative approaches to achieve the same or even better results.
>
>
>
> *[LES:] Be happy to review other solutions if/when someone writes them up.*
>
> *I think what is overlooked in the discussion of other solutions is that
> reachability info is provided by the IGP. If all the IGP advertises is a
> summary then how would individual loss of reachability become known at
> scale?*
>
> *You seem focused on the notification delivery mechanism only.*
>
>
>
> *   Les*
>
>
>
> Many thx,
>
> Robert
>
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] BGP vs PUA/PULSE

[Les Ginsberg (ginsberg)]

Robert -

From: Robert Raszuk 
Sent: Monday, January 10, 2022 2:56 PM
To: Les Ginsberg (ginsberg) 
Cc: Tony Li ; Christian Hopps ; Peter 
Psenak (ppsenak) ; Shraddha Hegde ; 
Aijun Wang ; Hannes Gredler ; lsr 

Subject: Re: [Lsr] BGP vs PUA/PULSE

Les,

We have received requests from real customers who both need to summarize AND 
would like better response time to loss of reachability to individual nodes.

We all agree the request is legitimate.

[LES:] It does not seem to me that everyone does agree on that – but I 
appreciate that you agree.

But do they realize that to practically employ what you are proposing (new PDU 
flooding) requires 100% software upgrade to all IGP nodes in the entire network 
? Do they also realize that to effectively use it requires data plane change 
(sure software but data plane code is not as simple as PI) on all ingress PEs ?

[LES:] As far as forwarding, as Peter has indicated, we have a POC and it works 
fine. And there are many possible ways for implementations to go.
It may or may not require 100% software upgrade – but I agree a significant 
number of nodes have to be upgraded to at least support pulse flooding.


And with scale requirements you are describing it seems this would be 1000s of 
nodes (if not more). That's massive if compared to alternative approaches to 
achieve the same or even better results.

[LES:] Be happy to review other solutions if/when someone writes them up.
I think what is overlooked in the discussion of other solutions is that 
reachability info is provided by the IGP. If all the IGP advertises is a 
summary then how would individual loss of reachability become known at scale?
You seem focused on the notification delivery mechanism only.

   Les

Many thx,
Robert

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

Re: [Lsr] BGP vs PUA/PULSE

[Les Ginsberg (ginsberg)]

Tony –

I understand what Chris wrote.
And if customers could do what he suggested then they would not have an issue.

But there are deployments where what he suggested is not possible – largely I 
think because the set of “prefixes of interest” is in itself large.

So while not all customers have an issue, some customers do and we are trying 
to find a way to address those deployments.

As far as the alternative proposals, I will comment on them if/when there is 
something visible – but I think they will all suffer from scale issues.

   Les

From: Tony Li  On Behalf Of Tony Li
Sent: Monday, January 10, 2022 1:41 PM
To: Les Ginsberg (ginsberg) 
Cc: Christian Hopps ; Peter Psenak (ppsenak) 
; Robert Raszuk ; Shraddha Hegde 
; Aijun Wang ; Hannes Gredler 
; lsr 
Subject: Re: [Lsr] BGP vs PUA/PULSE


Les,



We have received requests from real customers who both need to summarize AND 
would like better response time to loss of reachability to individual nodes.
If they could operate at the necessary scale without summarizing they would 
have already – so telling customers to simply make sure they don’t use 
summaries isn’t helpful.


To be clear: I think the suggestion was to not summarize the endpoints that you 
want detailed information about. Summarizing the rest of the area is certainly 
sensible.  This should not be hard to accomplish: simply advertise the 
loopbacks for the relevant systems out of another prefix and then leak them.

This should give you both scalability and specific information. It also has the 
advantage that the scale pressure is present in the steady state, not in 
failure scenarios. Failing into the worst case situation is always a serious 
concern.  Having to add heuristic mechanisms to prevent scalability failures is 
pretty indicative that this is not a very robust approach.

If response time really is the key concern, then why are we relying on 
flooding? We know that that’s not rapid as it will be hop-by-hop with arbitrary 
delay. If response time really is the priority, then the other alternatives 
we’ve discussed (BGP, BFD, a pub-sub mechanism) would all seem to be preferable.

Bottom line: this doesn’t seem like it should be in the IGP.

Regards,
Tony

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

Re: [Lsr] BGP vs PUA/PULSE

[Robert Raszuk]

Les,

The obvious issue is scale. Since you need a full mesh you are talking
> about N**2 behavior – so it doesn’t take many nodes to require thousands of
> BFD sessions.
>

That does sound scary doesn't it ? 1000s is a rather big number ... :)

Well good news is that we have recently finished work and moved to IESG
with unsolicited BFD proposal:

https://datatracker.ietf.org/doc/html/draft-ietf-bfd-unsolicited-09

That means that you can use BFD probes with zero configured session(s) yet
get full benefit of remote liveness discovery. Just imagine when BGP
registered with the RIB request to track given the next hop you trigger
such BFD probes at requested frequency.

Zero change to control plane nor data plane. Yet full benefit.

And while we are at this point let's observe that most if not all real PEs
can respond to BFD in line cards and the amount of such traffic would be
completely negligible when considering forwarding performance of today's
production PEs both in terms of PPS or LC throughput.

Cheers,
Robert.

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

Re: [Lsr] BGP vs PUA/PULSE

[Greg Mirsky]

Hi Les,
thank you for the detailed clarifications. Please find my follow-up notes
in-lined below under the GIM>> tag.

Regards,
Greg

On Mon, Jan 10, 2022 at 3:19 PM Les Ginsberg (ginsberg) 
wrote:

> Greg –
>
>
>
> The obvious issue is scale. Since you need a full mesh you are talking
> about N**2 behavior – so it doesn’t take many nodes to require thousands of
> BFD sessions.
>
GIM>> If I understand the scenario correctly, N represents the number of
PEs, not the number of routers in ASes. If that is the case, what could be
a good estimate for N?

>
>
> In terms of detect time, we are trying to get an order of magnitude
> improvement from normal BGP session timers – so we are aiming for a modest
> number of seconds.
>
GIM>> That is very helpful information, thank you. Then, we can expect that
a one-second interval for the transmission of a BFD Control packet would be
acceptable and guarantee failure detection within three seconds. If that is
the case, I'll note that many platforms support thousands of BFD sessions
at 3.3 msec intervals. It appears to me that the case we're discussing
produces/processes 330 times fewer BFD packets per session. Should somewhat
help with the scaling, would you agree?

>
>
>Les
>
>
>
>
>
> *From:* Greg Mirsky 
> *Sent:* Monday, January 10, 2022 1:30 PM
> *To:* Les Ginsberg (ginsberg) 
> *Cc:* Tony Li ; Christian Hopps ;
> Robert Raszuk ; Aijun Wang ;
> Shraddha Hegde ; Hannes Gredler ;
> lsr ; Peter Psenak (ppsenak) 
> *Subject:* Re: [Lsr] BGP vs PUA/PULSE
>
>
>
> Hi Les,
>
> thank you for bringing the real-life scenarios to the discussion. In your
> opinion, what prevents an operator from monitoring a remote PE using a
> multi-hop BFD? Do you have an estimated number of such sessions each PE
> must handle? What could be the required guaranteed failure detection time?
>
>
>
> Best regards,
>
> Greg
>
>
>
> On Mon, Jan 10, 2022 at 1:08 PM Les Ginsberg (ginsberg)  40cisco@dmarc.ietf.org> wrote:
>
> Chris/Tony –
>
>
>
> We have received requests from real customers who both need to summarize
> AND would like better response time to loss of reachability to individual
> nodes.
>
> If they could operate at the necessary scale without summarizing they
> would have already – so telling customers to simply make sure they don’t
> use summaries isn’t helpful.
>
>
>
> There are then two ways to respond:
>
>
>
> 1)Sorry, when you use summaries you lose the ability to receive state
> information about individual prefixes covered by the summary. There is
> nothing we can do to help you.
>
>
>
> This seems to be what the two of you are saying.
>
>
>
> 2)We can provide a way to improve response time for the loss of
> reachability to individual destinations covered by a summary, but its use
> will be limited to isolated failures. Failures which affect a significant
> number of destinations at the same time will realize no benefit from the
> solution. If this limitation is acceptable then we have proposals that we
> think will be useful.
>
>
>
> That’s what we are trying to do.
>
>
>
>Les
>
>
>
>
>
>
>
> *From:* Tony Li  *On Behalf Of *Tony Li
> *Sent:* Monday, January 3, 2022 1:09 PM
> *To:* Christian Hopps 
> *Cc:* Peter Psenak (ppsenak) ; Les Ginsberg (ginsberg)
> ; Robert Raszuk ; Shraddha Hegde <
> shrad...@juniper.net>; Aijun Wang ; Hannes
> Gredler ; lsr 
> *Subject:* Re: [Lsr] BGP vs PUA/PULSE
>
>
>
>
>
>
>
> On Jan 3, 2022, at 11:23 AM, Christian Hopps  wrote:
>
>
>
> And I'm saying if a prefix is important enough to merit a bunch of new
> protocol extensions and state, then it's important enough to simply be left
> out of the summarization in the first place.
>
> And then people get what they want, w/o protocol changes/upgrades, and
> it's using time tested and hardened IGP code and designs.
>
>
>
>
>
> +1
>
>
>
> T
>
>
>
> ___
> 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] BGP vs PUA/PULSE

[Robert Raszuk]

>  we are trying to get an order of magnitude improvement from normal BGP
> session timers
>

Please observe that "normal BGP session timers" play no role in this if we
are serious about the objective.

Just like ABR get's the information about PE down events so can the local
area BGP Route Reflector(s). I can argue that BGP withdrawal of subject
next hop can be triggered from such RR much faster then all ABRs in said
area will get and process local IGP flooding from all peers.

Then you need to compare the speed of flooding via 10s of IGP nodes vs at
most two RR hops to get to ingress PEs with the precious information.

I think the conclusion is obvious. Along the same lines OAM can do the job.
The problem with that however is the need for a new transport to propagate
that information around.

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

Re: [Lsr] BGP vs PUA/PULSE

[Les Ginsberg (ginsberg)]

Greg –

The obvious issue is scale. Since you need a full mesh you are talking about 
N**2 behavior – so it doesn’t take many nodes to require thousands of BFD 
sessions.

In terms of detect time, we are trying to get an order of magnitude improvement 
from normal BGP session timers – so we are aiming for a modest number of 
seconds.

   Les


From: Greg Mirsky 
Sent: Monday, January 10, 2022 1:30 PM
To: Les Ginsberg (ginsberg) 
Cc: Tony Li ; Christian Hopps ; Robert 
Raszuk ; Aijun Wang ; Shraddha 
Hegde ; Hannes Gredler ; lsr 
; Peter Psenak (ppsenak) 
Subject: Re: [Lsr] BGP vs PUA/PULSE

Hi Les,
thank you for bringing the real-life scenarios to the discussion. In your 
opinion, what prevents an operator from monitoring a remote PE using a 
multi-hop BFD? Do you have an estimated number of such sessions each PE must 
handle? What could be the required guaranteed failure detection time?

Best regards,
Greg

On Mon, Jan 10, 2022 at 1:08 PM Les Ginsberg (ginsberg) 
mailto:40cisco@dmarc.ietf.org>> wrote:
Chris/Tony –

We have received requests from real customers who both need to summarize AND 
would like better response time to loss of reachability to individual nodes.
If they could operate at the necessary scale without summarizing they would 
have already – so telling customers to simply make sure they don’t use 
summaries isn’t helpful.

There are then two ways to respond:

1)Sorry, when you use summaries you lose the ability to receive state 
information about individual prefixes covered by the summary. There is nothing 
we can do to help you.

This seems to be what the two of you are saying.

2)We can provide a way to improve response time for the loss of reachability to 
individual destinations covered by a summary, but its use will be limited to 
isolated failures. Failures which affect a significant number of destinations 
at the same time will realize no benefit from the solution. If this limitation 
is acceptable then we have proposals that we think will be useful.

That’s what we are trying to do.

   Les



From: Tony Li mailto:tony1ath...@gmail.com>> On Behalf 
Of Tony Li
Sent: Monday, January 3, 2022 1:09 PM
To: Christian Hopps mailto:cho...@chopps.org>>
Cc: Peter Psenak (ppsenak) mailto:ppse...@cisco.com>>; Les 
Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; Robert 
Raszuk mailto:rob...@raszuk.net>>; Shraddha Hegde 
mailto:shrad...@juniper.net>>; Aijun Wang 
mailto:wangai...@tsinghua.org.cn>>; Hannes Gredler 
mailto:han...@gredler.at>>; lsr 
mailto:lsr@ietf.org>>
Subject: Re: [Lsr] BGP vs PUA/PULSE



On Jan 3, 2022, at 11:23 AM, Christian Hopps 
mailto:cho...@chopps.org>> wrote:

And I'm saying if a prefix is important enough to merit a bunch of new protocol 
extensions and state, then it's important enough to simply be left out of the 
summarization in the first place.

And then people get what they want, w/o protocol changes/upgrades, and it's 
using time tested and hardened IGP code and designs.


+1

T

___
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] BGP vs PUA/PULSE

[Robert Raszuk]

Les,


> We have received requests from real customers who both need to summarize
> AND would like better response time to loss of reachability to individual
> nodes.
>

We all agree the request is legitimate.

But do they realize that to practically employ what you are proposing (new
PDU flooding) requires 100% software upgrade to all IGP nodes in the entire
network ? Do they also realize that to effectively use it requires data
plane change (sure software but data plane code is not as simple as PI) on
all ingress PEs ?

And with scale requirements you are describing it seems this would be 1000s
of nodes (if not more). That's massive if compared to
alternative approaches to achieve the same or even better results.

Many thx,
Robert
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] BGP vs PUA/PULSE

[Tony Li]

Les,


> We have received requests from real customers who both need to summarize AND 
> would like better response time to loss of reachability to individual nodes.
> If they could operate at the necessary scale without summarizing they would 
> have already – so telling customers to simply make sure they don’t use 
> summaries isn’t helpful.


To be clear: I think the suggestion was to not summarize the endpoints that you 
want detailed information about. Summarizing the rest of the area is certainly 
sensible.  This should not be hard to accomplish: simply advertise the 
loopbacks for the relevant systems out of another prefix and then leak them.

This should give you both scalability and specific information. It also has the 
advantage that the scale pressure is present in the steady state, not in 
failure scenarios. Failing into the worst case situation is always a serious 
concern.  Having to add heuristic mechanisms to prevent scalability failures is 
pretty indicative that this is not a very robust approach.

If response time really is the key concern, then why are we relying on 
flooding? We know that that’s not rapid as it will be hop-by-hop with arbitrary 
delay. If response time really is the priority, then the other alternatives 
we’ve discussed (BGP, BFD, a pub-sub mechanism) would all seem to be preferable.

Bottom line: this doesn’t seem like it should be in the IGP.

Regards,
Tony

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

Re: [Lsr] BGP vs PUA/PULSE

[Greg Mirsky]

Hi Les,
thank you for bringing the real-life scenarios to the discussion. In your
opinion, what prevents an operator from monitoring a remote PE using a
multi-hop BFD? Do you have an estimated number of such sessions each PE
must handle? What could be the required guaranteed failure detection time?

Best regards,
Greg

On Mon, Jan 10, 2022 at 1:08 PM Les Ginsberg (ginsberg)  wrote:

> Chris/Tony –
>
>
>
> We have received requests from real customers who both need to summarize
> AND would like better response time to loss of reachability to individual
> nodes.
>
> If they could operate at the necessary scale without summarizing they
> would have already – so telling customers to simply make sure they don’t
> use summaries isn’t helpful.
>
>
>
> There are then two ways to respond:
>
>
>
> 1)Sorry, when you use summaries you lose the ability to receive state
> information about individual prefixes covered by the summary. There is
> nothing we can do to help you.
>
>
>
> This seems to be what the two of you are saying.
>
>
>
> 2)We can provide a way to improve response time for the loss of
> reachability to individual destinations covered by a summary, but its use
> will be limited to isolated failures. Failures which affect a significant
> number of destinations at the same time will realize no benefit from the
> solution. If this limitation is acceptable then we have proposals that we
> think will be useful.
>
>
>
> That’s what we are trying to do.
>
>
>
>Les
>
>
>
>
>
>
>
> *From:* Tony Li  *On Behalf Of *Tony Li
> *Sent:* Monday, January 3, 2022 1:09 PM
> *To:* Christian Hopps 
> *Cc:* Peter Psenak (ppsenak) ; Les Ginsberg (ginsberg)
> ; Robert Raszuk ; Shraddha Hegde <
> shrad...@juniper.net>; Aijun Wang ; Hannes
> Gredler ; lsr 
> *Subject:* Re: [Lsr] BGP vs PUA/PULSE
>
>
>
>
>
>
>
> On Jan 3, 2022, at 11:23 AM, Christian Hopps  wrote:
>
>
>
> And I'm saying if a prefix is important enough to merit a bunch of new
> protocol extensions and state, then it's important enough to simply be left
> out of the summarization in the first place.
>
> And then people get what they want, w/o protocol changes/upgrades, and
> it's using time tested and hardened IGP code and designs.
>
>
>
>
>
> +1
>
>
>
> T
>
>
> ___
> 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] BGP vs PUA/PULSE

[Les Ginsberg (ginsberg)]

Chris/Tony -

We have received requests from real customers who both need to summarize AND 
would like better response time to loss of reachability to individual nodes.
If they could operate at the necessary scale without summarizing they would 
have already - so telling customers to simply make sure they don't use 
summaries isn't helpful.

There are then two ways to respond:

1)Sorry, when you use summaries you lose the ability to receive state 
information about individual prefixes covered by the summary. There is nothing 
we can do to help you.

This seems to be what the two of you are saying.

2)We can provide a way to improve response time for the loss of reachability to 
individual destinations covered by a summary, but its use will be limited to 
isolated failures. Failures which affect a significant number of destinations 
at the same time will realize no benefit from the solution. If this limitation 
is acceptable then we have proposals that we think will be useful.

That's what we are trying to do.

   Les



From: Tony Li mailto:tony1ath...@gmail.com>> On Behalf 
Of Tony Li
Sent: Monday, January 3, 2022 1:09 PM
To: Christian Hopps mailto:cho...@chopps.org>>
Cc: Peter Psenak (ppsenak) mailto:ppse...@cisco.com>>; Les 
Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; Robert 
Raszuk mailto:rob...@raszuk.net>>; Shraddha Hegde 
mailto:shrad...@juniper.net>>; Aijun Wang 
mailto:wangai...@tsinghua.org.cn>>; Hannes Gredler 
mailto:han...@gredler.at>>; lsr 
mailto:lsr@ietf.org>>
Subject: Re: [Lsr] BGP vs PUA/PULSE




On Jan 3, 2022, at 11:23 AM, Christian Hopps 
mailto:cho...@chopps.org>> wrote:

And I'm saying if a prefix is important enough to merit a bunch of new protocol 
extensions and state, then it's important enough to simply be left out of the 
summarization in the first place.

And then people get what they want, w/o protocol changes/upgrades, and it's 
using time tested and hardened IGP code and designs.


+1

T

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

Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

[Les Ginsberg (ginsberg)]

Aijun –

Top posting here.

I think what is desired is load balancing at the application layer – coupled 
with persistence of a given flow (AKA client-server connection). You aren’t 
going to achieve that by dynamically adjusting IGP costs.
And you are likely to get oscillation – which is undesirable.

As regards the relationship between draft-dunbar-lsr-5g-edge-compute and 
draft-wang-lsr-stub-link-attributes, I noted that in my reading but chose not 
to discuss it as my concerns with each draft are more fundamental and I did not 
want to distract.
But since you mention this, draft-dunbar-lsr-5g-edge-compute is proposing to 
advertise new prefix related information.
draft-wang-lsr-stub-link-attributes is proposing to advertise new link related 
information.
This difference matters to me – though it seems it does not to you.
One reason why we will never agree about this. 😊

As regards the IS-IS encoding, please look at the equivalent proposed OSPF 
encoding in the previous section and ask yourself why they are different. 😊

   Les


From: Lsr  On Behalf Of Aijun Wang
Sent: Monday, January 10, 2022 9:05 AM
To: Les Ginsberg (ginsberg) 
Cc: lsr@ietf.org; Linda Dunbar 
Subject: Re: [Lsr] Seeking feedback to the revised 
draft-dunbar-lsr-5g-edge-compute

Hi, Les:
Aijun Wang
China Telecom


On Jan 10, 2022, at 23:48, Les Ginsberg (ginsberg) 
mailto:ginsberg=40cisco@dmarc.ietf.org>>
 wrote:

Linda –

I believe the most valuable feedback you received during your presentation at 
IETF 112 is that using IGPs likely will not meet the deployment requirements.
In particular, persistence of a given client session with a given application 
server is likely a requirement which will not be achieved using an IGP based 
solution.
[WAJ] The main aim of draft is to how assist the router to select the most 
appropriate application servers, with regards to the metrics that is not 
limited to the link cost.

Also, the modification of IGP metrics will likely introduce unwanted 
oscillation in traffic flows.

[WAJ] These metrics are associated with the links that doesn’t participate in 
the IGP, that is, they are the characteristics of the “Stub-Link”, then only 
the application that utilize such information will be influenced, or optimized.


I suggest you start with a clean slate – focus on defining what all the 
requirements are without regard to what mechanism/protocol might be used – and 
then think about defining a solution which meets these requirements.
I think you will end up NOT using routing protocols at all

[WAJ] Selecting the most appropriate/optimized application server should base 
on the topology information which is routing protocol related.


On a more mundane note, the section describing the new IS-IS advertisement 
(https://datatracker.ietf.org/doc/html/draft-dunbar-lsr-5g-edge-compute-03#section-6
 ) is – to put it bluntly – a mess! 😊
TLVs 128 and 130 are legacy TLVs which don’t support sub-TLVs – they should not 
be mentioned at all.
And the encoding diagram shows a “prefix” being advertised in the new sub-TLV 
when it should not. The prefix has already been advertised in the parent TLV.

[WAJ] Actually, the most appropriate place to convey such information is via 
the Stub-Link TLV/Sub-TLV that defined in 
https://datatracker.ietf.org/doc/html/draft-wang-lsr-stub-link-attributes-02



   Les


From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
Linda Dunbar
Sent: Friday, January 7, 2022 11:29 AM
To: lsr@ietf.org
Subject: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

LSR experts,

We have revised the draft-dunbar-lsr-5g-edge-compute to address the comments 
and feedback from IETF 112.
https://datatracker.ietf.org/doc/draft-dunbar-lsr-5g-edge-compute/

In a nutshell, the proposed solution

  *   advertises the “Site-Cost” via IP prefix reachability TLV associated with 
the (anycast) prefix
The  Site-Cost is the aggregated cost associated with an Edge Compute (EC) 
server (i.e., ANYCAST prefix), computed based on the IP layer related metrics 
for the prefix, such as Load Measurement, the Capacity Index, the Preference 
Index, and other constraints by a consistent algorithm across all egress 
routers to which the EC servers are attached.


  *   Uses a Flag in the Flexible Algorithm TLV to indicate that  “site-cost” 
needs to be included for the constrained SPF to reach the Prefix


Any feedbacks? Or suggestions?

Thank you very much
Linda
___
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-wang-lsr-stub-link-attributes-02

[Tony Li]

I object to the adoption of this draft. 

I don’t think that it’s fundamentally a correct approach.

One of the important things that we’ve learned over the years is that we need 
to build general designs and not simply add new elements and mechanisms for 
each use case that we think of.

I understand the AS boundary use case. I agree that’s worthy of consideration. 
Not so much the others.

I would suggest that the authors spend a bit more time cogitating.

Regards,
Tony


> On Jan 3, 2022, at 10:58 PM, Christian Hopps  wrote:
> 
> Hi Folks,
> 
> This begins a 2 week WG Adoption Call for the following draft:
> 
> https://datatracker.ietf.org/doc/draft-wang-lsr-stub-link-attributes/
> 
> Please indicate your support or objections by January 18th, 2022.
> 
> Authors, please respond to the list indicating whether you are aware of any 
> IPR that applies to these drafts.
> 
> Thanks,
> Chris.
> 
> ___
> 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] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

[Tony Li]

> On Jan 10, 2022, at 9:05 AM, Aijun Wang  wrote:
> 
> [WAJ] Selecting the most appropriate/optimized application server should base 
> on the topology information which is routing protocol related.


Just because some mechanism wants to use toplogy information does NOT imply 
that it should be part of the routing protocol.

In this case, load balancing should be an independent mechanism.  If it wants 
to peek into the LSDB, that would be perfectly acceptable, IMHO.

Tony

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

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[Les Ginsberg (ginsberg)]

Aijun -

Please see inline.

> -Original Message-
> From: Aijun Wang 
> Sent: Monday, January 10, 2022 8:34 AM
> To: Les Ginsberg (ginsberg) 
> Cc: Christian Hopps ; lsr@ietf.org; lsr-cha...@ietf.org;
> lsr-...@ietf.org; draft-wang-lsr-stub-link-attribu...@ietf.org
> Subject: Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02
> 
> Hi, Les:
> 
> Wish the below explanation can correct your understanding of this draft, and
> also your conclusions.
> 
> Aijun Wang
> China Telecom
> 
> > On Jan 10, 2022, at 23:13, Les Ginsberg (ginsberg)
>  wrote:
> >
> > I oppose WG adoption of this draft.
> >
> > In addition to my comments below, I am in agreement with the points
> made by Peter and Shraddha previously in this thread.
> >
> > My comments below are in the context of IS-IS/RFC5316, but I believe are
> equally valid in the context of OSPF/RFC5392.
> >
> > There are two types of new information the draft proposes to advertise
> under TLV 141:
> >
> > 1)Identifying a link by the prefix locally configured on the link rather 
> > than by
> the local/remote addresses.
> >
> > The motivation for this addition seems to be to avoid the need for the
> operator to locally configure the remote address.
> [WAJ] For inter-AS stub link type, it is. For other stub link type, it isn’t.
> 
> > But I think this is not a desirable change.
> >
> > As pointed out by Peter, this does not work for unnumbered links. (It also
> would not work for Pt-2-MP links). The authors assert that it is unlikely that
> unnumbered links would be used in the expected use cases - but I do not
> find this argument convincing.
> [WAJ] Is there any operator adopt unnumbered link at its boundary
> network? There is even very rare case for the unnumbered interface be
> used within the operator network. And, with the IPv6 deployment, what is
> the usages of unnumbered interface? Won’t it be depreciated in future?
> Very curious you and Peter stick to this point, but not considering its wider
> use scenarios.
> 
[LES:] Aijun - Unnumbered links are in common usage today. We should not define 
extensions which do not allow support for this.

> > Even if unnumbered links are not currently being used, the restriction that
> they could not be used in the future seems highly undesirable.
> 
> [WAJ] Would like to hear the reason and scenarios that the unnumbered
> interface will be used in future. I think it should be deprecated instead.

[LES:] Deprecating the use of unnumbered is outside the scope of this 
specification - and I would argue is not something we (the WG) should be 
advocating in any case.

> 
> > It would put us in the position of having to revise this functionality in 
> > the
> future in an incompatible way in order to add such support. This is a bad
> design choice.
> 
> [WAJ] We should keep the trend, not stick to the obsolete obstacles.

[LES:] Unnumbered is not obsolete - it is only you who have arbitrarily decided 
that it is no longer needed.

> 
> >
> > Aside: The assertion that unnumbered links will not be used seems at odds
> with the inclusion of "loopback" as a link type.
> 
> [WAJ] The loop back address won’t borrow address from others. Or if you
> consider it maybe, please give the reason.
> 
> > More on that below.
> >
> > Also, as the draft builds on top of existing RFC5316 functionality, it is 
> > still
> required to advertise remote AS Number and Remote ASBR ID as well as
> remote Router IDs (IPv4 and/or IPv6) (see
> https://datatracker.ietf.org/doc/html/rfc5316#section-3.3 )
> 
> [WAJ] No. With the newly defined TLV/sun-TLV, we need not configured the
> above information manually then. And for other stub link type(for example,
> the edge router that connects the server) there will be no remote-AS, no
> remote ASBR, how can you configure them?
>
[LES:] Indeed - which means your extensions to TLV 141 violate RFC 5316. Please 
read the referenced section I provided and pay attention to the normative 
statements ("MUST") there.
So, RFC 5316 conformant implementations will not accept the TLVs you apparently 
intend to send.
This is not something which can be ignored.

 
> > - all of which still need to be locally configured since there is no IGP
> operating on the link. So the suggestion that not having to configure the
> remote link address provides significant simplification in deployment does
> not stand up to scrutiny.
> 
> [WAJ] Please see the previous explanation.
> >
> > 2)New link type information (AS boundary link/Loopback link/Vlan
> interface link) to be advertised
> >
> > There is no mention in the draft as to how this information will be used.
> [WAJ] The information about various stub link type is mainly for the
> controller. If necessary, we can add some potential use cases for such type
> information, but this is not the main points of this draft.
> 
[LES:] There is still nothing in the draft which explains what value the new 
information provides.
For example, why does a controller or a ro

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

[Tony Przygienda]

yes, first, if you abstract in _any_ way (except a full mesh for a single
metric) you will end up with suboptimal paths (compared to global, flat
topology view) traversing an abstracted subgraph and different ECMP
behavior in corner cases, it's basic graph theory (aggravated by hop-by-hop
or loose-source route forwarding planes) and is a well-known problem
encountered in any hierarchical network, be it IGP, seamless MPLS or even
BGP (look @ AIGP). FR deployed with underlying tunnels in L1 does not loop
and neither does it when deployed correctly with prefix leaking.

I cannot help it if a single person on this list is harboring fears,
preferences and doubts without hard technical arguments to make for a
meaningful discussion so I think it's time to put that repetitive
sub-thread aside.

As I said, I will be more than happy to help on a "deployment
considerations" or some such draft once those documents move up to
publication  so we have stable references to talk about ...

thanks

-- tony

On Mon, Jan 10, 2022 at 6:05 PM Acee Lindem (acee)  wrote:

> I'll defer to Tony but my understanding is that there could be suboptimal
> paths if there are both Level-1 and Level-2 paths but not loops.
> Thanks,
> Acee
>
> On 1/10/22, 11:38 AM, "Aijun Wang"  wrote:
>
> But there are unsolved issues for this draft—— BGP has loop prevention
> mechanism, current flood reflection draft hasn’t, the operator must  design
> the topology/link metric  carefully to avoid the possible loop.
>
> Aijun Wang
> China Telecom
>
> > On Jan 11, 2022, at 00:10, Acee Lindem (acee)  40cisco@dmarc.ietf.org> wrote:
> >
> > Speaking as a WG member, these documents are all "experimental" and,
> IMO, it would really stifle innovation to require a single experimental
> solution. We've never done that in the past. Also,  while all three
> solutions have the goal of reducing control plane overhead when using
> Level-1 areas as a transit, the flood reflection draft solves the problem
> with a different approach than the area proxy and TTZ drafts.  While the
> latter two focus on abstracting the transit area, the former also focusing
> on reducing the number of adjacencies and allows the reflector to be out of
> the data path (similar to the standardized and widely deployed BGP route
> reflection) I see no need to differentiate to stall advancement.
> >
> > Thanks,
> > Acee
> >
> > On 1/3/22, 7:05 AM, "Christian Hopps"  wrote:
> >
> >
> >Tony Przygienda  writes:
> >
> >> One thing Les is missing here is that proxy & reflection present in
> >> terms of deployment requirements and ultimate properties very
> >> different engineering & operational trade-offs. Different customers
> >> follow different philosophies here IME
> >>
> >> So we are not strictly standardizing here 2 solutions for the same
> >> thing, we are standardizing two solutions that meet very different
> >> deployment and operational requirements albeit from 20K feet view
> all
> >> that stuff looks the same of course as any other thing does ...
> >
> >Have we captured these "different deployment and operational
> requirements" anywhere? I think might be very useful...
> >
> >Thanks,
> >Chris.
> >[as wg member]
> >
> >
> >> -- tony
> >>
> >> On Tue, Dec 7, 2021 at 7:17 PM Les Ginsberg (ginsberg)  >> 40cisco@dmarc.ietf.org> wrote:
> >>
> >>
> >>When I look at this request, I see it in a larger context.
> >>
> >>
> >>
> >>There are two drafts which attempt to address the same problem in
> >>very different ways:
> >>
> >>
> >>
> >>https://datatracker.ietf.org/doc/
> >>draft-ietf-lsr-isis-flood-reflection/
> >>
> >>
> >>
> >>and
> >>
> >>
> >>
> >>https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-area-proxy/
> >>
> >>
> >>
> >>Both of them discuss in their respective introductions the
> >>motivation – which is to address scaling issues in deployment
> >>scenarios where the existing IS-IS hierarchy is being asked to
> >>“stand on its head” i.e., interconnection between different L1
> >>areas is not to be achieved by utilizing an L2 backbone – rather
> >>it is the L1 areas themselves which are required to be used for
> >>interconnection of sites (e.g., two datacenters) and the scaling
> >>properties of the existing protocol hierarchy when used in this
> >>way are not attractive.
> >>
> >>
> >>
> >>I find no technical basis on which to choose between the two
> >>proposed solutions – so in my mind a last call for
> >>“Flood-Reflection” presupposes a last call for “Area Proxy” – and
> >>therein lies my angst.
> >>
> >>The end result will be that multiple incompatible solutions 

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

[Acee Lindem (acee)]

I'll defer to Tony but my understanding is that there could be suboptimal paths 
if there are both Level-1 and Level-2 paths but not loops. 
Thanks,
Acee

On 1/10/22, 11:38 AM, "Aijun Wang"  wrote:

But there are unsolved issues for this draft—— BGP has loop prevention 
mechanism, current flood reflection draft hasn’t, the operator must  design the 
topology/link metric  carefully to avoid the possible loop.

Aijun Wang
China Telecom

> On Jan 11, 2022, at 00:10, Acee Lindem (acee) 
 wrote:
> 
> Speaking as a WG member, these documents are all "experimental" and, IMO, 
it would really stifle innovation to require a single experimental solution. 
We've never done that in the past. Also,  while all three solutions have the 
goal of reducing control plane overhead when using Level-1 areas as a transit, 
the flood reflection draft solves the problem with a different approach than 
the area proxy and TTZ drafts.  While the latter two focus on abstracting the 
transit area, the former also focusing on reducing the number of adjacencies 
and allows the reflector to be out of the data path (similar to the 
standardized and widely deployed BGP route reflection) I see no need to 
differentiate to stall advancement. 
> 
> Thanks,
> Acee
> 
> On 1/3/22, 7:05 AM, "Christian Hopps"  wrote:
> 
> 
>Tony Przygienda  writes:
> 
>> One thing Les is missing here is that proxy & reflection present in
>> terms of deployment requirements and ultimate properties very
>> different engineering & operational trade-offs. Different customers
>> follow different philosophies here IME
>> 
>> So we are not strictly standardizing here 2 solutions for the same
>> thing, we are standardizing two solutions that meet very different
>> deployment and operational requirements albeit from 20K feet view all
>> that stuff looks the same of course as any other thing does ... 
> 
>Have we captured these "different deployment and operational 
requirements" anywhere? I think might be very useful...
> 
>Thanks,
>Chris.
>[as wg member]
> 
> 
>> -- tony
>> 
>> On Tue, Dec 7, 2021 at 7:17 PM Les Ginsberg (ginsberg) > 40cisco@dmarc.ietf.org> wrote:
>> 
>> 
>>When I look at this request, I see it in a larger context.
>> 
>> 
>> 
>>There are two drafts which attempt to address the same problem in
>>very different ways:
>> 
>> 
>> 
>>https://datatracker.ietf.org/doc/
>>draft-ietf-lsr-isis-flood-reflection/
>> 
>> 
>> 
>>and
>> 
>> 
>> 
>>https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-area-proxy/
>> 
>> 
>> 
>>Both of them discuss in their respective introductions the
>>motivation – which is to address scaling issues in deployment
>>scenarios where the existing IS-IS hierarchy is being asked to
>>“stand on its head” i.e., interconnection between different L1
>>areas is not to be achieved by utilizing an L2 backbone – rather
>>it is the L1 areas themselves which are required to be used for
>>interconnection of sites (e.g., two datacenters) and the scaling
>>properties of the existing protocol hierarchy when used in this
>>way are not attractive.
>> 
>> 
>> 
>>I find no technical basis on which to choose between the two
>>proposed solutions – so in my mind a last call for
>>“Flood-Reflection” presupposes a last call for “Area Proxy” – and
>>therein lies my angst.
>> 
>>The end result will be that multiple incompatible solutions to
>>the same problem will be defined. It will then be left to
>>customers to try to determine which of the solutions seems best
>>to them – which in turn will put the onus on vendors to support
>>both solutions (depending on the set of customers each vendor
>>supports).
>> 
>>This – to me – represents an utter failure of the standards
>>process. We are reduced to a set of constituencies which never
>>find common ground – the end result being sub-optimal for the
>>industry as a whole.
>> 
>> 
>> 
>>It seems to me that the proper role of the WG is to address the
>>big questions first:
>> 
>> 
>> 
>>1)Is this a problem which needs to be solved by link-state
>>protocols?
>> 
>>We certainly have folks who are clever enough to define solutions
>>– the two drafts are a proof of that.
>> 
>>But whether this is a wise use of the IGPs I think has never been
>>fully discussed/answered.
>> 
>>Relevant to this point is past experience with virtual links in
>>OSPF – use of which was problematic and which has largely fallen
>>out of use.
   

Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

[Aijun Wang]

Hi, Les:

Aijun Wang
China Telecom

> On Jan 10, 2022, at 23:48, Les Ginsberg (ginsberg) 
>  wrote:
> 
> 
> Linda –
>  
> I believe the most valuable feedback you received during your presentation at 
> IETF 112 is that using IGPs likely will not meet the deployment requirements.
> In particular, persistence of a given client session with a given application 
> server is likely a requirement which will not be achieved using an IGP based 
> solution.
[WAJ] The main aim of draft is to how assist the router to select the most 
appropriate application servers, with regards to the metrics that is not 
limited to the link cost.
> Also, the modification of IGP metrics will likely introduce unwanted 
> oscillation in traffic flows.

[WAJ] These metrics are associated with the links that doesn’t participate in 
the IGP, that is, they are the characteristics of the “Stub-Link”, then only 
the application that utilize such information will be influenced, or optimized.

>  
> I suggest you start with a clean slate – focus on defining what all the 
> requirements are without regard to what mechanism/protocol might be used – 
> and then think about defining a solution which meets these requirements.
> I think you will end up NOT using routing protocols at all

[WAJ] Selecting the most appropriate/optimized application server should base 
on the topology information which is routing protocol related.
>  
> On a more mundane note, the section describing the new IS-IS advertisement 
> (https://datatracker.ietf.org/doc/html/draft-dunbar-lsr-5g-edge-compute-03#section-6
>  ) is – to put it bluntly – a mess! 😊
> TLVs 128 and 130 are legacy TLVs which don’t support sub-TLVs – they should 
> not be mentioned at all.
> And the encoding diagram shows a “prefix” being advertised in the new sub-TLV 
> when it should not. The prefix has already been advertised in the parent TLV.

[WAJ] Actually, the most appropriate place to convey such information is via 
the Stub-Link TLV/Sub-TLV that defined in 
https://datatracker.ietf.org/doc/html/draft-wang-lsr-stub-link-attributes-02

>  
>Les
>  
>  
> From: Lsr  On Behalf Of Linda Dunbar
> Sent: Friday, January 7, 2022 11:29 AM
> To: lsr@ietf.org
> Subject: [Lsr] Seeking feedback to the revised 
> draft-dunbar-lsr-5g-edge-compute
>  
> LSR experts,
>  
> We have revised the draft-dunbar-lsr-5g-edge-compute to address the comments 
> and feedback from IETF 112.
> https://datatracker.ietf.org/doc/draft-dunbar-lsr-5g-edge-compute/
>  
> In a nutshell, the proposed solution
> advertises the “Site-Cost” via IP prefix reachability TLV associated with the 
> (anycast) prefix
> The  Site-Cost is the aggregated cost associated with an Edge Compute (EC) 
> server (i.e., ANYCAST prefix), computed based on the IP layer related metrics 
> for the prefix, such as Load Measurement, the Capacity Index, the Preference 
> Index, and other constraints by a consistent algorithm across all egress 
> routers to which the EC servers are attached.
>  
> Uses a Flag in the Flexible Algorithm TLV to indicate that  “site-cost” needs 
> to be included for the constrained SPF to reach the Prefix
>  
>  
> Any feedbacks? Or suggestions?
>  
> Thank you very much
> Linda
> ___
> 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 Last Call fo "IS-IS Flood Reflection"-draft-ietf-lsr-isis-flood-reflection-05

[Aijun Wang]

But there are unsolved issues for this draft—— BGP has loop prevention 
mechanism, current flood reflection draft hasn’t, the operator must  design the 
topology/link metric  carefully to avoid the possible loop.

Aijun Wang
China Telecom

> On Jan 11, 2022, at 00:10, Acee Lindem (acee) 
>  wrote:
> 
> Speaking as a WG member, these documents are all "experimental" and, IMO, it 
> would really stifle innovation to require a single experimental solution. 
> We've never done that in the past. Also,  while all three solutions have the 
> goal of reducing control plane overhead when using Level-1 areas as a 
> transit, the flood reflection draft solves the problem with a different 
> approach than the area proxy and TTZ drafts.  While the latter two focus on 
> abstracting the transit area, the former also focusing on reducing the number 
> of adjacencies and allows the reflector to be out of the data path (similar 
> to the standardized and widely deployed BGP route reflection) I see no need 
> to differentiate to stall advancement. 
> 
> Thanks,
> Acee
> 
> On 1/3/22, 7:05 AM, "Christian Hopps"  wrote:
> 
> 
>Tony Przygienda  writes:
> 
>> One thing Les is missing here is that proxy & reflection present in
>> terms of deployment requirements and ultimate properties very
>> different engineering & operational trade-offs. Different customers
>> follow different philosophies here IME
>> 
>> So we are not strictly standardizing here 2 solutions for the same
>> thing, we are standardizing two solutions that meet very different
>> deployment and operational requirements albeit from 20K feet view all
>> that stuff looks the same of course as any other thing does ... 
> 
>Have we captured these "different deployment and operational requirements" 
> anywhere? I think might be very useful...
> 
>Thanks,
>Chris.
>[as wg member]
> 
> 
>> -- tony
>> 
>> On Tue, Dec 7, 2021 at 7:17 PM Les Ginsberg (ginsberg) > 40cisco@dmarc.ietf.org> wrote:
>> 
>> 
>>When I look at this request, I see it in a larger context.
>> 
>> 
>> 
>>There are two drafts which attempt to address the same problem in
>>very different ways:
>> 
>> 
>> 
>>https://datatracker.ietf.org/doc/
>>draft-ietf-lsr-isis-flood-reflection/
>> 
>> 
>> 
>>and
>> 
>> 
>> 
>>https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-area-proxy/
>> 
>> 
>> 
>>Both of them discuss in their respective introductions the
>>motivation – which is to address scaling issues in deployment
>>scenarios where the existing IS-IS hierarchy is being asked to
>>“stand on its head” i.e., interconnection between different L1
>>areas is not to be achieved by utilizing an L2 backbone – rather
>>it is the L1 areas themselves which are required to be used for
>>interconnection of sites (e.g., two datacenters) and the scaling
>>properties of the existing protocol hierarchy when used in this
>>way are not attractive.
>> 
>> 
>> 
>>I find no technical basis on which to choose between the two
>>proposed solutions – so in my mind a last call for
>>“Flood-Reflection” presupposes a last call for “Area Proxy” – and
>>therein lies my angst.
>> 
>>The end result will be that multiple incompatible solutions to
>>the same problem will be defined. It will then be left to
>>customers to try to determine which of the solutions seems best
>>to them – which in turn will put the onus on vendors to support
>>both solutions (depending on the set of customers each vendor
>>supports).
>> 
>>This – to me – represents an utter failure of the standards
>>process. We are reduced to a set of constituencies which never
>>find common ground – the end result being sub-optimal for the
>>industry as a whole.
>> 
>> 
>> 
>>It seems to me that the proper role of the WG is to address the
>>big questions first:
>> 
>> 
>> 
>>1)Is this a problem which needs to be solved by link-state
>>protocols?
>> 
>>We certainly have folks who are clever enough to define solutions
>>– the two drafts are a proof of that.
>> 
>>But whether this is a wise use of the IGPs I think has never been
>>fully discussed/answered.
>> 
>>Relevant to this point is past experience with virtual links in
>>OSPF – use of which was problematic and which has largely fallen
>>out of use.
>> 
>>Also, many datacenters use BGP (w or w/o IGP) and therefore have
>>other ways to address such issues.
>> 
>>Although I am familiar with the “one protocol is simpler”
>>argument, whether that justifies altering the IGPs in any of the
>>proposed ways is still an important question to discuss.
>> 
>> 
>> 
>>2)If link state protocols do need to solve this problem, what is
>>the preferred way to do that?
>> 
>>This requires meaningful dialogue and a willingness to engage on
>>complex technical issues.
>> 
>> 
>> 
>>The alternative is to do what we seem to be d

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[Aijun Wang]

Hi, Les:

Wish the below explanation can correct your understanding of this draft, and 
also your conclusions.

Aijun Wang
China Telecom

> On Jan 10, 2022, at 23:13, Les Ginsberg (ginsberg) 
>  wrote:
> 
> I oppose WG adoption of this draft.
> 
> In addition to my comments below, I am in agreement with the points made by 
> Peter and Shraddha previously in this thread.
> 
> My comments below are in the context of IS-IS/RFC5316, but I believe are 
> equally valid in the context of OSPF/RFC5392.
> 
> There are two types of new information the draft proposes to advertise under 
> TLV 141:
> 
> 1)Identifying a link by the prefix locally configured on the link rather than 
> by the local/remote addresses.
> 
> The motivation for this addition seems to be to avoid the need for the 
> operator to locally configure the remote address.
[WAJ] For inter-AS stub link type, it is. For other stub link type, it isn’t. 

> But I think this is not a desirable change.
> 
> As pointed out by Peter, this does not work for unnumbered links. (It also 
> would not work for Pt-2-MP links). The authors assert that it is unlikely 
> that unnumbered links would be used in the expected use cases - but I do not 
> find this argument convincing.
[WAJ] Is there any operator adopt unnumbered link at its boundary network? 
There is even very rare case for the unnumbered interface be used within the 
operator network. And, with the IPv6 deployment, what is the usages of 
unnumbered interface? Won’t it be depreciated in future? Very curious you and 
Peter stick to this point, but not considering its wider use scenarios.

> Even if unnumbered links are not currently being used, the restriction that 
> they could not be used in the future seems highly undesirable.

[WAJ] Would like to hear the reason and scenarios that the unnumbered interface 
will be used in future. I think it should be deprecated instead.

> It would put us in the position of having to revise this functionality in the 
> future in an incompatible way in order to add such support. This is a bad 
> design choice.

[WAJ] We should keep the trend, not stick to the obsolete obstacles.

> 
> Aside: The assertion that unnumbered links will not be used seems at odds 
> with the inclusion of "loopback" as a link type.

[WAJ] The loop back address won’t borrow address from others. Or if you 
consider it maybe, please give the reason.

> More on that below.
> 
> Also, as the draft builds on top of existing RFC5316 functionality, it is 
> still required to advertise remote AS Number and Remote ASBR ID as well as 
> remote Router IDs (IPv4 and/or IPv6) (see 
> https://datatracker.ietf.org/doc/html/rfc5316#section-3.3 )

[WAJ] No. With the newly defined TLV/sun-TLV, we need not configured the above 
information manually then. And for other stub link type(for example, the edge 
router that connects the server) there will be no remote-AS, no remote ASBR, 
how can you configure them?

> - all of which still need to be locally configured since there is no IGP 
> operating on the link. So the suggestion that not having to configure the 
> remote link address provides significant simplification in deployment does 
> not stand up to scrutiny.

[WAJ] Please see the previous explanation.
> 
> 2)New link type information (AS boundary link/Loopback link/Vlan interface 
> link) to be advertised
> 
> There is no mention in the draft as to how this information will be used.
[WAJ] The information about various stub link type is mainly for the 
controller. If necessary, we can add some potential use cases for such type 
information, but this is not the main points of this draft.

> Indeed, I do not even know what a "loopback link" is unless it is an 
> unnumbered link to which a loopback address has been associated - which makes 
> me wonder why the authors have dismissed the use of "unnumbered" in 
> deployments.

[WAJ] Actually, it is loopback interface, not loopback link, which you have 
imaged that one unnumbered link borrows the address from the loopback interface.
The loopback interface is one type of Stub Link, which has the characters that 
doesn’t send out IGP LSA.


> 
> I therefore conclude that existing functionality defined in RFC 5316/RFC5392 
> is sufficient and there is no need for the extensions defined in this draft.
[WAJ] Wish the above explanation can correct your conclusions.

> 
>Les
> 
>> -Original Message-
>> From: Lsr  On Behalf Of Christian Hopps
>> Sent: Monday, January 3, 2022 10:59 PM
>> To: lsr@ietf.org
>> Cc: lsr-cha...@ietf.org; lsr-...@ietf.org; cho...@chopps.org; draft-wang-lsr-
>> stub-link-attribu...@ietf.org
>> Subject: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02
>> 
>> Hi Folks,
>> 
>> This begins a 2 week WG Adoption Call for the following draft:
>> 
>> https://datatracker.ietf.org/doc/draft-wang-lsr-stub-link-attributes/
>> 
>> Please indicate your support or objections by January 18th, 2022.
>> 
>> Authors, please respond to t

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

[Acee Lindem (acee)]

Speaking as a WG member, these documents are all "experimental" and, IMO, it 
would really stifle innovation to require a single experimental solution. We've 
never done that in the past. Also,  while all three solutions have the goal of 
reducing control plane overhead when using Level-1 areas as a transit, the 
flood reflection draft solves the problem with a different approach than the 
area proxy and TTZ drafts.  While the latter two focus on abstracting the 
transit area, the former also focusing on reducing the number of adjacencies 
and allows the reflector to be out of the data path (similar to the 
standardized and widely deployed BGP route reflection) I see no need to 
differentiate to stall advancement. 

Thanks,
Acee

On 1/3/22, 7:05 AM, "Christian Hopps"  wrote:


Tony Przygienda  writes:

> One thing Les is missing here is that proxy & reflection present in
> terms of deployment requirements and ultimate properties very
> different engineering & operational trade-offs. Different customers
> follow different philosophies here IME
>
> So we are not strictly standardizing here 2 solutions for the same
> thing, we are standardizing two solutions that meet very different
> deployment and operational requirements albeit from 20K feet view all
> that stuff looks the same of course as any other thing does ... 

Have we captured these "different deployment and operational requirements" 
anywhere? I think might be very useful...

Thanks,
Chris.
[as wg member]


> -- tony
>
> On Tue, Dec 7, 2021 at 7:17 PM Les Ginsberg (ginsberg)  40cisco@dmarc.ietf.org> wrote:
>
>
> When I look at this request, I see it in a larger context.
>
>  
>
> There are two drafts which attempt to address the same problem in
> very different ways:
>
>  
>
> https://datatracker.ietf.org/doc/
> draft-ietf-lsr-isis-flood-reflection/
>
>  
>
> and
>
>  
>
> https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-area-proxy/
>
>  
>
> Both of them discuss in their respective introductions the
> motivation – which is to address scaling issues in deployment
> scenarios where the existing IS-IS hierarchy is being asked to
> “stand on its head” i.e., interconnection between different L1
> areas is not to be achieved by utilizing an L2 backbone – rather
> it is the L1 areas themselves which are required to be used for
> interconnection of sites (e.g., two datacenters) and the scaling
> properties of the existing protocol hierarchy when used in this
> way are not attractive.
>
>  
>
> I find no technical basis on which to choose between the two
> proposed solutions – so in my mind a last call for
> “Flood-Reflection” presupposes a last call for “Area Proxy” – and
> therein lies my angst.
>
> The end result will be that multiple incompatible solutions to
> the same problem will be defined. It will then be left to
> customers to try to determine which of the solutions seems best
> to them – which in turn will put the onus on vendors to support
> both solutions (depending on the set of customers each vendor
> supports).
>
> This – to me – represents an utter failure of the standards
> process. We are reduced to a set of constituencies which never
> find common ground – the end result being sub-optimal for the
> industry as a whole.
>
>  
>
> It seems to me that the proper role of the WG is to address the
> big questions first:
>
>  
>
> 1)Is this a problem which needs to be solved by link-state
> protocols?
>
> We certainly have folks who are clever enough to define solutions
> – the two drafts are a proof of that.
>
> But whether this is a wise use of the IGPs I think has never been
> fully discussed/answered.
>
> Relevant to this point is past experience with virtual links in
> OSPF – use of which was problematic and which has largely fallen
> out of use.
>
> Also, many datacenters use BGP (w or w/o IGP) and therefore have
> other ways to address such issues.
>
> Although I am familiar with the “one protocol is simpler”
> argument, whether that justifies altering the IGPs in any of the
> proposed ways is still an important question to discuss.
>
>  
>
> 2)If link state protocols do need to solve this problem, what is
> the preferred way to do that?
>
> This requires meaningful dialogue and a willingness to engage on
> complex technical issues.
>
>  
>
> The alternative is to 

Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

[Les Ginsberg (ginsberg)]

Linda –

I believe the most valuable feedback you received during your presentation at 
IETF 112 is that using IGPs likely will not meet the deployment requirements.
In particular, persistence of a given client session with a given application 
server is likely a requirement which will not be achieved using an IGP based 
solution.
Also, the modification of IGP metrics will likely introduce unwanted 
oscillation in traffic flows.

I suggest you start with a clean slate – focus on defining what all the 
requirements are without regard to what mechanism/protocol might be used – and 
then think about defining a solution which meets these requirements.
I think you will end up NOT using routing protocols at all.

On a more mundane note, the section describing the new IS-IS advertisement 
(https://datatracker.ietf.org/doc/html/draft-dunbar-lsr-5g-edge-compute-03#section-6
 ) is – to put it bluntly – a mess! 😊
TLVs 128 and 130 are legacy TLVs which don’t support sub-TLVs – they should not 
be mentioned at all.
And the encoding diagram shows a “prefix” being advertised in the new sub-TLV 
when it should not. The prefix has already been advertised in the parent TLV.

   Les


From: Lsr  On Behalf Of Linda Dunbar
Sent: Friday, January 7, 2022 11:29 AM
To: lsr@ietf.org
Subject: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

LSR experts,

We have revised the draft-dunbar-lsr-5g-edge-compute to address the comments 
and feedback from IETF 112.
https://datatracker.ietf.org/doc/draft-dunbar-lsr-5g-edge-compute/

In a nutshell, the proposed solution

  *   advertises the “Site-Cost” via IP prefix reachability TLV associated with 
the (anycast) prefix
The  Site-Cost is the aggregated cost associated with an Edge Compute (EC) 
server (i.e., ANYCAST prefix), computed based on the IP layer related metrics 
for the prefix, such as Load Measurement, the Capacity Index, the Preference 
Index, and other constraints by a consistent algorithm across all egress 
routers to which the EC servers are attached.


  *   Uses a Flag in the Flexible Algorithm TLV to indicate that  “site-cost” 
needs to be included for the constrained SPF to reach the Prefix


Any feedbacks? Or suggestions?

Thank you very much
Linda
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Les Ginsberg (ginsberg)]

+1
Hopefully this would help us understand the use cases better and why/if more 
than one solution might be appropriate.

Can’t happen too soon IMO. 😊

Les

From: Jeff Tantsura 
Sent: Monday, January 3, 2022 11:21 AM
To: Tony Przygienda 
Cc: Christian Hopps ; Les Ginsberg (ginsberg) 
; lsr ; Acee Lindem (acee) 
Subject: Re: [Lsr] WG Last Call fo "IS-IS Flood Reflection" 
-draft-ietf-lsr-isis-flood-reflection-05

I’d very much support applicability draft work!
Cheers,
Jeff


On Jan 3, 2022, at 08:05, Tony Przygienda 
mailto:tonysi...@gmail.com>> wrote:

AFAIS this is a "operational and deployment" or "applicability" draft and not 
part of a protocol specification. But yes, such a draft would have value AFAIS, 
especially if it deals with both abstract node & reflection in one as available 
 solutions. More than happy to attack that once the specs have moved to 
publication.

-- tony

On Mon, Jan 3, 2022 at 1:05 PM Christian Hopps 
mailto:cho...@chopps.org>> wrote:

Tony Przygienda mailto:tonysi...@gmail.com>> writes:

> One thing Les is missing here is that proxy & reflection present in
> terms of deployment requirements and ultimate properties very
> different engineering & operational trade-offs. Different customers
> follow different philosophies here IME
>
> So we are not strictly standardizing here 2 solutions for the same
> thing, we are standardizing two solutions that meet very different
> deployment and operational requirements albeit from 20K feet view all
> that stuff looks the same of course as any other thing does ...

Have we captured these "different deployment and operational requirements" 
anywhere? I think might be very useful...

Thanks,
Chris.
[as wg member]


> -- tony
>
> On Tue, Dec 7, 2021 at 7:17 PM Les Ginsberg (ginsberg)  40cisco@dmarc.ietf.org> wrote:
>
>
> When I look at this request, I see it in a larger context.
>
>
>
> There are two drafts which attempt to address the same problem in
> very different ways:
>
>
>
> https://datatracker.ietf.org/doc/
> draft-ietf-lsr-isis-flood-reflection/
>
>
>
> and
>
>
>
> https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-area-proxy/
>
>
>
> Both of them discuss in their respective introductions the
> motivation – which is to address scaling issues in deployment
> scenarios where the existing IS-IS hierarchy is being asked to
> “stand on its head” i.e., interconnection between different L1
> areas is not to be achieved by utilizing an L2 backbone – rather
> it is the L1 areas themselves which are required to be used for
> interconnection of sites (e.g., two datacenters) and the scaling
> properties of the existing protocol hierarchy when used in this
> way are not attractive.
>
>
>
> I find no technical basis on which to choose between the two
> proposed solutions – so in my mind a last call for
> “Flood-Reflection” presupposes a last call for “Area Proxy” – and
> therein lies my angst.
>
> The end result will be that multiple incompatible solutions to
> the same problem will be defined. It will then be left to
> customers to try to determine which of the solutions seems best
> to them – which in turn will put the onus on vendors to support
> both solutions (depending on the set of customers each vendor
> supports).
>
> This – to me – represents an utter failure of the standards
> process. We are reduced to a set of constituencies which never
> find common ground – the end result being sub-optimal for the
> industry as a whole.
>
>
>
> It seems to me that the proper role of the WG is to address the
> big questions first:
>
>
>
> 1)Is this a problem which needs to be solved by link-state
> protocols?
>
> We certainly have folks who are clever enough to define solutions
> – the two drafts are a proof of that.
>
> But whether this is a wise use of the IGPs I think has never been
> fully discussed/answered.
>
> Relevant to this point is past experience with virtual links in
> OSPF – use of which was problematic and which has largely fallen
> out of use.
>
> Also, many datacenters use BGP (w or w/o IGP) and therefore have
> other ways to address such issues.
>
> Although I am familiar with the “one protocol is simpler”
> argument, whether that justifies altering the IGPs in any of the
> proposed ways is still an important question to discuss.
>
>
>
> 2)If link state protocols do need to solve this problem, what is
> the preferred way to do that?
>
> This requires meaningful dialogue and a willingness to engage on
> complex technical issues.
>
>
>
> The alternative is to do what we seem to be doing – allowing
> multiple solutions to move forward largely without comment. In
> which case I see no basis on which to object – anyone who can
> demonstrate a deployment case should then be allowed 

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[Les Ginsberg (ginsberg)]

I oppose WG adoption of this draft.

In addition to my comments below, I am in agreement with the points made by 
Peter and Shraddha previously in this thread.

My comments below are in the context of IS-IS/RFC5316, but I believe are 
equally valid in the context of OSPF/RFC5392.

There are two types of new information the draft proposes to advertise under 
TLV 141:

1)Identifying a link by the prefix locally configured on the link rather than 
by the local/remote addresses.

The motivation for this addition seems to be to avoid the need for the operator 
to locally configure the remote address. But I think this is not a desirable 
change.

As pointed out by Peter, this does not work for unnumbered links. (It also 
would not work for Pt-2-MP links). The authors assert that it is unlikely that 
unnumbered links would be used in the expected use cases - but I do not find 
this argument convincing. Even if unnumbered links are not currently being 
used, the restriction that they could not be used in the future seems highly 
undesirable. It would put us in the position of having to revise this 
functionality in the future in an incompatible way in order to add such 
support. This is a bad design choice.

Aside: The assertion that unnumbered links will not be used seems at odds with 
the inclusion of "loopback" as a link type. More on that below.

Also, as the draft builds on top of existing RFC5316 functionality, it is still 
required to advertise remote AS Number and Remote ASBR ID as well as remote 
Router IDs (IPv4 and/or IPv6) (see 
https://datatracker.ietf.org/doc/html/rfc5316#section-3.3 ) - all of which 
still need to be locally configured since there is no IGP operating on the 
link. So the suggestion that not having to configure the remote link address 
provides significant simplification in deployment does not stand up to scrutiny.

2)New link type information (AS boundary link/Loopback link/Vlan interface 
link) to be advertised

There is no mention in the draft as to how this information will be used. 
Indeed, I do not even know what a "loopback link" is unless it is an unnumbered 
link to which a loopback address has been associated - which makes me wonder 
why the authors have dismissed the use of "unnumbered" in deployments.

I therefore conclude that existing functionality defined in RFC 5316/RFC5392 is 
sufficient and there is no need for the extensions defined in this draft.

Les

> -Original Message-
> From: Lsr  On Behalf Of Christian Hopps
> Sent: Monday, January 3, 2022 10:59 PM
> To: lsr@ietf.org
> Cc: lsr-cha...@ietf.org; lsr-...@ietf.org; cho...@chopps.org; draft-wang-lsr-
> stub-link-attribu...@ietf.org
> Subject: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02
> 
> Hi Folks,
> 
> This begins a 2 week WG Adoption Call for the following draft:
> 
> https://datatracker.ietf.org/doc/draft-wang-lsr-stub-link-attributes/
> 
> Please indicate your support or objections by January 18th, 2022.
> 
> Authors, please respond to the list indicating whether you are aware of any
> IPR that applies to these drafts.
> 
> Thanks,
> Chris.
> 
> ___
> 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