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

[Aijun Wang]

Hi, Les:

 

IGP is now considering the dynamic metric(for example, the delay metric within 
flexalgo), not only the static metic.

The proposed “AggCost” is also one kind of dynamic metric. It can assist the 
new clients to avoid the already heavy-burden application server. 

With the “Flow Affinity to an ANYCAST server” capabilities that mentioned in 
https://datatracker.ietf.org/doc/html/draft-dunbar-lsr-5g-edge-compute-03#section-13,
 the oscillation phenomena can be mitigated for the existing client/server flow.

Or else, all the dynamic cost can’t be used within the IGP.

 

Best Regards

 

Aijun Wang

China Telecom

 

From: lsr-boun...@ietf.org  On Behalf Of Les Ginsberg 
(ginsberg)
Sent: Wednesday, January 12, 2022 1:14 PM
To: Linda Dunbar ; lsr@ietf.org
Subject: Re: [Lsr] Seeking feedback to the revised 
draft-dunbar-lsr-5g-edge-compute

 

Linda -

 

From: Linda Dunbar mailto:linda.dun...@futurewei.com> > 
Sent: Tuesday, January 11, 2022 7:47 PM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com> >; 
lsr@ietf.org  
Subject: RE: Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

 

Les, 

 

Starting with a clean slate: 

 

Problem: 

Most applications are instantiated at multiple locations to achieve optimal 
performance. Traditional shortest path to reach one single destination is 
making load balancers the bottleneck, or pushing the traffic management 
responsibility to DNS.

 

>From Underlay IP network perspective, connecting applications with instances 
>instantiated at multiple locations is like having multiple Egress routers 
>towards the same destination (ANYCAST).   

For example, to reach an application B instantiated at B1, B2, B3, which 
corresponds to egress ER1, ER2, ER3 respectively,  the Shortest Path 
Computation need to include both routing distance and the resources attached to 
ER1, ER2, ER3. i.e. the cost in the ECMP (Equal Cost Multiple Path) should 
include both the routing distances and the resource cost.

 

[LES:] What I am saying is that you need to do load balancing at the 
Application Layer – not at Layer 3.

IGPs can provide you with paths to the set of Application servers that share 
the same anycast address – but dynamically manipulating the IGP metrics (even 
this new metric you propose) – will give you oscillation – not application 
server load balancing.

 

 

Suggested solution:

Using TLV 128 and 130 to carry the “aggregated site cost” (associated t the 
Egress router) is suggested by Peter Psenak (through the offline discussion 
prior to the IETF 112, see the attached email thread)

 

There is only one sentence in the Section 6, which is per Peter’s suggestion: 

“Aggregated Cost appended to the IP Reachability TLV: 128, 130, or 135.”

 

Why do you say it is a “mess”?   I felt your words are more like personal 
attack than giving a constructive suggestion. 

 

[LES:] Apologies if you were offended – I did put a smiley in to try give it a 
light touch – but I should know better than to be so flippant in this context.

My point is that in what is indeed a very small section there are multiple 
errors:

 

·   The TLVs mentioned are not correct

·   The diagram with the proposed sub-TLV encoding incorrectly includes the 
prefix. The prefix is already present in the parent TLV – it should not be 
present in the sub-TLV. You have this correct in Section 5 for OSPF.

 

But these points can be ignored because I believe using the IGPs isn’t the 
right solution and so we won’t need these new sub-TLVs anyway.

 

I don’t know what comment from Peter you are referring to – but if he mentioned 
TLVs 128/130 I will take that up with him – he knows better. 

I do recall that in an earlier version of the draft you were proposing to 
advertise the new metric as part of a link advertisement (TLV 22) – and he was 
quite correct in directing you to use Prefix Reachability advertisements (like 
TLV 135).

 

But please focus on looking at a non-IGP solution – that is what you need to do 
IMO.

 

   Les

 

 

 

 

Linda

 

 

 

From: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com> > 
Sent: Monday, January 10, 2022 9:48 AM
To: Linda Dunbar mailto:linda.dun...@futurewei.com> >; lsr@ietf.org  
Subject: RE: Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

 

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 

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

[Les Ginsberg (ginsberg)]

Linda -

