Last Modified: 2005-06-13
|Done||Post strawman WG goals and charter|
|Done||Identify and document a limited set of candidate solutions for signalling and for measurement. Among candidate control solutions to be considered are the existing GMPLS drafts.|
|Done||Build appropriate design teams|
|Done||Submit WG document defining path setup portions of common control plane protocol|
|Done||Submit WG document defining common measurement plane protocol|
|Done||Submit LMP MIB to IESG|
|Done||Submit protection & restoration documents to IESG|
|Done||Submit ASON signaling requirements doc to IESG|
|Done||Submit GMPLS MIBs to IESG|
|Done||Produce CCAMP WG document for generic tunnel tracing protocol|
|Done||Produce CCAMP WG document for multi-area/AS signaling and routing|
|Done||Submit ASON routing requirements doc to IESG|
|Mar 04||Submit revised charter and milestones to IESG for IESG consideration of more detailed deliverables and determination of usefulness of continuation of WG|
|RFC3471||PS||Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description|
|RFC3472||PS||Generalized Multi-Protocol Label Switching (GMPLS) Signaling Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions|
|RFC3473||PS||Generalized Multi-Protocol Label Switching (GMPLS)Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions|
|RFC3609||I||Tracing Requirements for Generic Tunnels|
|RFC3945||Standard||Generalized Multi-Protocol Label Switching Architecture|
|RFC3946||Standard||Generalized Multiprotocol Label Switching Extensions for SONET and SDH Control|
|RFC4003||Standard||GMPLS Signaling Procedure For Egress Control|
IETF-63 Paris August 2005
CCAMP Working Group
Minutes thanks to Deborah Brungard and Don Fedyk
Adrian reviewed slides of agenda
2) WG Status
Adrian reviewed draft status and milestones
3) ITU and OIF liaison report - Lyndon Ong
Adrian: Understand that there is no urgency for responding. Will respond as quickly as possible, will post on mailing list.
Lyndon: These are results of the demo so there is no dependence but they are important.
Dimitri: Were these issues identified before or after demo?
Lyndon: Some before, some after.
Dimitri: Why not asked over the list for those before?
Lyndon: Some of the issues were, like the encoding. The first issue was on an informal response. So we want a formal response. The other issues we made some implementation decisions so we want to verify the decisions.
4) Interdomain RSVP - Arthi Ayyangar
Dimitri: Do you plan to keep the examples in the document or as appendix?
Arthi: Do you think it affects readability?
Dimitri: Prefer as appendix
Adrian: Is this an example or is it normative?
Arthi: The example only describes the overall working.
5) LSP stitching: Arthi Ayyangar
Adrian: Also from a control plane point of view it is better to have a consistent behavior
Dimitri: I see no reason for this, why are we still discussing?
Adrian: I said yes on the list because of the last bullet on the slide. Why disallow it?
Kireeti: I think yes also, why disallow it?
Dimitri: Why allow it?
Adrian: If we take it out of scope now, we may have to change later, so why remove it now? Yet we don't want to do it speculatively.
Igor: Question for kireeti: Can we stitch PSC1 with PSC2 LSP? And we said while we could do this with a label stack, but we shouldn't allow it as these LSPs were provisioned for a reason as two different types (PSC1 and PSC2). In the non-packet world this more clear. Use hierarchy and adaptation.
Kireeti: Not so clear for me. PSC1 & PSC2 We understand but Non-PSC we don't understand. For non PSC, we don't know where it will go, e.g. wavelength switching. So why prevent it?
Igor: It is not complex but it is pointless.
Kireeti: You can always say no when you receive a request to stitch.
Arthi and Igor: No, you can't say no
Lou: What is the difference between stitching and hierarchical LSP. The LSP on top (inner label) uses all the bandwidth of the one below (outer label).
Adrian: The difference is if you add a label for the passenger LSP.
Arthi: It's not just label allocation it's resource allocation. I'll address this later.
Lou: Minor suggestion; use a different C-type. Call it Option 2 Prime.
Arthi: You can, but it is still an issue.
Adrian: You have to do special processing when you do stitching anyway.
Arthi: You still have to implement the C-type.
Kireeti: You don't have to allocate a special label.
Adrian: Agree Point 4: Need to provide end-to-end bidirectional service. For example for mpls/gmpls migration. Need to stitch two unidirectional LSPs in the middle.
Arthi: Or could do 2nd part of (4). This is not really any changes Just need stronger description on what we are doing Personally like a sending label that is ignored.
Adrian: Who likes this 2nd part? - Send any label and have receiver ignore it # Some show of hands
Adrian: Anyone prefer one of the other solutions? # (No one?)
Adrian: Seems a preference for this 2nd option, will take to list
Lou: Clear to make the change. Change the text to Must.
Dimitri: Can you make document clearer by adding a specific section on the stitching rules wrt directionality
Arthi: Should it be required for non PSC?
Lou: Anyone that supports stitching MUST support the procedures if they support stitching.
Arthi: But if you are not following this document. You could be doing data plane stitching and not control plane stitching.
Lou: If it is outside the standard then it is out of scope. If you follow the document you MUST follow the procedures.
6) Per-Domain-Paths - JP Vasseur
Would like to get feedback on last issue on slides.
Adrian: I think the use of IP reachability information is important. The WG must make a conscious decision.
JP: This I-D is only describing reachability outside of domain
Adrian: We should say so more clearly
Dimitri: I sent feedback. We should cover this question. Not sure if part of this document. This is a problem in several documents. If we have IP reachability, but don't know switching capability, then it's not sure if we can make the connection. This an issue when have a mixture of switching capabilities.
Igor: When we compute path, we consider TE resources, not IP reachability. Should not rely on knowing reachability. Once you have a mix of terminating points this is a real issue.
Adrian: We need to have a global solution.
Igor: You want to compute path consider the resources TE resource reachability of destination. Not to rely on the IP but have static information that you can reach the path.
JP: Just want to rely on IP reachability to reach next domain, and then let next domain decide if it can satisfy the request.
Igor: OK - maybe could do aggregation rules You can have a static TE entry.
JP: But we don't have information on resources
Janis ??: Agree that if we are separating data and control plane, this will not work
Adrian: Specifying what information to use for path computation is not covered anywhere. It is part of the algorithm, but not part of the protocol. CSPF can use any information including IP reachability or the weather.
Arthi: So how do we find next hop? How do you get to the next domain?
Adrian: If we don't do this process inside the domain, why do we have to have a way to get out of the domain?
JP: So we should remove next hop?
Arthi: Does not make sense. How to do crankback?
Kireeti: OK - we need to consider further
7) Addresses in GMPLS networks - Richard Rabbat
Arthi: why you are proposing as a std track?
Adrian: This decision was a result of a loose poll based on whether this advises, recommends or mandates.
Arthi: Can we do again the poll
Adrian: We can, who prefers:
Adrian: If text is repeating the same must/should from another document then it should be deleted. If this is new must/should language then it should be std track Need to clarify definitions. If you are Restating with same values, its BCP. If you change values it is Standards updating an existing RFC or a new Standards track document.
Arthi: Then this should be std track as it is already doing it
Lou: It is bringing together many items - would suggest informational. Could be informational. I did not vote because I was waiting for informational.
Adrian: Who wants informational? # almost same show of hands as BCP
Lou: If it's implementation then BCP, but if bringing together info, then informational. The document is putting recommendations on implementing. Is it just for building and deploying? Or is it Defining a new field or procedure?
Adrian: OK we should discuss more
Dimitri: I thought the same - it is bringing together experience on using addresses, not saying how to do, and not covering future issues. So I have issue with 9.3 which is not based on experience
Adrian: The WG needs to decide how want to do
Kireeti: We will discuss with ADs and take to list
Arthi: For example, for the FA it says a MUST for how to use, but it doesn't say what to do for static case, so doesn't cover all cases
Richard: This is an oversight. we'll correct it in the next revision to say that we're talking about the dynamic case.
Yakov: Slide #3. Why the decision on FA LSP, this is a change to the protocol.
Richard: You don't know it is a FA LSP. How do you know that it is to be advertised back?
John Drake: It is covered in RFC3477.
Lou: That is unnumbered interfaces.
Adrian: Numbered FA LSPs need a way to indicate to the egress that they will be used as FAs. Compare with unnumbered LSPs that have a special object.
Arthi: What is the point of changing it to 0?
Kireeti: Let's discuss on the list
8) GMPLS/ASON Lexicography - Igor Bryskin
Igor: If anyone is interested in furthering ason-gmpls convergence, talk to Adrian or myself to help
Richard: What is your objective?
Igor: Have consensus in the group and expand the dictionary.
Richard: Saw in one the drafts on ASON there is an appendix. With ASON terms. Should we integrate the ason-gmpls documents' reference terms into this document?
Dimitri: No, that work was for CCAMP people to understand ASON. This is a different purpose
Igor: Agree. This is for ITU people to understand GMPLS
9) ASON routing evaluation - Dimitri Papadimitriou
Adrian: Who from DT is in the room? # Dimitri and Lyndon
Adrian: Thanks for work. Does the DT think this is ready for last call?
Lyndon: Yes. Just some minor editing
Adrian: Anyone object to last call # None
Alex: Doesn't WG need to read this first
Adrian: Yes, need to read it for last call OK take to list for last call
10) ASON signaling - Dimitri Papadimitriou
Dimitri: The community that wants to use this document needs it to be recognized as an RFC, it is important to finish
Alex: Any technical issues on this or the last document that need to discuss now?
Dimitri: Only this item on simultaneous call/connection signaling
Alex: Please summarize the technical issues. Please focus the time in the meeting to raise and discuss open issues
Lyndon: Will you liaison to SG15 before last call?
Steve Trowbridge: Should also include specific changes against g7713.2
Adrian: What is the intention?
Steve: Should be for alignment, should not have two normative versions of ASON signaling
Adrian: ITU already has versions .1, .2, .3
Steve: State how it differs from .2 version
Adrian: OK. This is GMPLS. 7713.2 is not GMPLS. We can do a comparative analysis. Principal difference is call/connection piggybacking
Lyndon: Is this UNI/ENNI/INNI?
Dimitri: The document states clearly this if you read it It covers client-initiated and network-initiated calls and so call/connection signaling at UNI and E-NNI/I-NNI
Alex: Are the technical issues complete? It would be much better if we have the technical summary. Not just say this work is ready or work is stable.
Adrian: We owe the WG status.
Kireeti: Dimitri, can you start the liaison?
11) CCAMP Work Plan
Kireeti reviewed the slide on options what to do
Kireeti: Should look at pipelining work as we already started first slide. It all depends on how long it takes to do charter. We have been waiting now for more than a year
Alex: Can prioritize and identify if can spin off work to a new, separate working group. Just like Layer 1 VPN that uses GMPLS. Take out other lumps and put in other WGs? Chairs should identify items.
Adrian: We can discuss which could spin off, though we need to decide, and not delay, as many items are already being worked on.
Bijan Jabbari: When I look at what is being implemented by vendors there is a mismatch with what this group is doing. Perhaps should look at short term.
Alex: Yes my thoughts should look at 1 year to 2 years.
Bijan: Not really clear what is being implemented
Bijan: I work with Academia and industry, and the answer is not clear. You see implementations but you don't see deployments. Business reasons etc. New way of thinking that takes time.
Alex: When go for standard track, do need implementation
Kireeti: Also need deployments, and that takes time
JP: Regarding the item on "input to PCE requirements". Not sure if need this input
Adrian: Explain history is that CCAMP made a commitment to assist PCE Could agree to remove this commitment
Alex: Yes we should discuss more in both groups. Don't want to make commitment to remove this before discussing it. If we have consensus maybe we don't need the document.
JP: On advertisement of TE/GMPLS capabilities, we're about to celebrate the third anniversary of this ID. The ID has been discussed, implemented and deployed in 5 large service providers, so would like to expedite this.
Lou: Slide Back to Slide3: For the item on charter - missing is ASON. What do we do about alignment, and that we have two versions of RSVP? There is only one version of GMPLS, what do we need to do? What steps that we need to take as a WG?
Alex: ASON is on our charter
Lou: It's on charter - we have completed our documents. We can send to SG15, but what do we do from there to align GMPLS and ASON solutions?
Adrian: Added it to slides
Richard: On recent new topics - do we know what is in-charter currently?
Alex: It is up to chairs:
Adrian: If it is in the scope of the charter, we will do milestones There will be discussion on the list.
Dimitri: Why is "deployment considerations" considered marginal? If you want feedback, how can this be classified as marginal? Please prioritize and please discuss.
Adrian: This is from the community view gathered on the list last year
Dimitri: Then how will we have deployment
Kireeti: You can do canvassing to get people to discuss. We will take back to the list to do a poll again
12) GMPLS for Ethernet - Dimitri Papadimitriou
Define a set of scenarios:
Don Fedyk: We still don't know what is actually meant by GMPLS Ethernet. The document does not go far enough today with enough detail. The document is too open ended and we don't know what exactly is being specified. I asked for more detailed specification.
Ali Sajassi: Ethernet differs from other data planes as it's not point to point. Do you want to keep it as in the perspective of IEEE? Other comments: you want to replace existing Ethernet control plane with GMPLS: again how will you do multipoint? Shortest path may overlap with issues discussed in TRILL. How are you going to coordinate with other WGs?
Loa: Not speaking for the DT as we didn't discuss it: I have experience running a medium/large scale Ethernet network as a point-to-point network (unified/core). It would be very applicable to add a gmpls control plane. Note that if we can't do it as a standard we (deployers) will do it ourselves. It is pretty straight forward.
Ali: I can see for point to point, it's for multipoint that I see it will have issues
Dimitri: OK. Can you input specifics? This said these questions are relevant but the scope (of the document) has been restricted to point-to-point. The issues on how we coordinate and potentially overlap with other working groups must also be addressed (implicitly: if we decide to move forward with this item.)
Richard Spencer: Can you confirm that using GMPLS in enterprise is out of scope?
Dimitri: As no one has expressed interest I would say it is out of scope
Richard S: Will there be any changes to Ethernet control/data plane? What would be the potential difficulties? Have a discussion with the IEEE and see where they would be impacted.
Dimitri: I can not say what will be the solution chosen, we already suggested we work with IEEE to assess impact
Richard S: I see little value for aggregation. I don't see in metro why a provider would want to use this instead of VPLS
Dimitri: I have replied to some of the issues you are currently raising on the list. If further clarification required we should discuss them on the list.
Kireeti: We will not change the Ethernet data plane here. If we conclude it may need to be changed, we will liaise to IEEE and get their agreement. CCAMP is focused on core tunneling technologies, though we don't say how you will use them - metro or core - I would like us to continue not to be specific for access or core. If there is anything specifically different for access, then need to add to charter.
Lyndon: There is a lot of interest in other groups (ITU, OIF, MEF). I think there is interest. Where people are uncertain is how. Need to look at more on supporting pt to pt or multipt.
Don O'Conner: How does this differ from l2vpn?
Dimitri: As explained in the introduction of the problem statement document it differs from the forwarding which is not based on packet header (as in MPLS) but based on the Layer-2 frame header.
Kireeti: L2VPON charter is different. L2VPN sets up vpns. This work is on signaling and routing in Ethernet networks.
Tom Nadeau: Is this in the scope of CCAMP today?
Adrian: Yes this is in the scope as a core network. GMPLS handles packet transport networks. Maybe this is could be a new working group. Note, however, that changes to the data plane are not in scope for CCAMP and would require action by other SDOs, in this case IEEE.
Tom: Seems similar to TRILL.
Adrian: Yes. Need to determine if there is overlap. Perhaps this work should go there. Alternatively, perhaps this work goes in a new WG.
Dimitri: Some of these items such as the difference with TRILL have been discussed on the mailing list.
Loa: Trill is in campus networks.
Alex: For structuring this work, we need to be very clear what data path modifications need to be done. Should communicate with IEEE liaison, preferably before BOF. TRILL working group is a specific example.
Dimitri: What would be the way to contact the IEEE to do this? Is there a liaison with IEEE that we can make use of?
Alex: We have an established liaison relationship with IEEE.
Dimitri: OK, we will enter in contact with the liaison representative.
Kireeti: First need to decide if we need a change in the data plane. Then talk to the IEEE.
Adrian: Also need to tell IEEE what we plan to do, no matter how we do it.
Adrian: We haven't decided anything about how forwarding will occur yet
Dinesh Mohan: I haven't heard yet that there is planned a change to the data plane. Need to understand better. Should look at this as a new control plane using existing data plane. It would be nice to have the GMPLS Control plane but is there no intent to change the control plane? The basic assumption is that you have a different control plane then that should be the assumption. This is fine to explore, but the starting point is not to modify the data plane.
Adrian: When we control SDH we did not mess with the data plane. We should not be modifying the transport technology.
Monique Morrow: Echo what Alex said, any modification we need to talk to the IEEE.
Dimitri: OK, but we are not talking in the context that there is a change to data plane.
Ali: Trill and this are using ISIS. Trill plan to change the data plane.
Kireeti: Please stop, take to list.
Ali: Several vendors offer Ethernet switches that offer point to point using MPLS control plane supporting millions of connections.
Yakov: How? Could you tell me whether they carry a label?
Ali: Yes. They are MPLS switches
Yakov: So it is a router, an LSR , that you can call an Ethernet switch and you are done?
Adrian: That is indeed a suggestion.
Don O'C: Ethernet is connectionless and now GMPLS is connection-oriented, so this is different. This is redefining Ethernet to make it connection oriented. Is that the intent? Is this making VLAN tags look like GMPLS labels?
Adrian: Again, this has not been discussed
Loa: From experience, we don't want to remove VLAN tags. Need something else. And the chairs said to the design team not to do that, yet 80% of CCAMP are already assuming this is what we want to do.
Adrian: Design team job is done - Thanks. We need now for the WG to discuss.
Time is over. Other drafts that we didn't get to discuss, take to list.