[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: IETF 55 - CCAMP Minutes
I will add this to the minutes.
> -----Original Message-----
> From: Dimitri.Papadimitriou@alcatel.be
> Sent: Sunday, November 24, 2002 10:12 PM
> To: Ron Bonica
> Cc: email@example.com
> Subject: Re: IETF 55 - CCAMP Minutes
> hi ron, all
> i do not see the report on the gmpls for overlay networks
> what i have is as follows (may be others can correct me
> or complete this):
> G.Swallow: discussed the application of gmpls for overlay
> networks, ending with a proposal for making this a
> wg i-d (proposed standard) see for more details:
> K.Kompella: asked for people in favor/opposed: the result
> was that only a few people (2 or 3) were opposed whilst
> the vast majority were in favor
> S.Throwbridge: asked whether the proposal was aligned with
> the carrier requirements (without more details)
> K.Kompella: let's bring it to the mailing list.
> also some comments:
> "> Dmitri: Could you comment on applicability of incompatibility with
> > documents."
> "Can you comment on backward compatibility with the other lmp
> documents ?"
> - dimitri.
> Ron Bonica wrote:
> > Folks,
> > CCAMP WG minutes follow. Slides are attached. Please comment on
> the minutes
> > within two weeks so that we can make any required corrections
> and enter them
> > into the record.
> > Ron
> > P.S. Kireeti's presentation provides a snapshot of WG status. I
> will make
> > sure that the ID tracker stays up to date so we will always
> have a current
> > picture of WG status.
> > ===============================
> > 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/draft-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
> > 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
> > 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
> > 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
> > 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.
> > ===========================================
> > Ronald P. Bonica Ph: 703 886 1681
> > vBNS Engineering page: 1 888 268 8021
> > Ashburn, Va.
> > ===========================================
> > "We are not on Earth to guard a museum, but
> > to cultivate a flourishing garden of life."
> > -- Angelo Giuseppe Roncalli
> > Name: IETF55.zip
> > IETF55.zip Type: Zip Compressed Data
> > Encoding: base64
> Papadimitriou Dimitri
> E-mail : firstname.lastname@example.org
> Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> E-mail : email@example.com
> Public : http://psg.com/~dpapadimitriou/
> Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> Phone : Work: +32 3 2408491 - Home: +32 2 3434361