Re: [Lsr] Working Group Last Call for "Applicability of IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition (NRP)" - draft-ietf-lsr-isis-sr-vtn-mt-06

[Gengxuesong (Geng Xuesong)]

Hi Chongfeng,

Thanks for updating the document and the new version looks good to me.

Best
Xuesong

From: Chongfeng Xie [mailto:chongfeng@foxmail.com]
Sent: Tuesday, January 23, 2024 11:33 AM
To: Gengxuesong (Geng Xuesong) ; Acee Lindem 
; lsr 
Subject: Re: RE: [Lsr] Working Group Last Call for "Applicability of IS-IS 
Multi-Topology (MT) for Segment Routing based Network Resource Partition (NRP)" 
- draft-ietf-lsr-isis-sr-vtn-mt-06


Hi Xuesong,

Thanks for your support and review comments. We are working on a new revision 
which will take your comments into consideration.

As for your suggestion to add reference to the more scalable solution, 
according to the comments from Acee, we would not mention the specific solution 
in this draft, but we have referred to the NRP scalability document for more 
information on the scalability discussion.  Hope that would be OK to you.

Best regards,
Chongfeng

From: Gengxuesong (Geng Xuesong)<mailto:gengxues...@huawei.com>
Date: 2024-01-11 18:37
To: Acee Lindem<mailto:acee.i...@gmail.com>; Lsr<mailto:lsr@ietf.org>
Subject: RE: [Lsr] Working Group Last Call for "Applicability of IS-IS 
Multi-Topology (MT) for Segment Routing based Network Resource Partition (NRP)" 
- draft-ietf-lsr-isis-sr-vtn-mt-06
Hi WG,

I support the publication of this document. I think this is a reasonable method 
of network slicing implementation which could reuse the existing mechanism.
Some editing comments for authors' reference.

Best
Xuesong

--

1.  Introduction
...
This document describes a
   simplified mechanism to build SR based NRPs in those scenarios.  The
   resource-aware segments can be used with this approach to provide
   resource guaranteed SR based NRPs, while the normal SR segments may
   also be used to provide SR based NRPs with shared network resources
   in the forwarding plane.

   The proposed approach is to use IS-IS Multi-Topology [RFC5120] with
   segment routing [RFC8667] to define the independent network topology
   of each NRP.  The network resources and other TE attributes of an NRP
   can be advertised using IS-IS MT with the Traffic Engineering (TE)
   extensions defined in [RFC5305] and [RFC8570].

[Xuesong] I recommend to swap the position of these two sentences. It will be 
easier for readers' understanding: show what is the proposal firstly and then 
describe this could be used with resource-aware segments to provide resource 
guaranteed SR based NRPs

2.  Advertisement of Topology Attribute for SR based NRP

[Xuesong] It will be helpful if there is a summary about what Topology 
Attribute for SR based NRP is requested before introducing what could be reused 
in different existing RFCs.

3.  Advertisement of Resource Attribute for SR based NRP

   In order to perform constraint based path computation for each NRP on
   the network controller or on the ingress nodes, the network resource
   attributes and other attributes associated with each NRP need to be
   advertised.

[Xuesong] It could be considered to add some explanation for whether this is 
just for this proposal or also could be used to other resource guaranteed SR 
based NRPs


5.  Scalability Considerations
  The
   mechanism described in this document is considered useful for network
   scenarios in which the required number of NRP is small, as no control
   protocol extension is required.  For network scenarios where the
   number of required NRP is large, more scalable solution would be
   needed, which may require further protocol extensions and
   enhancements.

[Xuesong] This is helpful to add some reference for example of more scalable 
solutions.


> -Original Message-
> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem
> Sent: Tuesday, January 9, 2024 6:50 AM
> To: Lsr mailto:lsr@ietf.org>>
> Subject: [Lsr] Working Group Last Call for "Applicability of IS-IS 
> Multi-Topology
> (MT) for Segment Routing based Network Resource Partition (NRP)" -
> draft-ietf-lsr-isis-sr-vtn-mt-06
>
> This begins a two week LSR Working Group last call for the “Applicability of 
> IS-IS
> Multi-Topology (MT) for Segment Routing based Network Resource Partition
> (NRP)”. Please express your support or objection prior to Tuesday, January 
> 23rd,
> 2024.
>
> Thanks,
> Acee
> ___
> Lsr mailing list
> Lsr@ietf.org<mailto:Lsr@ietf.org>
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Working Group Last Call for "Applicability of IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition (NRP)" - draft-ietf-lsr-isis-sr-vtn-mt-06

[Gengxuesong (Geng Xuesong)]

Hi WG,

I support the publication of this document. I think this is a reasonable method 
of network slicing implementation which could reuse the existing mechanism.
Some editing comments for authors' reference.

Best
Xuesong

--

1.  Introduction
...
This document describes a
   simplified mechanism to build SR based NRPs in those scenarios.  The
   resource-aware segments can be used with this approach to provide
   resource guaranteed SR based NRPs, while the normal SR segments may
   also be used to provide SR based NRPs with shared network resources
   in the forwarding plane.

   The proposed approach is to use IS-IS Multi-Topology [RFC5120] with
   segment routing [RFC8667] to define the independent network topology
   of each NRP.  The network resources and other TE attributes of an NRP
   can be advertised using IS-IS MT with the Traffic Engineering (TE)
   extensions defined in [RFC5305] and [RFC8570].

[Xuesong] I recommend to swap the position of these two sentences. It will be 
easier for readers' understanding: show what is the proposal firstly and then 
describe this could be used with resource-aware segments to provide resource 
guaranteed SR based NRPs

