Re: [RTG-DIR] Rtgdir review: draft-ietf-pce-wson-rwa-ext-08

[Ravi Singh <[e-mail]>]

Hi Young
Thanks for making the changes.
Looks good.
Regards
Ravi

From: Leeyoung [mailto:[e-mail]]
Sent: Tuesday, October 30, 2018 3:26 PM
To: Ravi Singh <[e-mail]>; [e-mail]
Subject: RE: Rtgdir review: draft-ietf-pce-wson-rwa-ext-08

Hi Ravi,

Thanks for correcting the IPv4 and IPv6 length. They should be 4 bytes and 16 bytes respectively. I will change to the following encoding for IPV4 and IPV6. I don’t think we need prefix field.

  0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Type = 1     |  Reserved                                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | IPv4 address (4 bytes)                                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      IPv6 prefix Sub-TLV

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Type = 2     |  Reserved                                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | IPv6 address (16 bytes)                                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | IPv6 address (continued)                                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | IPv6 address (continued)                                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | IPv6 address (continued)                                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Section 4.3.2, the space is created after RFC reference.

Please see the diff file and let me know if there is still anything missing and needs to be addressed before the publication of revision to move forward.

Thanks.
Young
From: Ravi Singh [mailto:[e-mail]]
Sent: Tuesday, October 30, 2018 4:32 PM
To: Leeyoung <[e-mail]<mailto:[e-mail]>>
Subject: RE: Rtgdir review: draft-ietf-pce-wson-rwa-ext-08

Hi Young
Thanks for your email.

I had reviewed your updates but missed responding to you.

“Section 4.3.1:
a.       IPv4 address and IPv6 address as show in the figure do not align correctly as per the lengths: kindly fix.

YL>> Thanks for the catch. Fixed. “

I think you’ve understood my comment only partly.
My remark was that the IPv4 address as shown in the diagram was taking 6 bytes. Thanks for fixing the bit offset issue.

Similar issue in the IPv6 address. It is now taking 18 bytes.

Section 4.3.2: Could use a space after [RFC7579]
“is encoded as a Label Set field as specified in Section 2.6 in

is encoded as a Label Set field as specified in [RFC7579] section


[RFC7579]with

“



Regards
Ravi






From: Leeyoung [mailto:[e-mail]]
Sent: Tuesday, October 30, 2018 11:16 AM
To: Ravi Singh <[e-mail]<mailto:[e-mail]>>
Subject: FW: Rtgdir review: draft-ietf-pce-wson-rwa-ext-08

Hi Ravi,

I sent you my reply to your routing directorate review. I’d appreciate your action on that.

Thanks.
Young

From: Leeyoung
Sent: Wednesday, October 24, 2018 11:36 PM
To: 'Ravi Singh' <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: RE: Rtgdir review: draft-ietf-pce-wson-rwa-ext-08

Hi Ravi,

Thanks for providing your good comments. Please see inline for my response. Attached is a diff file (that compares the proposed 09 version with 08). Also attached is the proposed 09 version. Please let me know if this update is fine with you.

Thanks.
Young

From: rtg-dir [mailto:[e-mail]] On Behalf Of Ravi Singh
Sent: Monday, October 22, 2018 8:47 PM
To: [e-mail]<mailto:[e-mail]>
Subject: [RTG-DIR] FW: Rtgdir review: draft-ietf-pce-wson-rwa-ext-08

Meant to copy rtg-dir as well.
Regards


From: Ravi Singh
Sent: Monday, October 22, 2018 4:45 PM
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Rtgdir review: draft-ietf-pce-wson-rwa-ext-08

Hello,

I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir<https://urldefense.proofpoint.com/v2/url?u=http-3A__trac.tools.ietf.org_area_rtg_trac_wiki_RtgDir&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=6ArkE4n20mNZQF6JxrMYwJyAGBWWjzhSIC2O3-fXPV4&m=094c0dY1cnomAx1zL07ZrDe_ohTkqzedN5EbQzZEa7c&s=dYiGsBFu53QC_TWfgufOnJJvsQP1vR-S3EMZlbaogr4&e=>

Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.

