Subject: [CCAMP] draft-ietf-ccamp-gmpls-signaling-g709v3-02 comments/questions

From: "Gruman, Fred" <[email-masked]>
Date: Wed, 11 Apr 2012 12:06:17 +0000

Hello Fatai,

Thank you very much for your work on OTNv3 signaling and the latest update.  I have a few questions/comments regarding the latest version of this document.

1) Section 7. I believe another use case for the ADAPTATION object could be to inform the tail-end node of the configuration of the head-end TSG setting for the FA-LSP. Do you agree?

2) Section 7.1. What will be the type of class for the ADAPTATION object (0bbbbbbb, 10bbbbbb, 11bbbbbb)? Depending on which range the class number falls, there may be backwards implications when signaling across RFC4328 links (e.g., the translation method presented in Sect 9 may not be able to support ADAPTATION if class range is 11bbbbbb)

3) Section 7.1. Will the ADAPTATION object be carried in the Resv message, or is it carried only in the Path message?

4) Section 7.1. If head end selects TSG=1 (either 1.25 or 2.5), does the tail end need to inform the head end which TSG it selected, or does this setting mean the head end has the transport-plane capability to automatically detect and fallback to 2.5G.

5) Section 7.1. How does the Hierarchy TLV indicate multiple LO-ODUs at the same level? Is this one hierarchy TLV per LO-ODU?  (The example shows that when multiple ODUs are contained in the Hierarchy TLV that they represent multi-stage multiplexing).

6) Section 7.1. Indicating multistage multiplexing in the Hierarchy TLV does not have a way to specify the TSG for the intermediate ODU (the ODU2 in the example in Sect 7.1). This seems to be the same issue that resulted in the ADAPTATION object, server TSG TLV for the HO-ODU.

7) Section 8.  Errors should be sent with PathErr (also see comment #8)

    Section 8

    OLD:

    If any node along the ODUflex connection doesn't support hitless resizing, a Notify message ...

    NEW:

    If any node along the ODUflex connection doesn't support hitless resizing, a PathErr message ...

8) Section 8. I suggest that the procedure for handling a node that does not support resizing is to PathErr (with Path State Removed).  The source node may decide to resignal with the non-resize signal type (ST=22). It doesn't seem to be correct behavior to setup a ST=21 connection using ST=22 resources.

9) Section 8.  Assuming that PathTear should be used to teardown the original states for both bandwidth increasing and decreasing.

    Section 8

    OLD:

    Similarly, after completion of bandwidth decreasing, a ResvErr message SHOULD be sent ...

    NEW:

    Similarly, after completion of bandwidth decreasing, a PathTear message SHOULD be sent ...

10) Section 9. This section permits the translation function, where a node that supports the new signaling can translate the OTNv3 signaling to RFC4328.  Is it also permissible to allow the translation from RFC4328 to OTNv3 (i.e., is it "once we are RFC4328, we remain RFC4328 to egress" or can we translate back to OTNv3 signaling?)

Thanks,

Fred

Fred Gruman
Operations Planning
+1-972-479-2477

---

From: Fatai Zhang <[email-masked]>
Date: Fri, 13 Apr 2012 08:47:39 +0000

Hi Fred,

Thanks for your comments.

Please see in-line below.

Thanks

Fatai

From: [email-masked] [mailto:[email-masked]] On Behalf Of Gruman, Fred
Sent: 2012年4月11日 20:06
To: [email-masked]
Subject: [CCAMP] draft-ietf-ccamp-gmpls-signaling-g709v3-02 comments/questions

Hello Fatai,

[Fatai] It is not necessary to do that. There are two cases to make things clear. Case 1: If the head-end need one specific TSG and the tail-end can support that TSG, the FA-LSP will be created successfully, otherwise, it will refuse the setup. Case 2: If the head-end does not care about the TSG(either 1.25 or 2.5), the data plane can handle the fall-back procedures.

[Fatai] The safe way is to make the type as 0bbbbbb, otherwise, an FA-LSP may be created, but it is not the expected one.

[Fatai] Only carried in the Path message. It can be carried in the Resv message, but it seems that it is redundant.  See Point 1) above.

[Fatai] It means the head end has data-plane fallback capability. See Point 1) above.

[Fatai] Yes. This is one hierarchy TLV per Lo-ODU.

[Fatai] Good capture. We discussed this issue when we update this version. We think there is no need to specify the TSG for the intermediate ODU. For example, when an ODU 3 FA-LSP is to be created, it only needs to specify which TSG needs to be exported towards his own clients, not the TSG per layer.

    Section 8

    OLD:

    If any node along the ODUflex connection doesn't support hitless resizing, a Notify message …

    NEW:

    If any node along the ODUflex connection doesn't support hitless resizing, a PathErr message …

[Fatai] Good capture. Need to be updated.

    Section 8

    OLD:

    NEW:

[Fatai] Agree. Need to be updated.

[Fatai] Good capture. Your point makes sense. Need to be updated as what you suggested.

new----new (translation point)----old------old, in this case, for the Path direction, it needs to do the translation from OTNv3 to RFC4328, but from the RESV direction, it is better to have the translation from RFC4328 to OTNv3 to make PSB/RSB consistent.

Thanks,

Fred

Fred Gruman
Operations Planning
+1-972-479-2477