Subject: [Teas] more comments on this draft //FW: Update on <draft-ietf-teas-network-assigned-upstream-label>

From: "Zhangxian (Xian)" <[email-masked]>
Date: Tue, 23 Jun 2015 09:26:28 +0000

Hi, All,

I have reviewed this draft and believe this draft needs further revision. Please find my comments below:

Regards,
Xian

Major comments:
1: Which RFC does this draft aim to update? RFC3471/RFC3473 or RFC4208? The only use case present is a scenario applying RSVP-TE on UNI. I struggle to see this draft can be applied in a general case where within a single domain the first node is not able to assign an appropriate upstream label/symmetrical label. Thus, for now, I think it should update RFC4208. If you do not agree with, it would be good to explain why.

Abstract & Introduction:
2: There are two requirements described in this draft which current RSVP-TE cannot support: 1) network-assigned/downstream-node-assigned upstream label; 2) using same wavelength on both directions of a bidirectional LSP. I think both issues are valid but the 2nd point did not get mentioned at all in both sections, even briefly. Is there a reason not to do so?

Section 2:
3: what is an alien wavelength? Is it a single/fixed wavelength known previously by the DWDM network provider or something tunable? I guess it is the latter this draft is talking about. I did a search on ITU recommendations, and I do not think it is properly defined. Thus, it would be good at least have a terminology section explaining this term to avoid ambiguity.

Section 3:
4: Per RFC3473, a node must program its data plane before forwarding a UPSTREAM_LABEL. So I am not sure why it is described quite the opposite in this draft. Am I missing anything?
5: at the end of this section, it says: assuming the use of symmetrical labels. But I do not see how this impacts the use case described here. As I said earlier, I think it is a requirement which is not met by existing RSVP-TE protocol, so I would prefer to mention it at the very beginning as a reason for writing this draft.

Section 5:
6: I think “is” or “MUST” is better, instead of “can” in the following sentence:
The presence of this value in the UPSTREAM LABEL object of a PATH message can also be interpreted as a request to mandate "symmetric labels" for the LSP at the given hop.
A side question: what does at the given hop meant in this sentence? Not sure I get it. Maybe you meant at any given hop?
7: “If the downstream-node cannot pick the symmetric label, it MUST issue a PATH-ERR message with a "Routing Problem/Unacceptable Label Value" indication.”
-When a downstream node cannot pick a label, I think it MUST initiate something like “no label available”, instead of “upacceptable Label value”. Thoughts?
8: Figure 3 is not referred at all in the main body. What is it used for? I am not sure exactly what does the paragraph above Figure 3 wants to tell. Does it mean the upstream node can choose to signal other values, so that it disables downstream-node’s ability to choose a symmetric label later? If the behavior is mandatory, I suggest to use MUST.

Section 5.2:
9: in case (a): what error will it generate? Unacceptable label?
10: Since this draft is in TEAS, so I expect this draft is believed to have wider utility other than LSC LSP. Is it? If yes, will case (b) cause any issue? For example, take the label as a valid upstream label and in the meantime fail to choose a symmetric label as intended by such value?

Section 6
11: Why does Router B get the appropriate wavelength via UPSTREAM_LABEL/LABEL_SET? Another problem is since UPSTREAM_LABEL is assigned with a actual wavelength value, so how does Router B (as well as other intermediate nodes which did not receive UPSTREAM_LABEL=0xFF..FF) knows it should use a symmetric label for the A-B direction LSP? The solution I can think of is when the node in the optical network decides the route and label, it should use ERO to carry the information (so as able to convey both upstream and downstream label). Thoughts?
12: clarify the MUST to SHOULD change. This has been raised before in the mailing list.

Minor:
:s/This mechanism enables a given node to offload the task of assigning the upstream-label for a given LSP onto the network./This mechanism enables a upstream node to offload the task of assigning the upstream-label for a given LSP to a downstream node.
:s/The following setup sequence is an attempt to address the above use-case using existing protocol mechanisms:/The following setup sequence is an attempt to address the above use-case using the crankback approach supported by RSVP-TE protocol:
:S/The above approach does sort of work/ The above approach does work
:s/it picks some random label and signals it …/it picks a random label and signals it …

Editorial:
s/….Bidirectional LSP…/…bidirectional LSP
s/the use-case discussed in this draft…/the use case discussed in this draft…
s/ After the LSP is set up…./After a LSP is set up…

From: Teas [mailto:[email-masked]] On Behalf Of Zhangxian (Xian)
Sent: 2015年3月20日 15:44
To: Vishnu Pavan Beeram
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Teas] Update on <draft-ietf-teas-network-assigned-upstream-label>

Hi, Pavan,

Thank you for the update.

Could you explain a bit the motivation of this update? Since now it is SHOULD not MUST; so with a good reason, the ingress/egress can choose to ignore such label modify received from the other end, by not tuning the new wavelength, will it be any issue? Any additional texts needed to handle it?

  I will send more detailed review comments probably after this IETF.

Regards,
Xian

From: Teas [mailto:[email-masked]] On Behalf Of Vishnu Pavan Beeram
Sent: 2015年3月20日 3:35
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [Teas] Update on <draft-ietf-teas-network-assigned-upstream-label>

WG, Hi!
Latest Update:
A new version was published recently. The following are the diffs -

     *   Section 6.2 - Change MUST->SHOULD

        *   “In such a scenario, if the ingress client receives a changed label via the LABEL object in a RESV modify, it SHOULD retune the laser at the ingress to the new wavelength. Similarly if the egress client receives a changed label via UPSTREAM_LABEL/LABEL_SET in a PATH modify, it SHOULD retune the laser at the egress to the new wavelength.”

     *   Added Zafar Ali to the list of contributors
Open Issues:
None.
Next Steps:
Request further review from the WG (authors believe that the draft is ready to progress to the next stage)

Regards,
-Pavan
(On behalf of the authors/contributors)