Re: [mpls] FW: New Version Notification for draft-jags-mpls-ps-mna-hdr-00.txt

Tony Li <[email protected]> Thu, 20 Apr 2023 12:37:51 -0700
Newsgroups gmane.ietf.pwe3,gmane.ietf.mpls
Message-ID <[email protected]>
Hi Loa,


> - will a non-MNA capable implementation have problems "processing" (aka as skipping over) the MNA label and the extra LSEs after the MNA Label? How does it know what is an extra LSE and what is a Label?


This is an ISD question, not PSD.

Non-MNA implementations should not be attempting to process MNA ISD.  Assuming that we’ve specified ISD correctly and that implementations conform, the MNA ISD should never come to the top of stack at a non-MNA node.  

If a transit node needs to find PSD, it can scan the entire label stack for the bottom of stack bit.  I can’t think of a good reason to ever do this, given that it’s a transit node and should be payload indifferent.


> - we will only include the MNA first nibble if there is an MPLS Label in the packet. right? Existing (legacy) non-MMA capable implementations will not recognize the MNA first nibble as "MNA follows, only understand that this is something unrecognised. What does legacy implementations do with unrecognized first nibbles today?


There is not much point in having an MNA first nibble unless there is also MNA PSD.  And there is not much point in MNA PSD unless there is a label stack involved. Therefore, yes, there should be a label in the label stack.

AFAIK, legacy transit nodes should not be examining PSD at all, of any flavor.  That said, I cannot speculate on the behavior of all legacy implementations.

Sending MNA PSD to a legacy terminating node is not something that we should be supporting.


> - are there cases where PSD does not immediately follow the first nibble?


MNA PSD and other forms of PSD must interoperate somehow.  We may decide that MNA PSD is not at the top of PSD.


> - shouldn't the behaviour in these two cases be documented in one of our drafts?


We have tried to do so, but we are only human.

Regards,
Tony

_______________________________________________
Pals mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pals