|
Thanks Radha to take the action, I also agree on the Adrian’s suggestion. Thanks Sergio (as co-author) From: Radhakrishna Valiveti <rvaliveti@xxxxxxxxxxxx> Hi Adrian: I am fine with adding the text you proposed, as an appendix in the document. I will do it later this evening, or tomorrow and upload the revised version. regards,
radha From: Adrian Farrel <adrian@xxxxxxxxxxxx> Hello, Shepherd hat on my head! Joe’s point is well made, I think. When I went to find the text that talks about the possible future extensions, I found it took a little while to search. Although both points are made in the same section (4.2), they are a little hidden, so a new section might be helpful. However, I think that that new section would not need to be in the body of the draft, and I would not recommend removing the text from Section 4.2. I’d suggest a (short) appendix called “Possible Future Work” where the total text is something like…. ===
A.
Possible Future Work As noted in Section 4.2, the GMPLS TPN field in Section 6.1 of [RFC7139] is only 12 bits where an ODUCn link could require up to 14 bits. Although the need is not urgent, future work could extend the TPN field in GMPLS
to use the Reserved bits immediately adjacent. This would need to be done in a backward compatible way. Section 4.2 further notes that the current encoding of GMPLS labels can be inefficient for larger values of n in ODUCn. Future work might examine a more compact, yet generalized label encoding to address this issue should
it be felt, after analysis of the operational aspects, that the encoding is causing problems. Introduction of a new label encoding would need to be done using a new LSP Encoding Type / G-PID pairing to ensure correct interoperability. === Cheers, Adrian From: Radhakrishna Valiveti <rvaliveti@xxxxxxxxxxxx>
Hi Joe: Regarding your suggestion of creating a new section/subsection for the potential future work, here is my view. I feel that there are only two aspects mentioned in our draft that could involve future work: a) ability to handle the full
TPN space (i.e. 14-bit TPN) supported by the G.709-2020 b) optimizing the label format to reduce the label size. I feel that a separate section would make sense only if provide one or more options for addressing these topics. In other words, just the listing
the topics in a separate section doesn’t add much to the document. We could create a separate draft when the time to address these future items comes. What do you think? Regards, radha From: Joe Clarke (jclarke) <jclarke@xxxxxxxxx>
Thanks for the figure updates. Any thoughts from the authors on splitting out the potential future work into its own section? I think it would add clarity but perhaps not enough to justify the work. Joe
On 9/29/22, 12:42, "Radhakrishna Valiveti" <rvaliveti@xxxxxxxxxxxx> wrote: Hi Joe: Thanks for your review of the B100G applicability draft. I have taken your
suggestions into account and uploaded v12 of our draft. Please let me know if
any additional edits are needed. Regards, radha -----Original Message----- From: Joe Clarke via Datatracker <noreply@xxxxxxxx> Sent: Wednesday, September 28, 2022 9:29 AM To:
ops-dir@xxxxxxxx Cc:
ccamp@xxxxxxxx; Subject: Opsdir last call review of
draft-ietf-ccamp-gmpls-otn-b100g-applicability-11 CAUTION: This email originated from outside of the organization. Do not click
links or open attachments unless you recognize the sender and know the content
is safe. Reviewer: Joe Clarke Review result: Has Nits I have been tasked to review this document on behalf of the OPS DIR. I
wouldn't say I'm an expert in this area, but overall I found the draft easy to
read, and from an operations point of view I appreciate the succinct
applicability summaries, as well as the points to future extensibility work
(though I wonder if those deserve their own section for added clarity). On the nits side, I notice you compare your Figure 3 with the figure in
Section 3 of RFC7138. However, you omit the notion of labeling the A, B, etc. with
"OTN Switch", which I think would help. I'm also not sure what "3R" means
here or in Figure 1 (but that is likely my lack of experience here). Finally,
the two parts of Figure 3 seem to be showing both one-hop and multi-hop OTUCn
links but you do not call that out as is done in RFC7138. |
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
