Subject: [CCAMP] Question on NMC in draft-zhang-ccamp-gmpls-evolving-g709

From: Ben Wright <[email-masked]>
Date: Tue, 27 Sep 2011 09:10:49 +0000

Hi all,

I had a detailed query about the NMC usage in draft-zhang-ccamp-gmpls-evolving-g709.   This inherits the usage of the NMC from RFC4328, which would indicate the number of tributary slots requested for this signal type.   I think the following are both true.

-          This information is strictly speaking redundant because the label now describes how the signal type will be multiplexed onto a given link.

-          With the introduction of the 1.25Gbps size, the tributary slot size can vary in a network.   Therefore, to preserve the usage of the NMC from RFC4328 nodes which supported both TS sizes would need to translate the SENDER_TSPEC object at each hop to encode the right NMC value given the TS to be used on a given hop.   This isn't typical behaviour for a SENDER_TSPEC.

Given the above, it seems to me easier to revert back to the original definition, which deprecated this field from RFC4328.   To preserve back-compatibility with RFC4328, I understand you've already agreed that nodes supporting draft-zhang-ccamp-gmpls-evolving-g709 should signal OTN LSPs with switching capability 101 (OTN-TDM capable).  This makes it safe to deprecate the NMC field in this new usage.

What do you think?

Cheers,

Ben

---

From: Zhangfatai <[email-masked]>
Date: Wed, 28 Sep 2011 02:04:58 +0000

Hi Ben,

I personally quite agree with you that the easy way is to deprecate NMC.

We will add some text to address that (at least an editors' note will be added to capture that).

Fatai

Thanks

________________________________
发件人: [email-masked] [[email-masked]] 代表 Ben Wright [[email-masked]]
发送时间: 2011年9月27日 17:10
到: [email-masked]
主题: [CCAMP] Question on NMC in draft-zhang-ccamp-gmpls-evolving-g709

Hi all,

-          With the introduction of the 1.25Gbps size, the tributary slot size can vary in a network.   Therefore, to preserve the usage of the NMC from RFC4328 nodes which supported both TS sizes would need to translate the SENDER_TSPEC object at each hop to encode the right NMC value given the TS to be used on a given hop.   This isn’t typical behaviour for a SENDER_TSPEC.

Given the above, it seems to me easier to revert back to the original definition, which deprecated this field from RFC4328.   To preserve back-compatibility with RFC4328, I understand you’ve already agreed that nodes supporting draft-zhang-ccamp-gmpls-evolving-g709 should signal OTN LSPs with switching capability 101 (OTN-TDM capable).  This makes it safe to deprecate the NMC field in this new usage.

What do you think?

Cheers,

Ben