Re: [Lsr] WG Adoption Call - draft-gong-lsr-ospf-unreachable-link (02/23/24 - 03/08/24)

[Huzhibo]

I support the adoption of the draft as a WG document.

thanks,
Zhibo
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Yingzhen Qu
Sent: Friday, February 23, 2024 1:28 PM
To: lsr ; lsr-chairs 
Subject: [Lsr] WG Adoption Call - draft-gong-lsr-ospf-unreachable-link 
(02/23/24 - 03/08/24)


Hi,



This email begins a 2 week WG adoption poll for the following draft:

https://datatracker.ietf.org/doc/draft-gong-lsr-ospf-unreachable-link/



Please review the document and indicate your support or objections by March 
8th, 2024.

Authors and contributors, please respond to the list indicating whether you are 
aware of any IPR that applies to the draft.

Thanks,

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

[Huzhibo]

By it nature MT is a good candiate for the control plane of NRP, and it is 
beneficial to reuse existing technology when applicable. The document has 
limited its scope to providing a small number of NRPs, which can still be 
useful for some networks. 

I support the publication of this document.

Thanks
Zhibo
-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] WG Adoption Call - draft-wang-lsr-stub-link-attributes (01/05/2024 - 01/19/2024)

[Huzhibo]

Hi Acee:

  You're right, there are alternatives to address inter-domain link 
advertisements, and this document attempts to address such issues in a more 
simplified way, reducing the number of BGP-LS sessions required, or avoid the 
configurations related to the peering AS domains as required by RFC 9346. Do 
you have any suggestions for the problems this article is trying to solve?

Thanks
Zhibo Hu

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem
Sent: Tuesday, January 9, 2024 3:03 AM
To: Yingzhen Qu 
Cc: lsr 
Subject: Re: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes 
(01/05/2024 - 01/19/2024)

Speaking as WG member:

I don’t support adoption of this draft.

First of all, I think the basic premise of the draft is flawed in that a link 
is advertised as a stub and, from that, one can deduce uses of the link. Why 
not just advertise what is being deduced?

Second, I don’t think the draft is necessary. The use case in A.1 is solely for 
an IGP router to advertise this stub link characteristic to a controller for 
inter-AS TE. Since it is only for the controller why wouldn’t be BGP-LS be 
used? It seems this is how it ultimately gets to the controller anyway. 
Furthermore, if it were to be put into the IGPs, why wouldn’t something like 
RFC 9346 be used for inter-AS TE? For the use case in A.2, anycast prefix 
advertisement is already handled and documents exist to identify a prefix as an 
anycast address. For the use case in A.3, I don’t even understand how it works 
or what is supposed to happen between BGP and the IGPs? What is different about 
this from normal BGP route recursion over the IGP route? For this, the fact 
that it is a stub link is irrelevant.

Thanks,
Acee




On Jan 5, 2024, at 19:23, Yingzhen Qu 
mailto:yingzhen.i...@gmail.com>> wrote:

Hi,


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 19th, 2024.



