Re: [mpls] This is not a last call! draft-ietf-mpls-mna-requirements-08.txt

[Joel Halpern <[e-mail]>]

Thank you Matthew.  I still have a number of concerns, and I hope I can 
explain them better in line, after your comments, delimited by 
<jmh></jmh>.  (I have trimmed the nits as that appears to be covered.)

Yours,

Joel

On 1/11/2024 7:26 AM, Matthew Bocci (Nokia) wrote:
>
> Hi Joel
>
> Thanks for your detailed review and comments. Please see below.
>
> Best regards
>
> Matthew
>
> On 04/01/2024, 16:41, "Joel Halpern" [e-mail] wrote:
>
> I appreciate the wording of requirement 7 in section 3.1 (General
>
> Requirements). That seems to make clear the scoping of these requirements.
>
> Major:
>
> I keep re-reading requirement 34 that indication of post-stack data must
>
> be consistent with RFC 3031 and I am left very confused as to what it
>
> means.  It doesn't say that there MUST be an indication in the stack.
>
>      It seems to allow for it being magically known?   That doesn't 
> seem like
>
> a requirement.  Please clarify or remove.
>
> MB> I agree that there should be an indication in the stack that something
>
> follows BoS, and I think we should be explicit about this, but for E2E MNA
>
> with post-stack data the end points could just agree that something 
> follows
>
> without the need for any in stack indicator (similar to PW CW).
>
> Alternatively, you could have a post-stack specific MNA alert 
> mechanism and
>
> then you look below stack for an NAI, similar to the way GAL/GACH 
> works. I am
>
> not advocating that. I am just using it as a counterpoint. But I agree 
> that
>
> in-stack may be desirable for intermediate LSRs.
>
> What about?: “  If a network action requires post-stack ancillary
>
> data, it must be implicitly or explicitly indicated in the stack using 
> a method
>
> consistent with  [RFC3031].”
>
<jmh>I admit that part of my reaction is colored by the observation that 
end-to-end post-stack data (the equivalent of what we already have with 
CW) can be handled by ISD in the label set processed by the ultimate 
node.  So I tend not to worry about that case, and read the requirements 
as being about things that need to be known by intermediate nodes.  
Given that your proposed wording does not differentiate, we seem to 
still have the problem.  implicit indication does not seem to work if 
the post-stack ancillary data is to be processed by intermediate nodes.  
YOu could split it into two requirements, one for PSD to be processed by 
intermediate nodes, and one for E2E PSD.  With the latter permitting 
implicit indication. </jmh>
>
> Requirement 43 in section 3.5 (Requirements on Ancillary Data) is either
>
> an unclear restatement that in-stack or post-stack data MUST have
>
> indications, or it is some other requirement not consistent with our
>
> ongoing work.  I recommend removing it.  This seems related to
>
> requirement 44, which I would also recommend removing.
>
> MB> This requirement was intended to apply to post-stack ancillary 
> data, where the stack could
>
> be popped (so discarding the NAI) prior to the packet reaching the 
> egress LER. It is consistent
>
> with section 3.6.1 (First Nibble considerations) of the framework. I 
> suggest rephrasing to:
>
> "A common preamble for post-stack ancillary data MUST be defined so that a
>
> node receiving the ancillary data can determine whether to
>
> process, ignore, skip over or discard it according to network or
>
> local policies.
>
<jmh>I am still left quite confused by what is being required.  If 
post-stack data is indicated by in-stack indications, and is cleaned up 
when the last in-stack indication is removed (as I believe is the common 
case) then there is no need for whatever a "common preamble" is.  If the 
intention is for a common preamble to be tied to implicit indication of 
end-to-end post-stack data, then we need more words making it clear that 
is the case being dealt with.  Also, if we want such a preamble, it 
seems likely that we need some way to avoid ambiguity between the 
preamble and other packet contents?  At which point we are getting into 
solution instead of requirements.  But without that the requirement does 
not seem to have force.</jmh>
>
> I agree that 43 is possibly not needed if the NAI gives you enough
>
> context to find the AD, whether it is post-stack or in-stack. But that 
> assumes the
>
> NAI is present at the receiving node, which it may not be in the case 
> of post-stack
>
> where the stack is popped before reaching the terminating node e.g. in PHP
>
> MB> I think 44
>
> is needed. The in-stack AD needs to be structured so that a forwarder 
> can skip over
>
> it and correctly find the bottom of stack, for example. This is 
> consistent with the framework.
>
<jmh>I suspect that our problem is "container".  If ISD always has a 
length, that includes the ancillary data, then there is no need for a 
separate container for the AD.  Does that constittute a container as you 
understand the requirement?  It doesn't seem to by my reading.  Which is 
why I found the requirement too strong.

What if the wording was "The structure of the NAI and any carried 
in-stack ancillary data must enable proper skipping of unknown operation 
indications and ancillary information"? </jmh>

