Sixty-seventh IETF, San Diego, November 2006
Monday, November 6, 2006
0900-1130 Morning Session I
RTG ccamp Common Control and Measurement Plane WG
CCAMP Working Group Meeting Report
Note takers: Don Fedyk, Lyndon Ong, Richard Rabbat
Chairs: Adrian Farrel, Deborah Brungard
==========================
============================
0. Administrivia (chairs) [2 mins: 2/150]
Slides
============================
See Slides. No bashing.
=======================================================
1. WG status, RFCs, drafts, milestones (chairs) [8 mins: 10/150]
Slides
=======================================================
Adrian presented an update on the status of WG documents
Kireeti: Arthi is no longer involved. He will take over and plans to get
this out.
Ross Callon: any update on 2 [recovery] drafts?
Adrian: Dimitri will respin.
The pd-path-computation is waiting on the 2 drafts:
inter-domain-rsvp-te and lsp-stitching.
Kireeti: I should get things done by end of November. I have looked at
the mailing list and there are no comments that I need to
address. I will update some things by the end of November 2006.
Dimitri: Several times sent comments, requests for clarification on
pd-path-computation, that have not been replied.
Adrian: Editor is not here, please bring up to Deborah and me so we can
follow up.
Adrian: polled about interest in the pc-and-sc-reqs drafts: 6 people yes
0 no. Need to know if more support to continue work.
Dimitri: [GMPLS OAM requirements] Are we addressing a specific problem
or are we documenting techniques with respect to OAM
requirements?
Adrian: Not clear yet. We added since we thought there should be OAM
work. If there is nothing to do, we'll remove the milestone on
next re-charter.
Loa: [GELS Progress slide] why say SDO? why not say 802.1?
Adrian: 802.1 is from IEEE. Not for the IETF to say which SDO.
Kireeti: I agree with Loa. The fact that it's a data plane specification
needs to be communicated from IEEE.
Adrian: They give us the go ahead to work on a control plane for a
specific data plane.
Lou: Means we don't take action unil asked? If we wait for an SDO, it's
a higher bar. Waiting for that will never happen.
Kireeti: We started SONET work before we got it.
Lou: We never got anything on Lambdas.
Kireeti: If the IEEE says this is a valid use for the control plane,
then we can go ahead? They don't need to request a control
plane, just validate the data plane.
Adrian: We can ask them if this is a standard.
Yaakov: Does GMPLS place any constraints on the data plane? If GMPLS
places constraints on a data plane, we should document the
functionality that a control plane requires of a data plane.
Adrian: Not aware of such a document.
Yakov: We need this in order to work.
Lou: A control plane should never place requirements on a data plane. A
control plane function is to support a data plane.
Yakov: Any arbitrary data plane?
Lou: Yes.
Adrian: Then the document that Yaakov requests is short.
Kireeti: GMPLS today does link-local labels and doesn't assume global
labels. If labels are global, we should decide whether we
should allow this.
Adrian: You are making assumptions about the data plane.
Dave Allan: Agree with Lou, issue is what parts of Ethernet can be
controlled by GMPLS. Very shortly, we'll be in a position to
decide on the IEEE specification that GELS can focus on. We
should not look at a small issue such as global label.
Yaakov: Whatever data plane you choose, you should have a document that
specifies what will and will not be supported for a specific
data plane.
Igor: Why isn't 802.1ad good enough? Why not try to control a particular
data plane?
Adrian: Let's move the discussion to the mailing list; we're beyond the
time limit.
=======================================================
2. ITU-T and OIF progress report (Lyndon) [10 mins: 20/150]
Slides
=======================================================
Lyndon reported on progress at ITU and OIF (ITU ongoing, so details are
not complete) [refer to slides].
Adrian: [Liaisons] Two of them got lost because they were large files. I
got them again and will upload.
Adrian: [Ethernet] I asked Dimitri to cover that in the Ethernet
parameters discussion.
Dimitri: [OIF ENNI OSPF] Which changes from CCAMP were taken into
account?
Lyndon: Don't have a complete list but will be happy to take questions.
Adrian: There were descriptions of protocol extensions. Are they still
normative? The concern that I have heard is that the document
has extensions to IGPs that are presented as recommended to
people for deployment.
Lyndon: The extensions in the appendix say that they have been
implemented for prototyping and testing.
=======================================================
3. Ethernet Traffic Parameters (Dimitri) [10 mins: 30/150]
- Changes to draft and current plans
- OIF communication and proposed response
Slides
Background reading
- draft-ietf-ccamp-ethernet-traffic-parameters-01.txt
- OIF communication
=======================================================
Dimitri presented [refer to slides].
Adrian: On the two questions from OIF:
(1) how do you tell the type of switching being done? We
clarified in previous slide. Maybe Lyndon can tell us if we're
missing something?
(2) how do we handle the case where the concatenation of labels
is so large that it is impractical to carry this message? You
haven't described the scaling issue.
Dimitri: In rfc 3473, use label set with lower bound & upper bound.
There's no way to do any other concatenation.
Lyndon: On the 1st issue, the confusion was about switching type. The
liaison statement talked about type vs. granularity. there was
some confusion about that.
On the 2nd issue, the signaling may need to carry a large list
of VLAN tags. A suggestion from OIF, as input from some carrier
members on the large number of VLAN tags, it seems the label
will be the same at the ingress/egress. Is there a way to carry
one instead?
Dimitri: Apply the rule for the upstream label, and you're done. If you
have bidirectional LSPs, you need to send multiple upstream
labels. As far as I know, there has not been a complaint about
the scaling issue. What is the new concern?
Adrian: In theory, Ethernet can use up to 4000 vlan IDs that can be
carried in one message, but from an application p.o.v., is that
something we really want to do?
Lyndon: One of the carriers expressed the concern, but I'm not sure it
exists practically.
Dimitri: What is the concern?
Lyndon: What Adrian mentioned (4000 id's).
Dimitri: Is this a blocking point for making progress?
Lyndon: I don't think it is. If there are ways to get around it, it
would be good to document. OIF is still looking at the issues.
Deborah: Is this for the uni?
Lyndon: You want to specify that you want a certain number of vlan ids.
May have Ethernet interfaces mapped over GFP on different SONET
links. You want to have set of VLAN tags mapped into one.
Deborah: It would be good to have requirements, please explain
requirements.
Lyndon: We'll try to come up with some scenario(s) to liaise.
Dimitri: Yes, better to have requirements.
=======================================================
4. ARP over GMPLS (Zafar) [10 mins: 40/150]
- Requirements and motivation
- Discussion
Slides
Background reading
- draft-ali-arp-over-gmpls-controlled-ethernet-psc-i-02.txt
=======================================================
Zafar presented [refer to slides].
Igor: Why not just say that asking for ARP resolution for TE link ID is
illegal?
Zafar: We can address the problem by having a common understanding for
addressing but we still have the issue of latency for ARP.
Dimitri: This is when you have Ethernet interfaces over a non-Ethernet
core. Why use RSVP for address resolution? why don't you use
the base ARP mechanism?
Zafar: This leads to interop problems. We need a resolution.
Dimitri: Why not maintain an ARP request so that you prevent the delay?
Zafar: Not clearly documented. It'll be good to specify
Julien: Why don't you try to fix the ARP specification instead of
extending rsvp?
Zafar: We're not able to do interop. Let's agree on a common
understanding on how to use ARP.
Julien: Clarify this such as Richard's [addressing] interop document?
Lou: Broken implementations and confusion? Document the use of addresses
for ARP resolution. We still don't know if it's a broken
implementation. I have problems with using your solution. Better
approach is documentation on proper use of IP addresses in a BCP.
=======================================================
5. Addressing Draft (Richard) [5 mins: 45/150]
- Update on status
- Any remaining issues?
- Ready for last call?
Slides
Background reading
- draft-ietf-ccamp-gmpls-addressing-05.txt
=======================================================
Richard presented [refer to slides].
Adrian: Anybody object to this as standards-track?
Lou: Still prefer BCP, but OK with group decision.
Adrian: Contains clarifications using 2119 language. If it contains
description clarifying the documents, it's standards-track.
Lou: My issue is if it is unnecessarily restricting the protocol then I
have an objection.
Yakov: What is the flip side of making it BCP. What is the drawback for
BCP?
Adrian: None, should pick one.
Richard: Many interop events dependent. If you have as a BCP, cannot get
everyone to follow.
Lou: The IETF process has the process for BCP.
Adrian: BCP seems not the right approach so much as an implementation
profile.
Lou: If we ask the question, does anybody object?
Yakov: Don't know the implications.
George: I agree with Lou. Jarring to find that we still have not got
everybody on the unnumbered and numbered page.
Adrian: We'll discuss again with Ross and see.
=======================================================
6. ASON Routing Solutions (Dimitri) [10 mins: 55/150]
- Status and plans
Slides
Background reading
- draft-ietf-ccamp-gmpls-ason-routing-ospf-02.txt
=======================================================
Dimitri presented [refer to slides].
Adrian: we have a liaison to ITU about it. Let's take review from the WG
at this point and wait for ITU's response.
Snigdho: Does it change the addressing model? e.g. TE Router ID being
routable. Is that still needed?
Dimitri: We keep backward compatibility to 4203 and 3630.
Snigdho: Does 3630 still apply to ASON?
Dimitri: Protocol needs to be interoperable with earlier ones.
Snigdho: May need a similar document as the addressing draft to clarify.
Adrian: We have a work item to cover the building blocks, maybe that
fits there. If you have specific usage scenarios, that would be
helpful.
Snigdho: I'll keep the other questions for the mailing list.
Lyndon: I wanted to point out the issue of the TE Router ID being
addressable is still there.
Dimitri: What needs to be done, that is not already described?
Adrian: A TE router ID that is routable does not mean you can send an IP
packet to it down a Lambda. Reread the text and make sure we
have it covered.
Dimitri: Agree.
=======================================================
7. LSP Hierarchy (Kohei) [5 mins: 60/150]
- Next steps
- Discussion
Slides
Background reading
- draft-ietf-ccamp-lsp-hierarchy-bis-01.txt
=======================================================
Kohei presented [refer to slides].
Yaakov: Do you have a FA or RA or both? If you do RA only you have
control traffic and no data traffic, why do you need this?
Adrian: Agree, what is the value?
Zafar: If you're using GMPLS for signaling but only advertise it as a
link to the IP topology and not a TE link (no data plane), then
you do it this way.
Yaakov: In MPLS, you can have a link. How do you know if it's advertised
as a link or a TE link? You can do this today.
Zafar: You're dealing with unidirectional links. There's no need for the
remote end to know what the ingress wants to apply to the FA.
Yaakov: If you restrict it to bidirectional, you should say so.
Dimitri: Is (R,F)=(0,0) still the default behaviour [as in RFCs]?
Adrian: We should have the bits for default to be the same.
Kireeti: Advertising a link into a TE database and IP link into the
Routing database, and using the link. Confused about RA.
2nd: FA's are unidirectional, keeping that policy by making
RA's only work in bidirectional, is overly restrictive and
wrong way.
Igor: Why do we need numbered interfaces in this draft? Kireeti was
talking about simplifying interfaces. Why do we need them?
Kohei: We need to handle both while still moving in the direction of
simplifying things
Dimitri: Why do you need to advertise the instance of the link? The
instance that you are using is part of the policy related to
the interfaces, why do you need this? What is the problem that
you are trying to solve?
Zafar: The question about policy keeps coming in. This draft is in the
spirit of making things dynamic. Coming back to your instances
point. GMPLS can be advertised on different instances. Then you
need this mechanism.
Kireeti: The original RFC4206 was very specific. The FA was advertised
in the same instance, because we were in a different paradigm.
We were connected in one area, but not another. This is a
powerful departure, with a different deployment model, that
makes this sensible. Agree with this new use of instance ID.
=======================================================
8. VCAT/LCAS (Richard) [10 mins: 70/150]
- Changes to the draft
- Agreement on solutions
Slides
Background reading
- draft-ietf-ccamp-gmpls-vcat-lcas-01.txt
=======================================================
Richard presented [refer to slides].
Adrian: Who has read the documents? [10 hands] Take it to the list, if
there are implementations, can move forward.
=======================================================
9. Multi-Layer Network (Dimitri) [10 mins: 80/150]
- Work on protocol extensions
- Issues to be resolved
Slides
Background reading
- draft-ietf-ccamp-gmpls-mln-reqs-02.txt
- draft-ietf-ccamp-gmpls-mln-eval-02.txt
- draft-papadimitriou-ccamp-gmpls-mrn-extensions-03.txt
=======================================================
Dimitri presented [refer to slides].
John Drake: Overlap with the LSP hierarchy draft. Should combine the
two?
Adrian: In this draft, you're using a call to state whether or not the
underlying path is advertised as an FA. In the other draft,
we're using connections.
Dimitri: It's an issue of scalability and availability. The difference
is one has state in the network and the other does not. Both
methods are equally good and have downsides. Practice will show
what is the best technique.
Adrian: John is right, it would be good to get the authors to
collaborate and move things forward. Also the chairs will
review.
Lou: Please look at RFC 2997 on zero bandwidth.
Dimitri: It was never mentioned as part of the GMPLS RSVP-TE
SENDER_TSPEC possible encoding (meaning that the base spec
refers to Peak Data Rate field of Intserv objects [RFC2210])
Lou: There's a way of doing it.
=======================================================
10. Graceful Shutdown (Zafar) [5 mins: 85/150]
- Changes to the draft
- Next steps
Slides
Background reading
- draft-ietf-ccamp-mpls-graceful-shutdown-01.txt
=======================================================
Zafir presented [refer to slides].
Adrian: Comments on the list.
=======================================================
11. Multiple Nodes Graceful Restart (Dan) [5 mins: 90/150]
- Objectives
- Next steps
Slides
Background reading
- draft-li-ccamp-multinodes-gr-proc-00.txt
=======================================================
Dan presented [refer to slides].
Zafar: Isn't it overengineering?
Adrian: Just covering as informational text? I'd like to talk to Dan and
Zafar and see if we need this. We could get this done very fast
if it is just informational and no extensions required.
Richard: Not clear what the issue is?
Adrian: 2nd order failures. Need to clarify before people come up with
new solutions.
Richard: This is good. DARPA is starting to look at this stuff. May be
good to clarify.
Dimitri: Should widen the scope of applicability to single-node &
multi-node. Overengineering occurs when things are split apart.
Lou: Does this have any procedures in it?
Dan: No.
Lou: Is this going to be informational? We should make sure we don't do
MUST, SHOULD, etc. Let's not make it look like a protocol document.
Zafar: Would like to know if any service provider wants to do this as
don't do for other items - example, RSVP. If we think it should
be solved, let's ask SPs to comment on it.
=======================================================
12. MIB Module for MPLS-TE GMPLS TED (Tomohiro) [5 mins: 95/150]
- Change of focus to be TED MIB module
- Next steps
Slides
Background reading
- draft-ietf-ccamp-gmpls-ospf-mib-01.txt
=======================================================
Tomohiro presented [refer to slides].
Adrian: Update the name of the document as it will cover ISIS also.
=======================================================
13. MS-SPRing (Diego) [10 mins: 105/150]
- Requirements and objectives
Slides
Background reading
- draft-gao-ccamp-gmpls-msspring-01.txt (Update missed deadline)
=======================================================
Richard: Who is familiar with this? (hardly any hands shown). Can not do
timeslot interchange. When we are using MS-SPRing must use the
same slot. Can not support this with GMPLS.
Adrian: Is this to be able to build MS-SPRing using GMPLS or connecting
across a MS-SPRing?
Richard: Yes. Looking at a topology that could use MS-SRing and want to
signal it.
Adrian: You want to manage an existing MS-SPRing topology?
Dimitri: What is the incentive for using GMPLS to provision MS-SPRing?
Currently provisioned using Management Systems. Different using
GMPLS for X-connects. Do we need to solve this problem? Are we
restricting this to SDH?
Richard: We have a carrier that wants to control an MS-SPRing using a
control plane. Other technologies can not speak for.
Dimtri: Where do you have the Recommendation, can send?
Gert: Data plane mechanisms are independent of the control plane. Want
to define a control plane for a specific data plane?
Adrian: We have timed out.
========================================================
End of time for the session.
Adrian: Sorry for the people who did not get to present. Please look at
the slides on line and discuss the work on the mailing list.
Adrian: Should we have two CCAMP meetings at the next meeting? Good support.
=======================================================
Agenda items not covered
14. Data Channel Status - LMP (Dan)
- Requirements and objectives
- Discussion of solution
Slides
Background reading
- draft-li-ccamp-confirm-data-channel-status-00.txt
15. Inter-domain Recovery (Tomonori)
- Progress and plans
Slides
Background reading
- draft-takeda-ccamp-inter-domain-recovery-analysis-01.txt
16. Requirements for Inter-Domain LSP Recovery (Wataru)
- Objectives
- Comparison with draft-takeda-ccamp-inter-domain-recovery-analysis
Slides
Background reading
- draft-imajuku-ccamp-inter-domain-recovery-req-01.txt
17. Optimal Routing (Peng)
- Requirements and objectives
Slides
Background reading
- draft-he-ccamp-optimal-routing-00.txt
18. GMPLS Lambda Labels (Richard)
- Requirements and objectives
Slides
Background reading
- draft-rabbat-ccamp-gmpls-lambda-labels-00.txt
19. Routing Extensions to support network elements with switching constraint (Wataru)
- Requirements and objectives
- Comparison with draft-rabbat-ccamp-gmpls-lambda-labels
Slides
Background reading
- draft-imajuku-ccamp-rtg-switching-constraint-01.txt
20. GMPLS Reservation Service (Lucy)
- Requirements and objectives
Slides
Background reading
- draft-yong-ccamp-ason-gmpls-autobw-service-00.txt
=======================================================