Document: draft-ietf-pce-wson-rwa-ext-08
Reviewer: Ravi Singh
Review Date: 10/22/2018
Intended Status: Standard Track

Summary:
This document is basically ready for publication, but has nits that should be considered prior to publication.

Comments/Nits:
The draft is overall easy to understand.
However, there is a need to address some nits and make minor changes for better readability.

Specific details below:
1.      Section 3: The following text could elaborate the function/properties of a 3R regenerator in a little bit more detail.
"On the other hand, translucent networks include 3R regenerators that are sparsely placed." :

YL>> Added a sentence to describe the function of 3R generator following the above sentence.

NEW: The main function of the 3R regenerators is to convert one optical wavelength to another.

2.      Figure 1:  "SwCap": this could use some more info in the text somewhere.

YL> I would delete “SwCap” from Figure 1. In the paragraph, X actually refers to SwCap and we have explained it as “where X refers to the switching capability of I1 and I2. For example, X can be PSC, TDM, etc.” So SwCap and X are redundant.

3.      Section 4:
a.       " the PCEP extensions that are going to be specified in this document based on
   this architecture." ->
" the PCEP extensions that are going to be specified in this document are based on
   this architecture."

YL>> Agree. Changed.

4.      Section 4.1:

     *    text says that the WA object must be after the Endpoints object and does not say anything about ordering w.r.t. any following objects. It would be desirable to make an explicit statement either saying that ordering w.r.t. the other following objects is irrelevant, since the text is implying that that is the case.

YL>> Thanks for this clarification. You’re right and the text is added:

NEW: Orderings with respect to the other following objects are irrelevant.

b.      The term "explicit label control (ELC)" seems to have been coined in this draft and does not exist in RFC4003: while it logically follows from RFC4003, defining a new term in this doc should refer to lingo used in RFC4003 to enable better readability.

YL>> Thanks for pointing this out. Actually, the right reference for ELC is RFC3471 (Section 6). Changed the reference RFC4003 to RFC3471.

2.      Section 4.3:
a.       "Note that the Action field can be set to 0 when unnumbered link identifier is used." : not clear. Please clarify and this sentences belongs in a paragraph of its own to avoid entanglement with "action bits" description.

YL>> Thanks for catching this. Actually, I would delete this sentence. Action Field has nothing to do with unnumbered link identifier or numbered link identifier. Link identifier field has “type” that indicates IPv4/IPV6/unnumbered ID.

b.      "See Section 4.2.1. for the encoding of the Link Identifiers Field." : 4.2.1 -> 4.3.1
YL>> Yes. Will change.

c.       "See Section 4.2.1. for Link Identifier encoding and Section 4.2.2. for the Wavelength Restriction Field encoding, respectively." -> 4.3.1 and 4.3.2

YL>> Yes, will change.

5.      Section 4.3.1:
a.       IPv4 address and IPv6 address as show in the figure do not align correctly as per the lengths: kindly fix.

YL>> Thanks for the catch. Fixed.

b.      4.3.2: "section 2.6," hyperlink links to this draft rather than to RFC7579 as intended. Same for other sections referred in this section.

YL>> Correct.

OLD: …as specified in [RFC7579] section 2.6, as shown below, with…
NEW: …as specified in Section 2.6 in [RFC7579] as shown below with…
6.      Section 5:
a.       "Reply for wavelength allocation as discussed" -> "Reply for wavelength allocation request as discussed'
b.      4.2.1/4.2.2 -> 4.3.1/4.3.2

YL>> Thanks for the catch. Corrected.

7.      Section 8.2/8.5/8.6: is this IANA request really necessary since an existing subTLV format is being re-used?
YL>> Yes, they are still necessary. Although TLVs defined in 8.2/8.5/8.6 are re-use of GMPLS/WSON TLVs, these are PCEP TLVs as defined in this document.

Regards
Ravi