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

[Greg Mirsky <[e-mail]>]

Hi Stewart,
I found several statements in your note that I wanted to comment on. I used
top-posting. Please kindly consider my notes tagged GIM>> below:

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.

GIM>> We should remember that the ACH/G-ACH mechanism is used for
management, control, and OAM flows, not for data (the latter is explicitly
prohibited). As I understand it, MNA in general, and PSD in particular,
is intended to be applied to data flows, as well as, OAM, control, and
management.


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.

GIM>> If by PSD being "de-facto place" you refer to ACH/G-ACH mechanism, I
have to disagree on the basis noted above. ACH/G-ACH is not applicable to
data flows, although we might entertain the proposal to change RFC 5586:

The G-ACh MUST NOT be used to transport user traffic.

Hence, I consider the ACH/G-ACH mechanism as a useful but limited solution
to MNA problem.

There is an existence proof of the need for PSD, because we have RFCs that
use it.

GIM>> AFAIK, all RFCs that use ACH/G-ACH mechanism use it to transport
non-data traffic (e.g., PTP messages as in RFC 8169
<https://datatracker.ietf.org/doc/rfc8169/>). I am not familiar with any
RFC where that is not the case.


Regards,
Greg

On Fri, Sep 29, 2023 at 2:35 AM Stewart Bryant <[e-mail]>
wrote:

>
>
>
> 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
>
>
>
>
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls
>