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

From: John Scudder via Datatracker <[email-masked]>
Date: Tue, 06 Apr 2021 14:06:17 -0700

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
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/

----------------------------------------------------------------------
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/

---

From: "Aijun Wang" <[email-masked]>
Date: Wed, 7 Apr 2021 10:01:32 +0800

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: [email-masked] <[email-masked]> On Behalf Of John Scudder via Datatracker
Sent: Wednesday, April 7, 2021 5:06 AM
To: The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: [Lsr] John Scudder's Discuss on draft-ietf-lsr-ospf-prefix-originator-10: (with DISCUSS and COMMENT)

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

 

 <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:

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:

   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:

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:

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:

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?

5. Section 5, nit:

s/operation/operational/

_______________________________________________

Lsr mailing list

 <mailto:[email-masked]> [email-masked]

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

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Wed, 7 Apr 2021 05:29:47 +0000

Hi John,

Thanks for your review and comments. Please check inline below.

-----Original Message-----
From: John Scudder via Datatracker <[email-masked]>
Sent: 07 April 2021 02:36
To: The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; Christian Hopps <[email-masked]>; [email-masked]; [email-masked]
Subject: John Scudder's Discuss on draft-ietf-lsr-ospf-prefix-originator-10: (with DISCUSS and COMMENT)

DISCUSS:

[KT] I see that Aijun has responded on this one and we can use that thread for further discussion on this point.

COMMENT:

1. Section 2:

   as a prefix attribute.

[KT] Will update with your text proposal. Thanks.

2. Section 2.1:

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

[KT] The ignoring part is for the user of the information. Since the days of RSVP-TE (RFC3630), we've had OSPF flooding information about TE topology opaquely (i.e. not using for OSPF computations) while it is being used by for computation of RSVP-TE tunnel paths/LSPs. The same applies here.

— so does this mean the sub-TLV isn’t even supposed to be stored?

Flooded?

[KT] Per OSPF protocol, we have to store it and flood it - since the information is not "malformed" or "not parsable".

3. Section 3:

[KT] It was not meant to be normative/limiting. Will update to use "for example".

4. Section 3:

[KT] Consider that there are N contributing routes at the ABR and B of them were contributing to the "best reachability" (where N >= B). Out of those B routes, if only M advertisements are including the prefix origin info (where B >= M). Then the ABR does a single inter-area prefix advertisement that will include the M prefix origin info. This is conveyed by the two sentences in bold in the text above.

[KT] Ack

5. Section 5, nit:

s/operation/operational/

[KT] Ack

Thanks,

Ketan

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Wed, 7 Apr 2021 05:38:19 +0000

To add, the draft also has the following text in the introduction section:

   The primary use case for the extensions proposed in this document is
   to be able to identify the originator of a prefix in the network.  In
   cases where multiple prefixes are advertised by a given router, it is
   also useful to be able to associate all these prefixes with a single
   router even when prefixes are advertised outside of the area in which
   they originated.  It also helps to determine when the same prefix is
   being originated by multiple routers across areas.

The use-cases are similar in nature to those where the routing information being flooded/advertised by IGPs is used for/by other routing applications (e.g. TE) on the router or outside the router by an app/controller. The document does not describe those use-cases in further details since they are outside the scope of OSPF protocol and LSR WG.

The reason that the use-case that Aijun mentioned was asked to be removed from the document was on the same reasoning as above. Also, for that specific use-case, there was a lot of debate on the correctness and applicability as a generalized mechanism to be covered in this standards track document.

Hope this clarifies.

Thanks,
Ketan

From: Aijun Wang <[email-masked]>
Sent: 07 April 2021 07:32
To: 'John Scudder' <[email-masked]>; 'The IESG' <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Lsr] John Scudder's Discuss on draft-ietf-lsr-ospf-prefix-originator-10: (with DISCUSS and COMMENT)

Hi, John:

Thanks for your review.

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.

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.

Thanks in advance.

Best Regards

Aijun Wang
China Telecom

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>> On Behalf Of John Scudder via Datatracker
Sent: Wednesday, April 7, 2021 5:06 AM
To: The IESG <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [Lsr] John Scudder's Discuss on draft-ietf-lsr-ospf-prefix-originator-10: (with DISCUSS and COMMENT)

DISCUSS:

COMMENT:

1. Section 2:

   as a prefix attribute.

2. Section 2.1:

Flooded?

3. Section 3:

4. Section 3:

5. Section 5, nit:

s/operation/operational/

Lsr mailing list

[email-masked]<mailto:[email-masked]>

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

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Wed, 7 Apr 2021 08:47:51 +0000

Hi John,

An update to the draft with to address some of your comments (as discussed in the email below) as well as Ben's and Eric's comments has just been posted : https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-prefix-originator-11

Thanks,
Ketan