From: Linda Dunbar 
Sent: Tuesday, January 11, 2022 7:47 PM
To: Les Ginsberg (ginsberg) ; lsr@ietf.org
Subject: RE: Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

Les,

Starting with a clean slate:

Problem:
Most applications are instantiated at multiple locations to achieve optimal 
performance. Traditional shortest path to reach one single destination is 
making load balancers the bottleneck, or pushing the traffic management 
responsibility to DNS.

From Underlay IP network perspective, connecting applications with instances 
instantiated at multiple locations is like having multiple Egress routers 
towards the same destination (ANYCAST).
For example, to reach an application B instantiated at B1, B2, B3, which 
corresponds to egress ER1, ER2, ER3 respectively,  the Shortest Path 
Computation need to include both routing distance and the resources attached to 
ER1, ER2, ER3. i.e. the cost in the ECMP (Equal Cost Multiple Path) should 
include both the routing distances and the resource cost.

[LES:] What I am saying is that you need to do load balancing at the 
Application Layer – not at Layer 3.
IGPs can provide you with paths to the set of Application servers that share 
the same anycast address – but dynamically manipulating the IGP metrics (even 
this new metric you propose) – will give you oscillation – not application 
server load balancing.


Suggested solution:
Using TLV 128 and 130 to carry the “aggregated site cost” (associated t the 
Egress router) is suggested by Peter Psenak (through the offline discussion 
prior to the IETF 112, see the attached email thread)

There is only one sentence in the Section 6, which is per Peter’s suggestion:
“Aggregated Cost appended to the IP Reachability TLV: 128, 130, or 135.”

Why do you say it is a “mess”?   I felt your words are more like personal 
attack than giving a constructive suggestion.

[LES:] Apologies if you were offended – I did put a smiley in to try give it a 
light touch – but I should know better than to be so flippant in this context.
My point is that in what is indeed a very small section there are multiple 
errors:


  *   The TLVs mentioned are not correct
  *   The diagram with the proposed sub-TLV encoding incorrectly includes the 
prefix. The prefix is already present in the parent TLV – it should not be 
present in the sub-TLV. You have this correct in Section 5 for OSPF.

But these points can be ignored because I believe using the IGPs isn’t the 
right solution and so we won’t need these new sub-TLVs anyway.

I don’t know what comment from Peter you are referring to – but if he mentioned 
TLVs 128/130 I will take that up with him – he knows better. 
I do recall that in an earlier version of the draft you were proposing to 
advertise the new metric as part of a link advertisement (TLV 22) – and he was 
quite correct in directing you to use Prefix Reachability advertisements (like 
TLV 135).

But please focus on looking at a non-IGP solution – that is what you need to do 
IMO.

   Les




Linda



From: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Sent: Monday, January 10, 2022 9:48 AM
To: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>; 
lsr@ietf.org
Subject: RE: Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

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 mailto:lsr-boun...@ietf.org>> On Behalf Of 

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

[Linda Dunbar]

Les,

Starting with a clean slate:

Problem:
Most applications are instantiated at multiple locations to achieve optimal 
performance. Traditional shortest path to reach one single destination is 
making load balancers the bottleneck, or pushing the traffic management 
responsibility to DNS.

From Underlay IP network perspective, connecting applications with instances 
instantiated at multiple locations is like having multiple Egress routers 
towards the same destination (ANYCAST).
For example, to reach an application B instantiated at B1, B2, B3, which 
corresponds to egress ER1, ER2, ER3 respectively,  the Shortest Path 
Computation need to include both routing distance and the resources attached to 
ER1, ER2, ER3. i.e. the cost in the ECMP (Equal Cost Multiple Path) should 
include both the routing distances and the resource cost.

Suggested solution:
Using TLV 128 and 130 to carry the “aggregated site cost” (associated t the 
Egress router) is suggested by Peter Psenak (through the offline discussion 
prior to the IETF 112, see the attached email thread)

There is only one sentence in the Section 6, which is per Peter’s suggestion:
“Aggregated Cost appended to the IP Reachability TLV: 128, 130, or 135.”

Why do you say it is a “mess”?   I felt your words are more like personal 
attack than giving a constructive suggestion.

Linda



From: Les Ginsberg (ginsberg) 
Sent: Monday, January 10, 2022 9:48 AM
To: Linda Dunbar ; lsr@ietf.org
Subject: RE: Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

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 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
--- Begin Message ---
Linda,

