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

[Stewart Bryant <[e-mail]>]

Hi Jie

Here are my personal comments on your review comments.

> On 20 Sep 2023, at 12:56, Dongjie (Jimmy) <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.

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

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

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


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

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

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

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


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

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

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


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

Best regards

Stewart


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