Re: [Last-Call] Opsdir last call review of draft-ietf-ccamp-gmpls-otn-b100g-applicability-11

[Radhakrishna Valiveti <[e-mail]>]

Hi Adrian:

  I have added the Appendix as per you suggestion and upload v13 of our
draft. Please take a look and let me know if you are OK with it.

 

Regards,

radha

 

From: Belotti, Sergio (Nokia - IT/Vimercate) <[e-mail]> 
Sent: Monday, October 3, 2022 12:34 AM
To: Radhakrishna Valiveti <[e-mail]>; 'Joe Clarke (jclarke)'
<[e-mail]>; [e-mail]; [e-mail]
Cc: [e-mail];
[e-mail];
[e-mail]
Subject: RE: Opsdir last call review of
draft-ietf-ccamp-gmpls-otn-b100g-applicability-11

 

Thanks Radha to take the action,

I also agree on the Adrian's suggestion.

 

Thanks

Sergio (as co-author)

 

From: Radhakrishna Valiveti <[e-mail]
<mailto:[e-mail]> > 
Sent: Saturday, October 1, 2022 11:23 PM
To: 'Joe Clarke (jclarke)' <[e-mail] <mailto:[e-mail]> >;
[e-mail] <mailto:[e-mail]> ; [e-mail]
<mailto:[e-mail]> 
Cc: [e-mail] <mailto:[e-mail]> ;
[e-mail]
<mailto:[e-mail]> ;
[e-mail] <mailto:[e-mail]> 
Subject: Re: Opsdir last call review of
draft-ietf-ccamp-gmpls-otn-b100g-applicability-11

 

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 <[e-mail] <mailto:[e-mail]> >
Sent: Saturday, October 1, 2022 2:05 AM
To: Radhakrishna Valiveti <[e-mail]
<mailto:[e-mail]> >; 'Joe Clarke (jclarke)' <[e-mail]
<mailto:[e-mail]> >; [e-mail] <mailto:[e-mail]>
<[e-mail] <mailto:[e-mail]> >
Cc: [e-mail] <mailto:[e-mail]>  <[e-mail]
<mailto:[e-mail]> >;
[e-mail]
<mailto:[e-mail]>
<[e-mail]
<mailto:[e-mail]> >;
[e-mail] <mailto:[e-mail]>  <[e-mail]
<mailto:[e-mail]> >
Subject: RE: Opsdir last call review of
draft-ietf-ccamp-gmpls-otn-b100g-applicability-11 

 

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 <[e-mail]
<mailto:[e-mail]> > 
Sent: 29 September 2022 23:29
To: Joe Clarke (jclarke) <[e-mail] <mailto:[e-mail]> >;
[e-mail] <mailto:[e-mail]> 
Cc: [e-mail] <mailto:[e-mail]> ;
[e-mail]
<mailto:[e-mail]> ;
[e-mail] <mailto:[e-mail]> 
Subject: RE: Opsdir last call review of
draft-ietf-ccamp-gmpls-otn-b100g-applicability-11

 

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) <[e-mail] <mailto:[e-mail]> > 
Sent: Thursday, September 29, 2022 10:47 AM
To: Radhakrishna Valiveti <[e-mail]
<mailto:[e-mail]> >; [e-mail]
<mailto:[e-mail]> 
Cc: [e-mail] <mailto:[e-mail]> ;
[e-mail]
<mailto:[e-mail]> ;
[e-mail] <mailto:[e-mail]> 
Subject: Re: Opsdir last call review of
draft-ietf-ccamp-gmpls-otn-b100g-applicability-11

 

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" <[e-mail]
<mailto:[e-mail]> > 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 <[e-mail] <mailto:[e-mail]>
>

Sent: Wednesday, September 28, 2022 9:29 AM

To: [e-mail] <mailto:[e-mail]> 

Cc: [e-mail] <mailto:[e-mail]> ; 

[e-mail]
<mailto:[e-mail]> ; 

[e-mail] <mailto:[e-mail]> 

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.