Routing Area WG (rtgwg) THURSDAY, March 25, 2010 1300-1500 Afternoon Session I Palos Verdes ===================================================== CHAIR(s): Alex Zinin John Scudder Alia Atlas (not present) Scribe: Tariq Rafique (some additional notes from John Scudder) AGENDA o Administrivia 10 minutes Chairs - Note Well - Scribe - Blue Sheets - Document Status o Composite Link Requirements 10 minutes http://www.ietf.org/id/draft-ietf-rtgwg-cl-requirement-00.txt Dave McDysan o Composite Link Framework 10 minutes http://tools.ietf.org/id/draft-so-yong-rtgwg-cl-framework-00.txt Ning So Composite Link Requirements draft-ietf-rtgwg-cl-requirement-00.txt Dave McDysan /Dave explaining Introduction and problem statements /explained changes responses to email threads for the document /comment on slide 3: does support latency but not metrics; /dave: the logic on slide 3 is out of order and maybe more tuned to verizon's implementation /first bullet needs more details /change first bullet to 'supports RSVP-TE control plane and not LDP control plane' /no metric based explicitly based on delay /dave to see the rfc on the delay and metrics for the requirements /in respone to Curtis's reply: - will address #2 - #1 is closed - slide 3: Dimitri: "There is an RFC specifying how to use the TE metric for delay. Would that address the problem?" Dave: Would like to see the spec. Action to Dimitri to send reference to mailing list. - slide 5: intent is to focus on MPLS only; IP requirements are not important but if another SP raises, dave will address IP /chair: didn't see comments on the requirements; let's figure it out before addressing it. /Curtis: should include IP, load balance issue is related to IP as well as MPLS /Rahul: should focus on MPLS now, if SP requires it only then address /Chair: let's take it to list before finalizing it - slide 6: /in response to Lou's comments on G.800 /three separate cases, not related. do they meet SPs needs. /don't include the third point - slide 7: /summary of the email from Curtis /no responses received /dave is trying to parse out the recommended changes /#1 - editorial issue for later /#2 - consider rahul's feedback /curtis: 2.1 needs to be reworded after feedback, 2.2 is not mandatory - slide 8: /2nd bullet is summary of the section 3.1 /3rd bullet - slide 9: /dave thinks the wording may not /question: top level LSP atomic or not? /dave - the framework document explains the fatpw label matters /comment - Lou B - implicit requirements to traffic and this new entity - should be implicit in the requirement document not just only framework document - slide 10: /change the wording /propose wording on the slide, reasonal text to dave - slide 11: /changes recorded from the email thread /looks ok to dave - slide 12: /dimitri will provide comments on TE - slide 13: /impact on protocols listed / help on word and organize the slide - feedback are welcome - slide 14: /text from curtis email /curtis: not sure how operator would assign labels /dave: this is local configuration but need to think about what goes in there /third bullet - make-before-break / could be accomplished by lsp stitching /chair: crossing the line in the requirement doc, it looks like an RFC - stay away from configuration /dave thinks we need to be precise but agrees with the chair - slide 15: /3rd bullet is paraphrase of curtis's comments /question: Lou - end to end LSP or CTG? refer to 3209. /dimitri - why is signaling a mandate /dave - te metric would have latency of individual link in a bundle /ning so - primary intensive when group of links together with various latency, figure out what latency to use - minimum set of requirements are considered /dimitri clarification - why is signaling is part of measuring delay on component links /lou - refer to curtis's comments and include reponses in the requirements /lou - if requirements are known, can figure out what the right protocol is; could be srlg /dave wants to have a discussion in the 3rd session /dave thinks including scenarios initially and then how these requirements fit in - slide 16: / start discussion on 3rd bullet Composite Link Framework draft-so-yong-rtgwg-cl-framework-00.txt Ning So - slide 2: /ning so explained - slide 3: /curtis: do you have to know about LSPs in control plane and below the label stack /ning so: does not know and will consult with co-authors - slide 4: - slide 5: - slide 6: - slide 7: - slide 8: /question: BW measurement and change the BW? + open comments on Ning So's document /chair: the requirement doc should focus on the definition of the problem, enough context, and describing what you are trying to achieve without saying how /chair: high priority and not so high priority requirements; need to have discussion what needs to be implemented. verizon perspective is backbone links could be expensive in some parts of the world, if BW requirements change in those areas, do not abandon the existing links if the network has mixed type of incoming traffic, TE and non-TE traffic, how to use common backbone resources mpls-tp is transport mechanism, some networks could be TDM and TP based; need to be able to utilize the networks in a broad way /chair: need to modify the requirements document and include SP's feedback. primary point is to focus on requirements, get solutions out of the doc. /lou: no requirements present for LSPs traversing multiple component links /dave: entire label stack is considered in the requirements document for scalability and better management /lou: is a flow is identified by the stack or the outer label? /dave: by the stack /lou: requirements on the data plane, ecmp, oam, pwe oam, mpls-tp oam - think about what can be reduced in the document. data plane reqs must be crisp. /chair: figure out how the network should behave. also, remember that you can use "MAY support" if the requirement is not strong. + dave /if people think TE is resolved on the links (mix of speeds) /look at TE signaling in the requirements document for a reason in the TE flow or the IP flow and then look at the data plane /break them down to solutions and requirements + Curtis /why what exists today has shortcomings - include in the document / examples are very helpful + dave / set the TE metric to latency in the requirements to address the latency issue in a composite link consisted of high latency links. / static metric setting isn't practical in long term because underlying latency can change due to grooming, etc. + ning so /if try to keep the draft too short, may lose details - what's the right length? + chair /deleting stuff is upto the authors + alex / consider rebooting the document, keep it to *requirements*. how about five pages? + ning / how about ten? + alex / how about seven? + dimitri /are we including all link between two common nodes in a bundle /ning and dave think that it is useful for the sake of the scalability in IGP but is not necessarily a MUST + curtis /link bundling has advantages if reduced information; disadvantage if information is reduced too much. /provide more specific information and more information than what goes into the link bundling /also "non-disruptive" move of LSP within bundle if conditions change /add to signaling which lsp gets distributed across the component links /if we spread the lsp across the links, no knowledge on how to do that. /curtis agreed to be a co-author of the draft. + what's the max. acceptable latency /static tdm circuit /way to determine the latency + lou /is it requirement to use the least latency link / or can this be boiled down to high/low latency? /break the doc into for types of links and then routing metric/color bits will play out in the aggregate link. + dave / really a specific value, specific objective needs to be met + lou / ... because if you can boil it down to latency clas, affinities can do this for you / point is, how generic is the doc? + dave / really specific bounds + dimitri /what are the decisions you are basing the latency measurement or TE metric /frequency of measurement of latency /precision of the measurement of latency /how LSPs are moving + Tony Li /IGP advertisements and information in advertisements /impact on the payload with IGP information / options include shove all details into IGP, precompute, set up, OR summarize into IGP, best effort signalling, fail/retry at signalling time + dave / Doing it all in IGP would be great, but concern about IGP scalability. / Network stability is important. We thought signalling based approach / would be more stable but maybe that's a "solution" and not a "requirement". / The _requirement_ is stability and scalability. + tony / You can actually shove a lot into the IGP since TE stuff is just a bag on / the side. + curtis /what's the largest micro flow you could accomodate /e.g., optical fiber with n wavelengths, packet processors could handle micro flow. / Requirement to create LSP larger than any single member link + dave / Yes, implies ability to extract micro flows that do fit within member links + chair /include the may, must, should language into the document + rahul /if ipsec ip traffic in coming, then the router may not be able to look at the labels and may not hash correctly. / sometimes just can't break down into microflows. need to capture requirement / for flows that can't be subdivided (huge flows, encrypted flows) /coordination occur in the ingress LER, translate the MPLS label stack, routers would do the right thing / from a service PoV this imposes a requirement on network edge... this is worth noting /narrow down the requirements, and focus on the right requirements to come up with the solution, and then scale the solution. take out anything that's a soft requirement -- keep it to the essentials.