Hi Aijun,

You did misunderstand me so let me be brief.

  1.  By summarized prefix, I mean an unreachable prefix subsumed by the 
summary advertisement. I thought this would be clear from the context of your 
draft. So my point is that signaling unreachability from one ABR is only useful 
if the subsumed prefix is reachable though another ABR.
  2.  What I’m suggesting is provide connectivity between the ABRs. For 
example, you use the tunneling defining in section 6.1 whenever a subsumed 
prefix is unreachable. Please don’t come back with another circular argument.

From: Aijun Wang <wangai...@tsinghua.org.cn>
Date: Monday, July 27, 2020 at 9:57 PM
To: Acee Lindem <a...@cisco.com>, 'Aijun Wang' <wang...@chinatelecom.cn>, 
"lsr@ietf.org" <lsr@ietf.org>
Cc: 'Zhibo Hu' <huzh...@huawei.com>, 'Yaqun Xiao' <xiaoya...@huawei.com>
Subject: RE: [Lsr] New Version Notification for 

Hi, Acee:

Let me try to answer your concerns.

Please see the below inline.

If I missed your comments, please correct me.

Best Regards

Aijun Wang

China Telecom

-----Original Message-----
From: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] On Behalf Of Acee 
Lindem (acee)
Sent: Tuesday, July 28, 2020 1:51 AM
To: Aijun Wang <wang...@chinatelecom.cn>; lsr@ietf.org
Cc: 'Zhibo Hu' <huzh...@huawei.com>; 'Yaqun Xiao' <xiaoya...@huawei.com>
Subject: Re: [Lsr] New Version Notification for 

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.

[WAJ] Let’s confirm it is not cliff ☺, but traffic black hole that should be 
notified and repaired.

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 

[WAJ] section 3 of this 
 has demonstrated the problem/scenarios that needs to be addressed. We think 
this will be normal phenomena in the IPv6 era.

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

[WAJ] it is not the unreachability of a given summarized prefix, but the more 
specific prefix that within the summary address.

In this case, the network design should provide adequate intra-area redundancy 
to provide communications between the ABRs.

[WAJ] Even there is adequate intra-area redundancy communication between the 
ABRs, the failure of one specific prefix within the summary address that 
advertised by the ABR will lead to traffic black hole.

If this cannot be accomplished, an intra-area adjacency should be established 
over a tunnel between the ABRs in the backbone.

[WAJ] Section 6.1 introduces the tunnel solution to redirect the traffic to 
another ABR, when such ABR router can reach the specified prefix.  But this 
additional mechanism will be used only when the ABR all reach the PUA limit. If 
not, the PUA mechanism described in section 
 can be used to guide the traffic.

Contrary to section 6.1, Looping is normally not a problem as ABRs should add 
back hole routes for their advertised summaries.

[WAJ] Yes, you are right. Normally the ABR will drop the traffic that it can’t 
reach.  But there is situation that when the tunnel that is pre-established 
among ABRs, and each tunnel claim it can reach the specified prefix, the 
traffic loop may arise if the received ABR send traffic via another tunnel.


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

    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 

    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 <huzh...@huawei.com<mailto:huzh...@huawei.com>>; Aijun Wang 
<wang...@chinatelecom.cn<mailto:wang...@chinatelecom.cn>>; Yaqun Xiao 

    Subject: New Version Notification for 

    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 

    Name:              draft-wang-lsr-prefix-unreachable-annoucement

    Revision: 03

    Title:                 Prefix Unreachable Announcement

    Document date:      2020-07-27

    Group:             Individual Submission

    Pages:              11







       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 mailing list


Lsr mailing list

Reply via email to