2.  Advertisement of Topology Attribute for SR based NRP

[Xuesong] It will be helpful if there is a summary about what Topology 
Attribute for SR based NRP is requested before introducing what could be reused 
in different existing RFCs.

3.  Advertisement of Resource Attribute for SR based NRP

   In order to perform constraint based path computation for each NRP on
   the network controller or on the ingress nodes, the network resource
   attributes and other attributes associated with each NRP need to be
   advertised.

[Xuesong] It could be considered to add some explanation for whether this is 
just for this proposal or also could be used to other resource guaranteed SR 
based NRPs


5.  Scalability Considerations
  The
   mechanism described in this document is considered useful for network
   scenarios in which the required number of NRP is small, as no control
   protocol extension is required.  For network scenarios where the
   number of required NRP is large, more scalable solution would be
   needed, which may require further protocol extensions and
   enhancements.

[Xuesong] This is helpful to add some reference for example of more scalable 
solutions.


> -Original Message-
> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem
> Sent: Tuesday, January 9, 2024 6:50 AM
> To: Lsr 
> Subject: [Lsr] Working Group Last Call for "Applicability of IS-IS 
> Multi-Topology
> (MT) for Segment Routing based Network Resource Partition (NRP)" -
> draft-ietf-lsr-isis-sr-vtn-mt-06
> 
> This begins a two week LSR Working Group last call for the “Applicability of 
> IS-IS
> Multi-Topology (MT) for Segment Routing based Network Resource Partition
> (NRP)”. Please express your support or objection prior to Tuesday, January 
> 23rd,
> 2024.
> 
> Thanks,
> Acee
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Working Group Last Call for "OSPFv3 Extensions for SRv6" - draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

[Gengxuesong (Geng Xuesong)]

Hi WG,

I’ve read the document and it introduces reasonable OSPFv3 extensions for SRv6 
which is useful for SRv6 deployment.
Support publication.

Best
Xuesong

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Saturday, July 30, 2022 1:17 AM
To: lsr 
Cc: draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org
Subject: [Lsr] Working Group Last Call for "OSPFv3 Extensions for SRv6" - 
draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

As promised in today’s LSR WG meeting, this begins a 3 week WG Last Call, 
ending on August 19th, 2022, for draft-ietf-lsr-ospfv3-srv6-extensions. The 
extra week is to account for PIST (Post-IETF Stress Syndrome). The 
corresponding IS-IS draft is already on the RFC Queue and there are 
implementations.

https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-srv6-extensions/


Thanks,
Acee & Chris


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

Re: [Lsr] LSR WG Adoption Call for SRv6 YANG drafts

[Gengxuesong (Geng Xuesong)]

Support adoption of these 2 documents as a co-author. 
And I'm not aware of any IPR that applies to the drafts

Best
Xuesong

-Original Message-
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps
Sent: Thursday, July 22, 2021 6:48 PM
To: lsr@ietf.org
Cc: lsr-cha...@ietf.org; lsr-...@ietf.org; cho...@chopps.org
Subject: [Lsr] LSR WG Adoption Call for SRv6 YANG drafts


Hi Folks,

This begins a 3 week WG Adoption Call for the following related YANG drafts:

https://datatracker.ietf.org/doc/draft-hu-isis-srv6-yang/
https://datatracker.ietf.org/doc/draft-hu-lsr-ospf-srv6-yang/

Please indicate your support or objections by August 12th, 2021

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

