Re: [Lsr] John Scudder's Discuss on draft-ietf-lsr-ospf-prefix-originator-10: (with DISCUSS and COMMENT)

Aijun Wang <wangaijun@tsinghua.org.cn> Wed, 07 April 2021 02:01 UTC

Return-Path: <wangaijun@tsinghua.org.cn>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BAD33A3A2B; Tue, 6 Apr 2021 19:01:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level:
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5W9vtC6hJrQ7; Tue, 6 Apr 2021 19:01:38 -0700 (PDT)
Received: from mail-m17638.qiye.163.com (mail-m17638.qiye.163.com [59.111.176.38]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F37473A3A2C; Tue, 6 Apr 2021 19:01:36 -0700 (PDT)
Received: from DESKTOP2IOH5QC (unknown [219.142.69.75]) by mail-m17638.qiye.163.com (Hmail) with ESMTPA id 1ECB01C0139; Wed, 7 Apr 2021 10:01:32 +0800 (CST)
From: "Aijun Wang" <wangaijun@tsinghua.org.cn>
To: "'John Scudder'" <jgs@juniper.net>, "'The IESG'" <iesg@ietf.org>
Cc: <lsr-chairs@ietf.org>, <aretana.ietf@gmail.com>, <draft-ietf-lsr-ospf-prefix-originator@ietf.org>, <chopps@chopps.org>, <lsr@ietf.org>
References: <161774317736.9168.4218690589649539196@ietfa.amsl.com>
In-Reply-To: <161774317736.9168.4218690589649539196@ietfa.amsl.com>
Date: Wed, 7 Apr 2021 10:01:32 +0800
Message-ID: <007801d72b51$eea539f0$cbefadd0$@tsinghua.org.cn>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0079_01D72B94.FCCD0DD0"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQEVhT1kCuskXHH2uUVCb1Ep0DcDKKwrkSVA
Content-Language: zh-cn
X-HM-Spam-Status: e1kfGhgUHx5ZQUtXWQgYFAkeWUFZS1VLWVdZKFlBSkxLS0o3V1ktWUFJV1 kPCRoVCBIfWUFZSkhPSk5CHkgaS0tOVkpNSkxMTUtDQklOT05VEwETFhoSFyQUDg9ZV1kWGg8SFR 0UWUFZT0tIVUpKS09ISFVLWQY+
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6OBQ6FDo*Lz8TNCwVKUMyHzYe KDcaChJVSlVKTUpMTE1LQ0JIS0JMVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlJSkJVSk9JVU1CVUxOWVdZCAFZQUhPQ0lPNwY+
X-HM-Tid: 0a78aa1035d3d993kuws1ecb01c0139
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/arA6K9rv5Zahewp0yAG-ZfVt_gY>
Subject: Re: [Lsr] John Scudder's Discuss on draft-ietf-lsr-ospf-prefix-originator-10: (with DISCUSS and COMMENT)
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Apr 2021 02:01:43 -0000

Hi, John:

 

Thanks for your review.

Let me respond your concern for the usages of such information first.  Ketan, Acee and other co-authors may respond you other comments.

 

Actually, there are use case descriptions in the previous version of this draft, please refer to https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-prefix-originator-05. 

Section 4 <https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-prefix-originator-05#section-4>  and section 5 <https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-prefix-originator-05#section-5>  of this version describes its uses for inter-area topology recovery and external prefix source determination.

 

After discussion within the WG, we removes the use case descriptions within the body of the document, just keep some short descriptions as that in the introduction part of the current version:

“This document proposes extensions to the OSPF protocol for inclusion

   of information associated with the router originating the prefix

   along with the prefix advertisement.  These extensions do not change

   the core OSPF route computation functionality.  They provide useful

   information for topology analysis and traffic engineering, especially

   on a controller when this information is advertised as an attribute

   of the prefixes via mechanisms such as Border Gateway Protocol Link-

   State (BGP-LS)”

Do you think it is enough?

 

There is also one Appendix <https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-prefix-originator-05#appendix-A>  in the version 05 of this document, to describe clearly the usage of such prefix originator information, but was opposed by some experts during the WG last call.

Do we need to add back to them? I think they are helpful for the usage and deployment of this document. And, such use case is the main start point of this document.

 

Thanks in advance.

 

Best Regards

 

Aijun Wang

China Telecom

 

-----Original Message-----
From: lsr-bounces@ietf.org <lsr-bounces@ietf.org> On Behalf Of John Scudder via Datatracker
Sent: Wednesday, April 7, 2021 5:06 AM
To: The IESG <iesg@ietf.org>
Cc: lsr-chairs@ietf.org; aretana.ietf@gmail.com; draft-ietf-lsr-ospf-prefix-originator@ietf.org; chopps@chopps.org; lsr@ietf.org
Subject: [Lsr] John Scudder's Discuss on draft-ietf-lsr-ospf-prefix-originator-10: (with DISCUSS and COMMENT)

 

John Scudder has entered the following ballot position for

draft-ietf-lsr-ospf-prefix-originator-10: Discuss

 

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)

 

 

