Hi Adrian,
I would like to propose the following text for the new section and discuss with
you & WG before I submit a new version.
Further comments are appreciated.
============================================================================================
8. Operations, Administration and Maintenance (OAM) Considerations
Regarding OTN OAM configuration, it could be done through either Network
Management Systems (NMS) or GMPLS control plane as defined in [TDM-OAM].
[RFC4783] SHOULD be used for communication of alarm information in GMPLS based
OTN.
Management Information Base (MIB) may need be extended to read new information
(e.g, OTN-TDM Generalized Label, OTN-TDM SENDER_TSPEC/ FLOWSPEC) from the OTN
devices. This is out of scope of this document.
More information about the management aspects for GMPLS based OTN refer to
Section 5.7 of [OTN-FWK].
===================================================================================
Best Regards
Fatai
From: Fatai Zhang
Sent: Friday, September 06, 2013 3:33 PM
To: adrian(_at_)olddog(_dot_)co(_dot_)uk; ietf(_at_)ietf(_dot_)org
Cc: ccamp(_at_)ietf(_dot_)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
Hi Adrian,
I am updating this draft, but one issue is about the new small section.
You said "adding a small section including all of the statements you made in
your email", but I really don't know which kind of section should be added to
cover various aspects including management tools, OAM, alarm, MIB, etc.
I also suspect the value to have this kind of new section to talk about
something (and nothing new), which may not be related to the subject of this
draft (ie., RSVP-TE extensions for OTN *connection* establishment).
Therefore, I would like to hear more from you. Could you give a title for this
new section?
Best Regards
Fatai
From: Adrian Farrel [mailto:adrian(_at_)olddog(_dot_)co(_dot_)uk]
Sent: Wednesday, August 21, 2013 6:12 PM
To: Fatai Zhang; ietf(_at_)ietf(_dot_)org
Cc: ccamp(_at_)ietf(_dot_)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
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(_at_)huawei(_dot_)com]
Sent: 21 August 2013 08:40
To: adrian(_at_)olddog(_dot_)co(_dot_)uk; ietf(_at_)ietf(_dot_)org
Cc: ccamp(_at_)ietf(_dot_)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
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(_at_)ietf(_dot_)org
[mailto:ccamp-bounces(_at_)ietf(_dot_)org] On Behalf Of Adrian Farrel
Sent: Wednesday, August 21, 2013 2:51 AM
To: ietf(_at_)ietf(_dot_)org
Cc: ccamp(_at_)ietf(_dot_)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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ccamp