IETF 54 CCAMP Meeting Minutes

Schedule rearranged due to technical difficulties.....

Kireeti:  Can someone come up here and sing during the break? *)

0935 - 0950

http://www.ietf.org/internet-drafts/draf
t-ietf-ccamp-lmp-06.txt
                Lang

Provided summary of updates to LMP draft.  See his slides for details.  
Thinks we are ready for IESG last call. Summary of updates to LMP WDM 
draft. 
See slides for details. Ready for WG last call. 

Bonica: initiate last call on list after meeting.

LMP Test Sonet SDH draft. See slides for details. After changes, we 
should solicit comments from list. We would like a WG last call 
thereafter. Get a feel from the room?

Kireeti:  Assuming that J0-64 format is removed, are there any 
comments?

Bert: The base LMP document was intended for proposed standard. We got 
pushback from ITU people stating that we should not be working on some of 
this stuff, so we split it out to a separate document. Are we 
intending on prop standard for this stuff?

Kireeti: Yes, prop. Standards stuff.

Bert: Are we on our proper turf? I would like ITU people to speak up on 
this as well as review it. I don't want discussion during last call, want 
resolution now.

Speaker 1: Question RE: LMP. After this meeting I intend to start a 
draft.  After reading LMP specification, I believe it has mandatory 
configuration.  Are there security considerations.

Lang: Yes, security considerations are mandatory.

Speaker 1: I would like security to be optional.

Bert: Security considerations may not be optional.  We can have some as 
optional, but some mandatory security options are required. 

Kireeti: It is mandatory to define security - how to run LMP in a secure 
mode.  It is not mandatory to run LMP in a secure mode. Can you?

Lang: That is correct, it can be run un-secure.  Ipsec is defined for LMP.  
If you do not want to run IPSec, you can run it without. 

Speaker 2: I am concerned about J0 encoding. It doesn't seem to be 
consistent with ITU T.50 requirement. Printable ASCII characters in 
particular might be an issue.

Bert: Please pose question to mailing list.

Ron: That way we will have record of conversation.

Lyndon Ong(Cienna): My company is editing 7714.1 ITU document.  Will there be 
any additional alignment with this?

Lang: I think the 7714.1 document is more closely related to bootstrap 
document, and I would lke to discuss this in next part of 
presentation.

Lyndon: This is now taking LMP and LMP-WDM that are tech specific. Are 
there any non-tech specific things that cannot be applied to both.

Lang: The whole document can be applied to both.

Kireeti: Is there any objection in ITU from letting IETF have this 
document or will we dribble out requirements one by one?

ITU leason: I cannot speak for all ITUT, but we need to socialize this 
within the ITU.  
There is work going on with regard to discovery in ITU 7714 that might need 
to be aligned.  
However, I will try to get discussion going on rapidly.

Dmitry P:  There may be issues with the way the messages are encoded. 

Kireeti:  We are not talking about discovery; test messages. Documents were 
separated so that we can work issues doc-by-doc.  Good to get ruling for 
each document. The typical issues with using J0 etc... has rules for how to 
use this.  Make clear that that some issues are about before service 
starts. 

Speaker 5: 7714 issue: if they do the same thing, then why define two 
documents for this?

Lang: There may be overlap between next document, but not here.

Speaker 5: Need to be clear about what the overlaps are.

Lang: Bootstrap document (next doc), the intro describes why the doc 
exists. 
Prev. document is defined in LMP base document. If you disagree, let me 
know.

LMP Bootstrap document. See slides for details. This is not WG 
document. Would like technical comments on list.

Dmitri: Could you comment on applicability of incompatibility with other 
documents.

Lang: The point to make is the information exchanged is the same as that for 
the LMP protocol. There is no new information exchanged.

Kireeti: We need to continue this on the list (ITU input) on how we move 
these documents forward.

Kireeti - CCAMP 55 WG status.

Kireeti: Is there any problem with sending GMPLS framework to IESG as 
informational.

Bert: I reviewed this doc a while back, and question is that 
non-standard extensions are detailed here. This seems strange to publish a 
document that suggests a way of signaling things without a document being 
somewhere that details the specifics somewhere. 

Dmitri: We have been looking for comments RE: 
pointers/document to fulfill your query. I think it is unfair to 
continue without filling these requirements. When I sent comments on the 
list, I asked people to provide pointers. If people would like to 
continue, please send pointers ASAP.

