|
Hi Greg, Thank you for your replay and constructive suggestion. Please see inline [Bruno] From: Greg Mirsky <gregimirsky@xxxxxxxxx>
Hi Bruno, thank you for your thorough review, constructive comments, and helpful suggestions. Please find my notes below tagged by GIM>>. I attached the new working version of the draft and the diff that
highlights all the updates. Regards, Greg On Mon, Sep 2, 2024 at 4:53 AM Bruno Decraene via Datatracker <noreply@xxxxxxxx> wrote:
GIM>> Thank you for your kind words, Bruno.
GIM>> I think that "community interest" describes the attitude towards MNA work in general, while "actively discussed" is intended to reflect the situation with the use cases. [Bruno] OK.
GIM>> Indeed, over the course of the discussion, the feedback received from groups that work with the MPLS data plane indicated that theese groups have not yet reached consensus on the proposed
solutions. The authors proposed moving these cases to the appendix rather than removing them altogether for the historical value. It appears that the WG agreed and supported that update.
GIM>> I agree that some use cases, e.g., NOFRR, can be realized by using an assigned SPL. Some other use cases also can be supported by assigning a dedicated SPL. As the available number of
bSPLs is limited, it is very likely that the respective solutions will use eSPL, i.e., two LSEs. In that regard, MNA improves utilization of SPL space.
GIM>> Yes, although the use case described in Section 2.5 seems useful, I also cannot find a document on that topic that have been submitted for the discussion by SPRING WG. Do you propose
removing this section? [Bruno] I was proposing that use cases be split between:
Because probably network operator and vendors are primarily interested in uses cases strong enough to motivate the investment in a new technology. At least that’s
what I was looking for and section 2.5 did not seem like a strong reason to me so the use case could even be read as counter productive by some people (“if this is the use case for MNA, then I don’t really need MNA). But that’s just a feedback. I understand that different people may have different on each use case which make my comment difficult to address. So, up to you. No, I was not suggesting to remove a use case.
GIM>> Would the following updated text be clearer: OLD TEXT: The current state of the art requires allocating a new special-purpose label [RFC3032] or extended special-purpose label. To conserve that limited resource, an MPLS Network Action (MNA) approach was proposed to extend the MPLS architecture. MNA is expected to enable functions that may require carrying additional ancillary data within the MPLS packets, as well as a means to indicate the ancillary data is present and a specific action needs to be performed on the packet. NEW TEXT: The current state of the art requires allocating a new special-purpose label [RFC3032] or extended special-purpose label. To conserve that limited resource, an MPLS Network Action (MNA) approach was proposed to extend the MPLS architecture. MNA is expected to enable functions that may require carrying additional ancillary data within the MPLS packets, as well as a means to indicate the ancillary data is present and a specific action needs to be performed on the packet. [Bruno] I couldn’t spot any difference between your above OLD and NEW. Looking at the diff you provided (thanks, much useful), new text
seems better but it removes one technical argument/reason in favor of MNA. Personally I had in mind the following change: OLD: To conserve that limited or extended special-purpose label. An MPLS Network Action (MNA) NEW: SPL are a very limited resource while eSPL requires two extra label per Network Action which is expensive. Therefore an MPLS Network
Action (MNA)
GIM>> Thank you for the suggestion. I moved it to the Normative References list. [Bruno] OK, thanks.
GIM>> I think that "and" is appropriate in characterizing two types of MPLS Ancillary Data. But I noticed hypen missing in ISD and PSD. Fixed these. [Bruno] TBH, being non-native, I don’t really know, so totally up to you/RFC editor. FYI, while it’s a very biased search
😉, I could find example with “or”.
e.g., “Non-Standards Track RFCs may be classified as Informational or Experimental.“
https://www.ietf.org/process/informal/
GIM>> I know that some documents provide references in Abbreviation section. I find that references in the body of the document is sufficiently useful to a reader. [Bruno] OK. Anyway it’s an editorial choice so up to you.
GIM>> I agree; removed. [Bruno] Ack.
GIM>> As I understand it, the WG decided that the publication of
draft-ietf-mpls-inband-pm-encapsulation is to fix squatting of the code point and the MNA-based solution will be considered: Considering the MPLS performance measurement with the Alternate- Marking method can also be achieved by MNA encapsulation, it is agreed that this document will be made Historic once the MNA solution of performance measurement with the Alternate-Marking method is published as an RFC. [Bruno] Thanks for clarifying to me. I feel that the above clarification would be useful in the draft and would better motivate the creation
of MNA (rather than the current: “The MNA is an alternative mechanism that can be used to support AMM in the MPLS network.” which reads as creating a second solution for no extra benefit.) But up to you.
GIM>> I hope that the following update makes it clearer: NEW TEXT: The approach in [RFC8595] introduces some limitations discussed in [I-D.lm-mpls-sfc-path-verification]. However, that approach can benefit from the framework introduced with MNA in [I-D.ietf-mpls-mna-fwk]. [Bruno] ok, thanks.
GIM>> The work on MNA was first conducted by the Open DT chartered by MPLS, PALS, and DetNet WGs. Once fundamental MNA documents matured, they were adopted by the MPLS WG. After that MNA work,
as I understand it, has been conducted as part of MPLS WG agenda. [Bruno] OK, thanks for the clarification. I read your answer as a ‘No’ (this Segment Routing use case has not been discussed in the SPRING
WG.)
GIM>> That section is intended as the reminder to the authors of drafts that propose MNA-based solutions for the use cases listed in this document as well as for any applications in the future.
I agree that "new" is confusing in the sentence. I propose the following update: NEW TEXT: MNA-based solutions for the use cases described in this document and proposed in the future are expected to allow for coexistence and backward compatibility with all existing MPLS services. [Bruno] Thanks for the clarification. If that’s the intention I would not call that section a “use case”. At minimum I propose to change
the title of this section OLD: Existing MPLS Use cases NEW: Co-existence with existing MPLS extensions The above proposition tries to be aligned with the title of the next section. That being said, all the MPLS extensions defined in §3 seems
to be classified as Post Stack Data (PSD) (as per §1.1). If so, I’d rather propose NEW2: Co-existence with existing MPLS Post Stack extensions (I tried to avoid using the term PSD... Obviously please feel free to reword)
GIM>> I think that the the questions of MNA deployment are outside the scope of the document that is aimed at listing generic use cases that benefit from MNA. Deployment of MNA-based solutions
should be discussed in respective drafts that define the solution for the particular case listed in this document. [Bruno] Fair enough, I guess. But its seems that the point could at least be raised.
I still believe that MNA introduces security consideration including for existing network (in particular with Carrier’s Carrier deployment)
if MNA is activated by default on equipments. I.e. there is no MNA deployment done but MNA is exploited by unauthorized person which previously where shielded through MPLS hierarchy Cf VPN security text “unless it is known that such packets will leave the backbone before the IP header or any labels lower in the stack will be inspected,” https://datatracker.ietf.org/doc/html/rfc4364#section-13.1 with MNA the lower labels are inspected even if they will never appear at the top of stack. Regards, --Bruno
_________________ |
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
