Subject: [CCAMP] Fw: New Version Notification for draft-ietf-ccamp-lmp-behavior-negotiation-03

From: Dan Li <[email-masked]>
Date: Thu, 07 Apr 2011 17:08:19 +0800

Hi All,

We have updated this draft according to the comments raised during IETF 80th meeting, just very minor changes:
1) Replaced "Reserved" with "MUST_BE_ZERO" to avoid any confusion;
2) Added the text to describe the current status of the RFCs updates for LMP security issue.

Thanks Richard and Sasha for the valuable comments!

BTW, as we have raised the question in the meeting, do we need the "B" bit? If there is no objection, then we will remove "B" bit from this draft in next revision.

Thanks,

Authors of LMP-Behavior draft

----- Original Message ----- 
From: "IETF I-D Submission Tool" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, April 07, 2011 4:45 PM
Subject: New Version Notification for draft-ietf-ccamp-lmp-behavior-negotiation-03

> 
> A new version of I-D, draft-ietf-ccamp-lmp-behavior-negotiation-03.txt has been successfully submitted by Dan Li and posted to the IETF repository.
> 
> Filename: draft-ietf-ccamp-lmp-behavior-negotiation
> Revision: 03
> Title: Behavior Negotiation in The Link Management Protocol
> Creation_date: 2011-04-07
> WG ID: ccamp
> Number_of_pages: 9
> 
> Abstract:
> The Link Management Protocol (LMP) is used to coordinate the 
> properties, use, and faults of data links in Generalized 
> Multiprotocol Label Switching (GMPLS) networks. Various proposals 
> have been advanced to provide extensions to the base LMP 
> specification. This document defines an extension to negotiate 
> capabilities and support for those extensions, and provides a 
> generic procedure for LMP implementations that do not recognize or 
> do not support any one of these extensions.
>                                                                                  
> 
> 
> The IETF Secretariat.
> 
>

---

From: Lou Berger <[email-masked]>
Date: Thu, 07 Apr 2011 09:03:09 -0400

Authors,

I have a few comments on the latest rev:

- General comment: Multiple CONFIG objects
Multiple CONFIG objects are mentioned in just one place in the document.
 It seems to me that multiple CONFIG objects are a notable change to
4204 and a significant part of this draft.  I suggest inducing multiple
CONFIG objects at the end of section 1, add updated BNF (perhaps as a
sub-section of 2), describe the procedures/rules related to when
multiple CONFIG objects are generated and how they are to be processed.
 Note, I think you'll also have multiple CONFIG objects in ConfigNack
messages.

- Section 2:
What happens when a ConfigNack message is received with an identical
CONFIG object as was sent in the Config message?  This is what should
happen when the new C-type is unknown by the recipient per RFC 4204:

   If a node receives a Config message and recognizes the CONFIG object,
   but does not recognize the C-Type, a ConfigNack message including the
   unknown CONFIG object MUST be sent.

I think this case needs to be covered.

- Section 2, "and stop trying to perform LMP communications with its
neighbor.":

Why not just say "SHOULD follow [RFC4204] defined behavior."

- Section 2, suggest clarifying "rejected" means:
OLD:
  present on a Config message, the message SHOULD be rejected
NEW
  present in a received Config message, the message MUST be rejected
  via a ConfigNack message.  The ConfigNack message MUST contain all
  unacceptable CONFIG objects.

Clearly the processing associated with the receipt of such a ConfigNack
message must also be covered.

- Section 3:
I think you're missing one case in your list in Section 3.  One
additional response may be no response at all, i.e.,:
- The message may be treated as a malformed message and may be
  discarded without any response from the recipient.

- Section 3, final paragraph:
As this paragraph relates to future documents, the text really belongs
in those documents so I suggest dropping this paragraph.

- Section 4:
I suggest dropping the following as it doesn't really add anything to
what is already in 4204:
   The operation of the procedures described in this document does not
   of itself constitute a security risk since they do not cause any
   change in network state. It would be possible, if the messages were
   intercepted or spoofed to cause bogus alerts in the management plane,
   or to cause LMP peers to consider that they could or could not
   operate protocol extensions, and so the use of the LMP security
   measures are RECOMMENDED.

(You might want to check with Richard to see if he wants to contribute
any additional or alternate text to this section.)

