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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Fatai,

 

I think you nicely answered your own questions :-)

 

I would suggest adding a small section including all of the statements you made in your email. (Well, no need to refer to Berlin and the CCAMP chairs :-)

 

Cheers,

Adrian

 

From: Fatai Zhang [mailto:zhangfatai@xxxxxxxxxx]
Sent: 21 August 2013 08:40
To: adrian@xxxxxxxxxxxx; ietf@xxxxxxxx
Cc: ccamp@xxxxxxxx
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

 

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@xxxxxxxx [mailto:ccamp-bounces@xxxxxxxx] On Behalf Of Adrian Farrel
Sent: Wednesday, August 21, 2013 2:51 AM
To: ietf@xxxxxxxx
Cc: ccamp@xxxxxxxx
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@xxxxxxxx

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


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]