Subject: Re: [CCAMP] WG Last Call: WSON documents - rwa-info, general-constraint-encode, rwa-wson-encode, gmpls-general-constraints-ospf-te, wson-signal-compatibility-ospf, wson-signaling

From: "Margaria, Cyril (Coriant - DE/Munich)" <[email-masked]>
Date: Tue, 22 Oct 2013 10:53:47 +0000

http://tools.ietf.org/html/draft-ietf-ccamp-rwa-info-18

I've reviewed this document and believe it is ready for publication, with comments:
I think the document is good to go, I have two editorial comments:
 - I find the document history good to have, but maybe in an annex.
 - My stable mail address is [email-masked] , affiliation is Coriant.

http://tools.ietf.org/html/draft-ietf-ccamp-general-constraint-encode-11

I've reviewed this document and believe it is ready for publication, with comment:
I have the same comment as the rwa info regarding the history to be maybe moved to the annex 

http://tools.ietf.org/html/draft-ietf-ccamp-rwa-wson-encode-21

I've reviewed this document and believe it is ready for publication, with comments:
- editorial: The document history could be moved to the annex 
- section 3.3 : rbState (16 bit) : nits : is it signed or unsigned integer ? I would tend to understand unsigned.
- My stable mail address is [email-masked] , affiliation is Coriant, not NSN

http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-general-constraints-ospf-te-05

I've reviewed this document and believe it is ready for publication

http://tools.ietf.org/html/draft-ietf-ccamp-wson-signal-compatibility-ospf-12

I've reviewed this document and believe it is ready for publication, with comments:
- editorial: The document history could be moved to the annex 
- Section 2 : the section reference to WSON-Encode are wrong (this affect section 2, section 2.1
- Section 3 : it would be useful to reference the exact section of [Gen-encode] for the Available Label Sub-TLV and  Shared Backup Label Sub-TLV. 

http://tools.ietf.org/html/draft-ietf-ccamp-wson-signaling-06 
I've reviewed this document and I have the following comments:
 - section 4.3 : "If more than two objects are encountered,
   two MUST be processed and the rest SHOULD be ignored."
	This is ambiguous : the section refers to the RB information sub tlv, does this refers to the WSON_signaling object or RBInformation?
 - section 4.3 : http://trac.tools.ietf.org/wg/ccamp/trac/ticket/52, please remove this paragraph, the restriction is strong and would not allow a node to choose one RB per local policy /sharing.. etc
 - section 7 : the section assume a LSP_REQUIRED_ATTRIBUTE, but this is a targeted information as described in section 4.2, or should it be distinguished between targeted attribute (to be assigned in the ERO HOP_attribut, this depends on the space choosen by the draft-ietf-ccamp-lsp-attribute-ro) and e2e attribute (WA)?.

Best Regards/ Mit freundlichen Grüßen
Cyril Margaria

[email-masked]
http://www.coriant.com

Coriant R&D GmbH
Geschäftsleitung / Board of Directors: Robert Richter, Rolf Nauerz 
Sitz der Gesellschaft: München / Registered office: Munich
Registergericht: München / Commercial registry: Munich, HRB 197143

---

From: Leeyoung <[email-masked]>
Date: Mon, 28 Oct 2013 20:44:05 +0000

Hi Cyril

Thanks for this comprehensive review of all WSON documents. 
I have resolved all the issues you raised except the signaling draft (Hopefully, Giovanni can answer your comment for the signaling draft).

Please see inline for my comment. Thanks.

Regards,
Young

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Margaria, Cyril (Coriant - DE/Munich)
Sent: Tuesday, October 22, 2013 5:54 AM
To: CCAMP ([email-masked])
Subject: Re: [CCAMP] WG Last Call: WSON documents - rwa-info, general-constraint-encode, rwa-wson-encode, gmpls-general-constraints-ospf-te, wson-signal-compatibility-ospf, wson-signaling

**YOUNG>> History will normally be removed by RFC Editors as it is close to the final version. Will correct your affiliation. 

**YOUNG>> Same comment for history as above.

**YOUNG>> Added RB State (16 bit unsigned integer). Will correct your affiliation. 

YOUNG>> Agreed. Corrected all. Section 2.3 and 2.4 are referenced in Section 3. 

[email-masked]
http://www.coriant.com

Coriant R&D GmbH

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

---

From: "Giovanni Martinelli (giomarti)" <[email-masked]>
Date: Tue, 29 Oct 2013 10:28:57 +0000

Hi Cyril,

pls see inline 

> 	This is ambiguous : the section refers to the RB information sub tlv, does this refers to the WSON_signaling object or RBInformation?

GM> it refer ti RB information does this change is acceptable to you
old:
" If more than two objects are encountered,
two MUST be processed and the rest SHOULD be ignored."

new:
"If more than two RB Information objects are encountered,
two MUST be processed and the rest SHOULD be ignored."

> - section 4.3 : http://trac.tools.ietf.org/wg/ccamp/trac/ticket/52, please remove this paragraph, the restriction is strong and would not allow a node to choose one RB per local policy /sharing.. e…

GM>  Current change you propose is to remove this sentence

"RB Set Field MAY contain more than one RB Indetifier. Only the first
one MUST be processed, the others SHOULD be ignored.
"

I'm ok I'd like to know if anyone else have concern in remving. Simply we become liberal in in using the RB Identifiers in signaling. 

> - section 7 : the section assume a LSP_REQUIRED_ATTRIBUTE, but this is a targeted information as described in section 4.2, or should it be distinguished between targeted attribute (to be assigned i…

GM> Sounds to me this draft follow the draft-ietf-ccamp-lsp-attribute-ro as it was one of the use case. 

Cheers
G