MPLS WG agenda for Stockholm IETF 75th meeting Monday attendees: ~160 Wednesday attendees: ~150 --- Agenda bash / chairs / 000:340 George: I would like to make sure BFD drafts are on Wednesday Loa: an mpls-tp draft (draft-he-mpls-tp-csf-00) will be presented in PWE3 this afternoon 000. WG Status / Chairs / 005:340 Loa: Adrian, who is "External Party" in "AD Evaluation :: External Party" ? Adrian: MPLS WG is the External Party. Dependencies between documents. Adrian: on security framework draft; reviewed by Routing ADs but I am co-author should fall in hands of Security Loa: On IP Options draft; we Will discuss with ADs with regards to next steps. Rahul: on upstream drafts; they were refreshed and are ready for LC Dimitri: on resource-control; ready for LC George: php-oob draft needs a bit a clean up, but it is close Andy: on iab draft; issued a call for comment, closed June 28th please note this was similar to IETF LC. -01 released since. We allow comments to continue, will run until end of this week. open comments to ietf list, to iab only send to iab list. Any question? Italo: I disagree ... Loa: not the place, this is an IAB document, and should be discussed at the IAB plenary and the mailing list the call for comments were issued Andy: indeed Malcolm: you said LC still open. is it on 00 or 01? Andy: comments on 01 001. draft-ietf-mpls-p2mp-lsp-ping / George / 023:340 next step is to get -08 posted and would like joint LC with dsnmap Questions? Sandeep: current draft does not support mldp for multi-point trace route. Any plans for that? George: please review 08, posted on the MPLS WG list, I believe it does address it. Loa: general comments, please pay attentions to WG LCs on the lists, there will be several and docs need to be reviewed. 002.draft-lu-ldp-igp-sync-bcast-00 / Wenhu / 032:340 received comments since 74 but these did not require any change list of questions and answers summarized in the slides we ask for WG adoption Loa: we will ask authors of p2p igp to check this draft how many read the draft? (few hands) I will ask the list, then 003.draft-ietf-mpls-ldp-p2mp-07 / Ice / 038:340 few IANA allocation collisions removed mp2mp loop prevention procedures, will be a separate draft. draft stable, would like to have comments and move to LC Questions? Yakov: loop prevention mandatory or optional in mp2mp? Ice: optional Yaacov: then mp2mp is fine without loop prevention Ice: yes 004.draft-wijnands-mpls-mldp-in-band-signaling-01 / Ice / 041:340 asks for WG adoption. Questions? Yakov: The draft does not support certain modes. Draft should be crystal clear on this In present shape I do not believe ready Thomas Morin: useful extension to what we have section describes behaviour of leaves Yakov: draft says procedures out-of-scope but draft should spell out procedures or point out to drafts defining such procedures 005.draft-wijnands-mpls-mldp-csc-01 / Ice / 048:340 asks for WG adoption Questions? Yakov: draft has two parts, one in scope of this WG but another which is not, fits in L3VPN. if separation, I am fine with WG adoption George: different procedures exist, we could discuss with l3vpn chairs to have a joint wg doc. 006.draft-bishnoi-mpls-mldp-opaque-types-00 / Sandeep / 052:340 Questions? Yakov: mvpn is not the only application of mldp are you saying mvpn can only use Type 2? Sandeep: yes Yakov: why? make it optional, but not mandatory Ice: nicer to assign different encodings to different applications Yakov: here requiring to be globally unique Ice: not globally, it is per root Yakov: what difference between type 1 and type 2? Rahul: local implementation matter Ice: yes indeed but would be great if everybody uses the same. Yakov: you main concern to differentiate between static and dynamic set-up lsps? Sandeep: yes but not only Yakov: then focus on that first, not on single application per lsp Rahul: specialize the problem and make it optional George: we need SPs to tell us Thomas Morin: most of the cases you list seem to be solvable by local implementation or at the application space. Sandeep: no Thomas: ok, then please detail them George: yes, go to the list provide details and scenarios 007.draft-chen-mpls-return-path-specified-lsp-ping-00 / Mach / 068:340 Questions? George: Number of your cases are covered by Router Alert Mach: Router Alert will not always work. George: GAL/GACH is applicable to any lsp so you could use that mechanisms in need of control channel Mach: it is indeed an option George: avoid multiplicity of options George: dormant draft on inter area lsp ping, please check. Mach: this is not about mpls-tp and not only for bidir, so can not use George: I respectfully disagree 008.MPLS Global Mode / Albert John / 082:340 Questions? Yakov: This presentation was given by someone several years ago by someone having the same name than you. George: I see the value of global values we still have not figured how to implement them. Albert John: is this an implementation issue? George: no this is an architectural issue Albert John: what are the main concerns? George: please go to the list Adrian: please not that there is no internet draft, context is needed if you go to the list 009.Report from the MEAD team meeting / Loa / 092:340 Rahul: just one clarification on lsp ping, the objective is to split drafts and get in sync with George 010.draft-jenkins-mpls-tp-bt-requirements-00 / Ben / 112:340 security and easy provisioning are the focus points in addition to enhanced SLA check/verification capabilities. Questions? Rahul: really useful work these reqs apply to mpls, don't they? Ben: this is needed for existing deployed mpls network Rahul: what we do has to be applicable to mpls. Loa: we have that objective since day 1 Kireeti: what is the difference between not having an IP path but IP connectivity? Ben: no direct ip path between t-pe & s-pe no ip in t-pe to avoid jacking-in the network traffic would only impact its service Kireeti: need to catch subtleties in security section Dave Mc Dison: Will this be informational? Can not reasonably become a WG document. We should document the non-BT requirements of this draft and inject them in other appropriate drafts. Loa: would be useful if other SPs could do the same type of doc Rahul: related to Kireeti comment, will you be using IP addressing? Ben: yes Rahul: should this apply to LDP LSPs? Ben: would say yes Nurit: [missed] Kireeti: I like this document but it only reflects one SP. Good idea to do this but avoid having as many documents as SPs. Better to have one integrated document. Ben: ok, let's wait and see and have a pragmatic approach Jia: we have mpls-tp reqs and now SPs reqs for mpls-tp what is the relation? Ben: not anything new. more detailed + priority May need to clarify in document the relationship Jia: ok Ross (individual): great document, concise, well done 011.draft-ietf-mpls-tp-framework-02 / Matthew / 134:340 Questions? Nurit: relation with OAM framework? Matthew: [missed] 012.draft-ietf-mpls-tp-gach-dcn-03 / Adrian / 140:340 Questions? Igor: the draft defines an in-band control plane, is that right? Adrian: a channel for the control that travels in-band to data Igor: there is a req that says out of band George: this solution does not cancel the req 013.draft-ietf-mpls-tp-nm-req-02 / Eric / 145:340 Questions? -none- --- end of monday session --- 014.draft-ietf-mpls-tp-nm-framework-00 / Scott / 158:340 Questions? -none- 015.draft-swallow-mpls-tp-identifiers-01 / George / 162:340 TLV draft may be merged w/ this draft Nurit: these identifiers, do them impose use of control plane? George: No Questions? Nurit: not fine with definitions of MEG and MEP George: agree needs further discussion Rahul: I suggest respecting the normal procedure that is update the draft then ask for WG adoption Loa: [missed] Rahul: [missed] George: [missed] 016.draft-ietf-mpls-tp-oam-requirements-02 / Martin / xxx:340 Questions? -none- 017.draft-sprecher-mpls-tp-oam-analysis-04 / Nurit / xxx:340 Questions? Italo: I would like to see removed from the draft the bits on the wire discussion, Yang: why not just use Y.1731, it is a good solution? George: Team decision Nurit: should reuse as much as possible existing tool-set Stewart: Y.1731, good tutorial, but not best in class protocol Puneet: There are existing Y.1731 implementations, why not simply encapsulate? Stewart: There are also BFD implems out there our objective is not only for transport but also enhance mpls Rahul: we need better analysis on why Y.1731 better than enhanced ping for performance monitoring Feng: I don't agree you, OAM tools based on Y.1731 was tested and used in some network, it is proved as good one, why not use it? Nurit: Please see the draft. Feng: If BFD and LSP are extended and define some new for MPLS-TP OAM, it will be very complicated from view of PDU processing. Stewart: Y.1731 would predetermine time values 018.draft-fulignoli-mpls-tp-bfd-cv-proactive-and-rdi-01 018.draft-boutros-mpls-tp-cv-cc-00 Annamaria & Sami / 201:340 Questions? Nurit: cv includes global unique id, why do we need two different tools? Annamaria: because today bfd does only cc Nurit: could use two code points for two functions George: we reuse what exist Rahul: on timer optional & disabled negotiation; negotiation is important feature of BFD, make what exist the default! Rahul: any decision on length of identifier? Sami: will be based on George draft 019.draft-nitinb-mpls-tp-lsp-ping-bfd-procedures-00 / Rahul / 214:340 Questions? Igor: do you agree that MPLS-TP should work without control plane CV for data-plane is a must but not for control plane, they should be separated George: you can verify data-path with lsp-ping Rahul: I agree with George Kireeti: ping does more than CV George: [missed] Italo: [missed] 020.draft-bhh-mpls-tp-oam-y1731-03 / Italo / 228:340 Questions? Loa (WG chair): bad to have a long long list of authors on the ipr, been out there for a year, hope there will be no issue. Adrian: ipr applies to anybody, for all drafts. Italo: Do you prefer drafts that are not supported by a good number of people? Adrian: support is measured on mailing lists Nurit: good presentation we'll use it in the analysis Jia: suggest the thank & acknowledge people in corresponding section Eve: what is important is behaviour Nurit: doc is focused on pdu Italo: doc is describing indeed the second possibility (re-use pdu) but what is most important is functionality Stewart: I agree with 1st conclusion but I believe we should now focus on enhancing the IP based existing tools Italo: need to take into account 1731 as benchmark Malcolm: objective is to get something functionally equivalent 021.draft-boutros-mpls-tp-fault-02 / George / 248:340 Questions? -none- 022.draft-fulignoli-mpls-tp-ais-lock-tool-01 / Annamaria / 257:340 Questions? -none- 023.draft-ietf-mpls-tp-oam-framework-01 / Italo / 263:340 Questions? Martin: oam reqs will be updated so that you are not blocked (e.g. diag) 024.draft-fang-mpls-tp-security-framework-00 / Luyuan / 270:340 Questions? -none- 025.draft-abfb-mpls-tp-control-plane-framework-01 / Lou / 278:340 Questions? Nurit: on slide 2, we decided gmpls would be the cp, not mpls Igor: I did not read latest version; in previous was a req that mpls-tp cp should be interop with mpls cp. Lou: tp-reqs doc has such a requirement Igor: why such requirement anyway? Lou: in my view mpls over mpls-tp Igor: this is not interoperability Julien: some of the scenarios Igor is mentioning are covered in some ccamp doc. TP does require a CP but does not require the use of a CP 026.draft-mcwalter-mpls-tp-recovery-cp-analysis-00 / David / 287:340 Nurit: [missed] 027.draft-ietf-mpls-tp-survive-fwk-00 / Nurit / 143:340 Questions? -none- 028.draft-weingarten-mpls-tp-linear-protection-02 / Yaacov / 298:340 Albert John: APS linear protection is similar Yaacov: not sure to understand the question George: need to cut here 029.draft-weingarten-mpls-tp-ring-protection-00 / Yaacov / 304:340 Huub: I have a whole list of comments in transport networks, there is sharing I do not see it here Stewart: [missed] Italo: have you reviewed G.8132? increase linearly not squarely, should take this solution into account Nurit: we actually analyzed it Stewart: my recollection is that there was not a full solution for steering was saying for further study Huub: steering is defined in [missed] Stewart: please provide a pointer Yaacov: we'll take into account these comments Lieven: control plane considered? Yaacov: no Stewart: only first version 030.draft-dai-mpls-tp-p2mp-ring-protection-00 / Jian / 320:340 Jian, 5 min [280/340] 15:50 Questions? Loa: number of drafts on ring out there. Any overlap? Yaacov: yes Loa: please see what can be achieved then. 031.draft-ietf-mpls-tp-rosetta-stone-00 / 327:340 Huub, 5 min [285/340] 15:57 Questions? George: put definitions that do not need translation in a separate section 032.ITU-T MPLS-TP documents / Malcolm / 335:340 With ITU hat on. ongoing work on translation of IETF docs in ITU language fair number of documents at various stages one of them G8110.1 to be in shape for consent Appears not to be an easy process. Looking for more efficient ways -end of meeting- / 340:340