From: Ketan Talaulikar (ketant)
Sent: 07 April 2021 11:00
To: John Scudder <[email-masked]>; The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; Christian Hopps <[email-masked]>; [email-masked]
Subject: RE: John Scudder's Discuss on draft-ietf-lsr-ospf-prefix-originator-10: (with DISCUSS and COMMENT)

Hi John,

-----Original Message-----
From: John Scudder via Datatracker <[email-masked]<mailto:[email-masked]>>
Sent: 07 April 2021 02:36
To: The IESG <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Christian Hopps <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: John Scudder's Discuss on draft-ietf-lsr-ospf-prefix-originator-10: (with DISCUSS and COMMENT)

DISCUSS:

COMMENT:

1. Section 2:

   as a prefix attribute.

2. Section 2.1:

Flooded?

3. Section 3:

4. Section 3:

[KT] Ack

5. Section 5, nit:

s/operation/operational/

[KT] Ack

Thanks,

Ketan

---

From: John Scudder <[email-masked]>
Date: Thu, 8 Apr 2021 00:18:33 +0000

Hi Aijun,

Thanks for your reply. You’re right of course that the introduction has some description of what the extensions are for, I don’t think any more editing is needed there. I would prefer to see a sentence in the abstract as well, since for some people the abstract is the only look they’ll take at the document and for them, the question of “what is it for?” isn’t answered. I don’t insist on this, but I recommend it. The additional sentence, if you choose to add it, could be something like “this information does not change route computation but is expected to be useful for network analysis and troubleshooting”.

I don’t think there is any need to re-introduce the text or appendix the WG removed.

Thanks,

—John

On Apr 6, 2021, at 10:01 PM, Aijun Wang <[email-masked]<mailto:[email-masked]>> wrote:

Hi, John:

Thanks for your review.

Actually, there are use case descriptions in the previous version of this draft, please refer tohttps://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-prefix-originator-05<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-prefix-originator-05__;!!NEt6yMaO-gk!WeC6Da_Z-_FpiT5W-54Gss2gYdZ3WdksZhd7RWfkbQ3Zh8AanentfKK7B8Auzw$>.
Section 4<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-prefix-originator-05*section-4__;Iw!!NEt6yMaO-gk!WeC6Da_Z-_FpiT5W-54Gss2gYdZ3WdksZhd7RWfkbQ3Zh8AanentfKLXA-I2NQ$> and section 5<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-prefix-originator-05*section-5__;Iw!!NEt6yMaO-gk!WeC6Da_Z-_FpiT5W-54Gss2gYdZ3WdksZhd7RWfkbQ3Zh8AanentfKKIUz4-AQ$> of this version describes its uses for inter-area topology recovery and external prefix source determination.

There is also one Appendix<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-prefix-originator-05*appendix-A__;Iw!!NEt6yMaO-gk!WeC6Da_Z-_FpiT5W-54Gss2gYdZ3WdksZhd7RWfkbQ3Zh8AanentfKJ6qMsiHQ$> 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: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>> On Behalf Of John Scudder via Datatracker
Sent: Wednesday, April 7, 2021 5:06 AM
To: The IESG <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [Lsr] John Scudder's Discuss on draft-ietf-lsr-ospf-prefix-originator-10: (with DISCUSS and COMMENT)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html<https://urldefense.com/v3/__https://www.ietf.org/iesg/statement/discuss-criteria.html__;!!NEt6yMaO-gk!WeC6Da_Z-_FpiT5W-54Gss2gYdZ3WdksZhd7RWfkbQ3Zh8AanentfKKz0tebDA$>
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://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-prefix-originator/__;!!NEt6yMaO-gk!WeC6Da_Z-_FpiT5W-54Gss2gYdZ3WdksZhd7RWfkbQ3Zh8AanentfKJTFeK0qw$>

1. Section 2:

2. Section 2.1:

3. Section 3:

4. Section 3:

5. Section 5, nit:

s/operation/operational/

_______________________________________________
Lsr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lsr<https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!WeC6Da_Z-_FpiT5W-54Gss2gYdZ3WdksZhd7RWfkbQ3Zh8AanentfKJcqk9Wig$>

---

From: John Scudder <[email-masked]>
Date: Thu, 8 Apr 2021 00:29:50 +0000

Hi Ketan,

Thanks for your reply. Some comments in line.

On Apr 7, 2021, at 1:29 AM, Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>> wrote:
...
2. Section 2.1:

OK. If “ignore” makes it dead obvious to your audience (which might include relative novices as well as seasoned experts) that in context this is what it means, that’s fine. I leave it to your discretion whether it warrants any further clarification such as you’ve provided above.

...
4. Section 3:

OK. And it’s considered fine that that information for some, but not all, of the contributors is included? It seems potentially problematic that the route only includes partial information, but the consumer of the route has no way to know this. The other obvious choices would have been to omit the information altogether if only partial information was available, or to mark it as partial somehow.

Thanks,

—John