On 09/11/2021 18:09, Linda Dunbar wrote:
> Peter,
> You suggested creating a new sub-TLV for E-Intra-Area-Prefix-LSA, 
> E-Inter-Area-Prefix-LSA, E-AS-External-LSA, and E-Type-7-LSA [RFC8362].
> But if we use the original Intra/Inter-area-prefix LSA [RFC5340], we can 
> use 

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

[Aijun Wang]

Hi, Tony:

-Original Message-
From: lsr-boun...@ietf.org  On Behalf Of Tony Li
Sent: Wednesday, January 12, 2022 4:24 AM
To: Aijun Wang 
Cc: lsr ; lsr-...@ietf.org; Christian Hopps ; 
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


Hi Aijun,

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


This link doesn’t work.
[WAJ] I checked the above link again and it work from my side. Anyway, I have 
copied the key points of the above link in the following sentences.


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



It would seem to me that if you re-used existing TLVs, you could be adding 
subTLVs to carry any additional information.  This would probably be a lot 
cleaner.
[WAJ] Then we should update RFC5316, RFC5292, RFC3630 etc. It may also 
influence the existing deployment. 
There are also other situations that the RFC5316 and RFC5292 does not cover, 
for example, for the associated information that the edge computing wants to 
utilize etc.
Start from the clean slate will be more acceptable?

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] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[Aijun Wang]

Hi, Les:

I think we should find the most efficient way to accomplish the work.
The draft that is adopting, or is adopted, or is in the WGLC or in the IESG 
view process is reasonable to be updated to address the comments during the 
process.
I think update the draft accordingly to address the issues raised during the 
call demonstrate the authors are listening the feedback, and it also help the 
following readers to review it on the latest version, and are not hindered by 
the past/solved issues.

Such interaction can certainly improve the quality and efficiency of our work.

We are glad to hear more comments on the updated version of this draft. 
I think defining such new TLV within OSPF/ISIS can give more flexibility for 
the application of IGP protocol/information, especially for constrained based 
SPF(flexalgo) or controller based application.


Best Regards

Aijun Wang
China Telecom

-Original Message-
From: Les Ginsberg (ginsberg)  
Sent: Tuesday, January 11, 2022 11:06 PM
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 -

I am aware that, subsequent to this email, you posted a revised version of the 
draft. But in regards to how I prefer to move forward I am choosing to respond 
to this email.

It is important to remember that this thread is a 2 week WG adoption call. The 
primary purpose of this thread is to determine the WG consensus as to whether 
the draft is ready for adoption - not to do major revisions of the draft. 

I believe you have received meaningful feedback from multiple WG members that 
indicate there are significant issues with the draft in its current form. The 
issues raised question not just the implementation details, but whether the 
goals of the draft as currently stated are desirable. This, in my mind, is 
sufficient to conclude that the draft in its current form is NOT ready for WG 
adoption. The new version you posted does not come close to fully addressing 
these issues.

The most practical way forward (IMO of course) is for you to voluntarily 
withdraw your request for WG adoption. This will give you an opportunity to 
address the substantive issues that have been raised. It will also demonstrate 
that you are listening to the feedback being given. 

You can, of course, choose not to follow this path - in which case it will fall 
to the WG Chairs to determine the outcome of the adoption call.

Thanx.

   Les


> -Original Message-
> From: Aijun Wang 
> Sent: Monday, January 10, 2022 10:19 PM
> 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:
> 
> There is the way to solve your concern.
> 1. 
> https://datatracker.ietf.org/doc/html/draft-wang-lsr-stub-link-attribu
> tes-
> 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.
> 
> > 

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

[Tony Li]

Hi Aijun,

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


This link doesn’t work.


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



It would seem to me that if you re-used existing TLVs, you could be adding 
subTLVs to carry any additional information.  This would probably be a lot 
cleaner.

T

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

I am aware that, subsequent to this email, you posted a revised version of the 
draft. But in regards to how I prefer to move forward I am choosing to respond 
to this email.

It is important to remember that this thread is a 2 week WG adoption call. The 
primary purpose of this thread is to determine the WG consensus as to whether 
the draft is ready for adoption - not to do major revisions of the draft. 