Please refer to  <https://www.ietf.org/iesg/statement/discuss-criteria.html> https://www.ietf.org/iesg/statement/discuss-criteria.html

for more information about IESG DISCUSS and COMMENT positions.

 

 

The document, along with other ballot positions, can be found here:

 <https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-prefix-originator/> https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-prefix-originator/

 

 

 

----------------------------------------------------------------------

DISCUSS:

----------------------------------------------------------------------

 

Although the document is largely clear and well-written (thanks for that), I was left with one burning question: what are these sub-TLVs *for*? There’s no specification for what the router is supposed to do with them, only how to originate them. The only clue I get is buried down in Section 5:

 

   The identification of the node that is originating a specific prefix

   in the network may aid in debugging of issues related to prefix

   reachability within an OSPF network.

 

If their purpose is to act as debugging aids, I think you should at least say so briefly in the abstract and introduction. If they have some purpose beyond that, it’s missing from the doc.

 

 

----------------------------------------------------------------------

COMMENT:

----------------------------------------------------------------------

 

1. Section 2:

 

   This document defines the Prefix Source OSPF Router-ID and the Prefix

   Source Router Address Sub-TLVs for inclusion of the Router ID and a

   reachable address information for the router originating the prefix

   as a prefix attribute.

 

I found this sentence difficult to read. I think removing the redundant word “information” would help a little. Beyond that, it might help to break it into a couple sentences, as in: “This document defines the Prefix Source OSPF Router-ID and the Prefix Source Router Address Sub-TLVs. They are used, respectively, to include the Router ID of, and a reachable address of, the router that originates the prefix as a prefix attribute.”

 

2. Section 2.1:

 

   For intra-area prefix advertisements, the Prefix Source OSPF Router-

   ID Sub-TLV MUST be considered invalid and ignored if the OSPF Router

   ID field is not the same as Advertising Router field in the

   containing LSA.  Similar validation cannot be reliably performed for

   inter-area and external prefix advertisements.

 

What does it mean for the sub-TLV to be ignored? Since you haven’t specified any processing of the Sub-TLVs, there’s seemingly no ignoring to be done locally — so does this mean the sub-TLV isn’t even supposed to be stored?

Flooded?

 

3. Section 3:

 

   If the originating node is advertising an OSPFv2 Router Address TLV

   [RFC3630] or an OSPFv3 Router IPv6 Address TLV [RFC5329], then the

   same address MUST be used in the Router Address field of the Prefix

   Source Router Address Sub-TLV.  When the originating node is not

   advertising such an address, implementations can determine a unique

   and reachable address (i.e., advertised with the N-flag set [RFC7684]

   or N-bit set [RFC8362]) belonging to the originating node to set in

   the Router Address field.

 

As I read this, if there’s no Router Address TLV, then the implementation has to use something it advertised with the N-flag set. I infer this because you used “i.e.” (which essentially means “in other words”). If you do mean the parenthetical to be limiting, why not make it a MUST? If you don’t mean it to be limiting, shouldn’t it be “e.g.” or better still, “for example”?

 

(Looking at RFC 7684 it doesn’t seem as though it should be limiting, because RFC 7684 § 2.1 says the N-flag is optional even for local routes.)

 

4. Section 3:

 

   When an ABR generates inter-area prefix advertisements into its non-

   backbone areas corresponding to an inter-area prefix advertisement

   from the backbone area, the only way to determine the originating

   node information is based on the Prefix Source OSPF Router-ID and

   Prefix Source Router Address Sub-TLVs present in the inter-area

   prefix advertisement originated into the backbone area by an ABR from

   another non-backbone area.  The ABR performs its prefix calculation

   to determine the set of nodes that contribute to the best prefix

   reachability.  It MUST use the prefix originator information only

   from this set of nodes.  The ABR MUST NOT include the Prefix Source

   OSPF Router-ID or the Prefix Source Router Address Sub-TLVs when it

   is unable to determine the information of the best originating node.

 

What is it supposed to do if there are N contributing routes but it can only determine the information for M < N of the contributors?

 

Also, should “node” be “nodes” (last word of last sentence)?

 

5. Section 5, nit:

 

   Consideration should be given to the operation impact of the increase

 

s/operation/operational/

 

 

 

_______________________________________________

Lsr mailing list

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

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