Re: [CCAMP] Last Call: <draft-ietf-ccamp-gmpls-signaling-g709v3-11.txt> (Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for the evolving G.709 Optical Transport Networks Control) to Proposed Standard

Hi Adrian,

Thanks very much.

I can update the nits and editorial issues quickly, but I would like to discuss more with you for the following points to make things clear before I update the draft.

=========================================================================================

Please consider and note what updates to GMPLS management tools are needed.

[Fatai]This has been mentioned in [Framework] document. Did you mean that we need add one sentence in some place of this document to refer to [Framework] document to mention management tools?

Are there any changes to the Alarms that might arise? We have a document for that.

[Fatai] No. RFC4783 is still applicable.

Are there any changes to the way OAM is controlled? We have a document for that.

[Fatai] No, it could be done through NMS or [draft-ietf-ccamp-rsvp-te-sdh-otn-oam-ext].

Should the new G-PIDs show in the TC MIB managed by IANA at

https://www.iana.org/assignments/ianagmplstc-mib/ianagmplstc-mib.xhtml

This should happen automgically when the feeding registries are updated

but it is probably best to add a specific request for IANA.

[Fatai] Will do that.

Will other MIB work be needed (in the future) to make it possible to

read new information (labels, tspecs) from network devices?

[Fatai] I am not sure. I asked the similar question (not on this draft) during Berlin meeting. The chairs answered that it could be driven by drafts.

Best Regards

Fatai

-----Original Message-----
From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Adrian Farrel
Sent: Wednesday, August 21, 2013 2:51 AM
To: ietf@ietf.org
Cc: ccamp@ietf.org
Subject: Re: [CCAMP] Last Call: <draft-ietf-ccamp-gmpls-signaling-g709v3-11.txt> (Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for the evolving G.709 Optical Transport Networks Control) to Proposed Standard

As sponsoring AD I have the following last call comments I hope you will take on

board.

Thanks,

Adrian

Please fix the two lines that are too long (see idnits)

---

Please expand "OTN" on first use in the main text.

Please expand "TS" on its first use.

---

6.2

   The ingress node of an LSP MAY include Label ERO (Explicit Route

   Object) to indicate the label in each hops along the path.

Missing "subobject".

---

6.2.1

   When an upstream node receives a Resv message containing an

   GENERALIZED_LABEL object

s/an/a/

---

Please consider and note what updates to GMPLS management tools are

needed.

Are there any changes to the Alarms that might arise? We have a document

for that.

Are there any changes to the way OAM is controlled? We have a document

for that.

Should the new G-PIDs show in the TC MIB managed by IANA at

https://www.iana.org/assignments/ianagmplstc-mib/ianagmplstc-mib.xhtml

This should happen automgically when the feeding registries are updated

but it is probably best to add a specific request for IANA.

Will other MIB work be needed (in the future) to make it possible to

read new information (labels, tspecs) from network devices?

---

Please fix so that you have three sections:

Authors' Addresses (only those people on the front page)

Contributors (other people who made significant text contributions to

the document)

Acknowledgements (other people who helped with the work)

---

[OTN-OSPF] should be a normative reference for its use to define the

value of the switching type used in signaling.

_______________________________________________

CCAMP mailing list

CCAMP@ietf.org

https://www.ietf.org/mailman/listinfo/ccamp