I believe you have received meaningful feedback from multiple WG members that 
indicate there are significant issues with the draft in its current form. The 
issues raised question not just the implementation details, but whether the 
goals of the draft as currently stated are desirable. This, in my mind, is 
sufficient to conclude that the draft in its current form is NOT ready for WG 
adoption. The new version you posted does not come close to fully addressing 
these issues.

The most practical way forward (IMO of course) is for you to voluntarily 
withdraw your request for WG adoption. This will give you an opportunity to 
address the substantive issues that have been raised. It will also demonstrate 
that you are listening to the feedback being given. 

You can, of course, choose not to follow this path - in which case it will fall 
to the WG Chairs to determine the outcome of the adoption call.

Thanx.

   Les


> -Original Message-
> From: Aijun Wang 
> Sent: Monday, January 10, 2022 10:19 PM
> 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:
> 
> 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 

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

[Aijun Wang]

Hi, Christian:

The benefit of the proposed solution is that for inter-AS scenarios, it can 
accomplish the automatic pairing for the two ends of inter-AS link without the 
explicitly configuration for the remote end information.
In other scenarios,  it can also contain useful information for the edge 
computation services, aid the operator know exactly the boundary of the network 
and apply special security policy at such stub link if necessary etc.

I have updated the draft today in order to address the concerns for unnumbered 
interface and sub-TLV hierarchy that raised by Peter and Les. Please review it 
if there exists any other concerns.

Thanks.


Aijun Wang
China Telecom

> On Jan 11, 2022, at 20:55, Christian Hopps  wrote:
> 
> 
> Peter Psenak  writes:
> 
>> Aijun,
>> 
>>> On 05/01/2022 16:20, Aijun Wang wrote:
>>> [WAJ] The above remote information must be configured manually on the local
>>> device. It is paired by manual. Thinking there are many links among the 
>>> ASBRs,
>>> would you like to configure them manually for every remote ends on each 
>>> link?
> 
> No one with large scale networks, and/or routers with lots of links is doing 
> any sort of manual configuration. It seems to me that I keep seeing this 
> mentioned as justification for changes or extensions to the IGPs. It is not 
> reasonable justification b/c no-one is doing it.
> 
> I think it would be very useful if manual configuration or the assumption 
> that we need to make that less painful, stopped being brought up so we can 
> focus on other reasonable justifications (or lack thereof :)
> 
> Thanks,
> Chris.
> [as wg member]
> 
> 
>>> The prefixes that associated with the stub link can assist to accomplish 
>>> this task automatically.
>> 
>> If the ISIS/OSPF adjacency is not formed over the link, you need to manually
>> configure remote endpoint parameters. Defining a new TLV is not going to make
>> any difference.
>> 
>> Using the local subnet information for identifying two endpoints of the same
>> link does not sound appealing to me.
>> 
>> We have link local/remote IDs (and IP addresses) to pair the two endpoints of
>> the link in both OSPF and ISIS. We do not need another mechanism for the 
>> same.
>> In addition, what you propose does not work for unnumbered links.
>> 
>> I don't see a need for the new stub-link advertisement.
>> 
>> thanks,
>> Peter
>> 
>> 
>> ___
>> 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

[Christian Hopps]

Peter Psenak  writes:


Aijun,

On 05/01/2022 16:20, Aijun Wang wrote:

[WAJ] The above remote information must be configured manually on the local
device. It is paired by manual. Thinking there are many links among the ASBRs,
would you like to configure them manually for every remote ends on each link?


No one with large scale networks, and/or routers with lots of links is doing 
any sort of manual configuration. It seems to me that I keep seeing this 
mentioned as justification for changes or extensions to the IGPs. It is not 
reasonable justification b/c no-one is doing it.

I think it would be very useful if manual configuration or the assumption that 
we need to make that less painful, stopped being brought up so we can focus on 
other reasonable justifications (or lack thereof :)

Thanks,
Chris.
[as wg member]



The prefixes that associated with the stub link can assist to accomplish this 
task automatically.


If the ISIS/OSPF adjacency is not formed over the link, you need to manually
configure remote endpoint parameters. Defining a new TLV is not going to make
any difference.

Using the local subnet information for identifying two endpoints of the same
link does not sound appealing to me.

