RE: IETF 53 CCAMP Minutes

[Ron Bonica <Ronald.P.Bonica@wcom.com>]

I have added this to the minutes.

 

                        thanks,

                             Ron

 

-----Original Message-----
From: Eve Varma [mailto:evarma@lucent.com]
Sent: Monday, April 08, 2002 5:23 PM
To: Ron Bonica
Cc: ccamp@ops.ietf.org
Subject: Re: IETF 53 CCAMP Minutes

Hi,

Per your request from further down within the text - "can we supplement with other copy of the minutes", here are some of my notes.

Cheers,
    Eve

--------------------------------------------------------------------
Call for Design Team for GMPLS Profile for ASON/ASTN

ITU-T Liaison
Steve Trowbridge provided a report of the work of ITU-T Q14, as well as from Q11 identifying the areas that need further work, as outlined in the liaison to the IETF.  He also reviewed the Detector Controller Interface, clarifying this is over and above the actual payload.  It's the view of the anomalies and detectors from a control plane perspective, and identified the key information flows to be communicated across this interface.

Eric Mannie indicated that these gaps are very small, and were on their way to being solved.  He asked if these were all the gaps?  Steve said this doesn't mean that there wouldn't be something else identified, but would like to see disconnects addressed and resolved.

Dimitrios Pendarakis said the issue here is that the ITU-T has a set of requirements preceding this work, and have had some preliminary discussions.  Many are more clarification and applicability.  However, there may be some areas where some additional work might be involved.  The IETF gained alot from the OIF experience, and he suggested this would be a good opportunity with the ITU-T as well.

Yong Xue said the ITU-T is now working on version 2 of the document (G.7713), and should be considered.

Eve Varma provided a clarification that this was really for G.7713.2 (GMPLS RSVP-TE), though in the future as the G.7713 (protocol-neutral) capability set expands, the protocols may also need extension
-----------------------------------------------------------------------
 

Ron Bonica wrote:

Folks,

Minutes from our last meeting follow. Please review and comment.

                                          Ron

CCAMP Minutes

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Kireeti Kompella - Status Update

Draft Status Update

generalized signalling - finished last call,have implementation status,
ready for ietf last call

call for consensus to send to ietf last call:
        draft-ietf-ccamp-gmpls-sonet-sdh-extensions-01.txt  informational
                                -architecture-02.txt  informational
                                -ccamp-sdhsonet-control-00.txt  informational

Kireeti: Any objects to making fontana-ccamp-gmpls-g709-03.txt a
working group document?

NO OBJECTIONS

Kireeti: There was a call for design team for "GMPLS profile for ason/astn"

Tolbridge: g709 framework was going to go back to the ITU to produce
".g.709 for dummies".  Have not met yet.

Kireeti: happy to remove from plate of CCAMP if ITU will handle.

Osama: we have a draft at ITU-T that is a wg document

Kireeti: need a more concise statement from ITU

Kireeti: If you have any comments on the documents
(additions/subtractions/etc.), please post to the list.

Kireeti: there will be a charter update at some point

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Steve Tolbridge

Wasam Alanqar is liaison to ITU-T SG 15.

(2) communications to IETF CCAMP
  - signaling protocol work in Q14.15
  - detector-controller interface (DCI) from Q.11/15

See proceedings for URLs that show location of docs.

Documents sent to IETF from Q14.15
  - PNNI-based signaling
  - GMPLS RSVP-TE based signaling
  - GMPLS CR-LDP based signaling

Outlined a variety of "gaps" in the current work:
  - Call and connection separation
  - Additional error codes/value
  - Restart mechanisms
  - Support for crankback
  - Support for soft permanent connection

See proceedings for details.

Eric Mannie: Referring to slide "Identified Gaps".  Gaps seem to be
very small.  Most of the points are solved, can be easily solved, or
are in the process of being solved.

Tolbridge: This was a preliminary scan.  Further review, might turn up
more issues.  Technologies are similar, so lets identify and minimize
gaps.

Dimitri: ITU requirements precede much of IETF work.  Preliminary
discussions indicate that the current gaps are covered by existing
protocol work.  Areas where additional work will be required are
probably minimal, but need to be looked at.  IETF may gain final
improvements by looking at ITU work.

Yong Xue: ITU is working on v2 ASON document so more things could turn
up as "gaps".  Further communication between ITU and IETF should
continue.

Tolbridge: Technology will evolve within both organizations.  Should
expend effort to make sure that they evolve together.

Eva: ??? what was the point ???

[ can we supplement with other copy of the minutes ]

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Lou Berger

www.labn.net/gmpls-survey/...

17 organisations responded, mostly equipment vendors
1 provider
about 50% are independent implementation

charts no. of implementations as a function of feature
17 gen label and bw encoding
12 sonet/sdh label and traffic parameters
17 bidir lsps
...

no questions

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Eric Mannie - gmpls recovery terminology

Eric provided overview of terminology draft.  Draft covers:
  - LSP protection and restoration
  - LSPs controlled by a GMPLS control place
  - End-to-end segment and span recovery

Kireeti: Please send comments to list about whether or not this should
be a wg document. Sense of room:

About 20 have read document - all agree that this is a wg document.

Yong: All carriers have a different definition of
protection/restoration.  We need more carriers involved in the
process.  IP and transport folks rarely have the same perspective.

Kireeti: SP input came from TE WG and the SP representative on the
design team (KPNQwest).  Point is well-taken.  Carriers please make
comments.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Chen Lee - "Exclude Routes"

Draft defines a new RSVP-TE object that allows specification of
intermediate "objects" to avoid - avoid highly utilized nodes/ASs.

Wanted wg consensus on definition of this object.  Current draft does
!(A,B,C,D), but do we need to support (A, !B, !C, D).

Yakov: Regarding slide "application inter-area".  As far as I
understand, you want to exclude certain routers/links.  What is
purpose of excluding links?  If you just specify a link, what does
that do?

Lee: You may want 

Yakov: If you just want link diversity, then you want SLRGs, not links.

Yakov: Regarding "application - avoid highly utilized node/as".  Why
do this? Why not explicit route A, B, E, F?

Lee: What if you just know what you don't want, but know explicit route.

Kireeti: One of the issues.  When you do explicit routing with loose
hops, this is very similar.  However, don't want to do TE
node-by-node.  Want head-end or offline computations, not hop-by-hop
TE. The point is not to overload RSVP-TE with all of this information
- don't want to do this computation during the signaling process
anyway.

Ron: Take discussion to lists.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% draft-shiomoto-ccamp-multiarea-te-00.txt

hierarchical lsps for multiarea te
        lowr layer for abr-abr
        upper layer going ingress to egress

use of O-LSP for E-LSP routing.
next step: should be included in multiarea te framework

no questions
no support from floor, take to list

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% draft-imajuku-ml-routing-01.txt

LSR and PXC in same node. Number of links between the two should be
advertised as available resource in the switching capability no questions
from floor

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Jerry Ash - draft-ash-multi-area-te-compare-00.txt

comparison draft looks at existing proposals, try to converge on a reduced
set

4 main types:
distributed eg kompella scenario 1
path computation server, PCS, eg kompella scenario 2/4, 5
interarea summary methods
multiple path comparison

criteria: optimality, scalabilty, resoration, path selection performance,
path selection fuctionality

next steps: discuss options on list for consensus on selected method
if confirmed proceed with pcs, query and crankback exytensions

Yakov: You state that PCS achieves optimal section.  How much topology
information does the PCS need?

Ash: Has full-topology of backbone area.

Yakov: Therefore only optimal w.r.t. the backbone area.

Ash: Well it varies.

Yakov: Statement that PCS scales is "interesting".  : Normally
distributed approaches scale better.

Ash: Flooding is an issue with distributed schemes.

Yakov: There is also computational load.  Box may be a bottleneck.

Ash: That does not make it less scalable. [laughter here ]

McDysan: What happens when a router is controlling optical paths and
router goes berserk.  Might want to do "stability during
mismanagement" characterization.  Very valuable from SP point of view.

???: Single ISP or multiple ISPs?

Ash: Single ISP.

???: Why is protection hard in different areas?

Ash: Can be done.  Much discussion between authors on this.

Kireeti: As a router vendor, I take exception to the comment that
routers are more likely to screw up than OXCs.

Yakov: If you do protection/restoration on a per-area basis, then

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Eric Mannie -- draft-ietf-ccamp-gmpls-architecture-02.txt

Summarized modifications to document - see presentation.

Note: Remember that this wg id detailed the architecture of the GMPLS
building blocks, but not the detailed semantic of the technology
dependent structures, fields, objects, etc.

Ready for WG last call? About 20.

Bilel: Would be useful to send this to ITU and recommend use of GMPLS.

Kireeti: Are you suggesting that we take the document to ITU?

Bilel: Yes.  With perhaps an exercise to see if it meets requirements.

Kireeti: Who thinks that the document is not ready?  NONE

Kireeti: Please be diligent is making any comments.  Want to send to
ADS and request publications as an informational RFC.

next: meeting to sort out label issue, send updated drafts for last review,
go to iesg last call.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Eric Mannie -- draft-ietf-ccamp-gmpls-sonet-sdh-03.txt
% Eric Mannie -- draft-ietf-ccamp-gmpls-sonet-sdh-extensions-01.txt

Presented history and latest changes made.

Next steps - small revisions to drafts (specifically label coding) and
then go to IETF last call.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Eric Mannie -- draft-ietf-ccamp-gmpls-sonet-sdh-control-00.txt

Presented history and latest changes made.

