Re: [mpls] MPLS Working Group Last Call on draft-ietf-mpls-mna-requirements

[Stewart Bryant <[e-mail]>]

> On 28 Sep 2023, at 14:34, Joel Halpern <[e-mail]> wrote:
> 
> Loa, your phrasing leaves some room for ambiguity, so I want to ask some clarifying questions.  I think you are saying two things, and I am unsure as to whether you intend a third.
> 
> First, you seem to be saying that John, in his typical fashion, overstated the case.  I can't disagree with you.
> 
> Second, you seem to be saying that the chairs have asked that the working group continue to discuss the value / need for the claimed use cases for PSD.  That appears to be a valid restatement of what the chairs have said and done.
> 
> My concern is a potential third implication of what you wrote. You seem to be implying that the WG has agreed that there is a requirement for PSD?  I do not believe that happened, and I have not yet seen a demonstration of said need.  That is the basis for my request that the text about PSD be removed from the requirements draft.
> 
> I do not that Ice's recent message raises even larger concerns about the draft.  Possibly the right response is to shelve the requirements draft?
> 
> Yours,
> 
> Joel
> 

Ice may correct me, but I think the key takeaway from his email is the last sentence:

"To me ISD makes sense if the amount of data encoded isn’t more than 11 bits, otherwise I would prefer the MPLS WG to exploring solutions based on PSD.”

I approximately  agree here and am worried about how much clutter we may be adding to the MPLS label stack. I do not agree with an 11 bit limit, but I do think that we should rigorously limit the amount of in-stack information we add.

We tend to talk about two cases (HBH, E2E) but there is a third that I am sure will appear as engineers develop MPLS applications and that is Segment to Segment (S2S). I am not sure how to address this latter case, but it seems clear to me that the best place to put E2E is as PSD. Indeed within the wider MPLS protocol suite that is where we currently carry such data. It is what we do in PWs using the ACH, and what MPLS adopted particularly for the MPLS-TP applications. Indeed in MPLS-TP a whole routing protocol can be carried there, and that is certainly not going to be carried as ISD.

Carrying E2E ancillary data as PSD has many advantages, but in particular it carries the information at the point in the stack where it fits naturally - it is a good match between position in the packet and the scope of the information. 

Whether PSD is in scope for MNA depends on the scope of MNA. If MNA was purely HBH then it would be a more nuanced discussion, but MNA is currently both HBH and E2E and we have an existence proof of the suitability of, and I would argue the superiority of, PSD as the place to carry E2E ancillary data. 

Now to the specifics of the requirements draft under discussion this tries to take a permissive liberal approach saying that where the MNA information is carried is up to the application designer, and then sets out the considerations that apply. Given that PSD is the currently the de-facto place to put this information as documented in may RFCs, and ISD is the emergent technology this seems to me to be a balanced approach.

Joel says:

> You seem to be implying that the WG has agreed that there is a requirement for PSD?  I do not believe that happened, and I have not yet seen a demonstration of said need. 

The fact is the opposite. There is an existence proof of the need for PSD, because we have RFCs that use it. So the question becomes quite a narrow one: should we permit the use of MNA technology as an indicator of the presence of PSD? I would argue that to be a reasonable approach that the MPLS applications design engineers should have the ability to specify.

Now perhaps that is not the question that Joel intended to ask. Let us assume that the root of the question is whether HBH should be permitted to us PSD. That is a more difficult question because there is no doubt that this significantly stresses the forwarder, particularly in the presence of large SR label stacks. I think Joel is arguing for this to be taken off the table at this stage, whereas I take to position that the MNA architecture should permit the application design engineers to decide on a case by case basis depending on the needs of their customer.

Best regards

Stewart