- C-type 3 is not yet assigned.  Suggest changing "C-Type = 3" to
"C-Type = (To be assigned by IANA)" in section 2 and "3" to "3
(suggested)" in Section 5.1.

- minor nits:

- in a number of places you're missing the "message" following a message
type, e.g., "ConfigNack" rather than "ConfigNack message".

- It's not common / consistent with 4204 to use the <xxx> notation
outside of BNF.  Suggest changing "<CONFIG> object" to "CONFIG object"

- I agree with you on dropping the B.

Lou (as WG participant)

---

From: Dan Li <[email-masked]>
Date: Fri, 08 Apr 2011 14:36:16 +0800

Hi Lou,

Thanks for your comments, I agree with you on most points, and an updated version of this draft will be published as a result. 

Please see below. If you have any suggestions on the text, please let me know.

Thanks,

Dan

----- Original Message ----- 
From: "Lou Berger" <[email-masked]>
To: "Dan Li" <[email-masked]>; "Daniele Ceccarelli" <[email-masked]>
Cc: <[email-masked]>; "Richard Graveman" <[email-masked]>
Sent: Thursday, April 07, 2011 9:03 PM
Subject: Re: Fw: New Version Notification for draft-ietf-ccamp-lmp-behavior-negotiation-03

> Note, I think you'll also have multiple CONFIG objects in ConfigNack
[Dan] Multiple CONFIG objects is not mentioned in RFC 4204, but it's important
in this draft. So several paragraphs are added in section 1 and 2, and some words are moved from section 3.
At the end of section 1:
Note that [RFC4204] does not describe how multiple CONFIG objects with different C-Types should be processed. It’s possible that a Config message with newly defined CONFIG object in this document also includes a HelloConfig or LMP_WDM_CONFIG object. This document also describes how a legacy LMP node will respond when multiple CONFIG objects are received on a Config message.

A new sub-section 2.2 is added in section 2:
2.2. Multiple CONFIG objects
It’s possible that a Config message with BEHAVIOR_CONFIG object also includes a HelloConfig object, or LMP_WDM_CONFIG object, or both objects. So multiple CONFIG objects (each with a different Class Type) MAY be present on a Config message in which case all of the objects SHOULD be processed:

<Config Message> ::=   <Common Header> <LOCAL_CCID> <MESSAGE_ID> <LOCAL_NODE_ID> <CONFIG> [<CONFIG> …]

Consequently, multiple CONFIG objects MAY also be present on a ConfigNack message.

How will a legacy node respond when receiving the multiple CONFIG objects is described in Section 3 (Backward Compatibility). 

However, if more than one CONFIG object with the same Class Type is present in a received Config message, the message MUST be rejected via a ConfigNack message. The ConfigNack message MUST contain all unacceptable CONFIG objects.

> I think this case needs to be covered.
[Dan] Good, will be covered in section 2.1.
Upon receiving a CONFIG object with the unknown C-Type, a ConfigNack message MUST be sent with an identical CONFIG object as was sent in the Config message per [RFC4204]. An LSR receiving such a ConfigNack message SHOULD follow [RFC4204] defined behavior.

> Why not just say "SHOULD follow [RFC4204] defined behavior."
[Dan] Agree. The corresponding text will be changed.

> message must also be covered.
[Dan] Agree.  The corresponding text will be changed.

>  discarded without any response from the recipient.
[Dan] Added.

> in those documents so I suggest dropping this paragraph.
[Dan] Ok, dropped.

> any additional or alternate text to this section.)
[Dan] Yes, it could simply say go to 4204 for the LMP security consideration. But I also would like to get the comments from Richard for this part.

> (suggested)" in Section 5.1.
[Dan] Agree!

> outside of BNF.  Suggest changing "<CONFIG> object" to "CONFIG object"
[Dan] Agree!
 
> - I agree with you on dropping the B.
[Dan] Yes, I would like to remove "B" bit from this draft.

---

From: Lou Berger <[email-masked]>
Date: Fri, 08 Apr 2011 08:10:05 -0400

Dan,
	See below for responses in-line.

