Subject: Re: [CCAMP] comment on draft-ietf-ccamp-gmpls-g709-framework-06

From: Fatai Zhang <[email-masked]>
Date: Wed, 9 May 2012 02:05:17 +0000

Hi Lou,

We provided some text to refine the whole section 5.5.

Please review this text and comments or suggestions are welcome.

Note that we will also bring this to the list for discussion later.

Authors

________________________________________
发件人: [email-masked] [[email-masked]] 代表 Fatai Zhang [[email-masked]]
发送时间: 2012年3月29日 17:01
到: Lou Berger; CCAMP
Cc: [email-masked]
主题: [CCAMP] 答复:  comment on draft-ietf-ccamp-gmpls-g709-framework-06

Hi Lou,

Yes, correct for all questions. I think we have the common understanding.

Let's refine the text, :-)

Thanks

Fatai

________________________________________
发件人: [email-masked] [[email-masked]] 代表 Lou Berger [[email-masked]]
发送时间: 2012年3月28日 23:53
到: CCAMP
Cc: [email-masked]
主题: [CCAMP] comment on draft-ietf-ccamp-gmpls-g709-framework-06

Hi,
        I have some comments on the following text:

  5.5. Implications for Control Plane Backward Compatibility

   Assume [RFC4328] has been deployed to control the OTN networks
   supporting [G709-V1], control plane backward compatibility needs to
   be taken into consideration. Scenarios for backward compatibility are
   described as follows:

   o  Legacy OTN devices supporting [G709-V1] may run control plane
      protocol defined in [RFC4328];

   o  Legacy OTN devices supporting [G709-V1] may also support new OTN
      control plane characterized in this document after control plane
      updating;

   o  New OTN devices supporting [G709-V3] always support new OTN
      control plane characterized in this document;

   o  New OTN devices SHOULD support falling back to [RFC4328] for
      interworking scenarios.

   Based on these scenarios, control plane backward compatibility SHOULD
   be taken into account when interworking between the new control plane
   characterized in this document and the legacy control plane defined
   in [RFC4328].

   A new Switching Capability type is required for control of [G709-V3]
   in the routing and signaling to enable the backward procedure.

I'm having a hard time parsing the intent of this section. I'd like to
ask some questions at the higher level first, rather than focusing on
specific text.  (Which we can move on to once we have a common
understanding.)

I suspect your intent is to say (stated informally):

1) There may be networks that are composed of nodes that only support
the legacy OTN approach.  Such nodes and networks are out of scope of
this and the other OTNv3 documents.  -- Correct?

2) There may be networks that are composed of nodes that all support the
new OTNv3 control plane documents.  Such nodes and networks have no
control plane backwards compatibility issue.  -- Correct?

3) That there may be networks composed of a mixture of nodes, some  that
support the legacy RFCs and others that support the new OTNv3 control
plane documents. For these, the new routing and signaling documents must
support this case.   -- Correct?

4) Based on the routing and signaling drafts, I think this document
should also describe the approach taken by those documents at a (high)
sufficient level for them to deliver a consistent solutions.

From the ospf document see that support for both old and new routing
approaches MUST be supported. Signaling can use that information to
determine when to start signaling using old/new mode.  Also there are
cases there that information won't be available, so signaling still has
to handle the case where a new message arrives at a legacy node.  -- Is
this correct?

Again, once we have common understanding, we can worry about wordsmithing.

Thanks,
Lou
_______________________________________________
CCAMP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ccamp
_______________________________________________
CCAMP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ccamp

---

From: Lou Berger <[email-masked]>
Date: Wed, 09 May 2012 08:35:01 -0400

Fatai,
	I think this text addresses most of my comments.  Please see responses
inline below.

> Note that we will also bring this to the list for discussion later.

Looks like you already have, which seems best to me.

> Authors

Looks like the new text doesn't discuss this case, which seems appropriate.

> control plane backwards compatibility issue.  -- Correct?

Again, looks like the new text is silent on this point.  Not sure if
this is the best approach or not, but it at least implies that such
cases don't have compatibility issues.

> support this case.   -- Correct?

Looks like this is covered.
> to handle the case where a new message arrives at a legacy node.  -- Is

Looks like you cover these cases now too. Although you are using RFC2119
conformance language, which isn't appropriate for an informational
document.  I suggest rephrasing to describe the high-level approach
being taken and leave specific mechanisms/requirements to the protocol
documents (i.e., provide only narrative text).

Thanks,
Lou