Re: [mpls] Some following questions about ISD

[Tony Li <[e-mail]>]

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.


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


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


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


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

Regards,
Tony