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

2018-04-26 Thread 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


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

2018-07-06 Thread 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

2018-07-06 Thread 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


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

2018-07-09 Thread 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] Working Group Adoption Poll for "OSPF Extension for PrefixOriginator" - draft-wang-lsr-ospf-prefix-originator-ext-01

2019-02-27 Thread 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.

2019-02-13 Thread 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]

2019-02-11 Thread 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] I-D Action: draft-ietf-lsr-dynamic-flooding-04.txt

2019-11-29 Thread 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] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

2020-01-24 Thread 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

2020-01-23 Thread 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] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

2020-08-25 Thread 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-bonica-lsr-ip-flexalgo-00.txt

2020-09-29 Thread 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] New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt

2020-09-29 Thread 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] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call

2020-05-29 Thread 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


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

2020-06-03 Thread 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] A question about draft-ietf-lsr-flex-algo

2020-06-03 Thread 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


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

2020-07-29 Thread 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

2020-07-29 Thread 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

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

2020-07-30 Thread 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

2020-07-30 Thread 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

2020-07-30 Thread 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

2020-07-30 Thread 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

2020-07-30 Thread 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
>>&

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

2020-11-13 Thread 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] Prefix Unreachable Announcement Use Cases

2020-11-17 Thread 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)

2020-11-15 Thread 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