Kireeti: As a fallback, what are we going to do if no docs are 
received.

Bert: Throw it into the garbage.

Kireeti: Unless we get pointers, this goes in the can.

Kireeti: One thing has been asked about is changes to the charter. We want to 
make changes to the charter. Please send us suggestions. Few 
additions: inter-area (within AS domain),  
Protection/restoration, optical VPN.  This will be discussed partially 
during SUB-IP meeting, but approval of charter changes come from IESG. 

JPV: Question about the charter. Will signaling between computation 
server and client are part of the charter, or do we need to add?

Kireeti: The current charter does not explicitly have this. This is part of 
the charter extensions we are asking for. 

JPV: This can be used in other areas.

Kireeti: Don't go there. If it is in the charter it is, if not then no. 
Need to make sure this is in the charter. 

Ron: I will send out an update on the charter additions (proposed) to the 
mailing list.

Ashok - Interoperability draft.

Kireeti: FEC change and TSPEC changes are orthogonal to GMPLS. These are 
issues for RSVP.

Bert: These are separate documents. Do this in RSVP.

Lou:  Spec. requires TSPEC. Lets talk about this offline.

Kireeti: Okay. I want to talk about some implementation 
recommendations. How are these published?

Bert: Implementation recommendations are fine to either publish as BCP or 
Informational.  I am worried about the limited set of 
specifications/issues and that they are captured. 

Kireeti: Generic RSVP things are already specified (according to Lou). Lets 
talk about this offline to see where changes are required. Define what 
issues are, how are they specified. Do this offline.  Should we add 
recommendations to implementation survey as an appendix?

Bert: Whichever.

Lou: These look like guidelines to implementations. This is usually done 
outside of spec. done as BCP/Info.

Kireeti: Question is where to put it. 

Lou: Seems like this is not a BCP. 

Kireeti: Too early to say that these include "best" practices. Looks 
informational. Need to talk with Lou about remaining issues. 


Tom Nadeau did a presentation on the discussions regarding the GMPLS MIBs at 
the Sat MIB Meeting.

* how Saturday meeting affects the GMPLS MIBs?

* issues for CCAMP: how to represent SONET (i.e. longer) labels

* proposed solution on label/index given
  Tom asked for feedback from the working group on this proposed 
solution

   type field + octet string

   goal is to support longer labels

* Comment by Kireeti to rename 
  Link Bundling MIB to TE-LINK-MIB.

(No questions on presentation).


Nadeau: MIB overview presentation

Dora: MIB discussion. 2 issues.

Tom: SNMP is just another management interface, and like any other tool, it 
needs to be used appropriately. Otherwise, you will have scalability and 
provisioning issues.

Kireeti: Lets have a discussion on the list for all of these things.

Bert: Discussion going on in IESG/SNMP community. Been hearing that 
people do not want to use SNMP for configuration.   However, I will defer to 
the WG for guidance on this. We need discussion on this issue, in 
particular from operators.
Kireeti: We should take this to the mailing list. 


Protection/Restoration Team: 

Kireeti: I suggest that you kick off a discussion so that people can pick on 
points that might be controversial. We need to do this before we make this a 
WG document.  We need to take this into account.

Dmitri:  We took existing protocols and analysed them.   What I have said is a 
consolidation. I think we are fine with the scope. We need to focus on the 
validation.

Kireeti: We need to make sure there is a consensus on your cut off that it 
was reasonable.

Bonica: Tunnel trace draft. See slides.  Is the requirements draft ready for 
WG last call.

Monique:  How is this going to relate to LSP Ping?

Ron: When you discover a tunnel, GTTP invokes LSP ping.  There is one open 
item: if the LSP is supported by an IP/IP tunnel. LSP Ping will not tell you 
this.

Kireeti: Are there any comments from anyone else?  The requirements 
document is a WG document. Can we have a show of hands for support of GTTP 
proposed solution as WG document?  We have a small consensus in favor of 
this. Go back to mailing list to confirm.

Dmitri: Draft.

Dmitri: When you increase the scope of what GMPLS may cover. We need to 
handle the limited complexity here. This is what we have worked on.   We 
need to handle optical/PSTN. 

Kireeti: Lets not make this a WG document until discussion on the list.