[mpls] Re: John Scudder's Discuss on draft-ietf-mpls-mldp-multi-topology-05: (with DISCUSS and COMMENT)

[John Scudder <[e-mail]>]

Hi Mankamana,

Thanks for your reply. My replies below, trimmed (“…”) for brevity.

—John

On May 17, 2024, at 6:26 PM, Mankamana Mishra (mankamis) <[e-mail]> wrote:


Hi John,
Thanks for the comment. Please find inline answers.
…

## DISCUSS

### Sections 4.1.2, 6.1, sources of IGP Algorithm values

These sections say, “IPA: The IGP Algorithm, values are from the IGP Algorithm
registry”. But earlier on, the document talks about the IGP algorithm field as
relating specifically to flexible algorithms. Flexible algorithms are not
registered, other than the range 128-255 being marked as reserved in the
registry. RFC 9350 section 4 specifically says that they are locally
configured. So... are the values really from the registry?

Quite likely this only requires a small wording change, but I wanted to make
sure I'm not missing some bigger issue.

MM :mLDP needs to build hop by hop tree towards root and IGP provides information about next hop to reach root based in information stored in routing table. Routing table now can be tied to topology, Flex algo to compute the next hop. This document defines field where any algorithm can be encoded.  Do we need to specify it ?

We need to work a little bit more on the wording. I see two issues.

First, although your document focuses on Flex Algo, RFC 8665 also provides another non-default algorithm, and more could be specified in the future. If I understand both the document and your comment above correctly, you don't believe your document is limited to use only with Flex Algo, but instead, it could be used with any algorithm that's signaled in the Algorithm field. In some cases, this will be a registered algorithm, and in others such as the Flex Algo case, it will be locally defined. Is that an accurate statement? If so, I think it would be worth revising the document to make it clear that it's applicable more broadly. Something like this,

OLD:
   Multi-Topology Routing (MTR) is a technology to enable service
   differentiation within an IP network.  Flexible Algorithm (FA) is
   another mechanism of creating a sub-topology within a topology using
   defined topology constraints and computation algorithm.  In order to
   deploy mLDP (Multipoint label distribution protocol) in a network
   that supports MTR and/or FA, mLDP is required to become topology and
   FA aware.  This document specifies extensions to mLDP to support MTR,
   with FA, in order for Multipoint LSPs(Label Switched Paths) to follow
   a particular topology and algorithm.

NEW:
   Multi-Topology Routing (MTR) is a technology to enable service
   differentiation within an IP network.  Flexible Algorithm (FA) is
   another mechanism of creating a sub-topology within a topology using
   defined topology constraints and computation algorithm.  In order to
   deploy mLDP (Multipoint label distribution protocol) in a network
   that supports MTR, FA, or other methods of signaling non-default
   IGP algorithms, mLDP is required to become topology and
   algorithm aware.  This document specifies extensions to mLDP to support MTR,
   with algorithm, in order for Multipoint LSPs(Label Switched Paths) to follow
   a particular topology and algorithm.

That's not a complete revision, I just did the abstract. If you agree with the overall approach, maybe you could do a scrub on the document looking for “FA”, “Flexible Algorithm”, etc, and determine if revisions are called for. I'm not recommending you completely scrub the term “Flex Algo” out of the document, after all, it is your main use case, but I do think you should try to avoid creating the appearance that the document is restricted to that use.

Basically what I'm trying to do here is protect the future applicability of your document. If it appears to be limited to Flex Algo only, that might be unfortunate.

Second, we have the following identical text in two places:

Section 4.1.2:
      IPA: The IGP Algorithm, values are from the IGP Algorithm Types
      registry.

Section 6.1:
      IPA: The IGP Algorithm, values are from the IGP Algorithm Types
      registry.

My point was relatively subtle, which is that the registry isn't the source of values in all cases, in the Flex Algo case (which is your main use case!) the values are locally configured, the registry only protects the range. I think it would be overkill to spell out all the details in this document, after all, people will have to refer to the underlying specifications if they want to understand how to compute these alternative topologies anyway. So I think a little finessing of the text would be good enough, something like,

NEW:
      IPA: The IGP Algorithm, refer to the IGP Algorithm Types
      registry [IANA-REG].

And then supply the registry in your references. This is a less important point than the previous one, but we probably can agree that “values are from” isn’t quite right… I can’t go to the registry and find out what Algorithm 197 is, all I can find out is that it’s an FA code point, but the registry tells me nothing more.

...
## COMMENT

- This document should update RFC 7307, as a way of informing readers of RFC
7307 that the previously reserved half-field has been allocated and is no
longer available. (That is, it should use the "Updates" header, mention in the
abstract that it does, and briefly explain in the introduction, otherwise,
idnits will complain.)
MM : Added in top. It did not complaint about it .

Interesting, I guess that is only in the guidance to the document shepherd and not in the automated idnits tool. Nonetheless, it is a recommended best practice. Here's some suggested text, continuing to modify the previous NEW block from above. (Added final sentence.)

NEW:
   Multi-Topology Routing (MTR) is a technology to enable service
   differentiation within an IP network.  Flexible Algorithm (FA) is
   another mechanism of creating a sub-topology within a topology using
   defined topology constraints and computation algorithm.  In order to
   deploy mLDP (Multipoint label distribution protocol) in a network
   that supports MTR, FA, or other methods of signaling non-default
   IGP algorithms, mLDP is required to become topology and
   algorithm aware.  This document specifies extensions to mLDP to support MTR,
   with algorithm, in order for Multipoint LSPs(Label Switched Paths) to follow
   a particular topology and algorithm. It updates RFC 7307 by allocating
   eight bits from a previously reserved field to be used as the “IPA” field.