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

["Acee Lindem (acee)" <[e-mail]>]

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.
Thanks,
Acee

From: Aijun Wang <[e-mail]>
Date: Monday, July 27, 2020 at 9:57 PM
To: Acee Lindem <[e-mail]>, 'Aijun Wang' <[e-mail]>, "[e-mail]" <[e-mail]>
Cc: 'Zhibo Hu' <[e-mail]>, 'Yaqun Xiao' <[e-mail]>
Subject: RE: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt


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: [e-mail] [mailto:[e-mail]] On Behalf Of Acee Lindem (acee)
Sent: Tuesday, July 28, 2020 1:51 AM
To: Aijun Wang <[e-mail]>; [e-mail]
Cc: 'Zhibo Hu' <[e-mail]>; 'Yaqun Xiao' <[e-mail]>
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.

[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 design.

[WAJ] section 3 of this draft<https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-03#section-3> 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<https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-03#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.



Acee



On 7/26/20, 9:34 PM, "Lsr on behalf of Aijun Wang" <[e-mail] on behalf of [e-mail]<mailto:[e-mail][e-mail]>> 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: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]]

    Sent: Monday, July 27, 2020 9:16 AM

    To: Zhibo Hu <[e-mail]<mailto:[e-mail]>>; Aijun Wang <[e-mail]<mailto:[e-mail]>>; Yaqun Xiao <[e-mail]<mailto:[e-mail]>>

    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

    [e-mail]<mailto:[e-mail]>

    https://www.ietf.org/mailman/listinfo/lsr



_______________________________________________

Lsr mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/lsr