[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
IETF 53 CCAMP Minutes
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