Authors, please respond to the list indicating whether you are aware of any IPR 
that applies to the draft.
*** Please note that this is the second WG adoption poll of the draft. The 
first one was tried two years ago and you can see the discussions in the 
archive:
[Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02 
(ietf.org)


Thanks,

Yingzhen



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

Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-unreach-prefix-announce-04

[Huzhibo]

From: Les Ginsberg (ginsberg) [mailto:ginsberg=40cisco@dmarc.ietf.org]
Sent: Thursday, August 31, 2023 10:57 AM
To: Huzhibo ; Peter Psenak (ppsenak) ; 
linchangwang ; Acee Lindem ; 
lsr 
Cc: draft-ppsenak-lsr-igp-unreach-prefix-annou...@ietf.org
Subject: RE: [Lsr] Working Group Adoption of "IGP Unreachable Prefix 
Announcement" - draft-ppsenak-lsr-igp-unreach-prefix-announce-04


Zhibo -



Please see inline.



> -Original Message-----

> From: Huzhibo 
> mailto:huzhibo=40huawei@dmarc.ietf.org>>

> Sent: Wednesday, August 30, 2023 6:33 PM

> To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
> Peter Psenak (ppsenak)

> mailto:ppse...@cisco.com>>; linchangwang 
> mailto:linchangwang.04...@h3c.com>>;

> Acee Lindem mailto:acee.i...@gmail.com>>; lsr 
> mailto:lsr@ietf.org>>

> Cc: 
> draft-ppsenak-lsr-igp-unreach-prefix-annou...@ietf.org<mailto:draft-ppsenak-lsr-igp-unreach-prefix-annou...@ietf.org>

> Subject: RE: [Lsr] Working Group Adoption of "IGP Unreachable Prefix

> Announcement" - draft-ppsenak-lsr-igp-unreach-prefix-announce-04

>

> Hi Les:

>

> I think you may have connected something. Existing routers, on receiving a

> prefix reachability advertisement with a

> U-Flag described in 
> https://datatracker.ietf.org/doc/draft-ppsenak-lsr-igp-<https://datatracker.ietf.org/doc/draft-ppsenak-lsr-igp-ureach-prefix-announce/>

> ureach-prefix-announce/<https://datatracker.ietf.org/doc/draft-ppsenak-lsr-igp-ureach-prefix-announce/>
>  also will interpret that prefix as being reachable.



[LES:] This statement is incorrect.

RFC 5305 states:





If a prefix is advertised with a metric larger then MAX_PATH_METRIC

   (0xFE00, see paragraph 3.0), this prefix MUST NOT be considered

   during the normal SPF computation.  This allows advertisement of a

   prefix for purposes other than building the normal IP routing table.





(Equivalent statement in RFC 5308 for IPv6)



Existing implementations will ignore the advertisement purely on the basis of 
the metric value - this does not depend upon understanding the U bit.



But existing implementations will NOT ignore a prefix reachability 
advertisement just because it has a source Router ID set to 0 as 
draft-wang-lsr-prefix-unreachable-annoucement defines.



It is worth noting that AFTER the publication of 
draft-ppsenak-lsr-igp-pfx-reach-loss-00 in March 2022 (subsequently renamed as 
draft-ppsenak-lsr-igp-ureach-prefix-announce), the authors of 
draft-wang-lsr-prefix-unreachable-annoucement apparently realized they had  an 
interoperability problem with existing routers (something many of us had been 
highlighting for years) and in V10 (published in Jul 2022) an option was added 
to advertise using maximum metric (the solution already proposed by 
draft-ppsenak). But because the authors apparently didn’t want to abandon the 
use of "Router ID = 0", the new version of the draft proposed a dependency on 
how the unreachable prefix should be advertised. If all routers in the network 
indicated support for the new extension (indicated by yet another protocol 
extension - a new Router Capability sub-TLV for IS-IS) then the use of Router 
ID = 0 could be used, but if any router in the network did not advertise the 
new capability, then the use of max-metric is required. Which means the 
solution requires routers advertising unreachability to potentially regenerate 
the advertisement in a different form whenever the state of support by all 
routers in the network for the extension changes.



[Zhibo:] draft-wang-lsr-prefix-unreachable-annoucement doesn`t use “Router ID = 
0” to implement backward compatibility. It only provides two options: 
capability negotiation and MAX metric. When capability negotiation changes, 
there is no requirement to update the MAX metric value. It can be retained.



> Both two draft used The 0xFE00 metric indicates that the prefix is not

> reachable. Doesn't make a difference at this point.



[LES:] The solution defined in draft-ppsenak-lsr-igp-unreach-prefix-announce 
does not introduce any interoperability issues with existing routers, does not 
require multiple encoding formats, and does not require a router to regenerate 
advertisements in a different form based on the state of support by all routers 
in the network.

I think this makes a big difference. 

[Zhibo:] The same applies to draft-wang-lsr-prefix-unreachable-annoucement, 
which is not the main difference between the two documents.



Thanks

Zhibo



   Les



>

> Thanks

>

> Zhibo Hu

>

> > -Original Message-

> > From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Les Ginsberg

> > (ginsberg)

> > Sent: Thursday, August 31, 2023 12:31 AM

> > To: Peter Psenak 
> > mailto:ppsenak=40cisco@dmarc.ietf.org

Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-unreach-prefix-announce-04

[Huzhibo]

Hi Les:

I think you may have connected something. Existing routers, on receiving a 
prefix reachability advertisement with a
U-Flag described in 
https://datatracker.ietf.org/doc/draft-ppsenak-lsr-igp-ureach-prefix-announce/ 
also will interpret that prefix as being reachable.
Both two draft used The 0xFE00 metric indicates that the prefix is not 
reachable. Doesn't make a difference at this point.

Thanks

Zhibo Hu

> -Original Message-
> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Les Ginsberg
> (ginsberg)
> Sent: Thursday, August 31, 2023 12:31 AM
> To: Peter Psenak ; linchangwang
> ; Acee Lindem ;
> lsr 
> Cc: draft-ppsenak-lsr-igp-unreach-prefix-annou...@ietf.org
> Subject: Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix
> Announcement" - draft-ppsenak-lsr-igp-unreach-prefix-announce-04
> 
> Changwang -
> 
> It is very important to note ...
> 
> 
> > > 2. The Draft #1 utilizes the existing mechanisms [RFC7794] and
> > > [RFC9084] to
> > indicate reachability by checking whether the originator information
> > is
> > >NULL.
> 
> 
> This statement is incorrect. There is no existing mechanism defined in the
> protocol that states that a prefix reachability advertisement sent with a
> source router ID == 0 implies unreachability.
> Please see https://www.rfc-editor.org/rfc/rfc7794.html#section-2.2
> 
> Existing routers, on receiving a prefix reachability advertisement with a
> Source Router ID == 0 will interpret that prefix as being reachable - which
> is exactly the opposite of the intent defined in
> https://www.ietf.org/archive/id/draft-wang-lsr-prefix-unreachable-annouc
> ement-12.txt
> This is one of the things which is broken in this draft.
> This fact has been pointed out to the authors many times over the years -
> but they have consistently ignored it.
> 
> On the other hand,
> https://www.ietf.org/archive/id/draft-ppsenak-lsr-igp-ureach-prefix-annou
> nce-04.txt uses an existing mechanism defined in RFC 5305 to insure that
> legacy routers who do not understand the new use case or the new flags
> will ignore the prefix reachability advertisement. This has been verified by
> testing against multiple implementations.
> 
> Please be accurate in the statements that you make.
> 
>Les
> 
> 
> > -Original Message-
> > From: Lsr  On Behalf Of Peter Psenak
> > Sent: Wednesday, August 30, 2023 8:43 AM
> > To: linchangwang ; Acee Lindem
> > ; lsr 
> > Cc: draft-ppsenak-lsr-igp-unreach-prefix-annou...@ietf.org
> > Subject: Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix
> > Announcement" - draft-ppsenak-lsr-igp-unreach-prefix-announce-04
> >
> > Changwang,
> >
> > On 30/08/2023 08:15, linchangwang wrote:
> > > Hi WG,
> > >
> > > When considering adoption, it's important to take into account the
> > > following
> > drafts as well.
> > >
> > > Draft #1 link：https://www.ietf.org/archive/id/draft-wang-lsr-prefix-
> > unreachable-annoucement-12.txt
> > > Draft #2 link：https://www.ietf.org/archive/id/draft-ppsenak-lsr-igp-
> > ureach-prefix-announce-04.txt
> > >
> > > Reasons are as follows:
> > >
> > > 1. The two drafts mentioned above are similar in nature.
> > >The draft #1 covers more scenarios than the draft #2 as mentioned
> > > by
> > Zhibo Hu mail.
> > >Therefore, a more in-depth discussion and technical comparison
> > > should
> > take place before any adoption decision is made.
> > >
> > > 2. The Draft #1 utilizes the existing mechanisms [RFC7794] and
> > > [RFC9084] to
> > indicate reachability by checking whether the originator information
> > is
> > >NULL. On the other hand, the draft #2 introduces a new flag to
> > > indicate
> > reachability.
> > >From an implementation perspective, it would be easier to
> develop
> > > using
> > the existing RFC mechanisms.
> > >
> > > 3. The Draft #1 covers more scenarios and can address the
> > > aggregation issues
> > of multiple ABRs.
> > >However, the Draft #2 explicitly states in Chapter 6 that it does
> > > not support
> > this scenario.
> >
> > to be more precise, draft #1 talks about more scenarios, it does not
> > solves any of them, as these scenarios can not be solved by what the
> > draft #1 introduces.
> >
> > draft#2 clearly states the fact that these scenarios are not addressed.
> >
> > thanks,
> > Peter
> >
> > >
> > > 4. If we remove the additional scenarios covered in Draft #1 and
> > > compare the
> > two drafts, the only remaining difference is the method of indicating
> > unreachable prefixes -
> > >either through a UPA flag or using the originator TLV.
> > >
> > >
> > > Thanks,
> > > Changwang
> > >
> > >
> > > -Original Message-
> > > From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem
> > > Sent: Thursday, August 24, 2023 3:58 AM
> > > To: lsr
> > > Cc: draft-ppsenak-lsr-igp-unreach-prefix-annou...@ietf.org
> > > Subject: [Lsr] Working Group Adoption of "IGP Unreachable Prefix
> > Announcement" - 

Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft name)

[Huzhibo]

Object its adoption.

https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/ 
(PUA) covering all use cases and scenarios in this document, the PUA describes 
additional more useful use cases and scenarios, including:
1. PUA solves area/domain partition, which is necessary because it often occurs 
on the network.
2. PUA describes a detailed solution to the number of unreachable prefixes that 
exceed the limit.
3. PUA describes the rules for selecting reachable prefixes and unreachable 
prefixes.
I think this content is very useful and necessary. It is recommended that the 
LSR working group adopt a more mature and comprehensive solution.

Thank you.
Zhibo Hu

> -Original Message-
> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem
> Sent: Thursday, August 24, 2023 4:07 AM
> To: lsr 
> Cc: draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org
> Subject: [Lsr] Working Group Adoption of "IGP Unreachable Prefix
> Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed
> draft name)
> 
> LSR Working Group,
> 
> This begins the working group adoption call for “IGP Unreachable Prefix
> Announcement” - draft-ppsenak-lsr-igp-unreach-prefix-announce-04.
> Please indicate your support or objection on this list prior to September
> 7th, 2023.
> 
> 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] IPR Poll for Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-unreach-prefix-announce-04

[Huzhibo]

Object its adoption.

https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/ 
(PUA) covering all use cases and scenarios in this document, the PUA describes 
additional more useful use cases and scenarios, including:
1. PUA solves area/domain partition, which is necessary because it often occurs 
on the network.
2. PUA describes a detailed solution to the number of unreachable prefixes that 
exceed the limit.
3. PUA describes the rules for selecting reachable prefixes and unreachable 
prefixes.
I think this content is very useful and necessary. It is recommended that the 
LSR working group adopt a more mature and comprehensive solution.

Thank you.
Zhibo Hu

> -Original Message-
> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem
> Sent: Thursday, August 24, 2023 3:58 AM
> To: draft-ppsenak-lsr-igp-unreach-prefix-annou...@ietf.org
> Cc: lsr 
> Subject: [Lsr] IPR Poll for Working Group Adoption of "IGP Unreachable
> Prefix Announcement" -
> draft-ppsenak-lsr-igp-unreach-prefix-announce-04
> 
> Co-Authors,
> 
> Are you aware of any IPR that applies to
> draft-posenak-lsr-igp-unreach-prefix-announce-04?
> If so, has this IPR been disclosed in compliance with IETF IPR rules  (see
> RFCs 3979, 4879, 3669 and 5378 for more details).
> 
> There are a few IPR statements already -
> https://datatracker.ietf.org/ipr/search/?submit=draft=draft-ietf-lsr-dyn
> amic-flooding
> 
> If you are listed as a document author or contributor please respond to
> this email regardless of whether or not you are aware of any relevant IPR.
> *The response needs to be sent to the LSR WG mailing
> list.* The document will not advance to the next stage until a response has
> been received from each author and contributor.
> 
> If you are on the LSR WG email list but are not listed as an author or
> contributor, then please explicitly respond only if you are aware of any IPR
> that has not yet been disclosed in conformance with IETF rules.
> 
> Also, since there are nine authors, it would be great if you could reduce
> the author list and make the others contributors (which still requires an
> IPR response).
> 
> 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] IETF-116 LSR - IGP extensions for Advertising Offset forFlex-Algorithm

[Huzhibo]

Hi All：
I agree with Louis about the IGP flooding performance issues brought by 
Flexalgo, especially SRv6. In fact, we have made similar analysis. On a network 
with 1000 nodes, more than eight SRv6 Flexalgos will bring great flooding 
pressure. In fact, Flexalgo has some other points that need to be optimized.
1. Must deploying an independent IPv6 address space for each Flexalgo. 
According to our survey, this also brings a lot of workload to deployment and 
O
2. Flexalgo must be able to bypass to the basic topology. Otherwise, the 
reliability will be greatly reduced.
3: SRv6 Flexalgo needs to provide the per-flow traffic diversion capability.
To solve these problems, we also submitted a document for extending the Topo ID 
of the data plane. This solution allows each Flexalgo to reuse the same Sid/Ip 
address, which can solve the preceding problems.
https://www.ietf.org/archive/id/draft-hu-lsr-igp-ca-flex-algorithm-00.txt
https://datatracker.ietf.org/doc/draft-li-6man-topology-id/

Thanks
Zhibo

> -Original Message-
> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Louis Chan
> Sent: Thursday, April 13, 2023 4:53 PM
> To: Peter Psenak ; linchangwang
> ; 程伟强
> ; Les Ginsberg (ginsbe
> ; Acee Lindem 
> Cc: lsr ; Krzysztof Szarkowicz 
> Subject: Re: [Lsr] IETF-116 LSR - IGP extensions for Advertising Offset
> forFlex-Algorithm
> 
> Hi Peter/all,
> 
> Here I do a simple analysis on this scaling issue.
> 
> 1. Assume a network with these parameters
> - 20 x Flex-algo
> - 2 x core nodes with 1,000 links
> - network diameter with 5 hops
> 
> 2. Just check out the additional advertisement size from core nodes
> following ChangWang example.
> 
> For 1 core node,
> n x 20 x 1000
> MPLS-SR：If n = 10 bytes, it is 200K bytes per core node
> 
> With 2 core nodes, it is 400KB in total
> 
> LSP num: 400KB/1500 = 267 lsps, at least
> 
> 3. About the delivery/flooding rate, from
> https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-fast-flooding/
> >>>
>   As IS-IS is deployed in greater scale both in the number of nodes in
>an area and in the number of neighbors per node, the impact of the
>historic flooding rates becomes more significant.  Consider the
>bringup or failure of a node with 1000 neighbors.  This will result
> <--- 1000 adj links
>in a minimum of 1000 LSP updates.  At typical LSP flooding rates used
> <--- imply 1000 LSP updates
>today (33 LSPs/second), it would take 30+ seconds simply to send the
> <--- 33lsp/s
>updated LSPs to a given neighbor.  Depending on the diameter of the
>network, achieving a consistent LSDB on all nodes in the network
>could easily take a minute or more.
> <--- at least double
> <<<
> 
> 267/33 = 8.1 sec
> 
> 
> With a network diameter of 5, the additional time for delivering the
> consistent LSDB to all remote nodes =
> m x 8.1 sec,where 1 < m < 5 due to inefficiency or implementation
> issue
> 
> It is likely 16+ sec, according to the above description in that draft.
> 
> If using offset solution, it is around 0.008sec x 2 = 0.016sec in additional.
> This number is small.
> 
> Additional of 16+ sec is significant in global convergence time.
> 
> 4. This model/example does not include nodes from second layer, which
> also has 2 x 1,000 adj-sid in the reverse direction. The total number would
> be estimated bigger than 30+ sec.
> 
> Should this be improved?
> 
> 5. Flooding could be in all directions. Larger size of advertisement could
> delay some important update in busy period. i.e. smaller size in
> advertisement is better.
> And I assume this draft with offset would also reduce the refresh
> requirement.
> 
> Rgds
> Louis
> 
> -Original Message-
> From: Peter Psenak 
> Sent: Wednesday, April 12, 2023 11:26 PM
> To: linchangwang ; 程伟强
> ; Louis Chan ;
> Les Ginsberg (ginsbe ; Acee Lindem
> 
> Cc: lsr ; Krzysztof Szarkowicz 
> Subject: Re: [Lsr] IETF-116 LSR - IGP extensions for Advertising Offset
> forFlex-Algorithm
> 
> [External Email. Be cautious of content]
> 
> 
> Hi Changwang,
> 
> please see inline ##PP3:
> 
> On 12/04/2023 16:46, linchangwang wrote:
> > Hi Peter,
> >
> >
> > Please see inline [changwang lin].
> >
> >> Changwang,
> >
> >> please see inline (##PP2):
> >
> >
> > On 12/04/2023 15:13, linchangwang wrote:
> >> Hi Peter
> >>
> >>Please see inline [changwang lin].
> >>
> >>> We've met the same problem when applying Flex Algo in SRv6
> network.
> >>
> >> what problem exactly, can you please describe it?
> >>
> >> [changwang lin]
> >> Advertisement size of per Flex-Algo Adj-SID in the network Related to
> >> F(# of node, # of FA, # of links) For a node with 1,000 links and 20
> >> Flex-Algo
> >>  n x 20 x 1000
> >>  MPLS-SR：If n = 10 bytes, it is 200K bytes
> >>  SRv6：   If n = 24 bytes, it is 400K+ bytes
> >> If 500 nodes:
> >>  MPLS-SR：it is 200K*500   =  10k bytes
> >>  SRv6：   it is 400K+ * 500  = 20k bytes
> >> If interface mtu=1500, lsp length = 1497
> >>LSPs 

Re: [Lsr] New Version Notification for draft-hu-lsr-igp-link-mtu-00.txt

[Huzhibo]

Hi Working group,
We updated a new draft to replace draft-hu-lsr-igp-path-mtu. The updated 
contents are as follows:
1: Updated the draft name to replace draft-hu-lsr-igp-path-mtu.
2: Added the application scenario of IGP link MTU in Segment Routing.
3: We have retained the IS-IS Link MTU protocol extension. We have received 
different comments on whether the IS-IS Link MTU reuses the TRILL Link MTU. We 
hope to collect more comments in the mailist,

Any other comments are welcome.

Thanks
Zhibo Hu

> -Original Message-
> From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
> Sent: Monday, March 13, 2023 10:00 PM
> To: Pengshuping (Peng Shuping) ; xixing (A)
> ; Huzhibo 
> Subject: New Version Notification for draft-hu-lsr-igp-link-mtu-00.txt
> 
> 
> A new version of I-D, draft-hu-lsr-igp-link-mtu-00.txt has been successfully
> submitted by Xing Xi and posted to the IETF repository.
> 
> Name: draft-hu-lsr-igp-link-mtu
> Revision: 00
> Title:IGP Extensions for Link MTU
> Document date:2023-03-13
> Group:Individual Submission
> Pages:10
> URL:
> https://www.ietf.org/archive/id/draft-hu-lsr-igp-link-mtu-00.txt
> Status: https://datatracker.ietf.org/doc/draft-hu-lsr-igp-link-mtu/
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-hu-lsr-igp-link-mtu
> 
> 
> Abstract:
>Segment routing (SR) leverages the source routing mechanism.  It
>allows for a flexible definition of end-to-end paths within IGP
>topologies by encoding paths as sequences of topological sub-paths
>which are called segments.  These segments are advertised by the
>link-state routing protocols (IS-IS and OSPF).  Unlike the MPLS, SR
>does not have the specific path construction signaling so that it
>cannot support the Path MTU.  This draft provides the necessary IS-IS
>and OSPF extensions about the Path MTU that need to be used on SR.
>Here, the term "OSPF" means both OSPFv2 and OSPFv3.
> 
> 
> 
> 
> 
> The IETF Secretariat
> 
> 

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

Re: [Lsr] Slot request for LSR IETF 116

[Huzhibo]

Hi Acee & Yingzhen：
  I would like to request a TimeSlot,We will update a new version:
Draft：draft-hu-lsr-igp-path-mtu
Presenter: Zhibo Hu
Duration: 10 mins
Thanks

Zhibo


From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Yingzhen Qu
Sent: Wednesday, March 1, 2023 2:37 AM
To: lsr-chairs ; lsr 
Subject: [Lsr] Slot request for LSR IETF 116

Dear LSR WG:

The preliminary agenda for IETF 116 has been released, and the LSR session is 
scheduled on Monday Session I (9:30-11:30).

Please send your presentation request to LSR WG chairs 
(lsr-cha...@ietf.org) before the end of Monday 
March 13 with the following info:
· draft to be presented
· presenter name
· estimated time needed, including Q
If there is any question, please let me know.

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

Re: [Lsr] RFC 8362 and LSInfinity

[Huzhibo]

Hi LSR:

LSInfinity
The metric value indicating that the destination described by an
LSA is unreachable. Used in summary-LSAs and AS-external-LSAs

I want to clarify the meaning of unreachable in LSifinity, 
Assume that a node advertise specific route of 1.1.1.1/32, and an aggregate 
route 1.1.0.0/16 is configured.
This node should premature aging of the 1.1.1.1/32 LSA.
If this node using LSInfinity metric instead of prematuring aging, route 
1.1.1.1/32 is still reachable.
Therefore, the "unreachable" described by LSifinity is not really unreachable.

Thanks
Zhibo hu

> -Original Message-
> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak
> Sent: Wednesday, October 5, 2022 5:32 PM
> To: lsr@ietf.org
> Subject: [Lsr] RFC 8362 and LSInfinity
> 
> Hi Folks,
> 
> metric of LSInfinity (0xFF) has been defined in RFC2328:
> 
> LSInfinity
>  The metric value indicating that the destination described by an
>  LSA is unreachable. Used in summary-LSAs and AS-external-LSAs
> as
>  an alternative to premature aging (see Section 14.1). It is
>  defined to be the 24-bit binary value of all ones: 0xff.
> 
> RFC5340 inherited it from RFC2328:
> 
> Appendix B.  Architectural Constants
> 
> Architectural constants for the OSPF protocol are defined in
> Appendix
> B of [OSPFV2].  The only difference for OSPF for IPv6 is that
> DefaultDestination is encoded as a prefix with length 0 (see
> Appendix A.4.1).
> 
> Both RFC2328 and RFC5340 used 16 bits metric for intra-area prefix
> reachability, so the LSInfinity was not applicable for intra-area prefixes.
> 
> RFC8362 defines 24-bit metric for all prefix reachability TLVs -
> Intra-Area-Prefix TLV, Inter-Area-Prefix TLV, External-Prefix TLV.
> Although it is silent about the LSInfinity as such, it is assumed that such
> metric means unreachability for Inter-Area-Prefix TLV and External-Prefix
> TLV. Given that Intra-Area-Prefix TLV now has 24 bits metric as well, it
> would make sense to define the LSInfinity as unreachable for
> Intra-Area-Prefix TLV as well.
> 
> Would anyone object such a clarification in RFC8362?
> 
> 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] Working Group Last Call for "OSPFv3 Extensions for SRv6" - draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

[Huzhibo]

Hi Aijun,

Thanks for your detailed review and please check inline below for responses.


From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Aijun Wang
Sent: Friday, August 19, 2022 5:55 PM
To: 'Acee Lindem (acee)' ; 'lsr' 
Cc: draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org
Subject: Re: [Lsr] Working Group Last Call for "OSPFv3 Extensions for SRv6" - 
draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

Hi, All:
 I have the following comments for this draft, and would like to support 
its forwarding when the below concerns are addressed.


1. For SRv6 SID’s advertisement, I suggest we should also consider it is 
advertised as sub-TLVs of OSPF-Stub-Link TLV, as proposed in 
https://datatracker.ietf.org/doc/html/draft-wang-lsr-stub-link-attributes-04#section-4.1.
  There are situations that such information can be utilized by the routers 
within the area, as I presented at the IETF 114 meeting (the draft is pending 
to be updated).  Then the following sentence:
   “SRv6 SIDs are advertised as Sub-TLVs in the SRv6 Locator TLV except
   for SRv6 End.X SIDs/LAN End.X SIDs which are associated with a
   specific Neighbor/Link and are therefore advertised as Sub-TLVs of E-
   Router-Link TLV.”


Should be relaxed as:
   “SRv6 SIDs are advertised as Sub-TLVs in the SRv6 Locator TLV except
   for SRv6 End.X SIDs/LAN End.X SIDs which are associated with a
   specific Neighbor/Link and are therefore advertised as Sub-TLVs of 
Neighbor/Link related TLVs.”



Zhibo> This description does not affect the new TLVs. If a new TLV is added, 
you can include the sub TLV in the new TLV.



2. Support for the “SRv6 Locator TLV” to be included within the existing 
LSA, rather than to define the new “Locator LSA”.

Zhibo> The reason for defining new LSAs is to prevent processing errors on 
nodes that do not support SRv6. For example, ignoring algorithm fields may 
cause loops.

Of course, using LSinfinity metric is one way to solve this problem, but the 
protocol specifies the IGP does not generate the RIB/Fib for LSinfinity Metric 
prefix.

The LSinfinity metric does not meet this scenario. In addition, IS-IS also 
defines a New TOP TLV. The OSPF definition is the same as that of IS-IS.

Best Regards

Aijun Wang
China Telecom

From: lsr-boun...@ietf.org 
mailto:lsr-boun...@ietf.org>> On Behalf Of Acee Lindem 
(acee)
Sent: Saturday, July 30, 2022 1:17 AM
To: lsr mailto:lsr@ietf.org>>
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] Working Group Last Call for "OSPFv3 Extensions for SRv6" - draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

[Huzhibo]

I support progressing this draft as a co-author. This draft is a basic protocol 
extension of OSPFv3 for SRv6, which is useful and necessary.

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] Question about draft-ppsenak-lsr-igp-ureach-prefix-announce

[Huzhibo]

Peter:

> -Original Message-
> From: Peter Psenak [mailto:ppse...@cisco.com]
> Sent: Friday, August 5, 2022 1:55 PM
> To: Huzhibo 
> Cc: lsr@ietf.org
> Subject: Re: Question about draft-ppsenak-lsr-igp-ureach-prefix-announce
> 
> Zhibo,
> 
> On 03/08/2022 21:09, Huzhibo wrote:
> > Hi Peter:
> >   Please see inline.
> >
> >> -Original Message-
> >> From: Peter Psenak [mailto:ppse...@cisco.com]
> >> Sent: Wednesday, August 3, 2022 11:20 PM
> >> To: Huzhibo 
> >> Cc: lsr@ietf.org
> >> Subject: Re: Question about
> >> draft-ppsenak-lsr-igp-ureach-prefix-announce
> >>
> >> Hi Zhibo,
> >>
> >> On 29/07/2022 20:49, Huzhibo wrote:
> >>> Hi Peter:
> >>>
> >>> Supplement to yesterday's online questions, If a node that does not
> >>> support IP Flexalgo, which has a default route, should the node
> >>> process the IP Flexalgo prefix as a UPA?
> >>
> >> - I assume you are talking about the algo 0 default route. Because IP
> >> Flex-algo default route does not make much sense really.
> >>
> >> - If the node does not support IP flex-algo, than it would not use
> >> any IP algo prefix as BGP service endpoint or for any other purpose.
> >>
> >
> > Which IP Algo prefix as BGP service endpoint is not determined by the 
> > ingress
> node, Such as VXLAN and SRv6 VPN.
> > When the ingress node receives an BGP Service cayyied a IP algo prefix
> > as endpoint and it has a algo 0 default route, it should be process this BGP
> service. and this can not be affected by the IGP Flexalgo prefix.
> 
> sorry, but above is completely wrong.
> 
> When you want to use IP flex-algo forwarding, you must advertise the prefix as
> algo prefix, relying on the algo 0 default would not give you algo forwarding.
> 
> Advertising IP algo prefix at the egress and relying in algo 0 default at the
> ingress is going to cause all sorts of problems. You CAN NOT mix/change algos
> along the path through the network - if you do, you may end up in a permanent
> loop.
  
  If the ingress node does not support Flexalgo, the ingress node does not 
cause a 
permanent loop because once the packet is forwarded to the Flexalgo node, it 
always 
follows Flexalgo forwarding. If the packet does not reach the Flexalgo node, it 
always follows 
Algo 0 forwarding.

> 
> > Therefore,
> > the IGP does only not generate the RIB/Fib for LSinfinity Metric prefix, 
> > but can
> not trigger BGP Service Down.
> > In addition, LSinfinity Metric may be applied to other scenarios in
> > the future. We cannot guarantee that LSinfinity Metric will not conflict 
> > with
> other purposes when being processed as a UPA.
> 
> no, it can not, because the LSinfinity has a very strict definition - it means
> unreachable, which is exactly what the UPA is about.
> 
I believe you are confusing a concept. The LSInfinity metric defined in RFC 
5308 
can be considered as zero route, but PUA/UPA actually defines a negative route.
It's not consistent

> Peter
> 
> >
> >> - If such node receives the IP algo prefix and even if it treats it
> >> as UPA, given that such IP algo prefix was never reachable before on
> >> this node, the UPA would result in no action.
> >>
> >> thanks,
> >> Peter
> >>>
> >>> Thanks
> >>>
> >>> Zhibo
> >>>
> >>
> >
> >
> 

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

Re: [Lsr] IPR Poll Coincident with the Working Group Last Call for "OSPFv3 Extensions for SRv6" - draft-ietf-lsr-ospfv3-srv6-extensions-06.txt

[Huzhibo]

Hi Acee,



I am not aware of any undisclosed IPR that applies to 
draft-ietf-lsr-ospfv3-srv6-extensions-06.txt



thanks,

Zhibo


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

Co-authors,

Are you aware of any IPR that applies to 
draft-ietf-lsr-ospfv3-srv6-extensions-06.txt?

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

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

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

Thanks,
Acee & Chris


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

Re: [Lsr] Question about draft-ppsenak-lsr-igp-ureach-prefix-announce

[Huzhibo]

Hi Peter:
 Please see inline.

> -Original Message-
> From: Peter Psenak [mailto:ppse...@cisco.com]
> Sent: Wednesday, August 3, 2022 11:20 PM
> To: Huzhibo 
> Cc: lsr@ietf.org
> Subject: Re: Question about draft-ppsenak-lsr-igp-ureach-prefix-announce
> 
> Hi Zhibo,
> 
> On 29/07/2022 20:49, Huzhibo wrote:
> > Hi Peter:
> >
> > Supplement to yesterday's online questions, If a node that does not
> > support IP Flexalgo, which has a default route, should the node
> > process the IP Flexalgo prefix as a UPA?
> 
> - I assume you are talking about the algo 0 default route. Because IP 
> Flex-algo
> default route does not make much sense really.
> 
> - If the node does not support IP flex-algo, than it would not use any IP algo
> prefix as BGP service endpoint or for any other purpose.
> 

Which IP Algo prefix as BGP service endpoint is not determined by the ingress 
node, Such as VXLAN and SRv6 VPN. 
When the ingress node receives an BGP Service cayyied a IP algo prefix as 
endpoint and it has a algo 0 default route,
it should be process this BGP service. and this can not be affected by the IGP 
Flexalgo prefix. Therefore, 
the IGP does only not generate the RIB/Fib for LSinfinity Metric prefix, but 
can not trigger BGP Service Down.
In addition, LSinfinity Metric may be applied to other scenarios in the future. 
We cannot guarantee that LSinfinity Metric 
will not conflict with other purposes when being processed as a UPA.

> - If such node receives the IP algo prefix and even if it treats it as UPA, 
> given
> that such IP algo prefix was never reachable before on this node, the UPA
> would result in no action.
> 
> thanks,
> Peter
> >
> > Thanks
> >
> > Zhibo
> >
> 

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

[Lsr] Question about draft-ppsenak-lsr-igp-ureach-prefix-announce

[Huzhibo]

Hi Peter:
Supplement to yesterday's online questions, If a node that does not support IP 
Flexalgo, which has a default route, should the node process the IP Flexalgo 
prefix as a UPA?


Thanks

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

Re: [Lsr] Comments on draft-wang-lsr-prefix-unreachable-annoucement

[Huzhibo]

Peter

> -Original Message-
> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak
> Sent: Friday, July 29, 2022 8:33 AM
> To: Aijun Wang ; Acee Lindem (acee)
> 
> Cc: Ketan Talaulikar ; Les Ginsberg (ginsberg)
> ;
> draft-wang-lsr-prefix-unreachable-annoucem...@ietf.org; lsr 
> Subject: Re: [Lsr] Comments on
> draft-wang-lsr-prefix-unreachable-annoucement
> 
> Aijun,
> 
> On 28/07/2022 19:55, Aijun Wang wrote:
> > Hi, Acee:
> >
> > Thanks for your comments, but most of them are indefensible,
> > especially the conclusion.
> > As you have also noticed, UPA mechanism doesn’t consider the network
> > partition scenarios, doesn’t consider how to control the number of
> > advertisement of unreachable messages, doesn’t provide the explicit
> > notification of unreachable statement(as also pointed out Ketan, Bruno
> > etc.), then how you hurry to get the conclusion that UPA is superior to PUA?
> 
> IETF documents are not deployment guides, nor design or implementation
> documents, not the source of education for the other vendors.
> 
> IETF documents are there to specify the bare minimum to achieve
> interoperability.
> 
> In other words, the fact that you put more content in your document, does not
> make it any better. Contrary, the less you need to do to achieve the
> interoperability, the better it is.

[HZB] More content you mentioned of the documents are addresses comments on the 
promotion of this document.
It is an essential part of a complete solution. 
RFC 5305 define that LSInfinity metric is used for other purposes other than
building the normal routing table. UPA uses LSInfinity metric only to identify 
unreachable prefixes, which is contrary to RFC 5305. 
[draft-ietf-lsr-ip-flexalgo] also uses LSInfinity metric. It may also be 
applied to other purposes. Therefore, using LSInfinity metric alone is not 
enough.
In conclusion, the PUA solution is more complete and the unreachable prefix is 
defined in a more reasonable manner.

Zhibo Hu


> Peter
> 
> 
> >
> > We have yet mentioned that PUA mechanism has been discussed two years
> > before the UPA solution.
> >
> > More responses are inline. Anyway, I am glad that your comments have
> > some bases, although you misunderstood something.
> >
> > Aijun Wang
> > China Telecom
> >
> >> On Jul 29, 2022, at 02:04, Acee Lindem (acee)  wrote:
> >>
> >> Speaking as WG Member:
> >>
> >> Hi Ketan,
> >>
> >> Thanks for pointing out the similarities. Even after the recent
> >> changes,  there are still some difference between the drafts which
> >> I’ll describe in the baseless comments which follow. For conciseness,
> >> I’ll refer to the drafts as PUA (Draft Wang) and UPA (Draft Psenak).
> >>
> >>  1. Backward Compatibility – Now that PUA has appropriated the metric
> >> mechanisms from UPA, it is also backward compatible. However, PUA
> >> still proposes extensions the IGPs to advertise the PUA
> >> capabilities and says the nodes may misbehave if they don’t agree
> >> on these capabilities. I guess removing these was omitted when the
> >> UPA metric mechanisms were appropriated.
> >
> > WAJ] No. the context in the document just describes why and when the
> > LSInfinity is necessary. The usages of LSInfinity in two drafts are
> > different: one(PUA) is to avoid the misbehavior(which is conform to
> > the RFC rules), another(UPA) is to indicate the unreachable
> > information(which is not described in the RFC rules)
> >
> >> 1.
> >>  2. Receive Router Behavior – For UPA, the unreachable prefix
> >> notification is solely for an event signal to be used by other
> >> routers in the IGP domain to trigger actions, e.g., BGP PIC
> >> excluding the unreachable prefix.  PUA is used for the switchover
> >> of services as well but is also used to modify persistent state.
> >> In section 4, the PUA advertisement will trigger the advertisement
> >> of the prefix by an ABR that does have a route to the unreachable
> >> prefix advertised by another ABR.
> > [WAJ] Is this one evidence that PUA covers UPA?
> >>
> >> 2.
> >>  3. Advertisement Persistence – PUA is advertised like any other LSA
> >> and presumably advertised as long as the prefix is unreachable.
> >> Conversely, UPA is an ephemeral LSA that will be withdrawn after
> >> enough time is allowed for the event notification to propagate.
> > [WAJ] No. if there is no network update again, the PUA will not be
> > advertised “as long as the prefix is unreachable “. Actually, there is
> > description in the document:
> >
> > “The advertisement of PUAM message should only last one
> configurable
> > period to allow the services that run on the failure prefixes are
> > switchovered.  If one prefix is missed before the PUAM takes effect,
> > the ABR will not declare its absence via the PUAM.”
> >
> >
> > I think you may ignore them.
> >
> >>3.
> >>
> >> In my opinion, UPA is superior to PUA since it is addresses the
> >> original 

[Lsr] Data Plane topology ID

[Huzhibo]

Hi 6man and LSR:
We submitted a draft of the DataPlane extension Topo ID: 
https://tools.ietf.org/id/draft-li-6man-topology-id-00.txt

  
https://tools.ietf.org/id/draft-hu-lsr-igp-ca-flex-algorithm-00.txt
This draft sloves the following problem: MT And Flexalgo Shared Addresses 
Space. RFC5120 defines if the topologies are quality of
Service (QoS) partitioned, then the Differentiated Services CodePoint (DSCP) 
bits in the IP packet header can be utilized to make the
decision.
However, we now apply MT and Flexalgo to other scenarios, such as slicing, 
where QoS cannot be used to differentiate topologies.
This document introduces a dedicated data plane ID to distinguish between 
different topologies. In this way, different topologies (MT or Flexalgo)
can reuse the same address space, simplifying multi-topology deployment and 
improving multi-topology performance.
Any comments and question are welcome. In addition, from the carrier's 
perspective, does deploying an independent address space on each plane bring 
complexity?

Thanks
Zhibo Hu


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

[Lsr] Data Plane Topology ID

[Huzhibo]

Hi LSR:
We submitted a draft of the DataPlane extension Topo ID: 
https://tools.ietf.org/id/draft-li-6man-topology-id-00.txt.
This draft sloves the following problem: MT And Flexalgo Shared Addresses 
Space. RFC5120 defines if the topologies are quality of
Service (QoS) partitioned, then the Differentiated Services CodePoint (DSCP) 
bits in the IP packet header can be utilized to make the
decision.
However, we now apply MT and Flexalgo to other scenarios, such as slicing, 
where QoS cannot be used to differentiate topologies.
This document introduces a dedicated data plane ID to distinguish between 
different topologies. In this way, different topologies (MT or Flexalgo)
can reuse the same address space, simplifying multi-topology deployment and 
improving multi-topology performance.
We expect your review and comments.

Thanks
Zhibo Hu

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

Re: [Lsr] Handling multiple Extended IS Reachability TLVs for a link

[Huzhibo]

Hi Everyone:

I think it is necessary to specify the key of the TLV and the information that 
needs to be carried repeatedly in this document. I am not sure that everyone 
has the same understanding of the key. If different vendors have different 
understandings of the key, there may be interoperability problems.

Thanks

Zhibo

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Ketan Talaulikar
Sent: Thursday, June 30, 2022 11:15 AM
To: Les Ginsberg (ginsberg) 
Cc: Tony Li ; draft-pkaneria-lsr-multi-...@ietf.org; lsr 

Subject: Re: [Lsr] Handling multiple Extended IS Reachability TLVs for a link

Hi Les,

Please check inline below.

On Wed, Jun 29, 2022 at 11:05 PM Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>> wrote:
Ketan –

To add to what Tony has said…one thing which we did not want this draft to 
become was for it to be the place where a definition of the “key” for every TLV 
was defined.

KT> I agree.

Perhaps in the text you quote “MUST” should not be capitalized as we are simply 
describing the generic logic required.

KT> I think it would be better for the first part of the draft to just describe 
the general rules/logic for handling these cases. This part should stand on its 
own. Whether it needs to be normative or not, can be discussed later. IMHO, if 
normative language is better and the text can be worked out as the document 
progresses.


It is also worth pointing out that this draft is not defining new behavior nor 
is it extending the protocol in any way.

KT> I don't fully agree with that ...

The use of multiple TLVs for a given object is already implemented and deployed 
by multiple vendors and does not require any protocol extensions.

KT> I agree that this problem has been around for some time now. I agree that 
there are implementations that have "worked out a solution" and that they are 
also deployed. There aren't that many ways to tackle this after all ;-) ... 
that said, this handling is not yet specified in an RFC or ISO document, right? 
If not then, IMHO, this is an extension of the protocol behavior.

Given the increasing need for using multiple TLVs, it seemed prudent to 
document the generic behavior – which is the motivation for this draft.

KT> Agree. Also agree at a high level with the proposal. Again, there are not 
too many different ways to go about this :-)

But there is no intent to discuss all possible TLVs to which this behavior 
might apply.

KT> Agree

If you expect that then I think we are not in sync.

It has been discussed that the most common cases where multiple TLVs are likely 
to be required are the Prefix Reachability TLVs and the IS Neighbor TLVs. As 
such, it might not be a bad idea to discuss these two cases (the draft already 
discusses Prefix Reachability).

KT> For most TLVs/sub-TLVs, I believe the "keys" are part of the fixed form and 
hence the problem (unspecified keys) that I mentioned in my first email on this 
thread does not arise. There are though, some TLVs, where the keys remain 
unspecified and I strongly believe that (at least the most important of those?) 
need to be tackled in this document for it to help implementors.

Thanks,
Ketan


   Les

From: Ketan Talaulikar mailto:ketant.i...@gmail.com>>
Sent: Wednesday, June 29, 2022 9:33 AM
To: Tony Li mailto:tony...@tony.li>>
Cc: 
draft-pkaneria-lsr-multi-...@ietf.org;
 lsr mailto:lsr@ietf.org>>
Subject: Re: Handling multiple Extended IS Reachability TLVs for a link

Hi Tony,

No. It does not work. Take the following text from Sec 4.


   If this is insufficient sub-TLV space, then the node MAY advertise

   additional instances of the Extended IS Reachability TLV.  The key

   information MUST be replicated identically and the additional sub-TLV

   space may be populated with additional information.  The complete

   information for a given key in such cases is the joined set of all

   the carried information under the key in all the TLV instances.

There is a normative MUST there, but the "key information" is unspecified. 
Without that information these rules would not be really useful for 
implementation, would they?

I agree with the challenge of trying to catalog "keys" and "rules" on a per 
TLV/sub-TLV basis. Perhaps starting with the more widely used TLVs/sub-TLVs 
that are likely to exceed limits would be better than not covering any of them?

Thanks,
Ketan

On Wed, Jun 29, 2022 at 9:53 PM Tony Li 
mailto:tony...@tony.li>> wrote:

Hi Ketan,

We are hoping to not be that detailed in this document.  As soon as we become a 
catalog of LSPs, then the applicability of our statements is weakened with 
respect to TLVs that aren’t in the catalog.

What we’re trying to accomplish is to write some general rules that we all 
understand that apply uniformly across all TLVs that don’t specify their own 
overflow mechanisms.

Does this work for you?

Tony


> On Jun 29, 2022, at 6:47 AM, Ketan Talaulikar 
> mailto:ketant.i...@gmail.com>> 

Re: [Lsr] Working Group Last Call for draft-ietf-lsr-ip-flexalgo-04 - "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks"

[Huzhibo]

Hi Ketan:
I agree with you.
IGP MT is a good precedent. If IPv4 and IPv6 use the same MT, the IPv4 and IPv6 
topologies must be the same. The same MT does not define separate topologies or 
path computation for different data planes. If IPv4 and IPv6 data plane has 
different topologies, different MTs are used. I suggest Flexalgo uses the same 
logic as MT.

Thanks

Zhibo

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Ketan Talaulikar
Sent: Wednesday, April 13, 2022 12:01 PM
To: Peter Psenak 
Cc: lsr@ietf.org; draft-ietf-lsr-ip-flexa...@ietf.org; Acee Lindem (acee) 

Subject: Re: [Lsr] Working Group Last Call for draft-ietf-lsr-ip-flexalgo-04 - 
"IGP Flexible Algorithms (Flex-Algorithm) In IP Networks"

Hi Peter,

Please check inline below with KT2. I am trimming everything other than the one 
point of continuing debate.

>  >
>  > 2) The relationship between the algo usage for IP FlexAlgo and other
>  > data planes (e.g. FlexAlgo with SR) is not very clear. There arise
>  > complications when the algo usage for IP FlexAlgo overlap with other
>  > (say SR) data planes since the FAD is shared but the node
> participation
>  > is not shared. While Sec 9 suggests that we can work through these
>  > complications, I question the need for such complexity. The FlexAlgo
>  > space is large enough to allow it to be shared between various data
>  > planes without overlap. My suggestion would be to neither carve out
>  > parallel algo spaces within IGPs for various types of FlexAlgo data
>  > planes nor allow the same algo to be used by both IP and SR data
> planes.
>  > So that we have a single topology computation in the IGP for a given
>  > algo based on its FAD and data plane participation and then when it
>  > comes to prefix calculation, the results could involve
> programming of
>  > entries in respective forwarding planes based on the signaling of
> the
>  > respective prefix reachabilities. The coverage of these aspects in a
>  > dedicated section upfront will help.
>
> ##PP
> I strongly disagree.
>
> FAD is data-pane/app independent. Participation is data-plane/app
> dependent. Base flex-algo specification is very clear about that. That
> has advantages and we do not want to modify that part.
>
>
> KT> No issue with this part.
>
>
> Topology calculation for algo/data-plane needs to take both FAD and
> participation into account. You need independent calculation for each
> data-plane/app in the same algo.
>
>
> KT> So, an implementation now needs to potentially support performing
> multiple topology computations for each algo. This is a complication for
> which I do not see the justification. Why not just pick different
> algorithms for different data planes for those (rare?) deployments where
> someone wants multiple data planes?

##PP2
flex-algo architecture supports multiple apps/data-planes per algo, with
unique participation per app/data-plane. That requires per-algo/per
app/data-plane calculation. What is complicated on it?

KT2> This specific and precise statement that you have provided is not covered 
in either draft-ietf-lsr-flex-algo or this document. For starters, this needs 
to be clarified and covered so that it gets the attention of any reader during 
the review. This has implications for implementations.


If your implementation does not want to support it, fine, but the
architecture allows it and there is/are implementation(s) that already
support it. This is not defined in this draft, it's defined in base
flex-algo spec.

KT2> I am not sure if it is really an option for implementation once it is in 
the specification. And this is not about "my" implementation :-). So it is not 
that because some implementations can do (or does) it that it should be in the 
specification. The determination on whether it should be in a specification 
needs to be based on the tradeoff between requiring multiple computations per 
algo with the potential benefit or use case that is enabled by it.



>
>
> The fact that the same FAD is shareable between all apps has it
> advantages and use cases - e.g. if the participation for algo X is the
> same in SR and IP data-planes, one can use SR to protect IP in that
> algo.
>
>
> KT> Would this protection use case not violate the base FlexAlgo rule
> that the protection has to remain within the specific topology. If there
> is an SR data plane, then why would one want an IP data plane as well?

##PP2
if the participation in two app/data-planes is the same for the algo,
the resulting topology is the same. If your implementation is smart, it
can only run a single computation for that case. There is no violation
here whatsoever.

KT2> If the resulting topology is the same between SR data plane and IP data 
plane, what is the need to enable the IP data plane? Why not just steer the IP 
traffic over the FlexAlgo data plane? And when it 

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

[Huzhibo]

Hi, WG:

This draft provides a way to advertise the stub link and their associated 
attributes.
I support its adoption as a co-author.
 
I am not aware of any IPR that related to this draft.


Best Regards

Zhibo hu

-Original Message-
From: Lsr [mailto: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] 答复: 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Huzhibo]

Hi Robert:

There may be other egress protection solution. However, the PLR is a P node and 
cannot sense BGP information. The PLR needs to establish a master/backup PE 
relationship. In some implementations as I know, It was manually specified in 
some way. Dynamic and automated I'm not sure if there's a available and safe 
solution.

Regards

Zhibo

发件人: Lsr [mailto:lsr-boun...@ietf.org] 代表 Robert Raszuk
发送时间: 2021年11月26日 17:00
收件人: Huzhibo 
抄送: Les Ginsberg (ginsberg) ; Gyan Mishra 
; Acee Lindem (acee) ; Christian Hopps 
; Aijun Wang ; Tony Li 
; lsr ; Shraddha Hegde 
; Tony Przygienda 
主题: Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting 
Minutes


Huzhibo,

> specifying the master/backup relationship of egress protection is complex

Sure is - but there is absolutely no requirement to do it. BGP already carries 
all information needed to instantiate such protection. It is therefore all 
dynamic and automated.

As said cost is extra LFIB space on the PEs acting as a backup. With per VRF or 
per CE label allocation that is not big deal. With per prefix label allocation 
yes that can be a resource constraint to consider.

So if we are discussing drawbacks of any proposal let's just use correct 
arguments :)

Cheers,
R.






On Fri, Nov 26, 2021 at 9:09 AM Huzhibo 
mailto:40huawei@dmarc.ietf.org>> wrote:
Hi, Shraddha:

 If there are a large number of CE-to-PE mix-homing scenarios, specifying 
the master/backup relationship of egress protection is complex, which greatly 
increases deployment complexity. Therefore, local protection is not applicable 
to all scenarios. In addition, local protection also generates suboptimal 
paths. Therefore, even if local protection is deployed, speeding up ingress PE 
convergence is useful.

Regards

Zhibo

From: Lsr [mailto:lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org>] On Behalf 
Of Shraddha Hegde
Sent: Friday, November 26, 2021 12:49 PM
To: Huzhibo 
mailto:40huawei@dmarc.ietf.org>>; 
Aijun Wang mailto:wangai...@tsinghua.org.cn>>; 'Tony 
Li' mailto:tony...@tony.li>>
Cc: 'Les Ginsberg (ginsberg)' mailto:ginsb...@cisco.com>>; 
'Gyan Mishra' mailto:hayabusa...@gmail.com>>; 'Christian 
Hopps' mailto:cho...@chopps.org>>; 'lsr' 
mailto:lsr@ietf.org>>; 'Acee Lindem (acee)' 
mailto:a...@cisco.com>>; 'Tony Przygienda' 
mailto:tonysi...@gmail.com>>
Subject: Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR 
Meeting Minutes

Huzhibo,

Local protection is always executed on the node where failure occurs (for link 
protection) and the previous node
(for node failure). You don’t really require the failure event to propagate to 
another domain to trigger local protection.

Rgds
Shraddha



Juniper Business Use Only
From: Huzhibo 
mailto:huzhibo=40huawei@dmarc.ietf.org>>
Sent: Thursday, November 25, 2021 3:04 PM
To: Shraddha Hegde mailto:shrad...@juniper.net>>; Aijun 
Wang mailto:wangai...@tsinghua.org.cn>>; 'Tony Li' 
mailto:tony...@tony.li>>
Cc: 'Les Ginsberg (ginsberg)' mailto:ginsb...@cisco.com>>; 
'Gyan Mishra' mailto:hayabusa...@gmail.com>>; 'Christian 
Hopps' mailto:cho...@chopps.org>>; 'lsr' 
mailto:lsr@ietf.org>>; 'Acee Lindem (acee)' 
mailto:a...@cisco.com>>; 'Tony Przygienda' 
mailto:tonysi...@gmail.com>>
Subject: RE: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR 
Meeting Minutes

[External Email. Be cautious of content]

Hi, Shraddha:

If you punch a hole in the summary, the other area nodes come to know about the 
mid-point failure.---> Yes, you're right. Once any node knows about the 
mid-point failure，It can execution local protection by looking up next sid to 
fix SRv6 Policy reachability.

Thanks

Zhibo


From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Shraddha Hegde
Sent: Thursday, November 25, 2021 12:11 PM
To: Aijun Wang mailto:wangai...@tsinghua.org.cn>>; 
'Tony Li' mailto:tony...@tony.li>>
Cc: 'Les Ginsberg (ginsberg)' mailto:ginsb...@cisco.com>>; 
'Gyan Mishra' mailto:hayabusa...@gmail.com>>; 'Christian 
Hopps' mailto:cho...@chopps.org>>; 'lsr' 
mailto:lsr@ietf.org>>; 'Acee Lindem (acee)' 
mailto:a...@cisco.com>>; 'Tony Przygienda' 
mailto:tonysi...@gmail.com>>
Subject: Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR 
Meeting Minutes

Aijun,

There are multiple possible solutions for the SR-Policy mid-point failure 
scenario
1.   Use anycast SID as mid-points for redundancy
2.   Mid-point failure local protection by looking up next sid (This is 
probably the one you pointed out)
3.   E2E S-BFD for SR-Policy  path liveness detection

If you punch a hole in the summary, the other area nodes come to know about the 
mid-point failure
and remove the failed node reachability. It is not clear how that is solving 
the SR-Policy liveness problem.

Rgds
Shraddha



Juniper Busine

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Huzhibo]

Hi, Shraddha:

 If there are a large number of CE-to-PE mix-homing scenarios, specifying 
the master/backup relationship of egress protection is complex, which greatly 
increases deployment complexity. Therefore, local protection is not applicable 
to all scenarios. In addition, local protection also generates suboptimal 
paths. Therefore, even if local protection is deployed, speeding up ingress PE 
convergence is useful.

Regards

Zhibo

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Shraddha Hegde
Sent: Friday, November 26, 2021 12:49 PM
To: Huzhibo ; Aijun Wang 
; 'Tony Li' 
Cc: 'Les Ginsberg (ginsberg)' ; 'Gyan Mishra' 
; 'Christian Hopps' ; 'lsr' 
; 'Acee Lindem (acee)' ; 'Tony Przygienda' 

Subject: Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR 
Meeting Minutes

Huzhibo,

Local protection is always executed on the node where failure occurs (for link 
protection) and the previous node
(for node failure). You don’t really require the failure event to propagate to 
another domain to trigger local protection.

Rgds
Shraddha



Juniper Business Use Only
From: Huzhibo 
mailto:huzhibo=40huawei@dmarc.ietf.org>>
Sent: Thursday, November 25, 2021 3:04 PM
To: Shraddha Hegde mailto:shrad...@juniper.net>>; Aijun 
Wang mailto:wangai...@tsinghua.org.cn>>; 'Tony Li' 
mailto:tony...@tony.li>>
Cc: 'Les Ginsberg (ginsberg)' mailto:ginsb...@cisco.com>>; 
'Gyan Mishra' mailto:hayabusa...@gmail.com>>; 'Christian 
Hopps' mailto:cho...@chopps.org>>; 'lsr' 
mailto:lsr@ietf.org>>; 'Acee Lindem (acee)' 
mailto:a...@cisco.com>>; 'Tony Przygienda' 
mailto:tonysi...@gmail.com>>
Subject: RE: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR 
Meeting Minutes

[External Email. Be cautious of content]

Hi, Shraddha:

If you punch a hole in the summary, the other area nodes come to know about the 
mid-point failure.---> Yes, you're right. Once any node knows about the 
mid-point failure，It can execution local protection by looking up next sid to 
fix SRv6 Policy reachability.

Thanks

Zhibo


From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Shraddha Hegde
Sent: Thursday, November 25, 2021 12:11 PM
To: Aijun Wang mailto:wangai...@tsinghua.org.cn>>; 
'Tony Li' mailto:tony...@tony.li>>
Cc: 'Les Ginsberg (ginsberg)' mailto:ginsb...@cisco.com>>; 
'Gyan Mishra' mailto:hayabusa...@gmail.com>>; 'Christian 
Hopps' mailto:cho...@chopps.org>>; 'lsr' 
mailto:lsr@ietf.org>>; 'Acee Lindem (acee)' 
mailto:a...@cisco.com>>; 'Tony Przygienda' 
mailto:tonysi...@gmail.com>>
Subject: Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR 
Meeting Minutes

Aijun,

There are multiple possible solutions for the SR-Policy mid-point failure 
scenario
1.   Use anycast SID as mid-points for redundancy
2.   Mid-point failure local protection by looking up next sid (This is 
probably the one you pointed out)
3.   E2E S-BFD for SR-Policy  path liveness detection

If you punch a hole in the summary, the other area nodes come to know about the 
mid-point failure
and remove the failed node reachability. It is not clear how that is solving 
the SR-Policy liveness problem.

Rgds
Shraddha



Juniper Business Use Only
From: Aijun Wang mailto:wangai...@tsinghua.org.cn>>
Sent: Wednesday, November 24, 2021 11:14 AM
To: Shraddha Hegde mailto:shrad...@juniper.net>>; 'Tony 
Li' mailto:tony...@tony.li>>
Cc: 'Les Ginsberg (ginsberg)' mailto:ginsb...@cisco.com>>; 
'Gyan Mishra' mailto:hayabusa...@gmail.com>>; 'Christian 
Hopps' mailto:cho...@chopps.org>>; 'lsr' 
mailto:lsr@ietf.org>>; 'Acee Lindem (acee)' 
mailto:a...@cisco.com>>; 'Tony Przygienda' 
mailto:tonysi...@gmail.com>>
Subject: RE: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR 
Meeting Minutes

[External Email. Be cautious of content]

Hi, Shraddha:

If the traffic is steered via the SRv6 policy, the intermediate points should 
also be protected. There are already one draft to propose the solution( please 
refer to 
https://datatracker.ietf.org/doc/html/draft-chen-rtgwg-srv6-midpoint-protection-05<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-chen-rtgwg-srv6-midpoint-protection-05__;!!NEt6yMaO-gk!SSAVRO90Q62ieX5DTTgZBW4FKiC_YHXU9biL8pK-jEOUv7jmUHGUaHAt89kXBaSb$>.)
  In such situation, if the intermediate points located in different areas, how 
then know the liveness of each other if ABR has the summary address advertised? 
We will not consider to configure BFD on every intermediate points.


Best Regards

Aijun Wang
China Telecom

From: lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org> 
mailto:lsr-boun...@ietf.org>> On Behalf Of Shraddha Hegde
Sent: Wednesday, November 24, 2021 1:20 PM
To: Tony Li mailto:tony...@tony.li>>; Aijun Wang 
mailto:wangai...@tsinghua.org.cn>>
Cc: Les Ginsberg (ginsberg) mailto:ginsb

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Huzhibo]

Hi, Shraddha:

If you punch a hole in the summary, the other area nodes come to know about the 
mid-point failure.---> Yes, you're right. Once any node knows about the 
mid-point failure，It can execution local protection by looking up next sid to 
fix SRv6 Policy reachability.

Thanks

Zhibo


From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Shraddha Hegde
Sent: Thursday, November 25, 2021 12:11 PM
To: Aijun Wang ; 'Tony Li' 
Cc: 'Les Ginsberg (ginsberg)' ; 'Gyan Mishra' 
; 'Christian Hopps' ; 'lsr' 
; 'Acee Lindem (acee)' ; 'Tony Przygienda' 

Subject: Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR 
Meeting Minutes

Aijun,

There are multiple possible solutions for the SR-Policy mid-point failure 
scenario
1.   Use anycast SID as mid-points for redundancy
2.   Mid-point failure local protection by looking up next sid (This is 
probably the one you pointed out)
3.   E2E S-BFD for SR-Policy  path liveness detection

If you punch a hole in the summary, the other area nodes come to know about the 
mid-point failure
and remove the failed node reachability. It is not clear how that is solving 
the SR-Policy liveness problem.

Rgds
Shraddha



Juniper Business Use Only
From: Aijun Wang mailto:wangai...@tsinghua.org.cn>>
Sent: Wednesday, November 24, 2021 11:14 AM
To: Shraddha Hegde mailto:shrad...@juniper.net>>; 'Tony 
Li' mailto:tony...@tony.li>>
Cc: 'Les Ginsberg (ginsberg)' mailto:ginsb...@cisco.com>>; 
'Gyan Mishra' mailto:hayabusa...@gmail.com>>; 'Christian 
Hopps' mailto:cho...@chopps.org>>; 'lsr' 
mailto:lsr@ietf.org>>; 'Acee Lindem (acee)' 
mailto:a...@cisco.com>>; 'Tony Przygienda' 
mailto:tonysi...@gmail.com>>
Subject: RE: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR 
Meeting Minutes

[External Email. Be cautious of content]

Hi, Shraddha:

If the traffic is steered via the SRv6 policy, the intermediate points should 
also be protected. There are already one draft to propose the solution( please 
refer to 
https://datatracker.ietf.org/doc/html/draft-chen-rtgwg-srv6-midpoint-protection-05.)
  In such situation, if the intermediate points located in different areas, how 
then know the liveness of each other if ABR has the summary address advertised? 
We will not consider to configure BFD on every intermediate points.


Best Regards

Aijun Wang
China Telecom

From: lsr-boun...@ietf.org 
mailto:lsr-boun...@ietf.org>> On Behalf Of Shraddha Hegde
Sent: Wednesday, November 24, 2021 1:20 PM
To: Tony Li mailto:tony...@tony.li>>; Aijun Wang 
mailto:wangai...@tsinghua.org.cn>>
Cc: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
Gyan Mishra mailto:hayabusa...@gmail.com>>; Christian 
Hopps mailto:cho...@chopps.org>>; lsr 
mailto:lsr@ietf.org>>; Acee Lindem (acee) 
mailto:a...@cisco.com>>; Tony Przygienda 
mailto:tonysi...@gmail.com>>
Subject: Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR 
Meeting Minutes

WG,

MPLS egress protection framework RFC 8679 provides a mechanism to locally 
protect the traffic during
PE failures. The concepts can be applied to SRv6 as well. This mechanism is 
much more efficient and quick because it locally provides fast protection
And switchover to the other PE.
If you compare this  to  the mechanisms being discussed in this thread where 
the failure information is being
propagated by the egress PE to ABR and then  ABR to the ingress, the failover 
is going to be much slower.
The egress protection technology does not flood any information outside of the 
domain and hence does not
affect the IGP scale.

This is a valid alternate solution to solve the problem at hand IMO.
I would be interested to see if people have use cases where egress protection 
can’t be applied.

Rgds
Shraddha




Juniper Business Use Only
From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Tony 
Li
Sent: Tuesday, November 23, 2021 10:22 PM
To: Aijun Wang mailto:wangai...@tsinghua.org.cn>>
Cc: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
Gyan Mishra mailto:hayabusa...@gmail.com>>; Christian 
Hopps mailto:cho...@chopps.org>>; lsr 
mailto:lsr@ietf.org>>; Acee Lindem (acee) 
mailto:a...@cisco.com>>; Tony Przygienda 
mailto:tonysi...@gmail.com>>
Subject: Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR 
Meeting Minutes

[External Email. Be cautious of content]


Hi Aijun,

I object to adding negative liveness to the LSDB because of the scale and 
because it adds scale during failures.
[WAJ] If we have no such mechanism, operator should either advertise the host 
routes across areas(which has scale problem), or lose the fast convergences for 
some overlay services(which defeat the user experiences).
Within the real network, there is very rare chance for the massive failure. And 
even such thing happen 

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Huzhibo]

Hi Shraddha:
 MPLS egress protection is a FRR mechanism, PUA is a hard convergence 
mechanism. I don't think there's a conflict between the two solution.
Also, as far as I know, MPLS egress protection has not been deployed on a large 
scale.

Thanks

Zhibo

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Shraddha Hegde
Sent: Wednesday, November 24, 2021 1:20 PM
To: Tony Li ; Aijun Wang 
Cc: Les Ginsberg (ginsberg) ; Gyan Mishra 
; Christian Hopps ; lsr 
; Acee Lindem (acee) ; Tony Przygienda 

Subject: Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR 
Meeting Minutes

WG,

MPLS egress protection framework RFC 8679 provides a mechanism to locally 
protect the traffic during
PE failures. The concepts can be applied to SRv6 as well. This mechanism is 
much more efficient and quick because it locally provides fast protection
And switchover to the other PE.
If you compare this  to  the mechanisms being discussed in this thread where 
the failure information is being
propagated by the egress PE to ABR and then  ABR to the ingress, the failover 
is going to be much slower.
The egress protection technology does not flood any information outside of the 
domain and hence does not
affect the IGP scale.

This is a valid alternate solution to solve the problem at hand IMO.
I would be interested to see if people have use cases where egress protection 
can’t be applied.

Rgds
Shraddha




Juniper Business Use Only
From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Tony 
Li
Sent: Tuesday, November 23, 2021 10:22 PM
To: Aijun Wang mailto:wangai...@tsinghua.org.cn>>
Cc: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
Gyan Mishra mailto:hayabusa...@gmail.com>>; Christian 
Hopps mailto:cho...@chopps.org>>; lsr 
mailto:lsr@ietf.org>>; Acee Lindem (acee) 
mailto:a...@cisco.com>>; Tony Przygienda 
mailto:tonysi...@gmail.com>>
Subject: Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR 
Meeting Minutes

[External Email. Be cautious of content]


Hi Aijun,

I object to adding negative liveness to the LSDB because of the scale and 
because it adds scale during failures.
[WAJ] If we have no such mechanism, operator should either advertise the host 
routes across areas(which has scale problem), or lose the fast convergences for 
some overlay services(which defeat the user experiences).
Within the real network, there is very rare chance for the massive failure. And 
even such thing happen accidently, the information about node liveness is 
countable, is there any router can’t process such information?
The received unreachable information does not trigger the SPF calculation. Will 
they influence intensively the performance of the router?


If the scale is equal, then I would prefer to see flooding positive information 
rather than negative information.  Operationally this is key: if there is a 
failure and positive information doesn’t propagate, then it’s a bug that will 
be found in due course and the operator can react outside of a failure scenario.

Having a scale failure on top of a topology failure is a far more painful 
scenario.

The odds of a mass failure may be low. The fact of the matter is that they 
still happen. It is our job to ensure that the IGP performs well when it does.

Increasing the size of the LSDB always affects performance. It slows flooding. 
Some nodes may not realize that SPF is not needed.  When LSP fragments are 
rearranged, inferring that SPF is not necessary is non-trivial. Impacting 
router and network performance is a given.


My understanding is that N node failures would result in O(N) bytes added to 
the LSDB.  If someone has a way to compress that information to O(1), I (and 
Claude Shannon) would be interested.
[WAJ] Do you have other determined solutions except the PUB/SUB mechanism that 
does not exist in current IGP?


None of the mechanisms being discussed currently exist.

I have no objections to Robert’s BGP propagation ideas if that’s workable.

This is simply not the IGP’s job and the IGP is not a dump truck.

Tony


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

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

[Huzhibo]

I am not aware of any IPR related to the draft. 

Best Regards,
zhibo

-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] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID Advertisement"

[Huzhibo]

Hi:
I don't support the adoption of this document.Reserve different queue 
resources 
for different algorithms is not a existing feature of Flexalgo, I don't think 
it's appropriate to include it in this document. 
if needed it should be discussed separately from the per flexalgo adj sid 
extension

Best regards,
Zhibo

-Original Message-
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps
Sent: Thursday, May 27, 2021 4:57 AM
To: lsr@ietf.org
Cc: cho...@chopps.org
Subject: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID 
Advertisement"


Hi Folks,

This begins a 2 week WG Adoption Call for the following draft:

https://datatracker.ietf.org/doc/draft-peng-lsr-algorithm-related-adjacency-sid/

Please indicate your support or objections by June 9th, 2021

Authors, please respond to the list indicating whether you are aware of any IPR 
that applies to this draft.

Thanks,
Acee and 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] 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

[Huzhibo]

Support the adoption.

Zhibo Hu

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] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

[Huzhibo]

Hi peter:

If you think that IP and SR are two applications, which 
application-specific link attributes should IP flexalgo use?

Thanks
Zhibo

-Original Message-
From: Peter Psenak [mailto:ppse...@cisco.com] 
Sent: Friday, December 11, 2020 6:11 PM
To: Huzhibo ; Dongjie (Jimmy) ; Acee 
Lindem (acee) ; lsr 
Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms 
(Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

Zhibo,

On 11/12/2020 11:06, Huzhibo wrote:
> Hi peter:
> 
>  As you said, IGP does not distinguish between IP and SR when calculating 
> Algo 0. Why does Flexalgo distinguish between IP and SR Flexalgo? I think 
> you're trying to explain these differences in a ambivalent way.

because FA has the concept of application and participation. That is however 
not equal to dataplane type.

thanks,
Peter


> 
> 
> Thanks
> Zhibo
> -Original Message-
> From: Peter Psenak [mailto:ppse...@cisco.com]
> Sent: Friday, December 11, 2020 5:59 PM
> To: Huzhibo ; Dongjie (Jimmy) 
> ; Acee Lindem (acee) ; lsr 
> 
> Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms 
> (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01
> 
> Zhibo,
> 
> On 11/12/2020 10:39, Huzhibo wrote:
>> Hi Peter:
>>
>> Following this approach, IP and SR Flex-Algo can also be 
>> distinguished by using different FA IDs, thus there is no need to 
>> treat them as separate applications, and the existing SR FAD TLV can 
>> be reused? > My suggestion is to have a clear and consistent rule in 
>> FA
> participation, either defining application-specific FA partifcipation for 
> each data plane (IPv4, IPv6, SR-MPLS, SRv6, etc.), or do not define any 
> applications and simply use different FA IDs to distinguish them.
> 
> you are mixing data plane consistency with FA participation. Data plane 
> consistency is NOT done in IGPs for regular algo 0 calculation either.
> If you add non MPLS capable router in a middle of your MPLS network your data 
> path is broken and IGPs are not going to help you to find an alternate path 
> avoiding non MPLS capable router. I see no reason to do anything extra in FA 
> case to avoid it.
> 
> We have defined SR and IP as different applications for FA for good reason. 
> Participation for IP and SR is signaled independently. I see no reason to do 
> the same for every possible data plane - FA is not a data plane consistency 
> check tool - same way as regular IGPs are not the one for algo 0.
> 
> thanks,
> Peter
> 
> 
>>
>> Thanks
>> ZHibo
>> -Original Message-
>> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak
>> Sent: Friday, December 11, 2020 5:13 PM
>> To: Dongjie (Jimmy) ; Acee Lindem (acee) 
>> ; lsr 
>> Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms
>> (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01
>>
>> Hi Jimmy,
>>
>> On 11/12/2020 09:17, Dongjie (Jimmy) wrote:
>>> Hi Peter,
>>>
>>>> -Original Message-
>>>> From: Peter Psenak [mailto:ppse...@cisco.com]
>>>> Sent: Thursday, December 10, 2020 9:22 PM
>>>> To: Dongjie (Jimmy) ; Acee Lindem (acee) 
>>>> ; lsr 
>>>> Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms
>>>> (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01
>>>>
>>>> Hi Jimmy,
>>>>
>>>> On 10/12/2020 13:02, Dongjie (Jimmy) wrote:
>>>>> In Flex-Algo draft, it says:
>>>>>
>>>>> "Application-specific Flex-Algorithm participation advertisements 
>>>>> MAY be
>>>> topology specific or MAY be topology independent, depending on the 
>>>> application itself."
>>>>>
>>>>> The preassumption of current IP Flex-Algo participation is that 
>>>>> one node
>>>> always participate in a Flex-Algo for both IPv4 and IPv6, and for 
>>>> all the topologies it joins.
>>>>>
>>>>> I'm not saying this does not work, just want to understand the 
>>>>> reason of this
>>>> design, and whether some flexibility (e.g. AF specific or topology
>>>> specific) would be useful in some cases.
>>>>>
>>>>
>>>> this was the choice of authors, because there does not seem to be a 
>>>> string reason to do it per topology.
>>>>
>>>>
>>>>> BTW, a similar case is about SR-MPLS and SRv6 being treated as a 
>

Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

[Huzhibo]

Hi peter:

As you said, IGP does not distinguish between IP and SR when calculating 
Algo 0. Why does Flexalgo distinguish between IP and SR Flexalgo? I think 
you're trying to explain these differences in a ambivalent way.


Thanks
Zhibo
-Original Message-
From: Peter Psenak [mailto:ppse...@cisco.com] 
Sent: Friday, December 11, 2020 5:59 PM
To: Huzhibo ; Dongjie (Jimmy) ; Acee 
Lindem (acee) ; lsr 
Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms 
(Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

Zhibo,

On 11/12/2020 10:39, Huzhibo wrote:
> Hi Peter:
> 
> Following this approach, IP and SR Flex-Algo can also be distinguished 
> by using different FA IDs, thus there is no need to treat them as 
> separate applications, and the existing SR FAD TLV can be reused? > My 
> suggestion is to have a clear and consistent rule in FA
participation, either defining application-specific FA partifcipation for each 
data plane (IPv4, IPv6, SR-MPLS, SRv6, etc.), or do not define any applications 
and simply use different FA IDs to distinguish them.

you are mixing data plane consistency with FA participation. Data plane 
consistency is NOT done in IGPs for regular algo 0 calculation either. 
If you add non MPLS capable router in a middle of your MPLS network your data 
path is broken and IGPs are not going to help you to find an alternate path 
avoiding non MPLS capable router. I see no reason to do anything extra in FA 
case to avoid it.

We have defined SR and IP as different applications for FA for good reason. 
Participation for IP and SR is signaled independently. I see no reason to do 
the same for every possible data plane - FA is not a data plane consistency 
check tool - same way as regular IGPs are not the one for algo 0.

thanks,
Peter


> 
> Thanks
> ZHibo
> -Original Message-
> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak
> Sent: Friday, December 11, 2020 5:13 PM
> To: Dongjie (Jimmy) ; Acee Lindem (acee) 
> ; lsr 
> Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms 
> (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01
> 
> Hi Jimmy,
> 
> On 11/12/2020 09:17, Dongjie (Jimmy) wrote:
>> Hi Peter,
>>
>>> -Original Message-
>>> From: Peter Psenak [mailto:ppse...@cisco.com]
>>> Sent: Thursday, December 10, 2020 9:22 PM
>>> To: Dongjie (Jimmy) ; Acee Lindem (acee) 
>>> ; lsr 
>>> Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms
>>> (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01
>>>
>>> Hi Jimmy,
>>>
>>> On 10/12/2020 13:02, Dongjie (Jimmy) wrote:
>>>> In Flex-Algo draft, it says:
>>>>
>>>> "Application-specific Flex-Algorithm participation advertisements 
>>>> MAY be
>>> topology specific or MAY be topology independent, depending on the 
>>> application itself."
>>>>
>>>> The preassumption of current IP Flex-Algo participation is that one 
>>>> node
>>> always participate in a Flex-Algo for both IPv4 and IPv6, and for 
>>> all the topologies it joins.
>>>>
>>>> I'm not saying this does not work, just want to understand the 
>>>> reason of this
>>> design, and whether some flexibility (e.g. AF specific or topology
>>> specific) would be useful in some cases.
>>>>
>>>
>>> this was the choice of authors, because there does not seem to be a 
>>> string reason to do it per topology.
>>>
>>>
>>>> BTW, a similar case is about SR-MPLS and SRv6 being treated as a 
>>>> single
>>> application. Below is the discussion quoted from a previous mail on this 
>>> list:
>>>>
>>>>  [Jie] OK. While the meaning of "app" here maybe a little 
>>>> vague, are
>>> SR-MPLS and SRv6 considered the same or different apps?
>>>>
>>>>  [Peter] These are considered as single app, and share the same
>>> participation signaling. Please note that SRv6 support is signaled 
>>> independently of FA participation.
>>>>
>>>> Does this imply that for Flex-Algo path computation with SRv6, in 
>>>> addition to
>>> the Flex-Algo participation information, the SRv6 support 
>>> information of nodes also needs to be considered, so that nodes 
>>> participate in this Flex-Algo but do not support SRv6 will be pruned from 
>>> the topology?
>>>
>>> no.
>>
>> Let me elaborate with an example:
>>
>> 20   20

Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

[Huzhibo]

Hi Peter:

Following this approach, IP and SR Flex-Algo can also be distinguished by using 
different FA IDs, thus there is no need to treat them as separate applications, 
and the existing SR FAD TLV can be reused?
My suggestion is to have a clear and consistent rule in FA participation, 
either defining application-specific FA partifcipation for each data plane 
(IPv4, IPv6, SR-MPLS, SRv6, etc.), or do not define any applications and simply 
use different FA IDs to distinguish them.  

Thanks
ZHibo
-Original Message-
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak
Sent: Friday, December 11, 2020 5:13 PM
To: Dongjie (Jimmy) ; Acee Lindem (acee) 
; lsr 
Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms 
(Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

Hi Jimmy,

On 11/12/2020 09:17, Dongjie (Jimmy) wrote:
> Hi Peter,
> 
>> -Original Message-
>> From: Peter Psenak [mailto:ppse...@cisco.com]
>> Sent: Thursday, December 10, 2020 9:22 PM
>> To: Dongjie (Jimmy) ; Acee Lindem (acee) 
>> ; lsr 
>> Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms 
>> (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01
>>
>> Hi Jimmy,
>>
>> On 10/12/2020 13:02, Dongjie (Jimmy) wrote:
>>> In Flex-Algo draft, it says:
>>>
>>> "Application-specific Flex-Algorithm participation advertisements 
>>> MAY be
>> topology specific or MAY be topology independent, depending on the 
>> application itself."
>>>
>>> The preassumption of current IP Flex-Algo participation is that one 
>>> node
>> always participate in a Flex-Algo for both IPv4 and IPv6, and for all 
>> the topologies it joins.
>>>
>>> I'm not saying this does not work, just want to understand the 
>>> reason of this
>> design, and whether some flexibility (e.g. AF specific or topology 
>> specific) would be useful in some cases.
>>>
>>
>> this was the choice of authors, because there does not seem to be a 
>> string reason to do it per topology.
>>
>>
>>> BTW, a similar case is about SR-MPLS and SRv6 being treated as a 
>>> single
>> application. Below is the discussion quoted from a previous mail on this 
>> list:
>>>
>>> [Jie] OK. While the meaning of "app" here maybe a little vague, 
>>> are
>> SR-MPLS and SRv6 considered the same or different apps?
>>>
>>> [Peter] These are considered as single app, and share the same
>> participation signaling. Please note that SRv6 support is signaled 
>> independently of FA participation.
>>>
>>> Does this imply that for Flex-Algo path computation with SRv6, in 
>>> addition to
>> the Flex-Algo participation information, the SRv6 support information 
>> of nodes also needs to be considered, so that nodes participate in 
>> this Flex-Algo but do not support SRv6 will be pruned from the topology?
>>
>> no.
> 
> Let me elaborate with an example:
> 
>20   20
>  A--B---C
>   10 |  10 |/
>  ||   /  10
>  D--E --*
>10
> 
> (The metrics on the links are delay metric)
> 
> - Flex-Algo 128 is defined to use delay metric for computation. This FAD is 
> application independent, thus can be used by all applications.
> 
> - All of the nodes (A, B, C, D, E) participate in FA 128.
> 
> - Node A, B, C, D support both SR-MPLS and SRv6.
> 
> - Node E support SR-MPLS only, it may support IPv6.
> 
> Then node A computes the path to node C with FA 128. According to the 
> computation rules of FA 128, the path would be A-D-E-C. This path can be used 
> to send SR-MPLS packet to node C.
> 
> But if node A sends SRv6 packets with node C's SRv6 SID in FA 128 as the 
> destination address, when the packet arrives at E, it will be dropped, 
> because node E does not have the forwarding entry for C's SRv6 SID in FA 128.
> 
> Do you think this is a problem?
> 
> IMO this problem is due to the FA calculation is based on the combination of 
> the constraints in FA definition, and the nodes' FA participation (which is 
> app specific), while since SR-MPLS and SRv6 are treated as one single 
> application, the difference in supporting SR-MPLS or SRv6 is not considered 
> in FA calculation. This is why I asked whether the SRv6 support information 
> also need be considered in FA calculation.
> 
> To solve this problem, there are several options:
> 
> Option 1: Define two different Flex-Algos for delay metric computation, one 
> for SR-MPLS, the other one for SRv6. But this makes the FAD application 
> dependent.

Option 1 is the right one, given the way things are defined. And honestly I do 
not see a need to change it.


> Option 2: Include the SR-MPLS or SRv6 information in Flex-Algo participation, 
> i.e. make SR-MPLS and SRv6 separate applications.

Theoretically you can make SR MPLS and SRv6 a different applications 
using FA. Given the SR nature of both we intentionally kept them as a 
single app from FA perspective.

> Option 3: Also consider the SRv6 (or SR-MPLS) capability information in FA 
> calculation.

no. 

Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

[Huzhibo]

Hi Peter:

If Ti-LFA can protect IP flexalgo, the native IP and SR must share the same 
algorithm ID.

thanks,
Zhibo

-Original Message-
From: Peter Psenak [mailto:ppse...@cisco.com] 
Sent: Wednesday, December 9, 2020 7:16 PM
To: Huzhibo ; Acee Lindem (acee) 
; lsr 
Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms 
(Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

Zhibo,

On 09/12/2020 11:50, Huzhibo wrote:
> Hi authors,
> 
> Here are some comments about IP flexalgo as follows:
> 
> 1.In Flex-Algo draft, there is description about using fast-rerouting 
> with Flex-Algo for SR-MPLS and SRv6 data plane. It is recommended that 
> similar text be added for IP Flex-Algo.

there is a similar text in section 8, but more work is required indeed.

One important note - TI-LFA requires some form of traffic steering. This can be 
achieved by enabling both IP and SR flex-algo and use SR FA only to protect IP 
FA, similar to protection of "unlabeled" traffic with SR MPLS. Or some 
alternative mechanism for enforcing the traffic on the LFA path is required.

> 
> 2.Is Application-Specific Link Attribute (ASLA) MUST be used for IP 
> Flex-Algo path computation?

yes, the flex-algo application uses Flex-algo specific link attributes as 
defined in base flex-algo draft.

thanks,
Peter
> 
> Best regards,
> 
> Zhibo
> 
> *From:*Lsr [mailto:lsr-boun...@ietf.org] *On Behalf Of *Acee Lindem 
> (acee)
> *Sent:* Wednesday, December 2, 2020 5:13 AM
> *To:* lsr 
> *Subject:* [Lsr] WG Adoption Call for "IGP Flexible Algorithms
> (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01
> 
> This IP Flex Algorithm draft generated quite a bit of discussion on 
> use cases and deployment prior to IETF 109 and there was generally 
> support for WG adoption. This begins a two week WG adoption call. 
> Please indicate your support or objection to WG adoption on this list 
> prior to
> 12:00 AM UTC on December 16^th , 2020. Also, review comments are 
> certainly welcome.
> 
> Thanks,
> 
> Acee
> 

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

Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

[Huzhibo]

Hi authors,

Here are some comments about IP flexalgo as follows:

1.   In Flex-Algo draft, there is description about using fast-rerouting 
with Flex-Algo for SR-MPLS and SRv6 data plane. It is recommended that similar 
text be added for IP Flex-Algo.

2.   Is Application-Specific Link Attribute (ASLA) MUST be used for IP 
Flex-Algo path computation?

Best regards,
Zhibo

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Wednesday, December 2, 2020 5:13 AM
To: lsr 
Subject: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) 
In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

This IP Flex Algorithm draft generated quite a bit of discussion on use cases 
and deployment prior to IETF 109 and there was generally support for WG 
adoption. This begins a two week WG adoption call. Please indicate your support 
or objection to WG adoption on this list prior to 12:00 AM UTC on December 
16th, 2020. Also, review comments are certainly welcome.
Thanks,
Acee


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

Re: [Lsr] Prefix Unreachable Announcement Use Cases

[Huzhibo]

Hi Tony:

In fact, this protection use case protects the SRv6 mid-point. 
https://datatracker.ietf.org/doc/draft-chen-rtgwg-srv6-midpoint-protection/. 
When the SRv6 mid-point fails, the PLR node can perform the next SID operation, 
which is triggered by FIB miss. However, if there is a summary or default route 
in the area, FIB Miss cannot be triggered.

Thanks

Zhibo

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of tony...@tony.li
Sent: Tuesday, November 17, 2020 2:31 PM
To: Aijun Wang 
Cc: lsr ; Jeff Tantsura ; Robert Raszuk 
; Acee Lindem (acee) 
Subject: Re: [Lsr] Prefix Unreachable Announcement Use Cases


And how would that help connectivity restoration ?
[WAJ] This action will trigger the path protection procedures, which will 
divert the traffic to other backup path.


This seems to be making some major assumptions about how path protection 
features operate. Those assumptions need to be
very explicitly called out.

The path protection features that I’m familiar with are triggered by 
topological changes along the existing operable path. A PUA
does not provide that.  Rather, it’s something of a temporary signal saying 
’this broke’. Without more specifics about the failure, it’s difficult to
understand exactly what path protection should make of this.  If a prefix is 
unreachable, the obvious implication is that the associated link has
failed.  Path protection in a remote area is highly unlikely to have the 
topological details necessary to find an alternate path to that prefix.

Tony

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

[Lsr] 答复: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 11/16/2020)

[Huzhibo]

Hi les:
I agree with you that IGP still has work to do. I think we can leave the work 
to LSR to complete it, which does not affect the current BGP work.

Thank you.
Zhibo
发件人: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
发送时间: 2020年11月15日 1:29
收件人: Huzhibo ; Ketan Talaulikar (ketant) 
; Susan Hares ; 'Jeff Tantsura' 
; Stephane Litkowski (slitkows) ; 
i...@ietf.org; Acee Lindem (acee) 
抄送: lsr@ietf.org
主题: RE: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 
11/16/2020)

Zhibo –

It is good of you to “keep me honest” as regards my past comments.

In reviewing the relevant material, the best I can say as regards my comments 
from 2 years ago is that they were made with insufficient diligence. Apologies 
for any resulting confusion.

https://www.rfc-editor.org/rfc/rfc7176.html#section-2.4 clearly indicates that 
the advertised value is dependent on the results of MTU-probe testing as 
specified in https://www.rfc-editor.org/rfc/rfc6325#section-4.3.2 .

Particularly relevant is the statement:

“o  MTU: This field is set to the largest successfully tested MTU size
  for this link or zero if it has not been tested, as specified in
  Section 4.3.2 of [RFC6325].”

So, as currently defined, IS-IS is not allowed to advertise a non-zero MTU 
value unless MTU-probes/acks have been exchanged.

https://www.rfc-editor.org/rfc/rfc7177#section-5 further clarifies that:

“The purpose of MTU testing is to ensure that the links used in the
   campus topology can pass TRILL IS-IS packets, particularly LSP PDUs,
   at the TRILL campus MTU.”

So the stated purpose of the TRILL definitions is NOT to provide assurances of 
data packet MTU, but more specifically to ensure that the IS-IS protocol can 
function correctly.

Could the MTU sub-TLV be repurposed to meet the requirements being discussed in 
the context of draft-zhu-idr-bgp-ls-path-mtu? Yes – I think that is possible - 
but it requires further  work.

draft-hu-lsr-isis-path-mtu was published over two years ago to define IS-IS 
extensions to advertise MTU. As you have noted, you received feedback from both 
Acee and myself which suggested that the TRILL defined MTU sub-TLV might be a 
better choice than the node property you had proposed. It seems based on that 
feedback you abandoned draft-hu-lsr-isis-path-mtu and focused only on 
draft-zhu-idr-bgp-ls-path-mtu. But as others have also noted, there is a gap 
regarding IGP support. OSPF has no ability to support MTU advertisement 
currently and – as this thread explains – even in IS-IS there is work to be 
done.

I would like to restate that I am – like others – supportive of this work – but 
I think WG adoption at this stage (in ANY WG) is premature.

   Les


From: Huzhibo mailto:huzh...@huawei.com>>
Sent: Friday, November 13, 2020 7:20 PM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>; Susan 
Hares mailto:sha...@ndzh.com>>; 'Jeff Tantsura' 
mailto:jefftant.i...@gmail.com>>; Stephane Litkowski 
(slitkows) mailto:slitk...@cisco.com>>; 
i...@ietf.org<mailto:i...@ietf.org>; Acee Lindem (acee) 
mailto:a...@cisco.com>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>
Subject: 答复: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 
11/16/2020)

Hi Les, Acee:

Actually we have already discussed about this and reached agreements about two 
years ago. You may have forgotten. Please find the archives below.

https://mailarchive.ietf.org/arch/msg/lsr/C2bhd2ff2UJf4e_Gr-7j2W0g-SU/

I have followed your advice: "there already is a per link MTU sub-TLV defined 
by RFC 7176 ... in which case the existing sub-TLV is a perfect fit ...  IS-IS 
already has what is needed and therefore does not need any additional protocol 
extension". So we let our draft on ISIS extensions for MTU expired, i.e. 
draft-hu-lsr-isis-path-mtu. To be honest, I am a bit surprised when I saw your 
comments.

In this draft we focused on the extensions of BGP_LS for MTU only, which does 
not have to be feed by IGP LSDB. This draft has been discussed and revised a 
few rounds, based on the feedbacks both on ietf meetings and mail list, this 
document has good maturity to move forward.

Thanks
Zhibo


发件人: Idr [mailto:idr-boun...@ietf.org] 代表 Les Ginsberg (ginsberg)
发送时间: 2020年11月14日 7:58
收件人: Ketan Talaulikar (ketant) 
mailto:ketant=40cisco@dmarc.ietf.org>>; 
Susan Hares mailto:sha...@ndzh.com>>; 'Jeff Tantsura' 
mailto:jefftant.i...@gmail.com>>; 'Stephane Litkowski 
(slitkows)' 
mailto:slitkows=40cisco@dmarc.ietf.org>>;
 i...@ietf.org<mailto:i...@ietf.org>; 'Acee Lindem (acee)' 
mailto:acee=40cisco@dmarc.ietf.org>>
抄送: lsr@ietf.org<mailto:lsr@ietf.org>
主题: Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 
11/16/2020)

The points which Ketan has made regarding the use of MTU advertisements defined 
in RFC 7176 are very valid. Inde

[Lsr] 答复: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 11/16/2020)

[Huzhibo]

Hi Les, Acee:

Actually we have already discussed about this and reached agreements about two 
years ago. You may have forgotten. Please find the archives below.

https://mailarchive.ietf.org/arch/msg/lsr/C2bhd2ff2UJf4e_Gr-7j2W0g-SU/

I have followed your advice: "there already is a per link MTU sub-TLV defined 
by RFC 7176 ... in which case the existing sub-TLV is a perfect fit ...  IS-IS 
already has what is needed and therefore does not need any additional protocol 
extension". So we let our draft on ISIS extensions for MTU expired, i.e. 
draft-hu-lsr-isis-path-mtu. To be honest, I am a bit surprised when I saw your 
comments.

In this draft we focused on the extensions of BGP_LS for MTU only, which does 
not have to be feed by IGP LSDB. This draft has been discussed and revised a 
few rounds, based on the feedbacks both on ietf meetings and mail list, this 
document has good maturity to move forward.

Thanks
Zhibo


发件人: Idr [mailto:idr-boun...@ietf.org] 代表 Les Ginsberg (ginsberg)
发送时间: 2020年11月14日 7:58
收件人: Ketan Talaulikar (ketant) ; Susan Hares 
; 'Jeff Tantsura' ; 'Stephane 
Litkowski (slitkows)' ; i...@ietf.org; 
'Acee Lindem (acee)' 
抄送: lsr@ietf.org
主题: Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 
11/16/2020)

The points which Ketan has made regarding the use of MTU advertisements defined 
in RFC 7176 are very valid. Indeed, the contents of the sub-TLV defined in 
https://www.rfc-editor.org/rfc/rfc7176.html#section-2.4 depend upon the TRILL 
specific MTU-probe/MTU-ack procedures defined in 
https://www.rfc-editor.org/rfc/rfc6325#section-4.4.3. These procedures are not 
currently applicable to non-TRILL environments.

So, there are no existing IGP advertisements defined which can support the 
goals of this draft.

As Ketan has also indicated, there is no discussion in the draft of how a BGP 
only network (for example) could provide the information of interest.

From my perspective, WG adoption of this draft in ANY WG is premature.
This might be a useful functionality to have – but at the moment we simply have 
an idea with no definition of how to implement/deploy it.

So I therefore oppose WG adoption of this draft by IDR.

Continuing the discussion is certainly useful – and I would encourage the 
current authors to investigate and propose relevant mechanisms in all the 
protocols of interest in some future version of the draft.
At that point we could then have a far more meaningful WG adoption call.

   Les


From: Idr mailto:idr-boun...@ietf.org>> On Behalf Of 
Ketan Talaulikar (ketant)
Sent: Friday, November 13, 2020 1:35 AM
To: Susan Hares mailto:sha...@ndzh.com>>; 'Jeff Tantsura' 
mailto:jefftant.i...@gmail.com>>; 'Stephane Litkowski 
(slitkows)' 
mailto:slitkows=40cisco@dmarc.ietf.org>>;
 i...@ietf.org; 'Acee Lindem (acee)' 
mailto:acee=40cisco@dmarc.ietf.org>>
Cc: lsr@ietf.org
Subject: Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 
11/16/2020)

Hi Authors,

I believe this work is useful and should be taken up. It has value in providing 
the link MTU as part of the topology information via BGP-LS. However, as 
pointed out by others on this thread, the draft should remain scoped to just 
that – i.e. providing link MTU information. The discussion related to Path MTU 
and applicability to SR networks are best left outside the scope of this 
standards track draft.

Hi Sue,

I would support the points made by Acee for not taking up this draft in IDR WG 
and instead doing this in LSR.

Besides the missing coverage for OSPFv2/v3, there are also issues with how this 
would work with ISIS. The reference to the ISIS Trill specification points to 
this TLV https://tools.ietf.org/html/rfc7176#section-2.4 – if you see, there is 
more here than just the MTU value. What is more critical is the ISIS procedures 
(in non-Trill deployments) on how this value is determined. Please do not mix 
the following :

The MTU sub-TLV is used to optionally announce the MTU of a link as
   specified in [RFC6325], Section 
4.2.4.4.

Are the authors trying to specify that these Trill procedures for testing MTU 
need to be adopted for regular ISIS deployments.

My take is that while the ISIS TLV defined for Trill may be re-used in normal 
ISIS deployments, its usage and procedures need to be specified. Copying the 
LSR WG so that I may be corrected if I am wrong here.

Coming to the point of BGP-only networks, the draft has zero text related to 
that scenario. Moreover, the procedures for BGP-LS advertisements in BGP only 
fabric need to be specified as a base. The 
https://datatracker.ietf.org/doc/draft-ketant-idr-bgp-ls-bgp-only-fabric/ was 
my attempt to specify those procedures and it would be great if the IDR WG 
could review and provide feedback to this document and consider for adoption so 
we can cover the BGP-only networks.

I would also like to offer 

Re: [Lsr] New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt

[Huzhibo]

Hi Joel:

For details about the method defined in RFC 6550. It uses the HBH option to 
carry the RPLInstaceID. The RPLInstaceID and FlexAlgoID are similar.

Thanks

Zhibo

-Original Message-
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Joel M. Halpern
Sent: Wednesday, September 30, 2020 12:05 PM
Cc: lsr@ietf.org
Subject: Re: [Lsr] New Version Notification for 
draft-bonica-lsr-ip-flexalgo-00.txt

I am missing something in this discussion of multiple algorithms.

My understanding of flex-algo whether for MPLS, SRv6, SRH, or IPv6, is that you 
need to associated a forwarding label (e.g. MPLS label or IPv6
address) with a specific algorithm so that you can compute the next hope for 
the forwarding label using the proper algorithm.  Then when a packet arrives, 
it is simply forwarded according to the forwarding table (e.g. 
FIB, LIB, ..)

If that is so, then I do not understand how a given prefix can be safely 
associated with more than one algorithm.  I could imagine doing several 
calculations according to different algorithms.  But how do you decide which 
one applies to the packet?  As far as I know, flex-algo does not look at the 
QoS/CoS/ToS bits.

Yours,
Joel

PS: I will admit that it took until  an operator described some "interesting" 
constraints before I understood why one would even do this.

On 9/29/2020 11:50 PM, Huzhibo wrote:
> Hi.
> 
> Associating multiple algorithms with a given prefix is an interesting topic, 
> and I think this can simplify the complexity of FlexAlgo. I wonder if the 
> author would consider using cases with multiple algorithms with a given 
> prefix.
> 
> Thanks
> 
> ZHibo
> 
> -Original Message-
> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of tony...@tony.li
> Sent: Tuesday, September 29, 2020 10:05 PM
> To: Ron Bonica 
> Cc: lsr@ietf.org
> Subject: Re: [Lsr] New Version Notification for 
> draft-bonica-lsr-ip-flexalgo-00.txt
> 
> 
> Ron,
> 
> This is nice. It makes it clear that constraint based path computation need 
> not have MPLS overhead for those that don’t want it.
> 
> One thing that you don’t talk about is how this gets used, tho that may be 
> blindingly obvious: you’ll need all nodes placing their prefixes in the 
> RIB/FIB, where it will need to be selected over other path computation for 
> the same prefixes.  This somewhat precludes the possibility of a given prefix 
> being useful in multiple flex-algos.
> 
> More text on application would be most welcome, just to ensure that we’re on 
> the same page.
> 
> Tony
> 
> 
>> On Sep 29, 2020, at 6:37 AM, Ron Bonica 
>>  wrote:
>>
>>
>> Please review and comment
>>
>>Ron
>>
>>
>>
>> Juniper Business Use Only
>>
>>> -Original Message-
>>> From: internet-dra...@ietf.org 
>>> Sent: Tuesday, September 29, 2020 9:36 AM
>>> To: Parag Kaneriya ; Shraddha Hegde 
>>> ; Ron Bonica ; Rajesh M 
>>> ; William Britto A J 
>>> Subject: New Version Notification for 
>>> draft-bonica-lsr-ip-flexalgo-00.txt
>>>
>>> [External Email. Be cautious of content]
>>>
>>>
>>> A new version of I-D, draft-bonica-lsr-ip-flexalgo-00.txt
>>> has been successfully submitted by Ron Bonica and posted to the IETF 
>>> repository.
>>>
>>> Name:   draft-bonica-lsr-ip-flexalgo
>>> Revision:   00
>>> Title:  IGP Flexible Algorithms (Flexalgo) In IP Networks
>>> Document date:  2020-09-29
>>> Group:  Individual Submission
>>> Pages:  14
>>> URL:
>>> https://urldefense.com/v3/__https://www.ietf.org/id/draft-bonica-
>>> lsr-ip-flexalgo-00.txt__;!!NEt6yMaO-gk!X7PVDP-
>>> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck80Zbjoij$
>>> Status:
>>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-b
>>> o
>>> nica-lsr-
>>> ip-flexalgo/__;!!NEt6yMaO-gk!X7PVDP-
>>> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck8x7e5ZqI$
>>> Htmlized:
>>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/dr
>>> a
>>> ft-
>>> bonica-lsr-ip-flexalgo__;!!NEt6yMaO-gk!X7PVDP-
>>> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck82w_6CyU$
>>> Htmlized:   
>>> https://urldefense.com/v3/__https://tools.ietf.org/html/draft-
>>> bonica-lsr-ip-flexalgo-00__;!!NEt6yMaO-gk!X7PVDP-
>>> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck81_QrJ_p$
>>>
>>>
>>> Abstract:
>>>An IGP Flexible Algorithm computes

Re: [Lsr] New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt

[Huzhibo]

Hi.

Associating multiple algorithms with a given prefix is an interesting topic, 
and I think this can simplify the complexity of FlexAlgo. I wonder if the 
author would consider using cases with multiple algorithms with a given prefix.

Thanks

ZHibo

-Original Message-
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of tony...@tony.li
Sent: Tuesday, September 29, 2020 10:05 PM
To: Ron Bonica 
Cc: lsr@ietf.org
Subject: Re: [Lsr] New Version Notification for 
draft-bonica-lsr-ip-flexalgo-00.txt


Ron,

This is nice. It makes it clear that constraint based path computation need not 
have MPLS overhead for those that don’t want it.

One thing that you don’t talk about is how this gets used, tho that may be 
blindingly obvious: you’ll need all nodes placing their prefixes in the 
RIB/FIB, where it will need to be selected over other path computation for the 
same prefixes.  This somewhat precludes the possibility of a given prefix being 
useful in multiple flex-algos.

More text on application would be most welcome, just to ensure that we’re on 
the same page.

Tony


> On Sep 29, 2020, at 6:37 AM, Ron Bonica 
>  wrote:
> 
> 
> Please review and comment
> 
>   Ron
> 
> 
> 
> Juniper Business Use Only
> 
>> -Original Message-
>> From: internet-dra...@ietf.org 
>> Sent: Tuesday, September 29, 2020 9:36 AM
>> To: Parag Kaneriya ; Shraddha Hegde 
>> ; Ron Bonica ; Rajesh M 
>> ; William Britto A J 
>> Subject: New Version Notification for 
>> draft-bonica-lsr-ip-flexalgo-00.txt
>> 
>> [External Email. Be cautious of content]
>> 
>> 
>> A new version of I-D, draft-bonica-lsr-ip-flexalgo-00.txt
>> has been successfully submitted by Ron Bonica and posted to the IETF 
>> repository.
>> 
>> Name:   draft-bonica-lsr-ip-flexalgo
>> Revision:   00
>> Title:  IGP Flexible Algorithms (Flexalgo) In IP Networks
>> Document date:  2020-09-29
>> Group:  Individual Submission
>> Pages:  14
>> URL:
>> https://urldefense.com/v3/__https://www.ietf.org/id/draft-bonica-
>> lsr-ip-flexalgo-00.txt__;!!NEt6yMaO-gk!X7PVDP-
>> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck80Zbjoij$
>> Status:
>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-bo
>> nica-lsr-
>> ip-flexalgo/__;!!NEt6yMaO-gk!X7PVDP-
>> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck8x7e5ZqI$
>> Htmlized:
>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/dra
>> ft-
>> bonica-lsr-ip-flexalgo__;!!NEt6yMaO-gk!X7PVDP-
>> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck82w_6CyU$
>> Htmlized:   
>> https://urldefense.com/v3/__https://tools.ietf.org/html/draft-
>> bonica-lsr-ip-flexalgo-00__;!!NEt6yMaO-gk!X7PVDP-
>> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck81_QrJ_p$
>> 
>> 
>> Abstract:
>>   An IGP Flexible Algorithm computes a constraint-based path and maps
>>   that path to an identifier.  As currently defined, Flexalgo can only
>>   map the paths that it computes to Segment Routing (SR) identifiers.
>>   Therefore, Flexalgo cannot be deployed in the absence of SR.
>> 
>>   This document extends Flexalgo, so that it can map the paths that it
>>   computes to IP addresses.  This allows Flexalgo to be deployed in any
>>   IP network, even in the absence of SR.
>> 
>> 
>> 
>> 
>> Please note that it may take a couple of minutes from the time of 
>> submission until the htmlized version and diff are available at 
>> tools.ietf.org.
>> 
>> The IETF Secretariat
>> 
> ___
> 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] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

[Huzhibo]

Support WG adoption.
Thanks,

Zhibo Hu
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] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

[Huzhibo]

hi：

if abr1 advertise pua but abr2 not，other node will think the prefix is 
reachable via abr2. and will not advertise pua to other area.

I am not idea how bgp can work？keepalive expire？bfd？maybe bfd can work.local 
policy verification？some usecase maybe yes.


--
胡志波 Hu Zhibo
Mobile: +86-18618192287
Email: huzh...@huawei.com<mailto:huzh...@huawei.com>

发件人：Robert Raszuk 
收件人：Huzhibo 
抄 送：Acee Lindem (acee) ;Peter Psenak 
;Aijun Wang 
;Xiaoyaqun ;Aijun Wang 
;lsr 
时 间：2020-07-31 00:18:27
主 题：Re: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt

Hi,

Imagine I have two ABRs connecting area 1 to area 0. One is signalling 
transition to down for subset of summary and the other does not .. maybe it is 
slow ... maybe it does not support this new feature.

So all routers in the area 0 are receiving a full summary from one ABR and a 
summary with hole from the other one. Should that be logical AND or OR ?

Then on the other side there is area 2. Should the transition to down be leaked 
? If so in a nicely stable network we may see instead of few /20 summaries jump 
to 1M transitions to down yet summary continues - would that not have a bit 
negative effect on the entire network ? Where would ABR remove summary itself - 
when all atomic routes subsumed by the summary transition to down ?

- - -

I am supportive of the idea to signal unreachable network elements. But I am 
not sure if we should do it in IGP and BGP or only in BGP.

Thx,
R.


On Thu, Jul 30, 2020 at 6:08 PM Huzhibo 
mailto:huzh...@huawei.com>> wrote:

HI acee：

PUA does not advertise reachable or unreachable details, it advertise events 
with prefix from up to down.


thanks

Zhibo




--
胡志波 Hu Zhibo
Mobile: +86-18618192287
Email: huzh...@huawei.com<mailto:huzh...@huawei.com>

发件人：Acee Lindem (acee) mailto:a...@cisco.com>>
收件人：Peter Psenak 
mailto:40cisco@dmarc.ietf.org>>;Robert 
Raszuk mailto:rob...@raszuk.net>>
抄 送：Aijun Wang 
mailto:wang...@chinatelecom.cn>>;Xiaoyaqun 
mailto:xiaoya...@huawei.com>>;Huzhibo 
mailto:huzh...@huawei.com>>;Aijun Wang 
mailto:wangai...@tsinghua.org.cn>>;lsr 
mailto:lsr@ietf.org>>
时 间：2020-07-31 00:04:02
主 题：Re: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt

So, how do we define a reachable route - is it any route subsumed by the 
summary LSA that we knew about in the past that becomes unreachable? When the 
PUA is withdrawn, how do we know whether it is because of expiration of the 
interval or the route becoming reachable again? This is a slippery slope.
Thanks,
Acee

On 7/30/20, 10:34 AM, "Lsr on behalf of Peter Psenak" 
mailto:lsr-boun...@ietf.org> on behalf of 
ppsenak=40cisco@dmarc.ietf.org<mailto:40cisco@dmarc.ietf.org>> wrote:

On 30/07/2020 16:30, Robert Raszuk wrote:
> Hey Peter,
>
> Not sure how smart you really want to be here but keep in mind that BGP
> say option C may never hear about it all the way to the egress PE in
> other domain or area ... It is almost always incongruent with IGP.
>
> So if the BGP path is installed it will indeed be at risk to resolve via
> less specific when it is still active BGP path and you too quickly
> remove info about unreachability.

again, if you are smart you can use this info to your advantage, even
without putting it in the forwarding and leaving the less specific stuff
intact.

Peter


>
> Thx
> R.
>
> On Thu, Jul 30, 2020 at 4:21 PM Peter Psenak 
mailto:ppse...@cisco.com>
> <mailto:ppse...@cisco.com>> wrote:
>
> On 30/07/2020 16:14, Robert Raszuk wrote:
>  >  > 2：For bgp example，when the pe node down，the bgp peer
> must down
>  > within
>  >  > 30 mintus，It will not get it up via cancle advertise pua.
>  >
>  > for the above it is sufficient to advertise the
> unreachability for few
>  > seconds from each ABR independently. That would be a much
> more solid
>  > proposal.
>  >
>  >
>  > Not sure about "few seconds" ... IBGP def hold time in number of
>  > implementations is 180 sec :) .. but few minutes will work for 
sure.
>
> depends how you use it.
>
> If you can use the unreachable info in a smart way, it's sufficient if
> it is present for a very short time interval.
>
> thanks,
> Peter
>
>  >
>  > Thx,
>  > R.
>  >
>

___
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] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

[Huzhibo]

HI acee：

PUA does not advertise reachable or unreachable details, it advertise events 
with prefix from up to down.


thanks

Zhibo




--
胡志波 Hu Zhibo
Mobile: +86-18618192287
Email: huzh...@huawei.com<mailto:huzh...@huawei.com>

发件人：Acee Lindem (acee) 
收件人：Peter Psenak ;Robert Raszuk 

抄 送：Aijun Wang ;Xiaoyaqun 
;Huzhibo ;Aijun Wang 
;lsr 
时 间：2020-07-31 00:04:02
主 题：Re: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt

So, how do we define a reachable route - is it any route subsumed by the 
summary LSA that we knew about in the past that becomes unreachable? When the 
PUA is withdrawn, how do we know whether it is because of expiration of the 
interval or the route becoming reachable again? This is a slippery slope.
Thanks,
Acee

On 7/30/20, 10:34 AM, "Lsr on behalf of Peter Psenak"  wrote:

On 30/07/2020 16:30, Robert Raszuk wrote:
> Hey Peter,
>
> Not sure how smart you really want to be here but keep in mind that BGP
> say option C may never hear about it all the way to the egress PE in
> other domain or area ... It is almost always incongruent with IGP.
>
> So if the BGP path is installed it will indeed be at risk to resolve via
> less specific when it is still active BGP path and you too quickly
> remove info about unreachability.

again, if you are smart you can use this info to your advantage, even
without putting it in the forwarding and leaving the less specific stuff
intact.

Peter


>
> Thx
> R.
>
> On Thu, Jul 30, 2020 at 4:21 PM Peter Psenak  <mailto:ppse...@cisco.com>> wrote:
>
> On 30/07/2020 16:14, Robert Raszuk wrote:
>  >  > 2：For bgp example，when the pe node down，the bgp peer
> must down
>  > within
>  >  > 30 mintus，It will not get it up via cancle advertise pua.
>  >
>  > for the above it is sufficient to advertise the
> unreachability for few
>  > seconds from each ABR independently. That would be a much
> more solid
>  > proposal.
>  >
>  >
>  > Not sure about "few seconds" ... IBGP def hold time in number of
>  > implementations is 180 sec :) .. but few minutes will work for 
sure.
>
> depends how you use it.
>
> If you can use the unreachable info in a smart way, it's sufficient if
> it is present for a very short time interval.
>
> thanks,
> Peter
>
>  >
>  > Thx,
>  > R.
>  >
>

___
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] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

[Huzhibo]

HI Peter：

sure，we will cansider all the possible better solution.thanks for your 
suggestion.


zhibo

--
胡志波 Hu Zhibo
Mobile: +86-18618192287
Email: huzh...@huawei.com<mailto:huzh...@huawei.com>

发件人：Peter Psenak 
收件人：Huzhibo ;Aijun Wang 
抄 送：Aijun Wang ;lsr ;Xiaoyaqun 

时 间：2020-07-30 21:32:45
主 题：Re: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt

Hi Zhibo,

On 30/07/2020 15:18, Huzhibo wrote:
> HI Peter：
>
> 1：No problem is a problem that never can be proved.
>
> 2：For bgp example，when the pe node down，the bgp peer must down within
> 30 mintus，It will not get it up via cancle advertise pua.

for the above it is sufficient to advertise the unreachability for few
seconds from each ABR independently. That would be a much more solid
proposal.

thanks,
Peter


>
>
> ZHIBO
>
> --
> 胡志波 Hu Zhibo
> Mobile: +86-18618192287 
> Email: huzh...@huawei.com <mailto:huzh...@huawei.com>
>
> *发件人：*Peter Psenak 
> *收件人：*Huzhibo ;Aijun Wang 
> *抄 送：*Aijun Wang ;lsr
> ;Xiaoyaqun 
> *时 间：*2020-07-30 21:02:49
> *主 题：*Re: [Lsr] New Version Notification for
> draft-wang-lsr-prefix-unreachable-annoucement-03.txt
>
> Huzhibo,
>
> On 30/07/2020 14:49, Huzhibo wrote:
>>
>> Hi peter：
>>
>> On 30/07/2020 14:28, Aijun Wang wrote:
>>> Hi, Peter:
>>>
>>> Aijun Wang
>>> China Telecom
>>>
>>>> On Jul 30, 2020, at 20:00, Peter Psenak  wrote:
>>>>
>>>> Hi Aijun,
>>>>
>>>>> On 30/07/2020 13:44, Aijun Wang wrote:
>>>>> Hi, Peter:
>>>>> Currently, we have the following consideration:
>>>>> 1. If not all of the ABRs announce the unreachability of the specified 
>>>>> prefix(the specified prefix is still up), such PUA information will 
>>>>> continue advertising by the unreachable ABRs.
>>>>
>>>> so the behavior of ABR is going to be dependent on the behavior of the the 
>>>> other ABR(s)? That is a very thin ice you are dancing on.
>>>
>>> [WAJ] it is easy for ABR to get these information and make the judgment. 
>>> All ABRs locate within the same area.
>>
>> having that info is not the issue. The cyclic dependency is the one.
>>> [HZB] The cyclic dependency does not occur. The PUA advertisement behavior 
>>> of an ABR is not affected by the transient status of other ABRs. The 
>>> condition for canceling PUA advertisement is that all ABRs advertise the 
>>> PUA information with a certain prefix for 30 minutes.
>
> you have not convinced me with the above statement. You are making a
> dependency on the ABR behavior based on the other ABRs' behavior. That's
> a call for a trouble.
>
>
>>>
>>>>
>>>>> 2. If all of the ABRs announce the PUA of the specified prefix, such 
>>>>> information will be announced for a configurable duration, to make sure 
>>>>> other protocol(for example BGP) that based on the specified prefix has 
>>>>> converged.
>>>>
>>>> well, the problem is that no mater what is your configured time to 
>>>> advertise the un-reachability, you have no way of knowing whether the 
>>>> resource that became unreachable have done so intentionally and whether it 
>>>> will ever come back. And guessing based on the timer is not going to make 
>>>> it much better I'm afraid.
>>>>
>>>
>>> [WAJ] We need not care bout the reason for the unreachability. When ABR get 
>>> the PUA information from also all other ABRs, it will start one timer to 
>>> count the duration of following PUA message. After the duration, all ABRs 
>>> will stop the advertisement.
>>
>> once you stop advertising the un-reachability, you are back to square one as 
>> you were with the summary only.
>>> [HZB] There are two scenarios: First: The node is actually Down. In this 
>>> case, upper-layer services will be converged 30 minutes earlier.
>
> once you stop the unreachable advertisement, the resource will be seen
> as reachable outside of its area, even when it is down. That is a
> problem that you are trying to solve in a first place.
>
>
> thanks,
> Peter
>
> Even if the PUA is canceled, the problem will not occur. Second: If the
> node is not Down and only an ABR is unreachable, the ABR will
> continuously advertises PUA.
>>
>> thanks,
>> peter
>>
>>>
>>>
>>>> thanks,
>>>&

Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

[Huzhibo]

HI Peter：

1：No problem is a problem that never can be proved.

2：For bgp example，when the pe node down，the bgp peer must down within 30 
mintus，It will not get it up via cancle advertise pua.


ZHIBO

--
胡志波 Hu Zhibo
Mobile: +86-18618192287
Email: huzh...@huawei.com<mailto:huzh...@huawei.com>

发件人：Peter Psenak 
收件人：Huzhibo ;Aijun Wang 
抄 送：Aijun Wang ;lsr ;Xiaoyaqun 

时 间：2020-07-30 21:02:49
主 题：Re: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt

Huzhibo,

On 30/07/2020 14:49, Huzhibo wrote:
>
> Hi peter：
>
> On 30/07/2020 14:28, Aijun Wang wrote:
>> Hi, Peter:
>>
>> Aijun Wang
>> China Telecom
>>
>>> On Jul 30, 2020, at 20:00, Peter Psenak  wrote:
>>>
>>> Hi Aijun,
>>>
>>>> On 30/07/2020 13:44, Aijun Wang wrote:
>>>> Hi, Peter:
>>>> Currently, we have the following consideration:
>>>> 1. If not all of the ABRs announce the unreachability of the specified 
>>>> prefix(the specified prefix is still up), such PUA information will 
>>>> continue advertising by the unreachable ABRs.
>>>
>>> so the behavior of ABR is going to be dependent on the behavior of the the 
>>> other ABR(s)? That is a very thin ice you are dancing on.
>>
>> [WAJ] it is easy for ABR to get these information and make the judgment. All 
>> ABRs locate within the same area.
>
> having that info is not the issue. The cyclic dependency is the one.
>> [HZB] The cyclic dependency does not occur. The PUA advertisement behavior 
>> of an ABR is not affected by the transient status of other ABRs. The 
>> condition for canceling PUA advertisement is that all ABRs advertise the PUA 
>> information with a certain prefix for 30 minutes.

you have not convinced me with the above statement. You are making a
dependency on the ABR behavior based on the other ABRs' behavior. That's
a call for a trouble.


>>
>>>
>>>> 2. If all of the ABRs announce the PUA of the specified prefix, such 
>>>> information will be announced for a configurable duration, to make sure 
>>>> other protocol(for example BGP) that based on the specified prefix has 
>>>> converged.
>>>
>>> well, the problem is that no mater what is your configured time to 
>>> advertise the un-reachability, you have no way of knowing whether the 
>>> resource that became unreachable have done so intentionally and whether it 
>>> will ever come back. And guessing based on the timer is not going to make 
>>> it much better I'm afraid.
>>>
>>
>> [WAJ] We need not care bout the reason for the unreachability. When ABR get 
>> the PUA information from also all other ABRs, it will start one timer to 
>> count the duration of following PUA message. After the duration, all ABRs 
>> will stop the advertisement.
>
> once you stop advertising the un-reachability, you are back to square one as 
> you were with the summary only.
>> [HZB] There are two scenarios: First: The node is actually Down. In this 
>> case, upper-layer services will be converged 30 minutes earlier.

once you stop the unreachable advertisement, the resource will be seen
as reachable outside of its area, even when it is down. That is a
problem that you are trying to solve in a first place.


thanks,
Peter

Even if the PUA is canceled, the problem will not occur. Second: If the
node is not Down and only an ABR is unreachable, the ABR will
continuously advertises PUA.
>
> thanks,
> peter
>
>>
>>
>>> thanks,
>>> Peter
>>>
>>>
>>>> How about the above consideration and Do you have other thoughts ?
>>>> Aijun Wang
>>>> China Telecom
>>>>>> On Jul 30, 2020, at 17:21, Peter Psenak 
>>>>>>  wrote:
>>>>>
>>>>> Hi Ajun,
>>>>>
>>>>> one additional problem on top of others that have been mentioned is
>>>>> how are you going to get rid of "old" un-reachability
>>>>> announcements/
>>>>>
>>>>> Let's imagine you have the following prefixes in your area 1:
>>>>>
>>>>> - 10.10.0.1/32 - 10.0.0.255/32 - used for loopback adresses
>>>>> - 10.10.1.0/30 - 10.10.10.252/32 - used for transit links
>>>>>
>>>>> For simplicity your summary for area 1 is 10.0.0.0/16
>>>>>
>>>>> 1. Everything is up, you generate 10.0.0.0/16 on the ABR that
>>>>> connects to area 1 to all remaining connected areas
>>&

Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

[Huzhibo]

Hi peter：

On 30/07/2020 14:28, Aijun Wang wrote:
> Hi, Peter:
> 
> Aijun Wang
> China Telecom
> 
>> On Jul 30, 2020, at 20:00, Peter Psenak  wrote:
>>
>> Hi Aijun,
>>
>>> On 30/07/2020 13:44, Aijun Wang wrote:
>>> Hi, Peter:
>>> Currently, we have the following consideration:
>>> 1. If not all of the ABRs announce the unreachability of the specified 
>>> prefix(the specified prefix is still up), such PUA information will 
>>> continue advertising by the unreachable ABRs.
>>
>> so the behavior of ABR is going to be dependent on the behavior of the the 
>> other ABR(s)? That is a very thin ice you are dancing on.
> 
> [WAJ] it is easy for ABR to get these information and make the judgment. All 
> ABRs locate within the same area.

having that info is not the issue. The cyclic dependency is the one.
> [HZB] The cyclic dependency does not occur. The PUA advertisement behavior of 
> an ABR is not affected by the transient status of other ABRs. The condition 
> for canceling PUA advertisement is that all ABRs advertise the PUA 
> information with a certain prefix for 30 minutes.
> 
>>
>>> 2. If all of the ABRs announce the PUA of the specified prefix, such 
>>> information will be announced for a configurable duration, to make sure 
>>> other protocol(for example BGP) that based on the specified prefix has 
>>> converged.
>>
>> well, the problem is that no mater what is your configured time to advertise 
>> the un-reachability, you have no way of knowing whether the resource that 
>> became unreachable have done so intentionally and whether it will ever come 
>> back. And guessing based on the timer is not going to make it much better 
>> I'm afraid.
>>
> 
> [WAJ] We need not care bout the reason for the unreachability. When ABR get 
> the PUA information from also all other ABRs, it will start one timer to 
> count the duration of following PUA message. After the duration, all ABRs 
> will stop the advertisement.

once you stop advertising the un-reachability, you are back to square one as 
you were with the summary only.
> [HZB] There are two scenarios: First: The node is actually Down. In this 
> case, upper-layer services will be converged 30 minutes earlier. Even if the 
> PUA is canceled, the problem will not occur. Second: If the node is not Down 
> and only an ABR is unreachable, the ABR will continuously advertises PUA.

thanks,
peter

> 
> 
>> thanks,
>> Peter
>>
>>
>>> How about the above consideration and Do you have other thoughts ?
>>> Aijun Wang
>>> China Telecom
> On Jul 30, 2020, at 17:21, Peter Psenak 
>  wrote:

 Hi Ajun,

 one additional problem on top of others that have been mentioned is 
 how are you going to get rid of "old" un-reachability 
 announcements/

 Let's imagine you have the following prefixes in your area 1:

 - 10.10.0.1/32 - 10.0.0.255/32 - used for loopback adresses
 - 10.10.1.0/30 - 10.10.10.252/32 - used for transit links

 For simplicity your summary for area 1 is 10.0.0.0/16

 1. Everything is up, you generate 10.0.0.0/16 on the ABR that 
 connects to area 1 to all remaining connected areas

 2. A router in area 1 with loopback 10.10.0.25/32 goes down.

 3. ABR in area 1 generates un-reachable announcement for 
 10.0.0.25/32 to all other connected areas

 4. When does ABR stop generating the un-reachable announcement for 
 10.0.0.25/32? In section 6 you mention that "The receiver router should 
 keep the black hole routes for PUA as one configurable time(MAX_T_PUA)", 
 but the draft does not say anything about when the un-reachability 
 announcements should be removed by ABR. We can not rely on 10.10.0.25/32 
 ever coming back, as the user may have simply removed it for good. Keeping 
 the "stale" un-reachability announcements may result in the LSDB growth 
 over the period of time.


 thanks,
 Peter




> On 27/07/2020 03:32, Aijun Wang wrote:
> Hi, LSR experts:
> We have uploaded the new version of this PUA(Prefix Unreachable 
> Announcement) draft. The main updates are the followings:
> 1) Describes the solution that using tunnel to redirect traffic among 
> ABRs, when all ABRs reaches the PUA limit.
> 2) Describe fast rerouting to avoid routing black hole.
> 3) Defining PUA capabilities announcements for OSPFv2/OSPFv3 and ISIS.
> There are also some arguments about the current solution for PUA, for 
> example:
> 1) Is it suitable to set the "Prefix Originator" sub-TLV to NULL to 
> indicate the prefix is unreachable?
> 2) if not, what's the consideration? What's the other convincible 
> solution?
> Wish to hear comments and suggestions on the above issues. We will also 
> have the presentation on the coming IETF LSR meeting.
> Best Regards
> Aijun Wang
> China Telecom
> -Original Message-
> From: 

Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

[Huzhibo]

Hi Robert:

BGP next hop validation can solve some but not all problems. In your 
example, if PE1 has learned only 1.1.1.0/24 but not 1.1.1.1/32, BGP cannot 
detect the reachability of 1.1.1.1/32.

Thanks

Zhibo Hu
From: Robert Raszuk [mailto:rob...@raszuk.net]
Sent: Tuesday, July 28, 2020 5:18 PM
To: Acee Lindem (acee) 
Cc: Aijun Wang ; lsr@ietf.org; Huzhibo 
; Xiaoyaqun 
Subject: Re: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt

Hello Acee,

I would like to question your assessment that signalling unreachable routes is 
unnecessary.

Imagine hierarchical network with areas. Under no failures area 1 advertises to 
area 0 summary LSA with 1.1.1.0/24<http://1.1.1.0/24>. That block covers PE's 
loopbacks which within the area are /32s. Those loopbacks are also BGP next 
hops.

Now imagine PE1 with 1.1.1.1/32<http://1.1.1.1/32> fails. Well till BGP 
reconverges all paths advertised by this PE with 1.1.1.1/32<http://1.1.1.1/32> 
are still valid as this next hop is still reachable entire network wide. That 
means that traffic is being sent to this failed PE1 for relatively long period 
of time.

It seems natural that without breaking benefits of summarization across areas 
or domains in the above scenario we could continue to advertise 
1.1.1.0/24<http://1.1.1.0/24> - 1.1.1.1/32<http://1.1.1.1/32>. That is when I 
see most benefits of advertising unreachability aka negative routing.

Of course said all of the above - if you search your employer's archives - you 
will see a proposal where the above mechanism can be done within BGP itself 
with no touch to the IGP - just using a bit of twisted next hop validation 
steps and BGP native recursion. I am not going to make any judgements here 
which method is better or easier - naturally I personally like BGP one more :).

But I hope this is clear why at least discussion on the subject is important. 
It also illustrates why the below statement is not necessarily correct:

"Note that the unreachability of a given summarized prefix is only relevant if 
it is reachable through another ABR. "

Kind regards,
Robert.


On Mon, Jul 27, 2020 at 7:51 PM Acee Lindem (acee) 
mailto:40cisco@dmarc.ietf.org>> wrote:
Speaking as an LSR Working Group member:

Asking the WG precisely how to advertise prefix unreachability is the wrong 
question - it is analogous to asking whether to use a car or truck to drive off 
the edge of a cliff. Rather than messing up OSPF and IS-IS with these complex 
and unnecessary mechanisms, it would be better to address the requirement in 
your network design. Note that the unreachability of a given summarized prefix 
is only relevant if it is reachable through another ABR. In this case, the 
network design should provide adequate intra-area redundancy to provide 
communications between the ABRs. If this cannot be accomplished, an intra-area 
adjacency should be established over a tunnel between the ABRs in the backbone. 
Contrary to section 6.1, Looping is normally not a problem as ABRs should add 
back hole routes for their advertised summaries.

Acee

On 7/26/20, 9:34 PM, "Lsr on behalf of Aijun Wang" 
mailto:lsr-boun...@ietf.org> on behalf of 
wang...@chinatelecom.cn<mailto:wang...@chinatelecom.cn>> wrote:

Hi, LSR experts:

We have uploaded the new version of this PUA(Prefix Unreachable 
Announcement) draft. The main updates are the followings:
1) Describes the solution that using tunnel to redirect traffic among ABRs, 
when all ABRs reaches the PUA limit.
2) Describe fast rerouting to avoid routing black hole.
3) Defining PUA capabilities announcements for OSPFv2/OSPFv3 and ISIS.

There are also some arguments about the current solution for PUA, for 
example:
1) Is it suitable to set the "Prefix Originator" sub-TLV to NULL to 
indicate the prefix is unreachable?
2) if not, what's the consideration? What's the other convincible solution?

Wish to hear comments and suggestions on the above issues. We will also 
have the presentation on the coming IETF LSR meeting.

Best Regards

Aijun Wang
China Telecom

-Original Message-
From: internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> 
[mailto:internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>]
Sent: Monday, July 27, 2020 9:16 AM
To: Zhibo Hu mailto:huzh...@huawei.com>>; Aijun Wang 
mailto:wang...@chinatelecom.cn>>; Yaqun Xiao 
mailto:xiaoya...@huawei.com>>
Subject: New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt


A new version of I-D, draft-wang-lsr-prefix-unreachable-annoucement-03.txt
has been successfully submitted by Aijun Wang and posted to the IETF 
repository.

Name:   draft-wang-lsr-prefix-unreachable-annoucement
Revision:   03
Title:  Prefix Unreachable Announcement

Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

[Huzhibo]

Hi Acee:

In the scenario mentioned by Robert, the section 6.1 solution doesn't work. 
When BGP needs to detect the reachability of the next hop to trigger BGP 
convergence.

Thanks
Zhibo Hu

-Original Message-
From: Acee Lindem (acee) [mailto:a...@cisco.com] 
Sent: Tuesday, July 28, 2020 9:24 PM
To: Huzhibo ; Aijun Wang ; 
lsr@ietf.org
Cc: Xiaoyaqun 
Subject: Re: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt

See my response to Aijun... Please provide topologies where the section 6.1 
solution doesn't work. 
Acee

On 7/27/20, 10:03 PM, "Huzhibo"  wrote:

Hi Acee:

In fact, we have meet some scenarios where redundant paths cannot be 
deployed within a area. Especially when the access area uses the nearby access 
principle, ABRs form disordered combinations, which makes it difficult to 
deploy physical or tunnel connections. In addition, advertising unreachable 
prefixes can prevent traffic detours. Of course, This draft also has some other 
attempts to use Segment Routing to automatically establish connections between 
ABRs.

Thanks

Zhibo Hu

-Original Message-
From: Acee Lindem (acee) [mailto:a...@cisco.com] 
Sent: Tuesday, July 28, 2020 1:51 AM
To: Aijun Wang ; lsr@ietf.org
Cc: Huzhibo ; Xiaoyaqun 
Subject: Re: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt

Speaking as an LSR Working Group member:

Asking the WG precisely how to advertise prefix unreachability is the wrong 
question - it is analogous to asking whether to use a car or truck to drive off 
the edge of a cliff. Rather than messing up OSPF and IS-IS with these complex 
and unnecessary mechanisms, it would be better to address the requirement in 
your network design. Note that the unreachability of a given summarized prefix 
is only relevant if it is reachable through another ABR. In this case, the 
network design should provide adequate intra-area redundancy to provide 
communications between the ABRs. If this cannot be accomplished, an intra-area 
adjacency should be established over a tunnel between the ABRs in the backbone. 
Contrary to section 6.1, Looping is normally not a problem as ABRs should add 
back hole routes for their advertised summaries. 

Acee

On 7/26/20, 9:34 PM, "Lsr on behalf of Aijun Wang"  wrote:

Hi, LSR experts:

We have uploaded the new version of this PUA(Prefix Unreachable 
Announcement) draft. The main updates are the followings:
1) Describes the solution that using tunnel to redirect traffic among 
ABRs, when all ABRs reaches the PUA limit.
2) Describe fast rerouting to avoid routing black hole.
3) Defining PUA capabilities announcements for OSPFv2/OSPFv3 and ISIS.

There are also some arguments about the current solution for PUA, for 
example:
1) Is it suitable to set the "Prefix Originator" sub-TLV to NULL to 
indicate the prefix is unreachable?
2) if not, what's the consideration? What's the other convincible 
solution?

Wish to hear comments and suggestions on the above issues. We will also 
have the presentation on the coming IETF LSR meeting.

Best Regards

Aijun Wang
China Telecom 

-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
Sent: Monday, July 27, 2020 9:16 AM
To: Zhibo Hu ; Aijun Wang 
; Yaqun Xiao 
Subject: New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt


A new version of I-D, 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt
has been successfully submitted by Aijun Wang and posted to the IETF 
repository.

Name:   draft-wang-lsr-prefix-unreachable-annoucement
Revision:   03
Title:  Prefix Unreachable Announcement
Document date:  2020-07-27
Group:  Individual Submission
Pages:  11
URL:
https://www.ietf.org/internet-drafts/draft-wang-lsr-prefix-unreachable-annoucement-03.txt
Status: 
https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/
Htmlized:   
https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-03
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-wang-lsr-prefix-unreachable-annoucement-03

Abstract:
   This document describes the mechanism that can be used to announce
   the unreachable prefixes for service fast convergence.




Please note that it may take a couple of minutes from the time of 
submission until the htmlized version and diff are available at tools.ietf.org.

Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

[Huzhibo]

Hi Acee:

In fact, we have meet some scenarios where redundant paths cannot be deployed 
within a area. Especially when the access area uses the nearby access 
principle, ABRs form disordered combinations, which makes it difficult to 
deploy physical or tunnel connections. In addition, advertising unreachable 
prefixes can prevent traffic detours. Of course, This draft also has some other 
attempts to use Segment Routing to automatically establish connections between 
ABRs.

Thanks

Zhibo Hu

-Original Message-
From: Acee Lindem (acee) [mailto:a...@cisco.com] 
Sent: Tuesday, July 28, 2020 1:51 AM
To: Aijun Wang ; lsr@ietf.org
Cc: Huzhibo ; Xiaoyaqun 
Subject: Re: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt

Speaking as an LSR Working Group member:

Asking the WG precisely how to advertise prefix unreachability is the wrong 
question - it is analogous to asking whether to use a car or truck to drive off 
the edge of a cliff. Rather than messing up OSPF and IS-IS with these complex 
and unnecessary mechanisms, it would be better to address the requirement in 
your network design. Note that the unreachability of a given summarized prefix 
is only relevant if it is reachable through another ABR. In this case, the 
network design should provide adequate intra-area redundancy to provide 
communications between the ABRs. If this cannot be accomplished, an intra-area 
adjacency should be established over a tunnel between the ABRs in the backbone. 
Contrary to section 6.1, Looping is normally not a problem as ABRs should add 
back hole routes for their advertised summaries. 

Acee

On 7/26/20, 9:34 PM, "Lsr on behalf of Aijun Wang"  wrote:

Hi, LSR experts:

We have uploaded the new version of this PUA(Prefix Unreachable 
Announcement) draft. The main updates are the followings:
1) Describes the solution that using tunnel to redirect traffic among ABRs, 
when all ABRs reaches the PUA limit.
2) Describe fast rerouting to avoid routing black hole.
3) Defining PUA capabilities announcements for OSPFv2/OSPFv3 and ISIS.

There are also some arguments about the current solution for PUA, for 
example:
1) Is it suitable to set the "Prefix Originator" sub-TLV to NULL to 
indicate the prefix is unreachable?
2) if not, what's the consideration? What's the other convincible solution?

Wish to hear comments and suggestions on the above issues. We will also 
have the presentation on the coming IETF LSR meeting.

Best Regards

Aijun Wang
China Telecom 

-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
Sent: Monday, July 27, 2020 9:16 AM
To: Zhibo Hu ; Aijun Wang ; 
Yaqun Xiao 
Subject: New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt


A new version of I-D, draft-wang-lsr-prefix-unreachable-annoucement-03.txt
has been successfully submitted by Aijun Wang and posted to the IETF 
repository.

Name:   draft-wang-lsr-prefix-unreachable-annoucement
Revision:   03
Title:  Prefix Unreachable Announcement
Document date:  2020-07-27
Group:  Individual Submission
Pages:  11
URL:
https://www.ietf.org/internet-drafts/draft-wang-lsr-prefix-unreachable-annoucement-03.txt
Status: 
https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/
Htmlized:   
https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-03
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-wang-lsr-prefix-unreachable-annoucement-03

Abstract:
   This document describes the mechanism that can be used to announce
   the unreachable prefixes for service fast convergence.




Please note that it may take a couple of minutes from the time of 
submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



___
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] A question about draft-ietf-lsr-flex-algo

[Huzhibo]

Hi Alexander, Peter:

 Thank you very much，After I read the WG alias, I still have a lot of 
doubts, can we calculate the disjoint path by exclude  SRLG in flexalgo? In 
fact, unless you previously defined two disjoint planes using SRLG, you cannot 
guarantee that different FlexAlgo can calculate disjoint paths.

Thanks

Zhibo Hu
From: Alexander Vainshtein [mailto:alexander.vainsht...@ecitele.com]
Sent: Wednesday, June 3, 2020 8:19 PM
To: Huzhibo ; Peter Psenak (ppsenak) 
Cc: lsr@ietf.org; draft-ietf-lsr-flex-a...@ietf.org
Subject: RE: A question about draft-ietf-lsr-flex-algo

Hi Zhibo Hu,
Welcome to the club - I have already asked the same question and got a response 
from Peter.
You can find the relevant email thread 
here<https://mailarchive.ietf.org/arch/msg/spring/wvowYz7mOwR9f6je46qPV_pD9pU/>.

My 2c,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   
alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com>

From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
Huzhibo
Sent: Wednesday, June 3, 2020 3:07 PM
To: Peter Psenak (ppsenak) mailto:ppse...@cisco.com>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>; 
draft-ietf-lsr-flex-a...@ietf.org<mailto:draft-ietf-lsr-flex-a...@ietf.org>
Subject: [Lsr] A question about draft-ietf-lsr-flex-algo

Hi Peter:

I noticed that draft-ietf-lsr-flex-algo-07 adds exclude SRLG TLV. SRLG defines 
a group of risk-sharing link groups. It is generally used to prevent the 
primary and standby paths from passing the same risk-sharing link group .I 
don't know why a group of SRLG links should be excluded from the FlexAlgo 
calculation. What is its usecase?

Thanks

Zhibo Hu

___

This e-mail message is intended for the recipient only and contains information 
which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received 
this
transmission in error, please inform us by e-mail, phone or fax, and then 
delete the original
and all copies thereof.
___
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] A question about draft-ietf-lsr-flex-algo

[Huzhibo]

Hi Peter:

I noticed that draft-ietf-lsr-flex-algo-07 adds exclude SRLG TLV. SRLG defines 
a group of risk-sharing link groups. It is generally used to prevent the 
primary and standby paths from passing the same risk-sharing link group .I 
don't know why a group of SRLG links should be excluded from the FlexAlgo 
calculation. What is its usecase?

Thanks

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

[Huzhibo]

I support this adaption.It propose an algorithm for node to compute a flooding 
topology.It is useful for reduce flooding.

--
胡志波 Hu Zhibo
Mobile: +86-18618192287
Email: huzh...@huawei.com

发件人：Acee Lindem (acee) 
收件人：lsr 
时 间：2020-05-16 03:40:29
主 题：[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] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

[Huzhibo]

Support. Not aware of any undisclosed IPR.

Zhibo

--
胡志波 Hu Zhibo
Mobile: +86-18618192287
Email: huzh...@huawei.com

发件人：Christian Hopps 
收件人：lsr 
抄 送：draft-li-lsr-ospfv3-srv6-extensions 
;lsr-ads 
;Christian Hopps ;Acee Lindem (acee) 

时 间：2020-01-24 04:25:13
主 题：[Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

Hi LSR WG and Draft Authors,

The authors originally requested adoption back @ 105; however, some comments 
were received and new version was produced. Moving forward...

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

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

Please indicate your support or objection by Feb 6, 2020.

Authors, please respond indicating whether you are aware of any IPR that 
applies to this draft.

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

Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

[Huzhibo]

Support. Not aware of any undisclosed IPR.

Zhibo

--
胡志波 Hu Zhibo
Mobile: +86-18618192287
Email: huzh...@huawei.com

发件人：Christian Hopps 
收件人：lsr 
抄 送：lsr-ads ;Christian Hopps ;Acee Lindem 
(acee) 
时 间：2020-01-22 08:15:23
主 题：[Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

This begins a 2 week WG Last Call, ending after Feb 4, 2020, for 
draft-ietf-lsr-isis-srv6-extensions

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

Authors please indicate if you aware of any other IPR beyond what is posted:

  https://datatracker.ietf.org/ipr/3796/

Thanks,
Chris & 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] I-D Action: draft-ietf-lsr-dynamic-flooding-04.txt

[Huzhibo]

Hi authors:

Regarding this Draft, I have always had a question, how does dynamic 
flooding ensure the reliability of Flooding under multiple points of failure. 
Flooding depends on the consistent LSDB / Flooding SPF tree across the entire 
network, and the consistent LSDB on the entire network depends on Flooding. 
There will be different nodes with different LSDBs. In this case, how to ensure 
the reliability of Dynamic flooding? IETF 106 meeting says that products have 
been implemented for Dynamic Flooding. Has the reliability of Dynamic Flooding 
been tested in multi-point failure scenarios?

Thank you

Zhibo

-Original Message-
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of internet-dra...@ietf.org
Sent: Tuesday, November 26, 2019 11:29 PM
To: i-d-annou...@ietf.org
Cc: lsr@ietf.org
Subject: [Lsr] I-D Action: draft-ietf-lsr-dynamic-flooding-04.txt


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   : Dynamic Flooding on Dense Graphs
Authors : Tony Li
  Peter Psenak
  Les Ginsberg
  Huaimo Chen
  Tony Przygienda
  Dave Cooper
  Luay Jalil
  Srinath Dontula
Filename: draft-ietf-lsr-dynamic-flooding-04.txt
Pages   : 47
Date: 2019-11-26

Abstract:
   Routing with link state protocols in dense network topologies can
   result in sub-optimal convergence times due to the overhead
   associated with flooding.  This can be addressed by decreasing the
   flooding topology so that it is less dense.

   This document discusses the problem in some depth and an
   architectural solution.  Specific protocol changes for IS-IS, OSPFv2,
   and OSPFv3 are described in this document.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lsr-dynamic-flooding/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-lsr-dynamic-flooding-04
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-dynamic-flooding-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-dynamic-flooding-04


Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
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 Adoption Poll for "OSPF Extension for PrefixOriginator" - draft-wang-lsr-ospf-prefix-originator-ext-01

[Huzhibo]

Support.It is useful for collect cross-area IGP topologies

Ths
Zhibo Hu

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of peng.sha...@zte.com.cn
Sent: Wednesday, February 27, 2019 4:36 PM
To: a...@cisco.com
Cc: lsr@ietf.org
Subject: Re: [Lsr] Working Group Adoption Poll for "OSPF Extension for 
PrefixOriginator" - draft-wang-lsr-ospf-prefix-originator-ext-01


Support, as this draft provide useful originial source router-id of prefix, as 
the same as RFC7794.

For topology deducing, it seems too hard to work according to current 
description in the document. For example, It is hard to represent mulptile 
links between two nodes if we only know two node-id information but lack of 
interface IP address or interface-id that is link attribute not be included in 
prefix flooding, thus there is no way to consider which link could be contained 
in which TE path, also, so many TE parameters of link need to be supplied for 
the deducing topology, TE metric, bandwidth, etc. Maybe there already have a 
complete solution but just not describe detailedly in document.



Thanks

Deccan(Shaofu peng)






原始邮件
发件人：AceeLindem(acee) mailto:a...@cisco.com>>
收件人：lsr@ietf.org mailto:lsr@ietf.org>>;
日 期 ：2019年02月13日 21:26
主 题 ：[Lsr] Working Group Adoption Poll for "OSPF Extension for 
PrefixOriginator" - draft-wang-lsr-ospf-prefix-originator-ext-01
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


This begins a two week adoption poll for the subject draft. Please send your 
comments to this list before 12:00 AM UTC on Thursday, February 28th, 2019.

All authors have responded to the IPR poll and there is one  
https://datatracker.ietf.org/ipr/search/?submit=draft=draft-wang-lsr-ospf-prefix-originator-ext
It is listed multiple times but references the same CN201810650141.

Thanks,
Acee



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

Re: [Lsr] 答复: WG Adoption Call for draft-li-lsr-dynamic-flooding-02 + IPR poll.

[Huzhibo]

Supports for the adoption of two drafts at the same time, IGP Reduce Flooding 
still have some problem needs to be solved, for example, how to ensure the 
reliability of Flooding in a multi-point failure scenario. The way to solve 
these problems in a distributed and centralized manner may be different. 
Therefore, it is recommended to promote separately and continue to conduct 
research in their respective directions.

Ths

Zhibo

-Original Message-
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Aijun Wang
Sent: Thursday, February 14, 2019 10:38 AM
To: 'Christian Hopps' ; lsr@ietf.org
Cc: lsr-cha...@ietf.org; lsr-...@ietf.org
Subject: [Lsr] 答复: WG Adoption Call for draft-li-lsr-dynamic-flooding-02 + IPR 
poll.

Hi, Christian:

Supports for the adoption of two drafts at the same time, in which
one(draft-li-lsr-dynamic-flooding-02) focuses on the centralized mode and the 
other(draft-cc-lsr-flooding-reduction-01) focuses on the distributed mode.

The centralized mode for is one straightforward way to realize the flooding 
reduction, and I admire Tony Li give his solution first. But from the 
consideration of solution robustness, the distributed mode may be more 
promising.
My consideration for distributed mode is that it should not cover only the 
algorithm, more contents need to be standardized in future. Huaimo has one good 
start point for distributed mode, and he also gives abundant thoughts for the 
centralized mode that the current version of
draft-li-lsr-dynamic-flooding-02 has not covered yet.

Proposal for the name of two drafts may be 
draft-ietf-lsr-flooding-reduction-centralized-mode and 
draft-ietf-lsr-flooding-reduction-distributed-mode.


Best Regards.

Aijun Wang
Network R and Operation Support Department China Telecom Corporation Limited 
Beijing Research Institute,Beijing, China.

-邮件原件-
发件人: Christian Hopps [mailto:cho...@chopps.org]
发送时间: 2019年2月11日 18:45
收件人: lsr@ietf.org
抄送: lsr-cha...@ietf.org; lsr-...@ietf.org; cho...@chopps.org
主题: [Lsr] WG Adoption Call for draft-li-lsr-dynamic-flooding-02 + IPR poll.


Hi Folks,

We are starting a 2 week adoption call on draft-li-lsr-dynamic-flooding-02.

The aim of this document is to describe the problem space and standardize a
way to signal dynamic flooding information. It does not standardize any
specific algorithm for flooding topology creation.

Authors please respond indicating if you are aware of any IPR related to
this work.

We also have another draft (draft-cc-lsr-flooding-reduction-01) that started
as a distributed flooding topology algorithm and morphed into that plus
competing ideas on signaling of flooding topology information. The intent
after adoption of draft-li-lsr-dynamic-flooding-02 is two-fold. One, the WG
can discuss adding any signaling ideas from this work to the adopted
signaling draft (with proper attribution given as appropriate), and two, for
the authors of draft-cc-lsr-flooding-reduction-01 to publish a new document
without the signaling portion and instead focus on their flooding topology
algorithm. This new focused document can be considered in parallel along
with the other algorithm work that has been proposed.

Flooding topology creation is seen as a hard problem for which we don't
expect a one-size-fits-all solution. Taking the steps outlined above will
help us move forward on the solutions.

Thanks,
Chris & Acee.
LSR WG Chairs.

___
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] 答复: Moving Forward [Re: Flooding Reduction Draft Redux]

[Huzhibo]

Support to promote the centralized and distributed solutions in two separated 
drafts.

Best regards,
Zhibo
-Original Message-
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Dongjie (Jimmy)
Sent: Monday, February 11, 2019 4:47 PM
To: Lizhenbin ; Christian Hopps ; 
lsr@ietf.org
Subject: Re: [Lsr] 答复: Moving Forward [Re: Flooding Reduction Draft Redux]

Support moving forward with the centralized and distributed solutions specified 
in separated drafts. As discussed in previous mails, the procedure and protocol 
extensions needed for the two modes could be different, and a particular 
network may only want to use one mode.

As for the centralized solution, maybe it could be refined with the advantage 
of the centralized part in both existing drafts.

Best regards,
Jie

> -Original Message-
> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Lizhenbin
> Sent: Monday, February 04, 2019 5:36 PM
> To: Christian Hopps ; lsr@ietf.org
> Subject: [Lsr] 答复: Moving Forward [Re: Flooding Reduction Draft Redux]
> 
> Hi Chris & Acee,
> 
> > - Jan 2, 2018 Publication: draft-li-dynamic-flooding and
> drfat-li-dynamic-flooding-isis
> >   published centralized solution.
> >
> > - Mar 5, 2018 Publication: draft-cc-isis-flooding-reduction and
> draft-cc-ospf-flooding-reduction
> >   published distributed solution
> 
> Thanks for your summary we know the fact that at beginning there was 
> not any confliction between the two drafts.
> 
> 
> > - Jun 28, 2018 draft-li-dynamic-flooding-05 published (2 authors)
> >   - *SMALL CHANGE TO SUPPORT DISTRIBUTED ALGORITHM*.
> >   - Does not specify distributed algorithm only how to indicate one 
> > in use,
> small change.
> 
> I do not think it is a small change. It is to introduced the totally 
> new solution which was already defined in the other existing draft. It 
> is not an appropariate behavior and the root cause of the potential 
> confliction.
> 
> 
> I also think the distributed solution includes more than the 
> algorithms defined in the draft-cc-lsr-flooding-reduction-00  and the 
> overlapped signallings  defined in the 
> draft-cc-lsr-flooding-reduction-00/draft-li-dynamic-flooding-03. Since 
> the co-authors could not merge the draft, though the existing 
> suggestion proposed is try to separate the two drafts, there is still 
> overlap on the distributed solution between the two drafts which may 
> be the source of continuous confliction in the future. In order to 
> avoid the situation I would like to propose following
> suggestions:
> - move both the two drafts forward in parallel keeping 
> draft-li-dynamic-flooding focus on the centralized solution and 
> draft-cc-lsr-flooding-reduction on the distributed solution.
> - draft-li-dynamic-flooding can keep on refining the centralized 
> solution without mentioning distibuted solutions.
> - draft-cc-lsr-flooding-reduction can keep on refining the distributed 
> solutions.
> For the sigalling which can be shared by the two modes, the draft can 
> indicate the distributed solutions reuse the signalling defined in 
> draft-li-dynamic-flooding without defining new signalling.
> - both drafts change the draft names to reflect different solutions 
> without causing confusion.
> 
> 
> Thanks & Regards,
> Zhenbin (Robin)
> 
> 
> 
> 
> 
> 
> 发件人: Lsr [lsr-boun...@ietf.org] 代表 Christian Hopps [cho...@chopps.org]
> 发送时间: 2019年2月1日 20:25
> 收件人: lsr@ietf.org
> 抄送: cho...@chopps.org
> 主题: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]
> 
> Summary of where we are at with dynamic flooding reduction:
> 
>  - We have a well written original work that came first and described 
> the problems as well as a TLVs to allow for a centralized solution 
> (draft-li-dyanmic-flooding). We do not need to standardize the 
> centralized algorithm.
> 
>  - A small change to this work allowed for distributed algorithms and 
> for outside work on distributed algorithms to continue in parallel.
> 
>  - We have another original work that started primarily as a distributed 
> algorithm
>(draft-cc-ospf-flooding-reduction)
> 
>  - Finally we also have:
>- Cross-pollination of ideas.
>- Failed attempts at merging.
>- An authors list "Arms-Race".
> 
> Moving forward:
> 
> - During IETF 103 I proposed we have no conflict if we:
> 
>1) adopt draft-li-lsr-dyanmic-flooding as the base WG document.
>2) have authors of draft-cc-lsr-flooding-reduction work on a 
> distributed algorithm as they started with.
> 
> - Acee agreed during the meeting (as chair) that this was the best way 
> forward.
> We had some agreement form the floor as well.
> 
> - Any good ideas regarding the distribution of a centralized topology 
> can be debated and added (with appropriate attribution) to the base 
> document after we adopt one.
> 
> - This is what happens when we adopt a document as WG work, we work on it.
> 
> - The original authors of the distributed solution can continue to 
> 

Re: [Lsr] Comments on draft-hu-lsr-isis-path-mtu

[Huzhibo]

Hi Les & Acee:
Yes, I agree with you, we will merge ISIS & OSPF extensions for Path MTU, and 
isis will reference RFC 7176.

Ths
ZhiBo Hu

From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Monday, July 09, 2018 12:52 PM
To: Acee Lindem (acee) ; Huzhibo 
; lsr@ietf.org
Cc: Dailongfei (Larry, IP Research) ; Lizhenbin 
; zh...@gsta.com
Subject: Comments on draft-hu-lsr-isis-path-mtu

(Changed the subject – was “RE: [Lsr] IETF 102 LSR Working Group Call for 
Agenda Items”)

Zhibo –

Following up on Acee’s comment…he is (of course) quite correct that there 
already is a per link MTU sub-TLV defined by RFC 7176 – it is sub-TLV 28 
defined here: 
https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-22-23-25-141-222-223

In reading your draft, it seems that what you want to advertise is a per link 
attribute – not a per node attribute – in which case the existing sub-TLV is a 
perfect fit.

Not at all clear why we would need a new TLV – nor how such a TLV would allow 
you to advertise a per-link attribute without repeating all of the context 
information (neighbor ID, link endpoint identifiers) already available in TLVs 
22, etc.

Do you agree that IS-IS already has what is needed and therefore does not need 
any additional protocol extension?

   Les

From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Acee 
Lindem (acee)
Sent: Friday, July 06, 2018 6:21 AM
To: Huzhibo mailto:huzh...@huawei.com>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Cc: Dailongfei (Larry, IP Research) 
mailto:larry@huawei.com>>; Lizhenbin 
mailto:lizhen...@huawei.com>>; 
zh...@gsta.com<mailto:zh...@gsta.com>
Subject: Re: [Lsr] IETF 102 LSR Working Group Call for Agenda Items

Hi Zhibo,

I’m sorry but our agenda is already full for IETF 102. As LSR is one of the 
most popular WGs, you need to get your requests in early. With respect to this 
draft, there is already an IS-IS sub-TLV MTU advertisement defined in RFC 7176. 
While the RFC is specific to TRILL, I don’t see any reason why the sub-TLV 
couldn’t be used in non-TRILL deploymennts.

Thanks,
Acee

From: Huzhibo mailto:huzh...@huawei.com>>
Date: Friday, July 6, 2018 at 3:08 AM
To: Acee Lindem mailto:a...@cisco.com>>, 
"lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>
Cc: "zh...@gsta.com<mailto:zh...@gsta.com>" 
mailto:zh...@gsta.com>>, Robin Li 
mailto:lizhen...@huawei.com>>, "Dailongfei (Larry, IP 
Research)" mailto:larry@huawei.com>>
Subject: RE: [Lsr] IETF 102 LSR Working Group Call for Agenda Items

Hi,

Request a slot to discuss ISIS extended for PathMTU:

Drafts:
https://datatracker.ietf.org/doc/draft-hu-lsr-isis-path-mtu/
Presenter: ZhiBo Hu

Duration: 10 mins

Thanks!
ZHiBo

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Monday, June 18, 2018 9:45 PM
To: lsr@ietf.org<mailto:lsr@ietf.org>
Subject: [Lsr] IETF 102 LSR Working Group Call for Agenda Items

Hi Folks,

The LSR (link-state-routing) WG will be meeting on Monday, July 16, 2018 from 
9:30 to 12:00 (the first WG slot of IETF 102).

Please send us (lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>) any requests 
for presentation slots.

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

Re: [Lsr] IETF 102 LSR Working Group Call for Agenda Items

[Huzhibo]

Hi,

Request a slot to discuss Network Automatic Optimization Based on Dynamic 
Adjustment of IGP Metrics:

Drafts:
https://datatracker.ietf.org/doc/draft-hu-lsr-network-automatic-optimization/
Presenter: ZhiBo Hu

Duration: 15 mins

Thanks!
ZHiBo


From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Monday, June 18, 2018 9:45 PM
To: lsr@ietf.org
Subject: [Lsr] IETF 102 LSR Working Group Call for Agenda Items

Hi Folks,

The LSR (link-state-routing) WG will be meeting on Monday, July 16, 2018 from 
9:30 to 12:00 (the first WG slot of IETF 102).

Please send us (lsr-cha...@ietf.org) any requests 
for presentation slots.

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

Re: [Lsr] IETF 102 LSR Working Group Call for Agenda Items

[Huzhibo]

Hi,

Request a slot to discuss ISIS extended for PathMTU:

Drafts:
https://datatracker.ietf.org/doc/draft-hu-lsr-isis-path-mtu/
Presenter: ZhiBo Hu

Duration: 10 mins

Thanks!
ZHiBo

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Monday, June 18, 2018 9:45 PM
To: lsr@ietf.org
Subject: [Lsr] IETF 102 LSR Working Group Call for Agenda Items

Hi Folks,

The LSR (link-state-routing) WG will be meeting on Monday, July 16, 2018 from 
9:30 to 12:00 (the first WG slot of IETF 102).

Please send us (lsr-cha...@ietf.org) any requests 
for presentation slots.

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

[Lsr] Hi, Here are some clarification questions about the flex-algo draft.

[Huzhibo]

Hi,
Here are some clarification questions about the flex-algo draft.
1. As described in section 5, in path computation for a flex-algorithm, the 
node firstly needs to prune the links not included for this flex-algorithm, 
then run SPF or other algorithm within the pruned topology. If a node supports 
multiple algorithms, does this mean the node needs to maintain multiple pruned 
topologies?
2. If one path computed in algorithm-1 with latency metric and another path 
computed in algorithm-2 with bandwidth metric traverse the same link(s) in the 
network, can the latency or bandwidth SLA be guaranteed for the service? Or the 
path may need to be re-computed and adjusted to another link to avoid potential 
performance degradation?

ZhiBo Hu
发件人: Lsr [mailto:lsr-boun...@ietf.org] 代表 Acee Lindem (acee)
发送时间: 2018年4月17日 22:44
收件人: lsr@ietf.org
主题: [Lsr] LSR Working Group Adoption Poll for Flex Algorithm Drafts

This begins a two-week adoption poll for the following Flex Algorithm drafts:

https://datatracker.ietf.org/doc/draft-hegdeppsenak-isis-sr-flex-algo/
https://datatracker.ietf.org/doc/draft-ppsenak-ospf-sr-flex-algo/

The adoption poll will end at 12:00 AM EST on May 2nd, 2018. Please indicate 
your support of opposition of the drafts.

Additionally, the authors are amenable to combining the drafts into a single 
draft. If you have an opinion, please state that as well.

Thanks,
Acee




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