[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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:
http://www.ietf.org/internet-drafts/draft-swallow-gmpls-overlay-00.txt
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
other
> documents."
"Can you comment on backward compatibility with the other lmp
documents ?"
thanks,
- 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 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.
>
> ===========================================
> 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 (application/x-zip-compressed)
> Encoding: base64
--
Papadimitriou Dimitri
E-mail : dimitri.papadimitriou@alcatel.be
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : dpapadimitriou@psg.com
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone : Work: +32 3 2408491 - Home: +32 2 3434361