Re: [Lsr] Last Call: (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard

[Gengxuesong (Geng Xuesong)]

Hi Les,

Prefix Attributes sub-TLV is necessary when locator is leaked.
So we are not against Prefix Attribute sub-TLV implementation. We just propose 
to keep it optional ("should" rather than "must") for interoperability.

Best
Xuesong

From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Wednesday, May 12, 2021 6:29 AM
To: Shraddha Hegde ; Alvaro Retana 
; Peter Psenak (ppsenak) ; 
lsr@ietf.org; Gengxuesong (Geng Xuesong) 
Cc: cho...@chopps.org; draft-ietf-lsr-isis-srv6-extensi...@ietf.org; Van De 
Velde, Gunter (Nokia - BE/Antwerp) 
Subject: RE: [Lsr] Last Call:  
(IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed 
Standard

Shraddha/ Xuesong -

Since Prefix Attributes sub-TLV is required for correct operation when a 
Locator is leaked, would it be safe to assume that your implementations either 
do not leak Locators or you advise your customers not to deploy this feature 
with multiple levels?

The problem with allowing the sub-TLV to be optional is that if the sub-TLV is 
omitted you cannot tell whether the Locator has been leaked - so you don't know 
whether you have a problem or not.

The safest thing to do is require prefix-attributes sub-TLV always - then you 
can guarantee that if the prefix is leaked the necessary information will be 
present.
Anything else leaves us vulnerable.

We all appreciate interoperability considerations, but frankly this is a gap 
that needs to be closed to support correct operation.

   Les

From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
Shraddha Hegde
Sent: Tuesday, May 11, 2021 8:21 AM
To: Alvaro Retana mailto:aretana.i...@gmail.com>>; 
Peter Psenak (ppsenak) mailto:ppse...@cisco.com>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Cc: cho...@chopps.org<mailto:cho...@chopps.org>; 
draft-ietf-lsr-isis-srv6-extensi...@ietf.org<mailto:draft-ietf-lsr-isis-srv6-extensi...@ietf.org>;
 Van De Velde, Gunter (Nokia - BE/Antwerp) 
mailto:gunter.van_de_ve...@nokia.com>>
Subject: Re: [Lsr] Last Call:  
(IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed 
Standard

Juniper has an  implementation of SRv6 that does not support Prefix attributes 
sub-tlv in locator TLV.
We would prefer not to change the optional sub-TLV to MUST.

Rgds
Shraddha




Juniper Business Use Only
From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
Alvaro Retana
Sent: Friday, May 7, 2021 7:23 PM
To: Peter Psenak mailto:ppse...@cisco.com>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Cc: cho...@chopps.org<mailto:cho...@chopps.org>; 
draft-ietf-lsr-isis-srv6-extensi...@ietf.org<mailto:draft-ietf-lsr-isis-srv6-extensi...@ietf.org>;
 Van De Velde, Gunter (Nokia - BE/Antwerp) 
mailto:gunter.van_de_ve...@nokia.com>>
Subject: Re: [Lsr] Last Call:  
(IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed 
Standard

[External Email. Be cautious of content]

On May 3, 2021 at 5:17:58 AM, Peter Psenak wrote:

> Technically I agree with you and if everybody agrees, I'm fine to
> enforce the presence of the Prefix Attribute Flags TLV in the Locator TLV.

So...what does everyone else think?

We need to close on this point before the IESG evaluates the document.  I'm 
requesting it to be put on the May/20 telechat, which means that we should have 
a resolution and updated draft by the end of next week.


Thanks!

Alvaro.



On May 3, 2021 at 5:17:58 AM, Peter Psenak 
(ppse...@cisco.com<mailto:ppse...@cisco.com>) wrote:
Hi Gunter,

Prefix Attribute Flags Sub-TLV has been defined as an optional Sub-TLV.
The problem you describe is not specific to Locator TLV, same applies to
regular IPv4/v6 prefixes (forget SR MPLS for a while) - if the Prefix
Attribute Flags TLV is not included, one can not tell whether the prefix
has been propagated (L1->L2) or generated as a result of the local
interface attached on the originator. Same applies to redistribution and
R-flag for IPv4 prefix TLVs.

SRv6 Locator TLV has been defined a while back and the Prefix Attribute
Flags Sub-TLV has always been an optional Sub-TLV of it. I'm not sure we
can start to mandate the Prefix Attribute Flags TLV at this point.

Technically I agree with you and if everybody agrees, I'm fine to
enforce the presence of the Prefix Attribute Flags TLV in the Locator TLV.

thanks,
Peter


On 03/05/2021 10:45, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote:
> Hi Peter, All,
>
> Could we update to "draft-ietf-lsr-isis-srv6-extensions" that the 
> prefix-attribute tlv is mandatory when a locator is redistributed?
>
> Why?
> *When calculating a LFA for an SRv6 End.SID we better know if the locator has 
> been redistributed or not for a correct operation.
>
> Reasoning:
> * A locator has the D bit. This one is set when we redistribute from L2 to L1.
> ** So this end-sid will not be used as we know that it is redistributed.
>
> * In the 

Re: [Lsr] Last Call: (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard

[Gengxuesong (Geng Xuesong)]

Hi Les,

Thanks for mentioning the compatibility issue. The prefix-attributes sub-TLV is 
not supported in the existing implementation of SRv6 ISIS in Huawei device.
So maybe we should be more cautious before deciding to change it from optional 
to mandatory.

Best
Xuesong

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Les Ginsberg (ginsberg)
Sent: Saturday, May 8, 2021 12:52 AM
To: Ketan Talaulikar (ketant) ; Alvaro 
Retana ; Peter Psenak (ppsenak) ; 
lsr@ietf.org
Cc: cho...@chopps.org; draft-ietf-lsr-isis-srv6-extensi...@ietf.org; Van De 
Velde, Gunter (Nokia - BE/Antwerp) 
Subject: Re: [Lsr] Last Call:  
(IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed 
Standard

As has been mentioned in this thread, the need for the prefix-attributes 
sub-TLV to correctly process leaked advertisements is not unique to the Locator 
TLV. The reason prefix-attributes TLV was created was to address the same gap 
with IP/IPv6 reachability advertisements.
And I think by now implementations (certainly ones that support newer 
functionality like SRv6) should have added support for prefix-attributes 
sub-TLV .

In the case of the Locator TLV  – since this is new functionality – we have the 
option of mandating prefix-attributes sub-TLV – something we could not do with 
IP/IPv6 Reachability since that has been deployed for many years.

But,  please recognize two consequences of the MUST option:

1)Implementations may have to deal w  backwards compatibility w early 
deployments of SRv6. This would only be an issue if there are implementations 
that currently do NOT send prefix-attributes sub-TLV w Locator TLV.
Are there any such implementations??

2)In the case where the deployment is a single level, it could be argued that 
prefix-attributes sub-TLV isn’t needed.
I personally would NOT make such an argument, but we should understand that 
MUST applies to this case as well.

If everyone is OK with these consequences (personally I am OK) then I think it 
is fine to go with MUST.

   Les


From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
Ketan Talaulikar (ketant)
Sent: Friday, May 07, 2021 7:00 AM
To: Alvaro Retana mailto:aretana.i...@gmail.com>>; 
Peter Psenak (ppsenak) mailto:ppse...@cisco.com>>; 
lsr@ietf.org
Cc: cho...@chopps.org; 
draft-ietf-lsr-isis-srv6-extensi...@ietf.org;
 Van De Velde, Gunter (Nokia - BE/Antwerp) 
mailto:gunter.van_de_ve...@nokia.com>>
Subject: Re: [Lsr] Last Call:  
(IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed 
Standard

Hi Peter,

I agree that the support for the Prefix Attribute Flags TLV is required in the 
Locator TLV.

Thanks,
Ketan

From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
Alvaro Retana
Sent: 07 May 2021 19:23
To: Peter Psenak (ppsenak) mailto:ppse...@cisco.com>>; 
lsr@ietf.org
Cc: cho...@chopps.org; 
draft-ietf-lsr-isis-srv6-extensi...@ietf.org;
 Van De Velde, Gunter (Nokia - BE/Antwerp) 
mailto:gunter.van_de_ve...@nokia.com>>
Subject: Re: [Lsr] Last Call:  
(IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed 
Standard

On May 3, 2021 at 5:17:58 AM, Peter Psenak wrote:

> Technically I agree with you and if everybody agrees, I'm fine to
> enforce the presence of the Prefix Attribute Flags TLV in the Locator TLV.

So...what does everyone else think?

We need to close on this point before the IESG evaluates the document.  I'm 
requesting it to be put on the May/20 telechat, which means that we should have 
a resolution and updated draft by the end of next week.


Thanks!

Alvaro.



On May 3, 2021 at 5:17:58 AM, Peter Psenak 
(ppse...@cisco.com) wrote:
Hi Gunter,

Prefix Attribute Flags Sub-TLV has been defined as an optional Sub-TLV.
The problem you describe is not specific to Locator TLV, same applies to
regular IPv4/v6 prefixes (forget SR MPLS for a while) - if the Prefix
Attribute Flags TLV is not included, one can not tell whether the prefix
has been propagated (L1->L2) or generated as a result of the local
interface attached on the originator. Same applies to redistribution and
R-flag for IPv4 prefix TLVs.

SRv6 Locator TLV has been defined a while back and the Prefix Attribute
Flags Sub-TLV has always been an optional Sub-TLV of it. I'm not sure we
can start to mandate the Prefix Attribute Flags TLV at this point.

Technically I agree with you and if everybody agrees, I'm fine to
enforce the presence of the Prefix Attribute Flags TLV in the Locator TLV.

thanks,
Peter


On 03/05/2021 10:45, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote:
> Hi Peter, All,
>
> Could we update to "draft-ietf-lsr-isis-srv6-extensions" that the 
> prefix-attribute tlv is mandatory when a locator is redistributed?
>
> Why?
> *When calculating a LFA for an SRv6 End.SID we better know 

Re: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03

[Gengxuesong (Geng Xuesong)]

Hi WG,

I support the adoption of this informational document.
The combination of IS-IS MT with TE extensions allows to build VTNs with 
customized topology and link attributes, and SR SIDs are used to steer traffic 
using the topologies and resources of each VTN.  This mechanism is clear and 
makes sense.

A small editor comment:
In section 1 introduction, it is mentioned that “Thus these properties require 
integration between the underlay and the overlay networks.” This sentence has 
some abruptness in the text . Does “underlay  network” mean network resource 
and “network overlay” mean network topology? More descriptions here may help in 
the following version.

Best
Xuesong

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Wednesday, March 3, 2021 7:28 AM
To: lsr@ietf.org
Subject: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for 
Segment Routing based Virtual Transport Network” - 
draft-xie-lsr-isis-sr-vtn-mt-03

This information draft describes how MT could be used for VTN segmentation. The 
authors have asked for WG adoption.

This begins a three week LSR Working Group Adoption Poll for “Using IS-IS 
Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - 
draft-xie-lsr-isis-sr-vtn-mt-03. I’m giving it three weeks due to the IETF next 
week. Please register your support or objection on this list prior to the end 
of the adoption poll on 3/24/2020.

Thanks,
Acee


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

Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

[Gengxuesong (Geng Xuesong)]

Hi Tony,

My intension was not to talk about math/engineering/marketing or compare the 
size of marketing department. Them are not relevant to this thread.
I want to make clear about IETF process. In my understanding the document does 
not need to be perfect at this stage, as long as it is in the right direction 
to solve some acknowledged problem( IGP scalability). Comments will be helpful 
if it could provide ideas about how to improve.
But IMO the discussion in the mailing list about this draft has gone off the 
rails of technology, including keeping challenging tradeoff between value and 
complexity, which seems reasonable at the first sight, but at this stage, has 
turned out to be a question with no right answer and may bring endless argument.


Thanks
Xuesong

From: Tony Li [mailto:tony1ath...@gmail.com] On Behalf Of tony...@tony.li
Sent: Wednesday, September 2, 2020 12:07 PM
To: Gengxuesong (Geng Xuesong) 
Cc: Huaimo Chen ; Les Ginsberg (ginsberg) 
; Les Ginsberg ; Acee 
Lindem (acee) ; lsr@ietf.org
Subject: Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - 
draft-chen-isis-ttz-11.txt


Hi Xuesong,

Apologies first if I have missed any history of this discussion. But I’m not 
sure that we have to evaluate whether a method is “optimal” before WG adoption. 
Why not adopt some alternative solutions and leave the choice to 
industry/market?


First off, this is engineering, not theoretical math.  Optimal is not the 
issue. Heck, optimal isn’t even a goal.

What we are looking for is value and value that outweighs the complexity.

Leaving the choice to the market is a bad idea. The market does NOT make sound 
technical decisions. It makes pseudo-random decisions not based on technical 
merits. The canonical example here is VHS vs Betamax. Better technology lost.

Second, the market is unduly influenced by marketing. The size of your 
marketing department exceeds the size of my entire (not tiny) company. And it’s 
still second to that of Cisco.

Marketing does not make good technical and architectural decisions. That’s our 
job.

Tony

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

Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

[Gengxuesong (Geng Xuesong)]

Hi Tony,

Apologies first if I have missed any history of this discussion. But I’m not 
sure that we have to evaluate whether a method is “optimal” before WG adoption. 
Why not adopt some alternative solutions and leave the choice to 
industry/market?

Thanks
Xuesong

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of tony...@tony.li
Sent: Tuesday, September 1, 2020 11:02 PM
To: Huaimo Chen 
Cc: Les Ginsberg (ginsberg) ; Les Ginsberg 
; lsr@ietf.org; Acee Lindem (acee) 

Subject: Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - 
draft-chen-isis-ttz-11.txt


Hi Huaimo,

> The question I and others have asked is “what can we do with zones that 
> cannot be done with areas?”.
[HC]: IS-IS TTZ or say Zone is one of a few drafts which experiment/explore 
new ways for scalability. These new ways may be simpler and have some other 
features.


The English language is a remarkable creature. Enormously complex and 
intricate. Maddeningly irregular and inconsistent.

The word “may” is a fine example. It denotes the possibility of a relationship 
between two concepts, but says nothing about the likelihood of the reality. As 
a result, it can be used to
conjoin arbitrary entities.

Trump MAY win the election.

COVID MAY cure cancer.

The world MAY end tomorrow.

Any sentence with the word MAY in it is equally true if you replace “MAY” with 
“MAY NOT”.

Zones MAY be simpler.  Zones MAY NOT be simpler.  It’s up to you to convince us 
that they are simpler, better, or provide some value above and beyond the 
concepts that we have now.
The obligation is on you to make this point.

So far, you haven’t.

Regards,
Tony



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

Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

[Gengxuesong (Geng Xuesong)]

Yes, Support.
It is a reasonable technical solution to abstract a zone to a virtual node to 
enhanced scalability.

Best Regards
Xuesong

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Tuesday, August 18, 2020 10:17 PM
To: lsr@ietf.org
Subject: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - 
draft-chen-isis-ttz-11.txt


Based on the discussions in the last meeting and on the mailing list regarding 
draft-chen-isis-ttz-11, the chairs feel that there are enough differences with 
draft-ietf-lsr-isis-area-proxy-03 and in the community to consider advancing it 
independently on the experimental track.

These differences include abstraction at arbitrary boundaries and IS-IS 
extensions for smooth transition to/from zone abstraction.

We are now starting an LSR WG adoption call for draft-chen-isis-ttz-11.txt. 
Please indicate your support or objection to adoption prior to Tuesday, 
September 2nd, 2020.

Thanks,
Acee and Chris

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

Re: [Lsr] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call

[Gengxuesong (Geng Xuesong)]

Hi,

I’ve read the draft and I think the draft is useful and ready for WG adoption.
By the way, when reading the draft, I feel a little difficult to understand the 
mathematical symbols in the draft, especially in the “Appendix A.  FT 
Computation Details through Example .” It will be appreciated if the authors 
could add more explanations about this.  And I believe some brief introduction 
about the relationship between this draft and other existing work in the WG 
will also be very helpful.

Best Regards
Xuesong

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Saturday, May 16, 2020 3:40 AM
To: lsr@ietf.org
Subject: [Lsr] Flooding Topology Computation Algorithm - 
draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call

This begins a 3 week (due to holidays) WG adoption call for the “Flooding 
Topology Computation Algorithm” draft. Please issue your support or objection 
to this list by 11:59 PM, UTC on June 5th, 2020. Here is a URL for your 
convenience.

https://datatracker.ietf.org/doc/draft-cc-lsr-flooding-reduction/

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

Re: [Lsr] Questions about draft-ietf-lsr-dynamic-flooding-04

[Gengxuesong (Geng Xuesong)]

Hi Tony,

The whole process of temporary flooding is much more clear for me. Thank you 
for your explanation!

Best Regards
Xuesong

From: Tony Li [mailto:tony1ath...@gmail.com] On Behalf Of tony...@tony.li
Sent: Tuesday, May 12, 2020 1:03 AM
To: Gengxuesong (Geng Xuesong) 
Cc: sarahc...@arista.com; lsr@ietf.org
Subject: Re: [Lsr] Questions about draft-ietf-lsr-dynamic-flooding-04


Hi Xuesong,

Thank you for giving detailed proof, and it is very helpful to understand the 
mechanism.
As I understand, it is showed in the proof that if there is proper temporary 
flooding in R = E - E* - E’, same connectivity could be achieved by the 
flooding topology F’ just as G’. I agree with this.


I’m glad it helped.



The problem for me now is how to enable the temporary flooding properly.
Here is an example:

The solid line presents the physical link inside flooding topology, and the 
dashed line presents the physical link out of flooding topology.
From the view of me, when multipoint failure happens, node 3 is supposed to 
enable the temporary flooding between 3 and 4, in order to connect with the 
nodes inside the red box, while the other dashed line between node 1 and node 
nobody is not supposed to do temporary flooding although node 1 is connected to 
the failed link directly.
It seems a little unclear for me about how the node itself could decide whether 
a dashed line should do temporary flooding or not in this case.


The problem that you’re asking about is partition detection.

To explain this, I’ve taken the liberty of adding some more labels to your 
diagram.

To start, each node has its link state database and the flooding topology.  
Each node should receive link state updates from nodes in its partition, but 
will not receive updates from other nodes, thus the link state database is 
partially inconsistent and must be treated with care.

For example, node 2 will see updates from nodes 1, 6, and 7, informing it of 
the failure, but it will not receive an update from node 8.

Now, the job of each node is try to compute the partitions of the flooding 
topology.  In particular, each node needs to understand which nodes are in its 
partition. A node cannot know all of the partitions that exist, but it turns 
out that that’s irrelevant.

Once a node understands which nodes are in its partition, then it is a simple 
matter to see which links should be enabled for temporary flooding.  If a 
neighbor is in the same partition (e.g., nodes 1 and 5), then adding the link 
adds no value. If the neighbor is not in the same partition (e.g., nodes 3 and 
4), then it becomes a recovery link.

The actual computation of the partitions is straightforward, with one caveat: 
we always want to perform a two-way check for connectivity.  An implementation 
should be doing this during SPF already, so this should be familiar. The reason 
for doing this is quite clear: in node 2’s link state database (LSDB), the LSP 
for node 8 will show connectivity to node 1 even after the failure. However, 
node 1’s LSP will clearly show that the adjacency has failed.  We can only 
infer connectivity when we see both sides of the adjacency are up.

Given this, the specific algorithm that you choose is an implementation detail. 
 You could do a breadth-first search or a depth-first search. Our 
implementation chooses to walk the entire flooding topology, building a tree of 
the partitions that it detects. [IPR note: we have a IPR claim for this 
approach, with the “don’t sue us, we won’t sue you” terms.]

I hope this helps.

Regards,
Tony


[cid:image001.png@01D6294A.F14F40B0]
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Questions about draft-ietf-lsr-dynamic-flooding-04

[Gengxuesong (Geng Xuesong)]

Hi Tony,

Thank you for giving detailed proof, and it is very helpful to understand the 
mechanism.
As I understand, it is showed in the proof that if there is proper temporary 
flooding in R = E - E* - E’, same connectivity could be achieved by the 
flooding topology F’ just as G’. I agree with this.
The problem for me now is how to enable the temporary flooding properly.
Here is an example:
[1AB72D8D-D69C-4047-9E89-5F6062EB6526]
The solid line presents the physical link inside flooding topology, and the 
dashed line presents the physical link out of flooding topology.
From the view of me, when multipoint failure happens, node 3 is supposed to 
enable the temporary flooding between 3 and 4, in order to connect with the 
nodes inside the red box, while the other dashed line between node 1 and node 
nobody is not supposed to do temporary flooding although node 1 is connected to 
the failed link directly.
It seems a little unclear for me about how the node itself could decide whether 
a dashed line should do temporary flooding or not in this case.


Best Regards
Xuesong


From: Tony Li [mailto:tony1ath...@gmail.com] On Behalf Of tony...@tony.li
Sent: Sunday, May 10, 2020 1:18 AM
To: Gengxuesong (Geng Xuesong) 
Cc: sarahc...@arista.com; lsr@ietf.org
Subject: Re: [Lsr] Questions about draft-ietf-lsr-dynamic-flooding-04


Hi Xuesong,


Thank you for your work about Flooding Reduction mechanism. I think it is very 
useful for IGP scalability.


Thank you, we very much appreciate that.


When Sarah giving presentation for draft-chen-lsr-dynamic-flooding-algorithm-00 
in LSR interim meeting, I raised a question about how to handle multipoint 
failure in the flooding topology. I remembered that 
draft-ietf-lsr-dynamic-flooding-04 was mentioned. I have read this draft, 
especially section 6.8.11 and temporary flooding relevant content. I think it 
is a valid method logically. (We have tried to raise some examples to challenge 
this method, but in all these cases, this method works) Considering that 
reliability of IGP is crucial for deployment, we are still wondering whether 
some mathematical proof is necessary (or possible) to guarantee that, in all 
the possible scenarios, proper convergence could be achieved when using 
flooding reduction algorithm, just as traditional IGP mechanism. The proof may 
be case by case depending on the flooding reduction algorithm, but we think 
even some example or clue about how to do this will be very helpful.


A proof? Ok, I can try to be rigorous, but it’s been a very long time. I 
apologize in advance to Kireeti, Mr. Myers, Mr. Douglas, and Prof. Greever for 
what follows.


Definition: Let G=(V, E) be a finite graph. F=(V, E’) is a ‘flooding topology’ 
on G if E’ is a subset of E and F is connected.


We normally have other properties for flooding topologies, such as being 
bi-connected, relatively sparse, minimal diameter, and minimal degree, but 
those properties are not relevant for this proof.


Definition: Let C=(V*, E*), V* a subset of V, E* a subset of E, be the ‘cut’ of 
G. This represents the failures in the topology. Let G’ = G - C, the topology 
after failure, and let F’ = F - C, be the flooding topology after failure.


Definition: Let R = E - E* - E’. This is the set of 'recovery edges': edges 
that have not failed and are not part of the flooding topology.


Corollary: R is finite.

Proof: G is finite, by definition. Therefore E is finite, E* must be finite, 
and E’ is finite.


Lemma 1: If G’ is connected, then F’ + R is connected.

Proof:

G’ = G - C = (V, E) - (V*, E*) = (V - V*, E - E*).

F’ + R = (F - C) + (E - E* - E’) = (V, E’) - (V*, E*) + (E - E* - E’) = ( V - 
V*, E’ - E* ) + ( E - E* - E’) = ( V - V*, E’ - E* + E - E* - E’ ) = ( V - V*, 
E - E* - E* ) = ( V - V*, E - E* ) = G’.

Q.E.D.


Lemma 2: If G’ is connected, then incrementally adding edges from R to F’ will 
yield a connected flooding topology.

Proof: By induction. Let R’ be a subset of R. Induction property: Either F' + 
R’ is connected, or R’ is a proper subset of R.

Base case: R’ is the empty set. If F’ is connected, then F’ + R’ is connected 
and the property is satisfied. If F’ + R’ is not connected, R’ is empty, which 
is a proper subset of R.

Induction case: Let r be a recovery edge in R - R’ (i.e., a new edge to add).  
If F’ + R’ is connected, then the property is satisfied already. If F’ + R’ + r 
is connected, the property is satisfied. If R’ + r = R, then by Lemma 1, the 
property is satisfied. Otherwise, R’ + r != R, and the property is satisfied. 
By our corollary, the induction must terminate.

Q.E.D.



Bugs, questions, and comments are welcome.

Regards,
Tony

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

[Lsr] Questions about draft-ietf-lsr-dynamic-flooding-04

[Gengxuesong (Geng Xuesong)]

Hi Tony, Sarah

Thank you for your work about Flooding Reduction mechanism. I think it is very 
useful for IGP scalability.
When Sarah giving presentation for draft-chen-lsr-dynamic-flooding-algorithm-00 
in LSR interim meeting, I raised a question about how to handle multipoint 
failure in the flooding topology. I remembered that 
draft-ietf-lsr-dynamic-flooding-04 was mentioned. I have read this draft, 
especially section 6.8.11 and temporary flooding relevant content. I think it 
is a valid method logically. (We have tried to raise some examples to challenge 
this method, but in all these cases, this method works) Considering that 
reliability of IGP is crucial for deployment, we are still wondering whether 
some mathematical proof is necessary (or possible) to guarantee that, in all 
the possible scenarios, proper convergence could be achieved when using 
flooding reduction algorithm, just as traditional IGP mechanism. The proof may 
be case by case depending on the flooding reduction algorithm, but we think 
even some example or clue about how to do this will be very helpful.

Best Regards
Xuesong

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

Re: [Lsr] Congestion (flow) control thoughts.

[Gengxuesong (Geng Xuesong)]

Clear, thanks!

> -Original Message-
> From: Tony Li [mailto:tony1ath...@gmail.com] On Behalf Of tony...@tony.li
> Sent: Thursday, May 7, 2020 11:28 PM
> To: Gengxuesong (Geng Xuesong) 
> Cc: lsr@ietf.org; Christian Hopps 
> Subject: Re: [Lsr] Congestion (flow) control thoughts.
> 
> 
> Hi Xuesong,
> 
> > I agree that "minimal flooding time " is a good choice, which may differ 
> > from
> the traditional cc in layer 4, which is difficult to get the completion time 
> for
> each flow.
> > I am still a little confused about " fast brand X needs to not overrun slow
> brand Y while performing well with fast brand Z". Is this talking about
> interoperation between different company device, which may use different
> type of cc mechanism?
> 
> 
> Yes, I’m talking about interoperability.
> 
> Normally, in this working group, interoperability implies that each
> implementation is sending and receiving correctly formatted packets and
> computing correctly. This particular item adds in one other degree of
> complexity: timeliness. An implementation must be able to go fast or slow,
> depending on the needs of the receiver.
> 
> Tony

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

Re: [Lsr] Congestion (flow) control thoughts.

[Gengxuesong (Geng Xuesong)]

Hi Tony,

I agree that "minimal flooding time " is a good choice, which may differ from 
the traditional cc in layer 4, which is difficult to get the completion time 
for each flow.
I am still a little confused about " fast brand X needs to not overrun slow 
brand Y while performing well with fast brand Z". Is this talking about 
interoperation between different company device, which may use different type 
of cc mechanism?

Best Regards
Xuesong 

> -Original Message-
> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of tony...@tony.li
> Sent: Thursday, May 7, 2020 12:02 AM
> To: Gengxuesong (Geng Xuesong) 
> Cc: lsr@ietf.org; Christian Hopps 
> Subject: Re: [Lsr] Congestion (flow) control thoughts.
> 
> 
> Hi Xuesong,
> 
> >  I think there is no need to distinguish the concept of flow 
> > control
> and congestion control, considering that the core idea is the same: monitor 
> the
> sending rate to match the capability of the bottleneck, no matter there are
> competitors or not. And the control loop is necessary in both case.
> 
> 
> This matches my perspective.
> 
> 
> >  Thank you for explaining about the bottleneck of flooding and
> different cc solutions that are under discussion. It is helpful and I will 
> read the
> drafts.
> > There is still one more question left in the previous email: " What is the
> criteria of comparing different solutions?". I think this is crucial for 
> further
> discussion and comparative tests. I notice that in Bruno's data, some
> parameters are mentioned, such as " Duration"," LSP/second"," avg inter-LSP
> delay", "retransmission time". I'm wondering whether it is able to choose a
> better solution through these parameters. If not, what should be added or
> considered. (Some other issues are also considered when choosing cc
> mechanism in layer 4, such as: fairness among flows, co-existence with other
> cc mechanism .. )
> 
> 
> Sorry for missing the question. The criteria are, I think, quite clear: 
> minimize
> overall flooding time.  As Bruno’s figures show, that does NOT happen simply
> by transmitting at the maximum rate. That causes overruns, resulting in
> retransmissions and that ends up being quite slow (tho we can work on that
> too). The question then is: what control mechanisms do we put in place to
> ensure minimal flooding time? This needs to interoperate across the full
> spectrum of implementations: fast brand X needs to not overrun slow brand Y
> while performing well with fast brand Z.
> 
> The floor is very much open.
> 
> 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] Congestion (flow) control thoughts.

[Gengxuesong (Geng Xuesong)]

Hi Tony,

Thank you for your explanation. Please find my comments inline.

Best Regards
Xuesong

> -Original Message-
> From: Tony Li [mailto:tony1ath...@gmail.com] On Behalf Of tony...@tony.li
> Sent: Friday, May 1, 2020 12:16 AM
> To: Gengxuesong (Geng Xuesong) 
> Cc: Christian Hopps ; lsr@ietf.org
> Subject: Re: [Lsr] Congestion (flow) control thoughts.
>  
> 
> I consider flow control and congestion control to be separate, but similar
> problems.
> 
> Flow control is about creating a single control loop between a single
> transmitter and single receiver.
> 
> Congestion control is about creating multiple interacting control loops 
> between
> multiple transmitters and multiple receivers.

 I think there is no need to distinguish the concept of flow control 
and congestion control, considering that the core idea is the same: monitor the 
sending rate to match the capability of the bottleneck, no matter there are 
competitors or not. And the control loop is necessary in both case. 

> In our draft, we are proposing other feedback mechanisms.

 Thank you for explaining about the bottleneck of flooding and 
different cc solutions that are under discussion. It is helpful and I will read 
the drafts. 
There is still one more question left in the previous email: " What is the 
criteria of comparing different solutions?". I think this is crucial for 
further discussion and comparative tests. I notice that in Bruno's data, some 
parameters are mentioned, such as " Duration"," LSP/second"," avg inter-LSP 
delay", "retransmission time". I'm wondering whether it is able to choose a 
better solution through these parameters. If not, what should be added or 
considered. (Some other issues are also considered when choosing cc mechanism 
in layer 4, such as: fairness among flows, co-existence with other cc mechanism 
.. )


> Tony
> 

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

Re: [Lsr] Congestion (flow) control thoughts.

[Gengxuesong (Geng Xuesong)]

Hi,



Thank you Chris for emphasizing that congestion control is hard and more 
reference may be necessary.

And as the the follow-up of my comments in the interim meeting, I would like to 
make my question more clear:

In congestion control of layer 4, it is assumed that there is a bottleneck in 
the network, and the ideal rate of the transmitters equals to a fair share of 
the bandwidth in the bottleneck. The flows in the network change all the time 
and so as to the ideal transmitting rate. There are some methods to detect the 
bottleneck, for example detecting packet loss, setting ECN, RTT and so on. 
Considering that the goal of cc is to maximize the throughput and minimize the 
queuing delay, the throughput and delay could be used to compare different cc 
algorithms.

The problem of mine is that for CC of ISIS flooding, where is the 
bottleneck?(maybe the receiver capability) What method of detecting could be 
used? (In my understanding, we have two options at this stage: one from the 
receiver side and the other from the transmitter side) What is the criteria of 
comparing? (still a little confusing for me )



Best Regards

Xuesong



-Original Message-

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps

Sent: Wednesday, April 29, 2020 8:24 PM

To: lsr@ietf.org

Cc: cho...@chopps.org

Subject: [Lsr] Congestion (flow) control thoughts.



[As WG member]



I like the start these drafts are making, I have a few thoughts.



- I think its worthwhile work and as a WG we should end up adopting a draft or 
drafts that try to solve the problem.

- Congestion control is hard, and a very well studied problem, as such whatever 
we end up should reference prior-art to justify it's claims.

- Data, whatever solution we end up with needs to have data to back up it's 
claims.



** draft-ginsberg-lsr-isis-flooding-scale



Having just recently offered a, "CC algorithm is local so we aren't specifying 
it", in some unrelated work, I discovered (correctly so) that it was not 
sufficient (see [*] for the resulting changes if curious). One needs to provide 
(doesn't need to be normative) a working algorithm to prove that the protocol 
is providing enough information to the transmitter to actually implement a 
viable CC algorithm.



Now draft-ginsberg does suggest an algorithm, however only for P2P. We need to 
address LAN as well. This also needs references on how this algorithm relates 
to existing studied work, and perhaps most importantly some data showing that 
it actually works.



Without this it will almost for sure not clear the IESG (in particular 
Transport AD review), and rightly so. :)



** draft-decraene-lsr-isis-flooding-speed-03



I read this draft as providing feedback to transmitters on ways to modify the 
parameters of their CC algorithm. It doesn't actually seem in conflict with 
draft-ginsberg (or doesn't need to be) to me. I believe it's following the path 
of least resistance in utilizing existing IS-IS parameters. I wonder if we 
could be more adventurous here.



** Both



Both drafts mention trying to increase the ACK rate. I think we need to look 
deeply into this, as this is critical information for CC algorithms. It very 
well could be that we do not need protocol changes as the protocol provides an 
ACK (or NACK for LANs), but I also don't think changes or additions should be 
verboten either if they could provide significant improvements.



In the algorithms we propose or envision we need to be considering the affect 
of larger RTT on the algorithm for slow or long distant links (radios, 
satellites, long-haul fibers, etc).



Thanks,

Chris.

[As WG member]



[*] - https://tools.ietf.org/html/draft-hopps-ipsecme-iptfs-01#section-3

  https://tools.ietf.org/html/draft-hopps-ipsecme-iptfs-01#appendix-B),
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr