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

[Vishnu Pavan Beeram <[e-mail]>]

Xian, Hi!

Thanks for the review. Responses inline (prefixed VPB).

- Pavan (as a co-author)

On Tue, Jun 23, 2015 at 5:26 AM, Zhangxian (Xian) <[e-mail]>
wrote:

>  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.
>

[VPB] This draft updates the procedures associated with UPSTREAM_LABEL
(which is defined in RFC3473) -- it doesn't aim to update anything else. As
you noted, the use-case discussed in Section 2 of this draft discusses an
"Overlay Model" scenario. So a reference in Section 2 to RFC4208 would be
apt. This can be added in the next revision.


>
>
> 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?
>

[VPB] As noted in Section 4 of this document, the use-case discussed in
this document pertains to Lambda Switch Capable LSPs and it is an
undocumented fact that in practice, LSC LSPs always have symmetric labels
at each hop along the path of the LSP. When the draft was first introduced
(in late 2013), the introduction section did talk about explicitly
requesting "symmetric" labels. But it was removed based on the feedback
received from the WG.


>
> 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.
>

[VPB] Agree that adding a reference to the term "alien wavelength" is much
needed. This will be addressed in the next revision.


>
>
> 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?
>

[VPB] Section 3 discusses an alternative approach (how an implementation
may attempt to address the use-case with existing protocol mechanisms) and
points out the concerns with that approach. And yes, as you noted (also as
noted in the draft) one of the concerns with this approach is that a valid
UPSTREAM-LABEL can get signaled without programming the dataplane.


>  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.
>

[VPB] See response to (3)

>
>
> 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.
>

[VPB] ok


>  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?
>

[VPB] "given" meaning "particular or specific"


>  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?
>

[VPB] The intent was to use an existing error-code. I think we went back
and forth between "Unacceptable Label Value" and "Label Allocation Failure"
(before settling in on the former) -- I think the consensus was to follow
what is stated (procedures to follow when the Upstream Label Value is
unacceptable) in Section 3.1 of RFC3473.


>  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.
>

[VPB] Figure 3 is meant to illustrate the processing discussed in Section
5.1. As stated in in this section, if the upstream-node desires to make the
downstream-node aware of its limitations with respect to label selection,
it has the option to specify a list of valid labels via the LABEL_SET
object. This behavior is NOT mandatory.


>
> Section 5.2:
>
> 9: in case (a): what error will it generate? Unacceptable label?
>

[VPB] Yes. It will follow the processing rules in Section 3.1 of RFC3473.


>  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?
>

[VPB] Yes, the use-case being addressed in this document is specific to LSC
LSPs. And no, we didn't come across any issues with (b). Please let us know
if you can think of any.


>
>
> Section 6
>
> 11: Why does Router B get the appropriate wavelength via
> UPSTREAM_LABEL/LABEL_SET?
>

[VPB] Why not?


> 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?
>

[VPB] Again, as stated in the document, the use-case being addressed is
LSC-LSP specific. And as stated in this document, LSC LSPs always have
symmetric labels at each hop along the path of the LSP.


>  12: clarify the MUST to SHOULD change. This has been raised before in
> the mailing list.
>

[VPB] Yes. 'll do


>
>
> 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:[e-mail] <[e-mail]>] *On
> Behalf Of *Zhangxian (Xian)
> *Sent:* 2015年3月20日 15:44
> *To:* Vishnu Pavan Beeram
> *Cc:* [e-mail];
> [e-mail]
> *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:[e-mail] <[e-mail]>] *On
> Behalf Of *Vishnu Pavan Beeram
> *Sent:* 2015年3月20日 3:35
> *To:* [e-mail];
> [e-mail]
> *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)
>
> _______________________________________________
> Teas mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas
>
>