Target is informational RFC.  Let's have last review and last call
before next IETF.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Dimitri -- draft-ietf-ccamp-gmpls-g709-00.txt

Reviewed document status.  Would like WG to adopt working item?

SENSE OF ROOM: SUPPORT 10-15.  NO OBJECTIONS.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Dimitri -- draft-mannie-ccamp-gmpls-lbm-tdm-01.txt

Reviewed scenarios in document.  Is working group will to accept this
as a WG document?

NO RESPONSE FROM THE ROOM (maybe 3 for, none against).

Ron: Take this item to the mailing list.

Kireeti: How many SPs in the room.  20-25.

Kireeti: How many folks are interested in transport.  MOST EVERYONE

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Osama Aboul-Magd -- draft-aboulmagd-ccamp-call-conn-separation-00.txt.

Draft addresses one of the issues that Tolbridge highlighted in his
talk - call and connection control separation.

Proposal to accept document as a WG item.

Kireeti: There is an explicit statement from ITU requiring this.
There is nothing in the charter about this.  This is good stuff.  Ron
and I will go through a charter revision with Ads and discuss putting
this in the charter.  Also need to address other gaps that were raised
by ITU.

Scott: When you propose to add something to WG, it would be helpful to
state where it fits in the existing charter OR how and why charter
should be extended.

Eva: I think that it fits into the character as a requirement to the
signaling protocols.

Scott: OK - that is a good clean explanation that might save chairs
some time.

Yong: I second Eva's comment.

Kireeti: Need to figure out how to address other issues as well.
Also, MPLS OAM will be discussed in MPLS WG tomorrow.

Osama: What is outcome?

Kireeti: Let's think about this.  See about doing same for RSVP and
then move forward.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% John Lang - LMP status (draft -03)

Current status:
  - Finished WG last call
  - Fixed several edits
  - Added text to security considerations

Open Issues:
  - Security
      - currently md5 is defined for LMP authentication
      - Another proposal exists in draft-sankar for Ipsec usage
  - Make local/remote id different in class type instead of object class

Bert: I raised the local/remote id issue, but there were also other
issues where things could be combined.  Did you review other parts of
document as well?

John: We did.  Your comment reflects this class, but not others.

NO OBJECTIONS TO PROPOSED CHANGES

John Sadler: I have some open issues.  Test message and ???.

John: Test message was updated based on comments in last call and
should be consistent with OIF work.

John Sadler: Does not talk about control/address fields.  Do not talk
about 1662 frame format.

John: We can look at this.

Kireeti: OIF compatibility is not a requirement, but if we get that
for free (or cheap) great.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Tom Nadeau - MIBs for GMPLS

Reviewed status of current documents, minor changes, etc.  Want GMPLS
MIBs to be compatible with MPLS MIBs when then become RFCs.

Summary:
  - Make mpls-tev2 MIB CCAMP (or MPLS) wg document
  - Make GMPLS-label MIB CCAMP wg document.
  - GMPLS-TC MIB as CCAMP wg document to capture new GMPLS-related TCs.
  - Drop GMPLS-LSR MIB (will use as it is including new TC change).

Kireeti: Why would GMPLS-label MIB hold up current MPLS MIB?

Tom: New indexing scheme relies on having the label MIB - for MPLS
index is label.  For GMPLS there is more stuff in the GMPLS-label MIB.

Kireeti: Need to see new version and then move forward.  Nice if we
could decouple them.  Will discuss with chairs and Ads where this
should go.

Scott: Seems general, so belongs in CCAMP.

Tolbridge: "general" frequently means more than one thing.

Kireeti: We have "classical" MPLS and non-packet based MPLS.
Generalized covers both.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Yoshihiko Suemura (NEC) - extensions to RSVP-TE for signaling and
restoration

Presented drafts.

Kireeti: Protection group should consider these docs.  More discussion
on the list.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Ron Bonica

Issues:
  - Should we define protocols yet?
  - IP centric VS Tunnel Centric tools

We need a tool that tells us about the IP layer and the tunnels that
support it.  IP network may be supported by multiple types of tunnels
- don't want separate tools for each type.

Proposal - adopt tunnel tracing requirements as a wg document.
Continue work on protocol specification.  Orthogonal to any open
discussions about MPLS OAM.

Kireeti: Discussion to list.

???: Is the proposal to accept a new (03) draft that incorporates
comments from the list.

Ron: not the intention.  Accepting the doc just means that it is a
good enough starting point and we can spin revs later.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Dimitri - protection and restoration

Will submit draft as an individual ID.  Want comments from the list.

Kireeti: Thanks.

===========================================
Ronald P. Bonica       Ph: 703 886 1681
vBNS Engineering       page: 1 888 268 8021
Ashburn, Va.
===========================================
"Not all who wander are lost."
                -- J.R.R. Tolkien