http://www.ietf.org/proceedings/88/slides/slides-88-ccamp-0.pdf
Status of WG documents not presented at the meeting:
Oscar Gonzalez: SRLG collection draft. One of the functionalities was split out to another draft (draft-hartley-ccamp-rro-editing-00). Discussion on the rro-editing draft are needed. Once there is agreement on the new draft, the SRLG collection draft is ready to move forward to last call.
Zafar Ali: Same for TE metric recording draft.
- Overlay use cases discussion intro:
Lou Berger: The discussion is about what use cases we care about and what mechanisms do we want to progress as a group. Terminology is a key issue, it is not clear whether existing terminology is good enough, may we need new terminology or to just fix the existing one. It would be better to reuse as much as possible of what has been done before. PCE: operating without the PCE is still in the scope of this WG. A reasonable discussion is on which PCE approaches to use. We have some existing terminology (also coming from other WGs):
-UNI: which is the ability to initiate a service request which includes attributes and constraints. It does not include resource availability or topology information, just constraints. The definition of "our" UNI says that it is ok to have reachability information. Because routing may be involved does not automatically mean it is not a UNI.
-E-NNI: the difference with the UNI is that it includes resource and topology information. You have an understanding of links, nodes (which may be virtual) and what's possible across those.
It is possible to add policy to these interfaces, e.g., use same or different address spaces (it's up to the deployment). The capability of having policies is the main difference between them and the I-NNI. The question is: "is this sufficient or do we need new terminology"?
Gert Grammel: What does it mean for the UNI: "perhaps reachability"?
Lou Berger: The document that defines the UNI talks about the capability of having reachability information (RFC4208).
Fatai Zhang: Why not refreshing existing terminology? We don't need new terminology.
Lou Berger: That's part of the discussion. Part of the discussion is also: when you're crossing technology boundaries and have an MLN node (meaning a node that understands and participates in multiple layer and technology control planes), which side of the reference point does it sit on? Does the client understand what happens in the lower layer network or does the server layer do that translation? Different people have talked about different models; do we want to allow for multiple models or a single one?
An important part of this discussion is to come to an agreement where the group understands and accepts that someone else's model is in scope of the group.
> 1 9:15 6 Title: Problem Statement and Architecture for Information Exchange Between Interconnected Traffic Engineered Networkshttp://www.ietf.org/proceedings/88/slides/slides-88-ccamp-1.pdf
> 2 9:21 5 Title: Use cases for operating networks in the overlay model contexthttp://www.ietf.org/proceedings/88/slides/slides-88-ccamp-2.pdf
George Swallow: You could have also a technology boundary which is not an administrative boundary.
Daniele Ceccarelli: Yes. But is that overlay?
George Swallow: We might have different departments running the different layers, we just need to be clear here.
Gert Grammel: What is the context of "overlay", is a data plane or control plane construct? Can you clarify?
Daniele Ceccarelli: Control plane.
Lou Berger: I forgot to add that point to the discussion, i.e. data plane transition and control plane transition.
Gert Grammel: With respect to multiple client nodes, is this control plane or data plane clients?
Daniele Ceccarelli: Both.
Lou Berger: You showed only lines. Does it mean only links or links and nodes?
Daniele Ceccarelli: Both are possible
> 3 9:26 6 Title: Applicability of Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI)http://www.ietf.org/proceedings/88/slides/slides-88-ccamp-3.pdf
Lou Berger: The gap analysis is very useful. It would be good for the discussion to focus on the problem space and use cases, not on the solution.
Xian Zhang: Ok.
Zafar Ali: The gap depends on the solution you choose. In some cases e.g. the gap is with respect to the PCE case.
Deborah Brungard: It is useful that you specified the addressing issue. Most people tend to think that client and server domain must share the same addressing space but indeed only the edge and core node on the access link must share the same address space.
Lou Berger: slide 3 is misleading or confusing. Address sharing is between nodes on the overlay link or different domains?
> 4 9:32 5 Title: GMPLS-based Hierarchy LSP Creation in Multi-Region and Multi-Layer Networkshttp://www.ietf.org/proceedings/88/slides/slides-88-ccamp-4.pdf
Rajan Rao: RFC6001 talks about IACD, not about XRO.
Deborah Brungard: The statement is that the client layer should be able to select the switching capability of the server layer? Can you say why?
Xian Zhang: One example is IP over OTN with OTN as adaptation. There are many adaptation functions and you might support only some of them (e.g. GFP, GMP).
Deborah Brungard: It seems in a ROADM you might want to choose whether to use OTN or WDM, why would you want to do that?
Rajan Rao: Are we talking about overlay or MLN/MRN?
Xian Zhang: MLN/MRN. It's a node supporting multiple switching capabilities.
Deborah Brungard: You should say why you want to select the switching capability from the client layer.
> 5 9:37 7 Title: Overlay Network - Path Computation Approacheshttp://www.ietf.org/proceedings/88/slides/slides-88-ccamp-5.pdf
Igor Bryskin: I don't see a use case where you don't have data plane transition.
Himanshu Shah: why the client would want to know all these details of the server layer? What happens in the server is out of scope.
Rajan Rao: For end to end path optimization.
Deborah Brungard: some people say we should, some others say we shouldn't. That's exactly the discussion.
> 6 9:44 7 Title: RSVP-TE extension for extension for signaling Objective Function and Metric Boundhttp://www.ietf.org/proceedings/88/slides/slides-88-ccamp-6.pdf
Igor Bryskin: Suppose I have an SDN architecture and I need topology information and it is somehow delivered to the SDN brain. The question is can I have customized control plane interface that allows routing but not signaling?
Debeorah Brungard: Can you say why?
Igor Bryskin: I want to use routing to discover topology and deliver to SDN controller and do the provisioning via SDN.
Deborah Brungard: Mention it in your use cases.
Rajan Rao: question to George: Are you suggesting that the discussion should include the interface towards the SDN?
George Swallow: It's an evolving world. It's something customers presented to me.
Gert Grammel: What's the role of the UNI if the control is in the SDN blob?
George Swallow: Because signaling can be used also in the SDN domain.
Curtis Villazimar: Speaking about SDN you already jump to a solution.
Lou Berger: We don't do SDN in this WG.
> 7 9:51 7 Title: Virtual Link Enhancements for the Overlay Modelhttp://www.ietf.org/proceedings/88/slides/slides-88-ccamp-7.pdf
Lou Berger: What I think you said is that you like the model Rajan showed and Himanshu asked why anyone want to do that. Correct?
Pavan Beheram: Yes
> 8 9:58 7 Title: UNI Extensions for Diversity and Latency Supporthttp://www.ietf.org/proceedings/88/slides/slides-88-ccamp-8.pdf
Lou Berger: Where do you see the PCE fitting in this scenario?
Dieter: It fits in, the PE may need to request a path if a PCE exists in the domain.
Lou Berger: So per domain PCE. Do you see a communication between PCEs (for inter-domain)?
Dieter: Yes, it should support both scenarios.
> 9 10:05 30 Title: Open DiscussionLou Berger: We have seen different architectures and different opinions on whether the server topology should be exposed or not.
Zafar Ali: Flooding topology info violates the UNI principles. When you say you export abstract topology, there are customer constraints to be considered. How it is possible to create an abstract topology a priori without knowing all the customer constraints? How do you know how all these constraints will be met? Either you flood too much or too little, this is an issue of the E-NNI that we need to solve. When you export all the details it is close to I-NNI.
Igor Bryskin: The way you create the virtual topology is the same way you create the real topology: you do planning based on customers input. It is not so complex as it seems.
Zafar Ali: If you do planning of all the requirements you end up advertising too many details and create too many virtual TE links.
Igor Bryskin: it can be as simple or as complex as you want. It depends on customers requirements.
Lou Berger: I see different views on different models. Poll to have the feeling from the floor it there are two different parties or two vocal people.
George Swallow: can people support both?
Lou Berger: yes.
Poll(1): Is it reasonable to advertise through routing topology information and resource across this interface (virtual, abstract or real)?
Adrian Farrel: Can I ask for clarification? What you mean by advertising? It spans from a little bit to everything? Zero is part of any.
Lou Berger: The question is intentionally vague. Zero is not included. Poll(1): [Result: Reasonable number.]
Lou Berger: Poll(2) Is it unreasonable? [Result: only a small number.] Poll(3): case dependent, i.e. some networks will advertise topology and resources, but others will not. [Result: Approximately as Poll(1).]
George Swallow: I think it is reasonable to have some topology info in the overlay network, just some details, to help improve requests to the server.
Zafar Ali: Disagree with path computation in the client layer. The client layer shouldn't be allowed to allocate expensive resources in the server layer for small amount of traffic.
Gert Grammel: Confusion derives from terminology. e.g. ITU UNI does not allow routing, IETF UNI allows for reachability. For Zafar UNI means a customer to service provider interface, to me means just a demarcation point for policies.
Lou Berger: Regarding terminology, should we continue to use UNI & E-NNI? Poll(4): How many think there is value in those terms? Should we try to keep using those terms?
Julien Meuric: I like untainted terms, the terms have a strong history and if we want to have a fresh start then maybe we need new terms. So yes, new terminology.
Daniele Ceccarelli: I do not think we have a clear UNI/ENNI definition within the IETF. I like the definitions you gave but have not found them anywhere.
Lou Berger: I agree there is no protocol definition of UNI/ENNI, MPLS-TP started to discuss the term. Some us have previously discussed defining the terms. If we think there is value in those terms we can improve the definitions, otherwise it's no worth spending time on it.
Dieter Beller: Before taking decisions we need to understand which are the definitions.
Curtis Villazimar: The terms are really overloaded. Our UNI definition is not compliant with UNIs from other venues, even worse for ENNI. Whatever terminology we use we should get aligned with augmented model as per RFC3717. We should probably get rid also of the term overlay.
Igor Bryskin: UNI and ENNI are last century terminology but we don't need new terminology either, just routing, signaling or combination of them.
Curtis Villazimar: We should focus on requirements.
Lou Berger: back to the questions on the slides.
George Swallow: We all agree the existing terms are confusing.
Lou Berger: Hum: How many people think we need agreed upon terminology? [Result: consensus in the room.] Do we need terminology or reuse existing terminology?
George Swallow: Doesn't need to be a binary choice.
Oscar Gonzalez: If we go for an updated definition of the UNI are we going to post a document saying that this is the only definition and definitions in other SDOs are wrong?
Adrian Farrel: It has a meaning within the community that gave the name. Updating existing terminology could cause mismatch with existing work (i.e. how it has been used in such documents). New terminology would avoid such issue.
Young Lee: If you want to define a new name it must reflect functionalities and capabilities it supports.
Eric Gray: Agree with Adrian, but don't want to use a totally different name for something slightly different. It might be confusing.
George Swallow: It's difficult to define new names and map them with what exists.
Igor Bryskin: We don't need a new label. It's enough to have a CCAMP interface with RSVP, OSPF or PCE enabled or whatever.
Curtis Villazimar: Responding to Eric. It is easy to define something as a delta. E.g. the new interface is like the old one with these differences.
Lou Berger: We (the chairs) have a proposal on how to move forward: We propose (from slide) 3 (types) of documents:
Document 1 - Models & Terminology
A lot of good text already written & available
Document 2 - Framework
Includes analysis of what can be supported
and what functions need support
Again, already some good text available
Document type 3 - Solution documents
BCPs & PSes
The first will include existing and new terminology (if any). There is a lot of text to reuse. Second document is our classical framework document (also called gap analysis nowadays). We will appoint the editors of these. The third type of documents are solution documents; we are not going to direct those, but have them follow normal process, i.e., be proposal driven. This activity should not stop progress on all WG documents, but some may be impacted.
Dieter Beller: what does it mean for existing drafts? Text should be proposed to the editors of the 2 documents?
Lou Berger: It's up to the editors but we expect them to draw from existing docs. If you feel something is missing publish it or comment.
Daniele Ceccarelli: Is any of these document meant to include the use cases?
Lou Berger: The first might talk about use cases, might not, a dedicated document might exist. At some points we might have applicability documents, e.g., for a particular case it will describe how the solution applies.
Zafar Ali: Fresh start or work on existing docs?
Lou Berger: Two new documents starting as WG documents taking text from existing documents.
Fatai Zhang: What's the difference between models and framework?
Lou Berger: Like architecture and framework in the past. I expect a lot of text of existing doc being reused and doc being progressed in parallel.
Curtis Villazimar: Again referring to the models defined in RFC3717, one model that is missing and is widely deployed is the "dumb pipes Model". We should document it.
George Swallow: How do we move forward with existing work?
Lou Berger: If you have prior work and proposals then please bring them forward.
> 10 10:35 8 Title: Mutually Exclusive Link Grouphttp://www.ietf.org/proceedings/88/slides/slides-88-ccamp-10.pdf
> 11 10:43 7 Title: Shared Resource Link Grouphttp://www.ietf.org/proceedings/88/slides/slides-88-ccamp-11.pdf
Zafar Ali: Concerns about scalability for both solutions.
Igor Bryskin: Can you advertise SRLGs for links? You need to be aware of them in order to perform diverse path computation.
Zafar Ali: there are already different proposals for the management of SRLGs.
Lou Berger: New proposal never discussed on the list. Take the opportunity to start the discussion there.
Gert Grammel: The problem addressed here is persistent in any model.
> 12 10:50 8 Title: Extensions to Resource ReSerVation Protocol-Traffic Engineering (RSVP-TE) to Support Route Exclusion Using Path Key Subobjecthttp://www.ietf.org/proceedings/88/slides/slides-88-ccamp-12.pdf
Zafar Ali: RFC5553 mentions that path keys are supposed to be kept for small time. If a solution requires that a path key is kept for the life time of the path, then this is a state PCE. I don't think this was the intention of path key. Moreover there are existing solutions that work without forcing states on the PCE.
Xian Zhang: You have 2 questions. 1 - You are saying that our solution requires a statefull PCE. The PCE is already able to retain the path key for the lifetime of the path. It's not a new requirement. It's already there. Second question on the list.
> 13 10:58 7 Title: Extension to LMP/DWDM for DWDM Optical Line Systems to manage application code of optical interface parameters in DWDM applicationhttp://www.ietf.org/proceedings/88/slides/slides-88-ccamp-13.pdf
Deborah Brungard: I saw that you aligned with the application codes but I still see some parameters there like OSNR that can be done with application codes. You should clean up a little bit more.
Lou Berger: Poll: how many thinks it is a useful function? [Result: a reasonable number.]
> 14 11:05 10 Title: Routing & signaling extensions for FlexGridhttp://www.ietf.org/proceedings/88/slides/slides-88-ccamp-14.pdf
Lou Berger: You call this superchannel. It is not aligned with dataplane, is it?
Rajan Rao: It is under discussion in ITU. Not accepted terminology yet. It is related to flexigrid.
Lou Berger: It is not up to us to define OTN data plane. Remove the superchannel terminology and align with the defined dataplane and the Framework document.
Deborah Brungard: check alignment with latest ITU liaison.
> 15 11:15 7 Title: OSPF-TE extensions for MLNMRN based on OTNhttp://www.ietf.org/proceedings/88/slides/slides-88-ccamp-15.pdf
Lou Berger: there is a signaling document covering the same issue. How do you plan to line up? Are there changes for signaling needed?
Rajan Rao: I need to think a little bit more on signaling.
Lou Berger: But advertising info that you don't know how to use does not make much sense.
> Adjourn 11:30http://www.ietf.org/proceedings/88/slides/slides-88-ccamp-16.pdf
Lou Berger: what are you going to do with the collected information?
Zafar Ali: It is good for the client to know if e.g. the SRLG has been summarized. The objective is to inform the client about the policy being applied by the network.
Lou Berger: I think you need to describe the use a bit better. For example, does the client need to know that editing occurred on a RRO object level, or on the per sub-object level?
Zafar Ali: There are different use cases based on the information that is removed. This draft was motivated by the SRLG draft.
Lou Berger: Where you have ended up is different than I think most expected in the prior discussions (Object vs subobject level notification of change).
Oscar Gonzalez: As editor of the SRLG collection draft, this one clarifies that part of the functionality (i.e. knowing which SRLGs were edited) was taken out from the draft and brought to this new document and made more complicated. Now that it is general, use cases need to be revisited. We just started from the SRLG but other may be needed.
Lou Berger: Do you need to know that the subobject has been modified or that the whole RRO (Object) has been modified? [unsure] Answer on the list is ok.
Xian Zhang: This is not per object, it is per type of subobject.
Zafar Ali: Wants to know what doesn't work, rather than discuss what's needed.
Lou Berger: We generally make changes only if there is value in doing that, otherwise we don't.
Curtis Villazimar: I have doubts about the practicality of the presented example. Here in most cases you use the ERO and don't even bother about the RRO.
> 17 17:40 5 Title: RSVP-TE Recovery Extension for data plane initiated reversion, and protection timer signalinghttp://www.ietf.org/proceedings/88/slides/slides-88-ccamp-17.pdf
Lou Berger: Poll: How many think being able to signal these parameters is a useful functionality? [Result: a small number.] Poll: How many read the document? [Result: quite a bit more]. Seems to imply some doesn't think is a useful functionality. Poll: Of those who read how many think it is not useful? [Result: Much smaller than in favor.] Poll: how many like the approach in the document? [Result: Even less.] None of these numbers are high, we need to see if we have more interest.
Loa Andersson: The questions asked are tricky. There is a number of people that don't care about it.
Lou Berger: Yes, agreed. please trigger discussion so people can understand why the functionality of the draft is needed.
Lou Berger: Moreover you are redefining the format of an existing object (by adding TLVs) this breaks compatibility.
Zafar Ali: No it's a new C-type.
Lou Berger: We can discuss on list.
> 18 17:45 5 Title: Extensions to Resource Reservation Protocol For Fast Reroute of Bidirectional Co-routed Traffic Engineering LSPs[Withdrawn]
> 19 17:50 5 Title: RSVP-TE Extensions For Signaling GMPLS Restoration LSPhttp://www.ietf.org/proceedings/88/slides/slides-88-ccamp-19.pdf
[skipped]
> 20 17:55 5 Title: Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extension for Additional Signal Types in G.709 OTNhttp://www.ietf.org/proceedings/88/slides/slides-88-ccamp-20.pdf
Lou Berger: Those are not standard signal types. Maybe you should go for Experimental or BCP, my inclination is for Experimental. Standard track is not the right way to go for non-standard signal types.
> 22 18:08 7 Title: Network Assigned Upstream Label:http://www.ietf.org/proceedings/88/slides/slides-88-ccamp-22.pdf
Lou Berger: Problem solved in the past through allocation policy. There are networks deployed that require symmetry, saying that GMPLS prevents to do that is an overstatement.
Pavan Beeram: What I said is that we can't assume symmetry by default.
Zafar Ali: You should be more clear on requirements and link with what already exists. The alien wavelength problem is solved using the acceptable label set and there no mention of that in the document.
Pavan Beeram: The extensions are being proposed because there is not solution for the requirement. The first requirement is for the upstream node to say that I don't want to pick an upstream label. According to RFC3473 if you fill the upstream label with a value it means that you have already programmed your data plane with that particular label and you are just picking up a random label.
> 21 18:00 8 Title: RSVP Graceful Setup Procedurehttp://www.ietf.org/proceedings/88/slides/slides-88-ccamp-21.pdf
Dieter Beller: Question on 2 step approach, is there any particular use case?
Pavan Beeram: There are scenario in which the client needs to make the server LSP operational.
Himanshu Shah: How is it different from suggested label mechanisms?
Pavan Beeram: That's meant for the downstream side.
Deborah Brungard: Please take this to the list and discuss your use case.
Lou Berger: Please focus on requirements, e.g., say if it is a per network thing, a per technology thing or whatever your requirements are.
> 23 18:15 8 Title: - RSVP-TE Signaling Extension for Links with Discretely Variable Bandwidthhttp://www.ietf.org/proceedings/88/slides/slides-88-ccamp-23.pdf
Zafar Ali: Is the availability requirement coming from a Microwave link?
Amy Ye: Yes
Greg Mirsky: Availability in this case is a specific MW term we are reusing. It expresses a discrete variable bandwidth characterizing a MW link. We are used to use it for different purposes.
Lou Berger: Did you consider the loss probability expressed in TE routing extensions?
Greg Mirsky: In the specific world of microwave links it is not loss probability, they just go downshift or upshift in terms of frequency in order to maintain the quality of the link.
Lou Berger: The use of availability is a little bit confusing. It is worth saying that it does not mean availability in the sense we use it.
Himanshu Shah: It's a useful draft.
Lou Berger: Two editorial comments: 1. If you use an existing object don't copy it but just reference it, do not put them again in the draft. 2. Don't say you define a new one and then use an existing one, that's also confusing. Also, make it clear whether or not you want to use multiple bandwidths in your document.
> 24 18:23 7 Title: RSVP-TE Extensions for Bit Error Rate (BER) Measurementhttp://www.ietf.org/proceedings/88/slides/slides-88-ccamp-24.pdf
Deborah Brungard: There is no bit error rate defined for MPLS
Zhenbin: It is BER on a link
Deborah Brungard: But if you consider it between multiple LSRs it's going to be along multiple links. How does it work if there is a whole OTN network in between?
Zhenbin Li: On an IP link, not at optical layer
Deborah Brungard: There is not BER defined. The monitor is for a BER but the trigger is a degrade. You need to get aligned with the data plane aspects.
Zafar Ali: When you have a signal degrade on a link, why can't you preempt the service? You monitor the physical label and take action on signal degrade?
Zhenbin Li: For scalability reasons
Eric Osborne: If this is temporary function, how does it work with RSVP refresh? If this is a functionality always running, why not using IGP instead of RSVP?
Jon Hardwick: The error rate measurement is an OAM function. I wonder why you don't want to use already defined mechanisms of RSVP to turn on and off OAM functions and define a new one.
Lou Berger: That's a good comment and if we are going to adopt the document it must go in that way. You should also state whether this is a per interface or per LSP functionality, and address Eric's comment on the list.
> Adjourn 18:30