[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
CCAMP minutes
Many thanks to Sudheer for his detailed minutes and to Ed for his
colorful minutes (pity I can't publish them unexpurgated). Between
the two, we have excellent coverage.
The following is mostly from Sudheer, with comments from Ed prefaced
by "EK:" My own comments in []. The minutes are reproduced almost
as is. Note that the numbers when asking for consensus, while
faithfully reported, are *not* in themselves significant. The goal
is rough consensus, not a majority.
Kireeti.
-------
CCAMP Minutes:
Milestones:
To dos:
- Make framework as working group document
- What to do about or extend the working group for
o Inter-AS signaling
o Optical VPNs
o G.709
o Measurement (routing, LMP, OLI, ?)
o MIBs
o Security (new design team)
Charter & draft updates:
Routing drafts are broken as "common" and "Protocol-specific"
ISIS will be dealt in the ISIS working group
OSPF will be dealt in the CCAMP working group
(EK: (mike goes dead, we can thankfully no longer hear kireeti babble))
Protection and restoration - ?
Hierarchical (multi-area) TE drafts
- Where will the protocol work be done?
o Wei - Can decide after the TE WG.
(EK: kireeti says protocol work belongs in ccamp; te-wg chairs agree.)
Update from the DT:
No presentation made.
GMPLS update (Lou):
(Generalized-signaling, RSVP-TE, CR-LDP)
Changes:
- More on the technology specific is separated and covered in length
- SONET/SDH is moved out to be included in another draft
- Issued joint CCAMP and MPLS WG last calls
Detailed changes:
- Technical error in LDP (?)
- Re-introduced Switching type in the G-PID
o To support multiple switching types on the same interface
- Administrative status information TLV is added
o To support state of the LSP (in Path/RESV) and
o To notify the status of an LSP otherwise
- Changes made in the scope of "control channel separation"
o Identification of data channels when the channel is not uniquely
identified by control channel
o Handling of control channel failures that do not impact data
channels
Next changes:
- Need more comments
- Ask IANA assignment for CR-LDP and RSVP-TE related information
- Some issues resolved
o Missing timeout
o Minor changes to
o G-PID change to avoid duplicity for SONET (?)
(EK: kireeti cant run powerpoint to save himself.)
Discussion:
3 weeks from today [i.e., by August 27] will close on the comments and
move forward.
SONET/SDH (Eric):
GMPLS-SONET-SDH:
- This is the separated document from GMPLS signaling draft specific to
SONET/SDH
- Flexible concatenation is NOT part of this document
- Mostly editorial, re-organizing, correctness etc.
- Appendices are provided for different implementation mechanisms
supported using this draft
- Other modifications
o Improve the interoperability
o Etc.
- Targeted for informational RFC [not this doc, the new doc, see below]
- Move for IANA assignment
- Which appendices to be moved
o Contiguous concatenation
o Transparency (per byte)
o Virtual concatenation
o Signaling for non-std concatenation
o Appendix 1: Explained
Discussion:
Comment:
(EK: comment on if certain part should be on standards track or information)
[Clarification: the appendices that refer to items that are non-ITU-T
standards get moved to another *informational* document.]
Concatenation conversion (Eric):
Problem:
- To avoid wastage of timeslots due to different concatenation mechanisms
Solution:
- SDH/SONET "Virtual Concatenation"
Proposed a contiguous concatenation (C) to virtual concatenation
(V) conversion mechanism and extensions
- Realize ingress and egress aggregator
- Advertise the converting nodes using routing protocols
- Use signaling protocols to use this information to setup the path
Signaling:
- C->V is performed at the first converter and V->C is performed at
the end converter (before the destination)
- 5 possible concatenation mechanisms can be negotiated
o CC e-to-e
o CC->VC
o VC->CC
o VC e-to-e
o ? [CC->VC->CC]
Discussion:
o Are there such converters available?
o Eric says at least two vendors have. He sees this evolving more
and more.
o How many see this as useful function? - 10-15 (EK: 10)
o How many think this is should be done here? - 10
o How many think this makes sense? - 5 (EK: 8)
o How many think this does not make sense? - 2 (EK: 3)
o Why not in IPO?
o These are signaling extensions.
o Technology specific things should be in their respective groups
CCAMP is working on GMPLS
o What about VCs taking different paths?
o This does not include such paths
o (Marteen) This is a non-standard feature support. Why not also look
at supporting standard mechanism using GMPLS? This is part of the
transport network -- put it in.
Conclusion:
- WG chair's inclination is to make this as a WG draft. But since not
many people understand these concepts let us take this to the
mailing list before the decision.
G 709 (Dimitri): - Fontana-ccamp-gmpls-g709
What?
- Propose GMPLS based control plane for G709
- ITU-T G709 is getting standardized at ITU. Lets work on the control
plane for it.
Why?
- G709 is a tera-bit tech for the future
- GMPLS solves the signaling mechanisms to control such a technology
Changes:
- G709 OTN is independent of the control plane
- GMPLS provides all the hooks without major paradigm shift
Propose a new G709 drafts similar to SONET draft
This is only about signaling extensions
Routing extensions for G709 are under consideration
Changes:
- Document name has changed
- Encoding type
- Signaling type
- GPID value list
- ..
Further changes
- Move features not covered by G709 in a dedicated draft
- OOS field description to be completed in appendix
- RMT/RNC to be adopted in RMT/RNC and RVC field
Conclusions:
- Propose to be working group document
- Features not in the document to be moved to extensions --
Kireeti - This should be driven more by what is in the ITU G709 document.
(EK: kireeti says that its not a vote; if its in g709 it should be in
the document.)
[KK: Clarification: stuff that is not standardized by the ITU
should be moved to another document.]
Decision - Consensus in the room is to adopt as a WG document. But will be
taken to the mailing list before the final decision.
(EK: majority think this should be a wg document and that the
signalling part belongs here.)
GMPLS TE MIB (Adrian)
Existing TE MIB (which is in the final stages in MPLS WG) is only for MPLS.
(EK: clarification this is the mpls te mib)
GMPLS extensions are provided in this draft.
This effort should not impede MPLS TE MIB progress.
This should belong in CCAMP.
Lot of interest on this work (by implementers, operators etc.)
Work includes TE and LSR MIBs for GMPLS
Updates will be provided next month
Make this CCAMP WG document
Discussion:
(AD) Bert: Make a MIB framework document with the gamut of MIBs to put
them in perspective. Make sure that there will not be an overlap in these MIBs.
Decision - Wait for the overview draft.
(EK: bert before you extend or build on mpls mib document best to let that
document go through iesg last call so that it stabilizes before you extend
it. kireeti should we not make it a wg document until mplste mib
settles...bert yes.)
GMPLS Architecture draft (Eric)
Was accepted as a CCAMP WG document
Gives GMPLS overview and provides how the building blocks are glued.
Changes:
- TOC, open issues, L2SC added etc.
- Many changes including scope of UNI, GASTN/GASON in the GMPLS
context
Proposed sections:
- G709
- OLI
- Protection and restoration
o UPTO THIS IS IN THE CHARTER – What is below will be on
consensus from the DT and further discussion.
- Multicast
- Inter-area TE
- Inter-domain
- VPN (OVPN) section
- Etc..
Discussion:
- (Jim Luciani) Make sure there will be no overlap on ASON work in the
IPO group. - OK
(EK: lots of overlap with work thats being done elsewhere and work with
person doing req documents from cienna on interarea work.)
- (Marteen) Wait for the ITU to come on consensus on OTN and Protection
- Make ASON relationship clarified in this document in terms of scope.
- Kireeti: Track what OIF and ITU work is being done. But we need to
work on the signaling part should be done at CCAMP to move the work.
- No consensus on the draft status
[Editor to remove out-of-scope subjects. Draft status is "close to WG
Last Call".]
Framework document (Yongwang Xu):
- Control plane is discussed from different perspectives
- What are the fundamental changes betn pkt and ckt based network ctrl
plane design
- NW layering -- based on tech, BW mismatch, cost etc
- NW partitioning -- administrative (tech, geo, oper reasons)
- Overall -- reduce the tools to a common integrated control plane
Propose:
- Make this a WG document
Discussion:
- Greg: How is this different from what is being done in IPO? – More
number of authors and carriers
- Eric:
- ?: What about reliability of the control plane and bandwidth broker? --
Kireeti: Bandwidth broker is not in the charter. Reliability of the
control plane will be discussed only after what is to be done is clear.
Consensus: Will take to the mailing list with the assumption that people are
not sure.
(EK: kireeti: how many think we need gmpls framework document about 10
against 5.)
Framework on GMPLS based CP for SONET/SDH networks (Greg):
- Asked by many people to explain what are the problems with SONET using
GMPLS
Discussion:
- Kireeti: Will be a WG document as informational.
LMP changes (Jonathan) -- Draft-ietf-ccamp-lmp-00.txt
- Remove CCId from TE link related messages
- Modified the LMP common header to include
o CCId specific messages
o The TE link Id for specific msgs
- Removed ChFailNack
- Removed LMPCapabilities TLV
- Next steps:
o Remove link MUX type
o Add on graceful restart procedures
Discussion:
- Why ChFailNack removed? -- Always the upstream node worries about it.
So we can remove this msg without loss of info.
- What about tech specific mechanisms (for e.g., as specified by the
OIF UNI for in band)? -- Since this involves protocol specific
extensions, make a specific document.
- How many are implementing? -- 10 (EK: 15)
- How many carriers are interested in putting in the lab? -- None (EK: 5)
- How many think after the next rev there should a last call? -- 4
Wait for the next update and see if it is stable.
LMP MIB:
- Moved Link Summary retransmit values …
- TE link table uses if id
Discussion:
- Will this be a WG draft? -- Accept as a WG draft
(EK: does this have to wait for mplste mib to move forward...kireeti views it
as being 95% independant from the other mib so is available to move forward.
kireeti takes poll on if it should be wg document...20 for zero against.)
- Request: Send the dependency to the other TE components to the
mailing list
OLI (Andre)
- Main objectives
o Enhanced fault detection/recovery for transparent optical XCs
? PXCs have limited detection mechanisms unlike SONET
equipment
o Enhanced discovery of link characteristics for optical networks in
general
? Reduce manual errors in configuring
o General requirements
? Simple protocol to report health
? Defined parameters
? Extensible to future techs like G709
? Reliable
? Secure
? No assumption on 1:1 relation between client and server
- Requirements
o Neighbor discovery
o Control Channel Management
o OLI synchronization
o Connectivity discovery
o Fault management
o Property discovery
Discussion:
- Angela: Is this required to run only OOB? -- Not necessarily.
Could be used for opaque.
o Neighbor disc should be coordinated? - That was the intention
- Sham: Why this in IETF? -- Rough consensus to work in IETF.
This is because this work falls under measurement part of CCMP.
(EK: question: why should this work be done in ietf,no ip involved.....because
it has an ip control plane thats why. randy: iesg goes around
seriously..its here not because ip transport is being used to control the
device, but that its carrying ip traffic....
kireeti: not enough that they are IP
protocols but that they grow IP networks everywhere. hands on if we should
be working on this or not..about 40 hands for 15 against.)
NTIP
- Added auto-discovery
- Reliable transport -- TCP - X
- Simple -- Assymetric relationship - ???
- CC Maintenance -- Keep alive
- Auto-dsc -- Supported
- Fault notification -- Supported
- Trace monitoring -- Supported
- Resynchronization -- Supported - X
- Fast notification -- Supported - X
- Issues with LMP-DWDM
o Assumes LMP exists
o Employs
LMP-DWDM
Discussion:
- Vijay: To have less new code in a box, I prefer LMP-DWDM.
- WG chairs: Move with LMP-DWDM if we move forward (i.e., if we
are not stepping on ITU foot.)
- Osama: What is the procedure to follow up this formally with ITU.
o Randy: We have a formal channels
(EK: kireeti: needs duedilligence that we
will move forward with lmpdwdm if we move forward with anything because the
itu work might cover it making it not necessary to do this work at all.
question? how do we make sure this isnt work they are doing
randy: we have formal channels in place to ask the itu.
question: formal channels are in place...comment that it doesnt get used
enough, more common that liason statements are used. randy: there are many
other channels being used far more frequently then liason papers so nothing
more formal or other channel is necessary0
Tunnel trace protocol:
- Protocol is completely stateless
- Refined PIO and TIO
- ?
- Issues:
o Works only for tunnels that have TTL expiration
o GTTP should support MTU discovery
Discussion:
- Consensus that this is a required concept.
- No consensus that this should a WG draft.
- Will be discussed on the mailing list.
(EK: kireeti: useful document? 20 yes zero no...is this document useful
should this be a wg document 6 yes zero no.)