Re: IETF 55 - CCAMP Minutes

[Yangguang Xu <xuyg@lucent.com>]

I wasn't at IETF. From my reading of the draft and info from this thread, the
overlay ID sounds like the P-UNI effort which has been discussed lengthily in
OIF. Is my understanding correct? If so, can somebody clarify what happened to
OIF about this effort and why it's being brought up in IETF now?

Thanks,

Yangguang

Dimitri.Papadimitriou@alcatel.be wrote:
> 
> john, the point is probably that from a * protocol *
> viewpoint i didn't hear any compelling argument during
> the meeting (or on the mailing list), so if there are
> any gmpls signalling or other protocol issues that seems
> unclear for the ccamp community it would be very good
> to settle them asap in order to move forward with this
> i-d
> 
> imho, this is the only reason why kireeti asked to move
> the discussion to the list
> 
> thanks,
> - dimitri.
> 
> John Drake wrote:
> >
> > My count was 27 yes, 3 no to the question of whether the overlay I-D should
> > become a working group draft
> >
> > -----Original Message-----
> > From: Ong, Lyndon [mailto:LyOng@ciena.com]
> > Sent: Monday, November 25, 2002 4:25 PM
> > To: 'Ron Bonica'; Dimitri.Papadimitriou@alcatel.be
> > Cc: ccamp@ops.ietf.org
> > Subject: RE: IETF 55 - CCAMP Minutes
> >
> > Hi Ron,
> >
> > Just adding some more notes on George's overlay presentation -
> >
> > The question was raised on the difference between this
> > and the OIF UNI work, George responded that the OIF UNI
> > is aimed at public service providers with a separate
> > address space, while this is not.  George also noted
> > that the current addressing in Session and Sender_Template
> > objects may be overly constrained for overlay.
> >
> > IMHO, I'm not sure I would say a vast majority supported
> > it, the vast majority was generally pretty quiet at the meeting.
> >
> > Cheers,
> >
> > Lyndon Ong
> >
> > -----Original Message-----
> > From: Ron Bonica [mailto:Ronald.P.Bonica@wcom.com]
> > Sent: Sunday, November 24, 2002 7:10 PM
> > To: Dimitri.Papadimitriou@alcatel.be
> > Cc: ccamp@ops.ietf.org
> > Subject: RE: IETF 55 - CCAMP Minutes
> >
> > Thanks!
> >
> > I will add this to the minutes.
> >
> >                   Ron
> >
> > > -----Original Message-----
> > > From: Dimitri.Papadimitriou@alcatel.be
> > > [mailto:Dimitri.Papadimitriou@alcatel.be]
> > > Sent: Sunday, November 24, 2002 10:12 PM
> > > To: Ron Bonica
> > > Cc: ccamp@ops.ietf.org
> > > 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:
> > > 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
> 
> --
> 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