[mpls] Re: Looking at draft-sxg-mpls-mna-deterministic-latency

[[e-mail]]

Hi Adrian,
Thank you very much for review and sharing your comments and questions, very helpful.
Please find my replies inline tagged with [Xueyan].


Best regards,
Xueyan

Original


From: AdrianFarrel <[e-mail]>
To: [e-mail] <[e-mail]>;
Cc: [e-mail] <[e-mail]>;
Date: 2024年07月04日 23:16
Subject: [mpls] Looking at draft-sxg-mpls-mna-deterministic-latency

Thanks for this draft. I see it has bounced around a bit, but I  
believe you have now settled on the right positioning:
- It's an MPLS WG topic
- It is targeted for MNA
 
It is good to have a proposed solution for one of the MNA use cases.


I found the term "deterministic latency" hard to resolve without reading
the whole document. "Bounded latency" is explained in section 1 with a
brief definition and a pointer to RFC 9320. That's great, but can you  
also add a definition of deterministic latency near the top of the
Introduction? And perhaps a more detailed definition in section 3.2.


[Xueyan]: Sorry for bring your confusion. Actually the term "deterministic latency" is from [I-D.ietf-detnet-scaling-requirements], while "Bounded latency" is from RFC9320. These two terms seem like but when used together may bring confusion. I think we can delete the term "Bounded latency".
About the definition for "deterministic latency", it's added in section 2.2. I copied here for your convenience:
"Deterministic Latency (DL): The bound of network latency and delay variation between two DetNet endpoints."
Do you think it's OK?


You might add [I-D.ietf-mpls-mna-fwk] and  
[I-D.ietf-mpls-mna-requirements] to section 2.2

[Xueyan]: OK, will add these references to terminology section.


In Figure 1 (like Figure 1 of RFC 8964) it is really important that you
mark "top of stack" and "bottom of stack" because the picture is  
non-intuitively "upside down". It is correct that you follow the format
of 8964, but you need to highlight this. In particular, Figure 2 reverts
to the "normal" way of displaying LSE ordering.

[Xueyan]: OK, will update Figure 1 to reflect the stack position.


In section 2, I see that you are assuming that the DLNA will always be
carried by a Type C LSE. I think we have to consider the case where the
DLNA is the only MNA in the packet. In this case, are you assuming that
a Type B LSE will be included with opcode=2? You just need to add a few
words for this.

[Xueyan]: Yes, when traditional mechanisms such as DSCP and Traffic Class used for queue processing, Ancillary data may be not needed.
The information will be added in next version.


draft-ietf-mpl-mna-hdr has been a moving target! You need to do a little
work in Figure 2 to catch up with the latest LSE formats.

[Xueyan]: Thanks. Will update it to reflect the new changes.


Can you give any advice for the setting of the U-bit and IHS for the  
DNSL case?

[Xueyan]: OK, will add suggested value to these fields.


Quite a bit more work will be needed to explain what ancillary data is
carried and how it is encoded. Part of this will be explaining why you  
leave some of the bits in the Type C LSE as reserved.

[Xueyan]: Agree :-). The co-authors will discuss further and supplement this aspect.


For section 6, please consider that the MPLS header is not normally
protected. What would happen if an attacker changed the values in the
ancillary data? How can this be protected (

[Xueyan]: OK. The security defined in [I-D.ietf-mpls-mna-header] and RFC9055 (for DetNet security) applies for this draft. Other possible security considerations will be added in the future.


_______________________________________________
mpls mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]