Re: [mpls] Some review comments on draft-ietf-mpls-mna-fwk-04

["Dongjie (Jimmy)" <[e-mail]>]

Hi Stewart,

Thanks for your reply, please see further discussion inline:

From: Stewart Bryant [mailto:[e-mail]]
Sent: Thursday, September 21, 2023 9:54 PM
To: Dongjie (Jimmy) <[e-mail]>
Cc: Stewart Bryant <[e-mail]>; [e-mail]; MPLS Working Group <[e-mail]>; loa Andersson <[e-mail]>; Matthew Bocci <[e-mail]>; Tony Li <[e-mail]>
Subject: Re: [mpls] Some review comments on draft-ietf-mpls-mna-fwk-04

Hi Jie

Here are my personal comments on your review comments.


On 20 Sep 2023, at 12:56, Dongjie (Jimmy) <jie.dong=[e-mail]<mailto:jie.dong=[e-mail]>> wrote:

Hi authors,

Thanks for the effort on this important framework document. I’m reviewing the latest version, and please find some comments for your consideration.

1.       In the abstract, it says:

   “The document describes a common set of network actions and
   information elements supporting additional operational models and
   capabilities of MPLS networks.”

While I didn’t find specific network actions described in the following sections, maybe this sentence needs to be rephrased or removed?

Similar text is also used in the introduction.

SB> I agree, I will propose text to my colleague in the editing team.

[Jie] OK, I can check the updated text later.



2.       In the introduction, the reference to the MNA requirement document uses the old requirement draft name. Need to update it with “draft-ietf-mpls-mna-requirements”

There are several occurrence of this reference in the document, and in the normative reference section.

SB> Correct we will correct this,

[Jie] OK, thanks.



3.       In section 1.2.1, the definition of NAS, it says:

         “The TC and TTL values in the LSEs in the NAS may be redefined, but the meaning of the S bit is unchanged.”

This is not clear about whether the label field can be redefined or not. Suggest to make that explicit.

SB> Text proposed to the editors

[Jie] OK, thanks.


4.       In section 1.2.2:
-          The acronym “MNA” was firstly introduced and used in the requirement draft. Need to update the reference to the requirement draft.
SB> Correct


-          The acronym “NAI” is short for “Network Action Indication”, while here it is “Network Action Indicator”. Suggest to make it consistent. There are several occurrence of “Network Action Indicator” in the document.

SB> I agree it should be consistent, but FWK and Requirements both use “Indicator", where is Indication used?

[Jie] “Network action indication” was defined in the terminology section of the requirement draft. Maybe it is simpler to replace that one in the requirement draft with “indicator”.


5.       Section 2 begins with the description

“An MNA solution is envisioned as a set of network action sub-stacks, plus possible post-stack data.”

As a framework document, before going to the MNA solutions, maybe it is better to firstly introduce why the new concepts and entities (NAS, ISD, PSD) are introduced for MNA, the relationship between these entities (e.g. NAS may optionally contain ISD, ISD and PSD may be used to carry ancillary data for different applications), In addition, the characteristics (pros and cons) of ISD and PSD could also be described.

Another important thing is the changes introduced by NAS/ISD/PSD to the existing MPLS architecture needs be specified in this document.

SB> I think some additional text would be beneficial, particularly for those readers who are reading this at an RFC rather than for those of us that are developing this technology.

[Jie] That is also what I thought. More information needs to be provided to the readers who didn’t directly participate in the design and development of MNA.

And people needs to be informed of the potential changes introduced to the MPLS architecture, including the LSE encapsulation, the label stack processing and forwarding model, etc.


6.       Following the text in previous comment, section 2 says:
   “A solution must specify where in the
   label stack the network actions sub-stacks occur, if and how
   frequently they should be replicated, and how network action sub-
   stack and post-stack data are encoded. ”

This sounds like a requirement on the MNA encapsulation. Does it belong to this framework document, or the requirement draft? There are several other places where the text reads like a requirement on an MNA solution.

Here it mentions the replication of NAS. Before this, it may need to give some introduction about the cases where NAS needs to be replicated.


SB> I think that the approach is OK. A framework element mad provide a solution if that is generally agreed, but where not it may state the requirements on a component of the solution that operates with the framework.

[Jie] This explanation is OK to me.  While some of these requirements are related to the items in section 3.2 of the requirement draft.  It would be more convenient for readers if the related requirements are documented in one place.


7.       Section 2 gives description of NAS, the second bullet of which says:

      “Indicators : Optionally , a set of indicators that describes the set
      of network actions.”


IMO the indicators of network actions are mandatory in NAS for parsing the network actions correctly. Hence “optionally” here is not quite accurate.


Here is the problem. The FWK is written to cover the general case and we have an instance of a network action that does not have any indicators: The ELI which operates without and indicator. Thus the text is correct. However I can see that read from the perspective of the project we are working on I think Jie is correct in that to conserve SPLs we do not envisage a case where there is no indicator.

Note that the text includes the case where the indicators are post stack, and we could have PSD based on a service label (it is what we do with PWs).

So whilst I can see the confusion I think that on balance the text is correct.

If anyone can propose some text to better describe this, I am sure it would be welcome.

[Jie] Thanks for the analysis.  While it is not clear to me whether ELI/EL can be considered as one application of MNA, or it is something similar but independent of MNA, after the WG have decided not to reuse ELI for MNA indication.

But you correctly mentioned the case where the indicators are post stack, which is valid, in this case there will be no ISD, just the MNA label and the PSD.

Thus my suggested text is:

    Indicators: Optionally, a set of indicators that describes the set of network actions in NAS.



8.       Section 2 describes the relationship between indicator and ISD:

      “Indicators are not considered ancillary data.”

But it also says: “If the set of indicators is not in the sub-stack, a solution could encode them in post-stack data .”

This seems confusing as the definition of ISD and PSD are in-stack and post-stack ancillary data respectively. Suggest to make the relationship between the indicators and ISD/PSD aligned, either indicators can be part of the ISD/PSD, or indicators are independent of ISD/PSD.

Again it is tricky to get the balance right between the generality and the specifics of the solution for NMA ISD that we seem to be heading for.

I think the text is correct for the general case. The question for the WG is whether we need to also include some clarification for the specifics.

As I nite above you could conform the FWK without any ISD indicators, or actually even any PSD indicators.

If ancons can propose text that would be useful.

[Jie] I agree the framework needs to provide general descriptions without restricting to a specific encoding solution. While it still needs to clarify the relationship between indicators and ancillary data in general, and be consistent on whether ISD and PSD are just “ancillary data” or “indicator and ancillary data”.

Thus my suggestion on the text is:

        A solution may encode a set of indicators post the label stack, these indicators may be used with post-stack data.



9.       Section 2 has the following text about the size of ISD:

     “Each network action present in the network action sub-stack may have zero or more LSEs of in-stack data.”

Does this mean the size of the ancillary data for each network action is always 4-octet (the size of LSE) aligned in the NAS?

Maybe I do not understand the point, but an network action may be entirely contained one LSE (4 bytes) but it may have data in subsequent LSEs and this is always placed in the stack in one or more 4 byte LSEs. I think the text as written is correct.

[Jie] I didn’t make it clear enough. My question is: can the size of ISD for a specific action shorter than 4 bytes, or not be an integral multiple of four bytes?


10.   In section 2.1, the I2E scope is defined as:
“Ingress-to-Egress (I2E): Only the last node on the path will perform the action.”

Yes

Note that only some of the scopes are described and I suppose you might also have an Ingress and Egress scope.

An example of an I2E might be a ping reply. An example of a I&E might be a delay measurement.

So I think that the text is correct as written.

[Jie] Thanks for the explanation, now I understand the difference. In some cases the egress node may need to know whether the ingress have performed the action or not. Thus maybe I&E could be added to the types of scopes.


Does the ingress node also need to perform the action?

11.   Section 2.2 talks about the processing of MNA by legacy nodes. This is related to backward compatibility. It is suggested to have a dedicated section on backward compatibility, so as to help people to understand the backward compatibility with legacy MPLS nodes in existing MPLS networks.

In addition to saying legacy nodes will discard the packet with MNA label at the top of stack, the framework draft can also provide some text on how to avoid the legacy devices from discarding packets with MNA. For example: MNA nodes should avoid sending packets with MNA label on the top to legacy nodes, or MNA nodes should avoid sending packets with MNA on LSPs which include any legacy node.

And in addition to the behavior of discarding packets, the backward compatibility section could also describe the coexistence of MNA with existing MPLS mechanisms, such as entropy label.


The text is hight level, but I think is correct as it stands.

[Jie] I agree the current text is correct, what I suggest is to have more text on the backward compatibility with legacy nodes and existing MPLS mechanisms. This framework can provide general text on backward compatibility (similar to what I suggested above), and the solution draft can give more details.


There are some remaining comments on other sections, for readability they will be provided in separate mails.


I am not sure I have seen these yet. Please could you send them (or a pointer to them) again.

[Jie] I haven’t send them out yet. Will do it soon.

Best regards,
Jie

Best regards

Stewart



Best regards,
Jie
_______________________________________________
mpls mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/mpls