[CCAMP] Answer the comments on draft-zhang-ccamp-gmpls-h-lsp-mln-02.txt

Fatai Zhang <zhangfatai@huawei.com> Mon, 13 December 2010 07:01 UTC

Date: Mon, 13 Dec 2010 15:01:49 +0800
From: Fatai Zhang <zhangfatai@huawei.com>
To: ccamp@ietf.org, "Sadler, Jonathan B." <Jonathan.Sadler@tellabs.com>, Dimitri.Papadimitriou@alcatel-lucent.com
Message-id: <9AE0E9E3472F47E8B6DA49CA1D502063@china.huawei.com>
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_xw0fNKkyjrpjBcjChQ1mbQ)"
Subject: [CCAMP] Answer the comments on draft-zhang-ccamp-gmpls-h-lsp-mln-02.txt
Precedence: list

Hi Jonathan, Dimitri and all,

We got some comments at the Beijing meeting. 

One is from Jonathan. Jonathan said he likes the generalized nature of this draft, but he also pointed out that since different adaptations may be supported on the boundary nodes, the GPID used in the server layer signaling will be key to  keep the lower layer connection from being refused. Therefore, the question from him is: Is there a way for the SERVER_LAYER_INFO object can convey this information?

After investigation, we think that GPID is very important to tell how the client signals can be adapted into the server layer. We will update the draft to be capble of conveying GPID information.

Another comment from Dimitri, who pointed out that this capability already exists in [RFC 6001]. Actually, we had noticed the mechanism defined in [RFC 6001]. In [RFC 6001], it can only specify the switching capability implicitly by excluding some SCs, but it can not specify switching granularity to be used at the server layer. Some text is already stated in Section 3.1 and 4.2 of draft-zhang-ccamp-gmpls-h-lsp-mln-02.txt.

Welcome any more comments.

Fatai

Thanks

[CCAMP] Answer the comments on draft-zhang-ccamp-… Fatai Zhang