> I find requirement 50 in section 3.5 (Requirements on Ancillary Data)
>
> which claims to require a means to "verify the integrity of ancillary
>
> data processed by LSR" to be confusing. Despite what we may or may not
>
> have written in RFC 3552 we do not have as far as I know means to verify
>
> the integrity of anything related to MPLS.  I can vaguely imagine an OAM
>
> mechanism implied by this requirement, but I doubt that is what is
>
> meant.  Please clarify or remove?
>
> MB> Yes, agreed but we do need to mention this issue. I would suggest 
> rephrasing to be
>
> more of a commentary and moving it to the security considerations and 
> out of the requirements part.
>
<jmh>Thanks.  That should probably work.  I would suggest adding a few 
more words as to what we are requireing / expecting, as the current 
answer from the WG seems to be "nothing".</jmh>
>
> Requirement 53 in section 3.5 (Requirements on Ancillary Data) seems to
>
> prohibit an intermediate LSR which is pushing on labels and NAI from
>
> pushing on ancillary data along with them. Such a prohibition seems to
>
> be a contradict the WG agreements. Please fix.
>
> MB> The root cause of this issue is that LER is not well defined, and . I
>
> would rather we talked about the functions rather than the nodes. I would
>
> suggest breaking this down and rephrasing splitting into something like:
>
> - In-stack ancillary data MUST only be inserted in conjunction with 
> pushing one or more labels
>
> onto the top of stack and MAY be processed at any LSR.
>
> - Post-stack ancillary data MUST only be inserted where a new bottom 
> of stack label is pushed.
>
> and MAY be processed at any LSR.
>
> - Processing MAY
>
> include rewriting the ancillary data. A solution to a use case that 
> needs to change the size of the
>
> ancillary data MUST analyze the implications on packet forwarding and 
> specify how these are addressed.
>
<jmh>Mostly, that seems to fix my problem.  I don't see why you want to 
include the middle "MUST" about adding PSD only if one is adding at the 
bottom of the stack.  That is certainly the easier case for adding PSD.  
But since I do not know what the use cases are for PSD, I don't know why 
we are adding that clause.</jmh>
>
> Minor:
>
> Is requirement 5 of section 3.1 (General Requirements) intended to prevent
>
> MNA from covering Entropy.  It seems to, as it says that MNA solutions 
> MUST
>
> NOT obsolete existing MPLS mechanisms (e.g. ELI / EL)? This also seems
>
> related to requirement 41.
>
> MB> No. It is intended to prevent MNA from obsoleting basic forwarding
>
> mechanisms in MPLS. It does not prevent MNA from offering an alternative
>
> entropy mechanism if that makes sense in an overall set of solutions.
>
<jmh>Well.... That may be the intent.  But I don't think it says that.  
Entropy label is as much an existing mechanism as push, pop, or swap.  I 
suggest you take another crack at the wording. </jmh>
>
> Would it be helpful to elaborate requirement 21 in section 3.4 
> (Requirements
>
> on Network Action Indicators) to include text that control or management
>
> mechanisms may be used to meet this requirement?
>
> MB> A precedent for this is the signaling involved in Entropy Label
>
> Capability. I am not sure we should spell out such mechanisms here as 
> this is
>
> a requirements draft rather than a solutions draft.
>
<jmh>Yes, there is precedent for being vague.  I think greater clarity 
and specificity would help the reader.  It is okay with me to say "e.g. 
control or management mechanisms" to allow for something else if that is 
your concern. </jmh>
>
> In requirement 22 (apparently related to requirement 21) what does "in the
>
> way the imposing node intends" mean?   The text seems more specific 
> than just
>
> understanding the operation to be performed.
>
> MB> It means don’t send MNA to a node that you don’t know what it will do
>
> with it or will not handle it in a way that is acceptable to you. This is
>
> because it may affect forwarding and the AD may contain metadata form the
>
> payload. Potentially, the receiving node may just drop the whole 
> packet if it
>
> doesn’t recognise at least the MNA indicator. Does the following 
> rephrasing help?:
>
> 22.  An imposing node MUST NOT insert an NAI
>
>         unless it knows that any node that processes it has indicated 
> that it can do so
>
> in the way the imposing node intends.
>
<jmh>I don't think this helps.  As far as I can tell, the expectation of 
the group is that nodes will advertise what operations they support 
(somewhere, somehow, ...)   Reasonable.  But I do not know what "in the 
way the imposing node intends" is supposed to add to such advertised 
support.  Is this supposed to say that if there are sub-opcodes we need 
to have advertisements of those?  It is supposed to say that imposers 
will magically know the details of how processing nodes will do their 
work, or ?? </jmh>
>
> Requirement 47 in section 3.5 (Requirements on Ancillary Data) seems 
> vacuous.
>
> I can not see how its presence would affect any solution proposal.
>
> MB> This necessary advisory text, and is the result of discussions in 
> the OpenDT. I
>
> propose that we change the MUST to a SHOULD as it probably doesn't 
> matter for E2E port-stack
>
> AD that is not intended for processing by intermediate LSRs.
>
<jmh>First, unless it was confirmed by the WG, conclusions of the Open 
DT are not WG conclusions.  So not particularly relevant now.  More 
importantly, I don't know what it means for post-stack data to be as 
close as possible to the bottom of stack.  Is there something else that 
is envisioned that we are trying to require comes after the PSD rather 
than before?  Either elaborate on what is being discussed or remove it 
as meaningless please.</jmh>
>
>