We have link local/remote IDs (and IP addresses) to pair the two endpoints of
the link in both OSPF and ISIS. We do not need another mechanism for the same.
In addition, what you propose does not work for unnumbered links.

I don't see a need for the new stub-link advertisement.

thanks,
Peter


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




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

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

[chen.ran]

Hi WG,Support adoption.Best Regards,


Ran






-Original Message-From: lsr-boun...@ietf.org  On 
Behalf Of ChristianHoppsSent: Tuesday, January 4, 2022 2:59 PMTo: 
lsr@ietf.orgCc: lsr-cha...@ietf.org; lsr-...@ietf.org; 
cho...@chopps.org;draft-wang-lsr-stub-link-attributes@ietf.orgSubject: [Lsr] WG 
Adoption Call for draft-wang-lsr-stub-link-attributes-02Hi 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 anyIPR that applies to 
these drafts.Thanks,Chris.___Lsr 
mailing 
listLsr@ietf.orghttps://www.ietf.org/mailman/listinfo/lsr___Lsr
 mailing listLsr@ietf.orghttps://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]

Hi Les,

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

Since you keep asking for a write up on an alternate solution(s) and since
you clearly stated that your connectivity restoration goals is in seconds
please kindly consider the below solution.

Keep in mind that this solution has shipped around 2003-2004 and is used
all over the world in properly configured networks.

* In an area PEs peer with IBGP sessions to RRs
* RRs are (in vast majority of cases) part of IGP hence hear the same
flooding as would local area ABRs
* RRs deploy next hop tracking hence they can react in an event driven
fashion to PE down events
* RRs then either trigger withdraw or implicit withdraw of service routes
(*1*)
* Those are received only to those ingress PEs who care via RTC filtering

Without doing anything else you get connectivity restoration in seconds
today zero code change, zero protocol extension, zero noise.

(*1*) Now if one would like to further optimize this step it is really easy
to either withdraw all prefixes describing say all routes on the PEs or
simply withdraw previously advertised PE next hop. One message just like
PULSE except without trashing IGP and targeted to those who need it.

I do not see why the optimization (*1*) would not work out of the box. BGP
natively uses recursion so service route can resolve via another BGP route
then via IGP summary.

Hope this helps to understand my suggestion. I also do not see this needs
to be a draft or RFC as this is basic BGP 101.

Cheers,
R.

PS,. I do realize especially after you said that you want to improve the
situation where BGP reacts only after 3 x 60 sec keepalives to trigger
action that some networks may disable next hop validation on RRs. Some may
not even want to run IGP on service RRs. Sure this is ok in some
topologies. But in such cases there are other ways to detect state of local
area PEs on such RRs.
___
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, All experts:

Upon the responses from this adoption call, we have updated to the draft
https://datatracker.ietf.org/doc/html/draft-wang-lsr-stub-link-attributes to
address the comments received from now.
If you have still other concerns, please responses.
We are glad to address your concerns during the adoption call process.

The updated contents are mainly the followings:
1. Adding the description for the "Unnumbered AS boundary link" and the MUST
associated sub-TLVs.
2. Define the Top-Level TLV for IS-IS---"Stub-Link TLV", instead of putting
it under the inter-AS reachability TLV(141).

The above updates align the OSPF and IS-IS and the existing defined sub-TLVs
in more reasonable style.


Best Regards

Aijun Wang
China Telecom

-Original Message-
From: lsr-boun...@ietf.org  On Behalf Of Christian
Hopps
Sent: Tuesday, January 4, 2022 2: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

[Lsr] I-D Action: draft-wang-lsr-stub-link-attributes-03.txt

[internet-drafts]

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

Title   : Advertisement of Stub Link Attributes
Authors : Aijun Wang
  Zhibo Hu
  Gyan S. Mishra
  Acee Lindem
  Jinsong Sun
Filename: draft-wang-lsr-stub-link-attributes-03.txt
Pages   : 9
Date: 2022-01-11

Abstract:
   This document describes the mechanism that can be used to
   differentiate the stub links from the normal interfaces within ISIS
   or OSPF domain.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-wang-lsr-stub-link-attributes/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-wang-lsr-stub-link-attributes-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-wang-lsr-stub-link-attributes-03


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


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