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 J, 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 draft 
  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 4 
  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 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 

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

    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

     <mailto:Lsr@ietf.org> Lsr@ietf.org




Lsr mailing list

 <mailto:Lsr@ietf.org> Lsr@ietf.org


Lsr mailing list

Reply via email to