On 4/8/2011 2:36 AM, Dan Li wrote:
> Hi Lou,
>
> Thanks for your comments, I agree with you on most points, and an
> updated version of this draft will be published as a result.
>
> ----- Original Message ----- From: "Lou Berger" <[email-masked]> To:
> "Dan Li" <[email-masked]>; "Daniele Ceccarelli"
> <[email-masked]> Cc: <[email-masked]>; "Richard
> Graveman" <[email-masked]> Sent: Thursday, April 07, 2011 9:03
> PM Subject: Re: Fw: New Version Notification for
> draft-ietf-ccamp-lmp-behavior-negotiation-03
>
>
>> Authors,
>>
>> - General comment: Multiple CONFIG objects Multiple CONFIG objects
>> are mentioned in just one place in the document.  It seems to me that
>> multiple CONFIG objects are a notable change to 4204 and a
>> significant part of this draft.  I suggest inducing multiple CONFIG
>> objects at the end of section 1, add updated BNF (perhaps as a
>> multiple CONFIG objects are generated and how they are to be
>> processed.  Note, I think you'll also have multiple CONFIG objects in
>> ConfigNack messages.
>>
> [Dan] Multiple CONFIG objects is not mentioned in RFC 4204, but it's
> important in this draft. So several paragraphs are added in section 1
> and 2, and some words are moved from section 3.

> At the end of section 1:
> Note that [RFC4204] does not describe how multiple CONFIG objects
> with different C-Types should be processed. It’s possible that a
> Config message with newly defined CONFIG object in this document also
> includes a HelloConfig or LMP_WDM_CONFIG object.

I think you need a more general discussion of multiple CONFIG objects.
Perhaps with some words as to the motivation and purpose of multiple
CONFIG objects in this section. Also, it's generally more useful to
state things in the positive rather than the negative, i.e., why or what
to do vs why not or what not to do.

> This document also
> describes how a legacy LMP node will respond when multiple CONFIG
> objects are received on a Config message.
>
> It’s possible that a Config message with BEHAVIOR_CONFIG
> object also includes a HelloConfig object, or LMP_WDM_CONFIG object,
> or both objects. So multiple CONFIG objects (each with a different
> Class Type) MAY be present on a Config message in which case all of
> the objects SHOULD be processed:
>
> How will a legacy node respond when receiving the multiple CONFIG
> objects is described in Section 3 (Backward Compatibility).
>
> However, if more than one CONFIG object with the same Class Type is
> present in a received Config message, the message MUST be rejected via
> a ConfigNack message. The ConfigNack message MUST contain all

I think this needs a bit more polishing, and should be covered under a
section along the line of "Modified Message Formats".  Note the
ConfigNack is also impacted by the introduction of multiple CONFIG
objects.  Also formatting and processing rules need to be clearly
articulated.  (You can use existing RFCs as a template.)

>
>> - Section 2: What happens when a ConfigNack message is received with
>> an identical CONFIG object as was sent in the Config message?  This
>> is what should happen when the new C-type is unknown by the recipient
>> per RFC 4204:
>>
>>   If a node receives a Config message and recognizes the CONFIG
>>   object, but does not recognize the C-Type, a ConfigNack message
>>   including the unknown CONFIG object MUST be sent.
>>
> Upon receiving a CONFIG
> object with the unknown C-Type, a ConfigNack message MUST be sent with
> an identical CONFIG object as was sent in the Config message per
> [RFC4204]. An LSR receiving such a ConfigNack message SHOULD follow
> [RFC4204] defined behavior.
>

If it's already in 4204, normative language isn't needed in this
document.  Also this processing needs to be reconciled with Section 3.

If you and Daniele are not sure how to proceed, send me the draft source
privately, and I'll try to help out.

Lou (Again, as an individual WG participant.)

>> - Section 2, suggest clarifying "rejected" means: OLD: present on a
>> Config message, the message SHOULD be rejected NEW present in a
>> received Config message, the message MUST be rejected via a
>> ConfigNack message.  The ConfigNack message MUST contain all
>> Clearly the processing associated with the receipt of such a
>> ConfigNack message must also be covered.
>>
>> - Section 3: I think you're missing one case in your list in Section
>> 3.  One additional response may be no response at all, i.e.,: - The
>> message may be treated as a malformed message and may be discarded
>> without any response from the recipient.
>>
> [Dan] Added.
>
>> - Section 3, final paragraph: As this paragraph relates to future
>> documents, the text really belongs in those documents so I suggest
>> dropping this paragraph.
>>
> [Dan] Ok, dropped.
>
>> - Section 4: I suggest dropping the following as it doesn't really
>> add anything to what is already in 4204: The operation of the
>> procedures described in this document does not of itself constitute a
>> security risk since they do not cause any change in network state. It
>> would be possible, if the messages were intercepted or spoofed to
>> cause bogus alerts in the management plane, or to cause LMP peers to
>> consider that they could or could not operate protocol extensions,
>> and so the use of the LMP security measures are RECOMMENDED.
>>
>> (You might want to check with Richard to see if he wants to
>> contribute any additional or alternate text to this section.)
>>
> [Dan] Yes, it could simply say go to 4204 for the LMP security
> consideration. But I also would like to get the comments from Richard
> for this part.
>
>> (suggested)" in Section 5.1.  > [Dan] Agree!
>
>>
>> - minor nits:
>>
>> - in a number of places you're missing the "message" following a
>> message type, e.g., "ConfigNack" rather than "ConfigNack message".
>>
>>> We have updated this draft according to the comments raised during
>>> IETF 80th meeting, just very minor changes: 1) Replaced "Reserved"
>>> with "MUST_BE_ZERO" to avoid any confusion; 2) Added the text to
>>> describe the current status of the RFCs updates for LMP security
>>> issue.
>>>
>>> BTW, as we have raised the question in the meeting, do we need the
>>> "B" bit? If there is no objection, then we will remove "B" bit from
>>> this draft in next revision.
>>>
>>> Thanks,
>>>
>>> ----- Original Message ----- From: "IETF I-D Submission Tool"
>>> <[email-masked]> To: <[email-masked]> Cc:
>>> <[email-masked]> Sent: Thursday, April 07, 2011
>>> 4:45 PM Subject: New Version Notification for
>>> draft-ietf-ccamp-lmp-behavior-negotiation-03
>>>
>>>
>>>>
>>>> A new version of I-D,
>>>> draft-ietf-ccamp-lmp-behavior-negotiation-03.txt has been
>>>> successfully submitted by Dan Li and posted to the IETF repository.
>>>>
>>>> Filename: draft-ietf-ccamp-lmp-behavior-negotiation Revision: 03
>>>> Creation_date: 2011-04-07 WG ID: ccamp Number_of_pages: 9
>>>>
>>>> Abstract: The Link Management Protocol (LMP) is used to coordinate
>>>> the properties, use, and faults of data links in Generalized

---

From: Julien Meuric <[email-masked]>
Date: Wed, 13 Apr 2011 12:01:26 +0200

Hi Dan.

Thanks for the update. Just 2 comments for me.

In section 3, the case of silently ignored BEHAVIOUR_CONFIG object (and 
the malformed message suggested by Lou) is not explicitly mentioned in 
the following text. If it is deferred to RFC 4204, a simple sentence 
would be helpful.

About, the B bit, I believe the "core procedures" from RFC 4204 
("control channel management" and "link property correlation") should 
not allow negotiation, so removing the B bit is fine. All the same, RFC 
4204 is not a single feature: would not it make sense to consider the 
"additional procedures", i.e. "link connectivity verification" and 
"fault management", in BEHAVIOUR_CONFIG? (e.g. V and F bits)

Regards,

Julien

Le 07/04/2011 11:08, Dan Li a écrit :
> From: "IETF I-D Submission Tool"<[email-masked]>
> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp
>

---

From: Dan Li <[email-masked]>
Date: Thu, 14 Apr 2011 09:09:54 +0800

Hi Julien,

Thanks for the comments!

1) Yes, we may need some text to describe how to process in the case of silently ignored BEHAVIOR_CONFIG object in the Config message.
2) You raised a good question. Actually in the previous version of this draft we had discussed if we need some separate bits to indicate the optional behaviors defined in 4204, but finally we think we don't need it. Because the optional behaviors negotiation procedure has been defined in 4204 already. In 4204, support for these two procedures is indicated by setting the "Link Verification Supportted" flag and "Fault Management Supportted" flag in the TE_LINK object of the LinkSummary message.

Thank you!

Dan