Re: [mpls] draft-ietf-mpls-mna-hdr ready to start the WGLC process

[Tony Li <[e-mail]>]

Side nit: The acronym MSD is already taken by “Maximum SID Depth”, which has slightly different semantics.

We already have another appropriate term defined, Entropy Readable Label Depth (ERLD) which actually has the semantics that we’re after, tho of course, we are not concerned just with Entropy.

I would like to propose that we define Readable Label Depth (RLD) to be a synonym for ERLD, retroactively, and use that term hereafter.

Tony


> On Aug 4, 2023, at 2:26 PM, Joel Halpern <[e-mail]> wrote:
> 
> The working group has so far been clear that maximum visible stack depth (MSD) matters.  If the WG changes that view, then various things are possible.  As long as we take that view, having multiple occurrences of ISD is necessary.  
> 
> Yours,
> 
> Joel
> 
> On 8/4/2023 5:17 PM, Haoyu Song wrote:
>> Hi Greg,
>> Thanks for the explanation, although I think my point is perfectly technical and specific.
>> We are designing a protocol for dataplane. Therefore I think the simplicity and correctness considerations are critical. The procedure described by Joel does bind to an implementation and deployment scenario with the implication of multiple NAS copies in the stack. If we assume to support only a single NAS, the procedure could be quite different, which also needs to be documented. If we reject such an idea, we need specific technical reasons.   
>>  
>> Best,
>> Haoyu
>>  
>> From: Greg Mirsky <[e-mail]> <mailto:[e-mail]> 
>> Sent: Friday, August 4, 2023 1:54 PM
>> To: Haoyu Song <[e-mail]> <mailto:[e-mail]>
>> Cc: Tony Li <[e-mail]> <mailto:[e-mail]>; jmh.direct <[e-mail]> <mailto:[e-mail]>; Joel M. Halpern <[e-mail]> <mailto:[e-mail]>; Stewart Bryant <[e-mail]> <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>
>> Subject: Re: [mpls] draft-ietf-mpls-mna-hdr ready to start the WGLC process
>>  
>> Of course.
>> You've said:
>> My gut feeling is that maintaining a single NAS requires fewer lines of dataplane processing code. It also keeps the header overhead minimum which can potentially avoid other troubles such as MTU limitation. So I suggest we actually do such evaluations before deciding the final scheme.
>> You, as a seasoned developer, may decide to allow only a single NAS in the stack, while other implementors may decide differently. But, in my opinion, the architecture and the solution MUST NOT preclude any of such decisions (and it doesn't, AFAICS). And consideration of the Path MTU before pushing a new NAS onto a packet is, in my opinion, a common practice (at least it should be), not specific to MNA. Hence my invitation to you, please separate implementation and deployment issues from what really impacts the MNA architecture and solution.
>> I hope that my position is clearer to you now.
>>  
>> Regards,
>> Greg
>>  
>> On Fri, Aug 4, 2023 at 1:42 PM Haoyu Song <[e-mail] <mailto:[e-mail]>> wrote:
>> Greg,
>>  
>> Please be specific which of my comment is not technical and specific?
>>  
>> Best,
>> Haoyu
>>  
>> From: Greg Mirsky <[e-mail] <mailto:[e-mail]>> 
>> Sent: Friday, August 4, 2023 1:38 PM
>> To: Haoyu Song <[e-mail] <mailto:[e-mail]>>
>> Cc: Tony Li <[e-mail] <mailto:[e-mail]>>; jmh.direct <[e-mail] <mailto:[e-mail]>>; Joel M. Halpern <[e-mail] <mailto:[e-mail]>>; Stewart Bryant <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>
>> Subject: Re: [mpls] draft-ietf-mpls-mna-hdr ready to start the WGLC process
>>  
>> Hi Haoyu,
>> I consider the questions you brought up, the number of NASes allowed in the stack and MNA impact on MTU, to be implementation-related and operational, which, in my opinion, should have no impact on the ISD MNA solution. Hence, let us be constructive and concentrate on the questions as formulated in the original email
>> Before we ask for the RTG Dir review we'd like to ask the authors if
>> there are any further changes or updates that they want to do prior to
>> starting the WGLC process?
>> Joel provided the authors with the text addressing scenario that, as I understand, we had agreed requires explicit discussion in the draft-ietf-mpls-mna-hdr.  Do you have an additional issue that must be resolved before the document is moved further in the process?  I would appreciate it if your comments were technical and specific.
>>  
>> Regards,
>> Greg
>>  
>> On Fri, Aug 4, 2023 at 11:23 AM Haoyu Song <[e-mail] <mailto:[e-mail]>> wrote:
>> I don’t quite understand the point. May need more explanations.  
>> I have a more general related question: Is only the LER allowed to push NAS or any LSR can push NAS as well?
>>  
>> Regarding to the complication, we’d better have some objective method to evaluate it. My gut feeling is that maintaining a single NAS requires fewer lines of dataplane processing code. It also keeps the header overhead minimum which can potentially avoid other troubles such as MTU limitation. So I suggest we actually do such evaluations before deciding the final scheme.
>>  
>> Best regards,
>> Haoyu
>>  
>> From: Tony Li <[e-mail] <mailto:[e-mail]>> On Behalf Of Tony Li
>> Sent: Thursday, August 3, 2023 4:18 PM
>> To: jmh.direct <[e-mail] <mailto:[e-mail]>>
>> Cc: Haoyu Song <[e-mail] <mailto:[e-mail]>>; Joel M. Halpern <[e-mail] <mailto:[e-mail]>>; Greg Mirsky <[e-mail] <mailto:[e-mail]>>; Stewart Bryant <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>
>> Subject: Re: [mpls] draft-ietf-mpls-mna-hdr ready to start the WGLC process
>>  
>>  
>> It’s more complicated and it breaks some functional aspects that we have now.
>>  
>> Suppose that the node pushing a NAS wants it to have a bounded lifetime.  By placing the NAS (and any copies) judiciously, it can limit the effect of the NAS a portion of the path.
>>  
>> If a NAS self-replicates, then this capability would be lost.
>>  
>> Tony
>>  
>>  
>> 
>> On Aug 3, 2023, at 3:54 PM, jmh.direct <[e-mail] <mailto:[e-mail]>> wrote:
>>  
>> That is an alternative solution.  It seems more complicated to me.
>> Yours,
>> Joel
>>  
>>  
>>  
>> Sent via the Samsung Galaxy S20 FE 5G, an AT&T 5G smartphone
>>  
>>  
>> -------- Original message --------
>> From: Haoyu Song <[e-mail] <mailto:[e-mail]>>
>> Date: 8/3/23 6:41 PM (GMT-05:00)
>> To: Tony Li <[e-mail] <mailto:[e-mail]>>, "Joel M. Halpern" <[e-mail] <mailto:[e-mail]>>
>> Cc: Greg Mirsky <[e-mail] <mailto:[e-mail]>>, Stewart Bryant <[e-mail] <mailto:[e-mail]>>, [e-mail] <mailto:[e-mail]>
>> Subject: RE: [mpls] draft-ietf-mpls-mna-hdr ready to start the WGLC process
>>  
>> Then we may consider to ban the possibility of having multiple NAS replications in the stack. There will be only one and if it emerges at the top, the node must be responsible to re-push it to a proper depth. This can avoid many troubles.
>>  
>> Haoyu
>>  
>> From: Tony Li <[e-mail] <mailto:[e-mail]>> On Behalf Of Tony Li
>> Sent: Thursday, August 3, 2023 3:23 PM
>> To: Joel M. Halpern <[e-mail] <mailto:[e-mail]>>
>> Cc: Haoyu Song <[e-mail] <mailto:[e-mail]>>; Greg Mirsky <[e-mail] <mailto:[e-mail]>>; Stewart Bryant <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>
>> Subject: Re: [mpls] draft-ietf-mpls-mna-hdr ready to start the WGLC process
>>  
>>  
>> It would seem that the reasonable answer is for the node pushing the NAS to understand the MSD and do the math.  This should not be hard. The rule should be simple: the NAS should fit, in its entirety, within the MSD.
>>  
>> Now, you’re going to immediately say: what if it doesn’t?  Well, as we’ve just said: there will always be limitations.  If you have a 64 byte MSD, then you probably shouldn’t be trying to use a 64 byte NAS.  There’s just not much that we can do about that.
>>  
>> Tony
>>  
>>  
>> 
>> On Aug 3, 2023, at 1:51 PM, Joel Halpern <[e-mail] <mailto:[e-mail]>> wrote:
>>  
>> A reasonable question, separate from the problem I am trying to fix.
>> 
>> Yours,
>> 
>> Joel
>> 
>> On 8/3/2023 4:48 PM, Haoyu Song wrote:
>> For the second question, I’m asking if the MNA substack must be considered as a whole or it can be partially used. Let’s say the stack contains x actions with the depth of y. If only x’ action with the depth of y’ are visible, is that okay to only execute these and ignore the others? If so, we will have a lot of consistency troubles. So the best way is to avoid this and ensure every MNA-aware node to be able to see the entire substack. Then what’s the procedure and actual limitation of the substack size (plus the forwarding labels in front of it)? Must the node behavior of the entire network be deterministic to be able to correctly use it? We’d better have clear answer to all these questions before we move forward.
>>  
>> Haoyu
>>  
>> From: Greg Mirsky <[e-mail]> <mailto:[e-mail]> 
>> Sent: Thursday, August 3, 2023 1:14 PM
>> To: Haoyu Song <[e-mail]> <mailto:[e-mail]>
>> Cc: Stewart Bryant <[e-mail]> <mailto:[e-mail]>; Tony Li <[e-mail]> <mailto:[e-mail]>; Joel Halpern <[e-mail]> <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>
>> Subject: Re: [mpls] draft-ietf-mpls-mna-hdr ready to start the WGLC process
>>  
>> Hi Haoyu,
>> I agree with Joel, that the question you are asking is likely to be addressed as part of operational procedures. I can imagine that MNA be deployed in an SDN paradigm and that would allow for better control of paths that MNA-equipped packets take, for a more predictable actions node apply to such packets.
>> For your second question, I assume that you refer to a situation when ISD MNA doesn't fit entirely into a cash memory of a particular node. Is that, in your opinion, a result of not accurate MSD advertisement or a mistake in constructing the label stack and placing ISD MNA?
>>  
>> Regards,
>> Greg
>>  
>> On Thu, Aug 3, 2023 at 12:03 PM Haoyu Song <[e-mail] <mailto:[e-mail]>> wrote:
>> I have more questions.
>> If we think of a network with mixed MNA-aware and MAN-unaware nodes, the situation becomes more complicated. The MAN-unaware node may push new labels into the stack which  inadvertently push the existing MNA substack out of reach for the MNA-aware node and effectively make them "unaware" of the existing MNA. How to deal with this?
>> 
>> Another question: it that okay if a node can only reach a part of the MNA substack (i.e., a part of the substack is out of reach)?
>> 
>> Best,
>> Haoyu
>> 
>> -----Original Message-----
>> From: mpls <[e-mail] <mailto:[e-mail]>> On Behalf Of Stewart Bryant
>> Sent: Thursday, August 3, 2023 2:03 AM
>> To: Tony Li <[e-mail] <mailto:[e-mail]>>; Joel Halpern <[e-mail] <mailto:[e-mail]>>
>> Cc: [e-mail] <mailto:[e-mail]>
>> Subject: Re: [mpls] draft-ietf-mpls-mna-hdr ready to start the WGLC process
>> 
>> I can see that if a node is going to push some labels it has to bring the MNH into view for other nodes along the subpath it is adding.
>> 
>> Is that dept a network wide parameter with a single value or a path parameter and if the path changes for any reason (perhaps in a legacy node doing FRR) what is the procedure?
>> 
>> Now eventually the stack gets popped. Is the procedure to copy the MNH in its entirety to overwrite the old MNH instance? Are there any exceptions to this?
>> 
>> Is there a risk that the popping node cannot see far enough into the stack to find the new MNH?
>> 
>> - Stewart
>> 
>> > On 1 Aug 2023, at 19:14, Tony Li <[e-mail] <mailto:[e-mail]>> wrote:
>> >
>> >
>> >
>> >> As far as I know, there is no text in the draft yet to deal with preserving access to hop-by-hop MNA when MNA-capable nodes add entries to the label stack.  And there is not yet WG agreement on the approach to be used, so I have some difficulty proposing text.
>> >
>> >
>> > I thought that we had agreement:
>> >
>> > If the node is pushing enough labels that the hbh NAS would be below the window, then the node needs to copy the NAS into the window.
>> >
>> > If the node is modifying the NAS, then it needs to make its modifications and then do the above.
>> >
>> > T
>> >
>> > _______________________________________________
>> > mpls mailing list
>> > [e-mail] <mailto:[e-mail]>
>> > https://www.ietf.org/mailman/listinfo/mpls
>> 
>> _______________________________________________
>> mpls mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/mpls
>> 
>> _______________________________________________
>> mpls mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/mpls
>>  
>>  
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls