Re: [mpls] Some following questions about ISD

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

Hi Tony,


From: Tony Li [mailto:[e-mail]] On Behalf Of Tony Li
Sent: Wednesday, September 13, 2023 12:04 PM
To: Dongjie (Jimmy) <[e-mail]>
Cc: [e-mail]; MPLS Working Group <[e-mail]>; [e-mail]
Subject: Re: [mpls] Some following questions about ISD



Hi Jimmy,


[Jie#2] IMO, since RLD is introduced for imposing NAS to MPLS packets safely, how RLD would be used with MNA also needs to be described. This is similar to the description about the usage of ERLD for entropy label insertion in RFC 8662, 9088 and 9089.


I’m sorry, I don’t understand your comment. How RLD would be used with MNA is described in section 2.3.1 of the framework draft: https://datatracker.ietf.org/doc/html/draft-ietf-mpls-mna-fwk-04#name-readable-label-depth

That is both necessary and sufficient as far as I can tell. Again, we cannot mandate implementation choices, we can only place requirements on the results of those choices. That’s what we’ve done.

[Jie#3] Thanks for the pointer. Yes there is description about RLD usage with MNA in the latest framework draft, I overlooked it in my previous review.

One small suggestion: For readability the definition of RLD could be moved to the beginning of this section, followed by the description of RLD checking on the NAS imposing nodes.


For other cases in which a new path cannot be selected, it is OK to call it a failure, while the node’s behavior when such a failure is encountered also needs to be specified. As part of the label-stack/network action push specification, a default behavior for this failure would be needed, and customized behavior may also be specified for specific applications.


Failure handling is also implementation specific.

[Jie#3] I’m afraid I cannot agree with you on this point. Failure handling has been specified in many IETF documents, especially when a failure can impact packet delivery. I will leave this for others to comment.


I’m sorry, I was incorrect. It’s in the ISD draft: https://datatracker.ietf.org/doc/html/draft-ietf-mpls-mna-hdr-03#name-nas-placement-in-the-label-

[Jie#2] Thanks for the pointer. I see the current text describes the processing of NAS with each specific scope. While the processing of a packet with multiple NASes with different scopes is not specified yet. This is related to another comment in my previous mail:


Please read again. That does describe how a packet with multiple NASes is processed.

[Jie#3] I’ve reread it, and still find it missing necessary information about the encoding order and processing of multiple NASes in a packet.  The current text in this section says ”For a NAS with HBH scope, every node will process the top copy of the NAS.” It is not clear enough, whether it means “a node should always process the top copy of the NAS if it is with HBH scope”, or “a node should always parse the label stack until it finds a copy of HBH NAS”?

For example, if a packet carries both a HBH NAS and a Select NAS for node A, and both need to be processed by A, which one should be the top copy NAS? As you said the select NAS should be encoded right after the forwarding label to reach A, then the HBH NAS should follow the Select NAS for A.  In this case, nodes other than A will first reach the Select NAS for A, then do they still need to read further to see whether there is any HBH NAS? But if there is RLD limitations on some nodes, the HBH NAS may need to be encoded between the forwarding label to A and its Select NAS, which breaks the rule of “Select NAS directly follows its forwarding label”.

That’s why I suggest to have further description about the encoding order of NASes with different scopes, and their processing on different nodes.

    [Jie] This may depend on the order of the HBH NAS and the Select/I2E NAS, for example, can HBH NAS precede an select/I2E NAS due to RLD consideration?


The framework defines the order of evaluation of actions. Yes, NASes of different scopes may be placed in different orders. This is precisely so that there is semantic flexibility.

[Jie#3] That means the top copy of HBH NAS may not always be the top NAS, and nodes need to be prepared to process NASes in different orders.

I don’t recall the order of NASes with different scopes has been specified in the framework document or somewhere else. But clearly both the order and the parsing procedure need to be documented if it is not there yet.


It’s there, please read it.

We have not decided that PSD is needed. Until we do, we do not necessarily need an indication for it.

[Jie#2] Since PSD is described in the MNA framework draft, it is assumed that it is already part of the framework (and remember the WG poll on it last year).


That’s an inaccurate assumption.


[Jie#3] I don’t remember the WG has made any further decision on this, except the WG poll on ISD vs PSD in June 2022:

Poll 1:
=======

Asked if it is the consensus on the working group(s) that:

The Framework document must be solution independent and say:

   a packet may carry Ancillary Data using one or both of the
   following methods:

    (1) in-stack, and

    (2) post-stack."

Consensus call (Poll 1):
------------------------

- The poll shows that there is a strong consensus support for this
   position.

- There is also a fairly strong opinion that solutions that specify
   the use of ISD, should take special care to provide the motivation
   for the use of ISD.

The authors of the framework document should make any necessary
updates to the framework document. Other MNA documents should be
updated accordingly.

What haven’t got converged yet is for specific applications (e.g. IOAM) whether PSD is needed or not. Then why not making the PSD indicator part of the general MNA header encoding in the beginning? The discussion on per-application choice of ISD vs PSD can continue.

If we are not going to need PSD, then we shouldn’t waste our time and our bits.

We’ve now discussed this to death. Please move on.

[Jie#3] IMO we need to follow the WG’s consensus and decision made on this (whether PSD is part of the framework), rather than based on individual’s preference. Or do you think we need another WG poll?

Best regards,
Jie

Regards,
Tony