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 |
| RFC | Status | Title |
|---|---|---|
| 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 ------------------ 1) Admin Adrian reviewed slides of agenda ------------------ ------------------ 2) WG Status Adrian reviewed draft status and milestones ------------------ ------------------ 3) ITU and OIF liaison report - Lyndon Ong Reviewed slides
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 Reviewed slides
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 Arthi: OK Adrian: Is this an example or is it normative? Arthi: The example only describes the overall working. ------------------ ------------------ 5) LSP stitching: Arthi Ayyangar Reviewed slides
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 Reviewed slides ------------------ 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 Reviewed slides ------------------ 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 Reviewed slides ------------------ 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 Reviewed slides ------------------ 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? Kireeti: Yes 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? Dimitri: OK ------------------ ------------------ 11) CCAMP Work Plan Kireeti reviewed the slide on options what to do
Alex:
Alex continues:
Adrian:
Adrian:
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 Reviewed slides Define a set of scenarios: 4 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. Dimitri: 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. |