Agenda bashing, WG Status
chairs, 25 min (17:40, start: 17:46, end: 18:10)

Agenda bashed: Sami (ttl-tlv) appears at the end but will be today

Adrian (as P2MP MIB Editor): Thought we agreed to kill?
Loa: need to check.

[name]: for ldp-p2mp draft, I posted a comment that needs to be resolved.

Adrian as AD on Polling and Voting

Italo: Nice presentation, thank you so much. I think I know what are the poll you are referring to.
There were a lot of technical comments and a lot of people that is involved in this project
who have raised technical concerns that were not listned to. They were heard but not listened to
and there was expression of clear intention not to address the concerns That's the point.

Adrian: this is important. if people have such impression
I would like that to be raised to me with the evidence.
So either move on or bring out the issue, documented

Stewart: Would like to support my colleague

Sasha: any situation where non technical reasons should be considered?

Adrian: IETF process reasons for example


draft-kini-mpls-ring-frr-facility-backup
draft-kini-mpls-lsp-fast-alert
Sri, 15min (18:05, start: 18:11, stop: 18:25)

George: take questions on the list


draft-kompella-mpls-rsvp-ecmp
Kireeti, 8min (18:20, start: 18:26, stop: 18:35)

Kireeti presents LSP "design" attributes (ease of conf, frr, te, ecmp)
Can we have TE and ECMP?
Introduce the notion of "multi-path" LSP

Lou: we have almost exactly what you want in vcat/lcas documents.
The only problem is that it is techno specific.

Loa: please engage discussion on the list


draft-jin-mpls-mldp-leaf-discovery
Jin, 5min (18:28, start: 18:36, stop: 18:40)

draft defines a new bgp nlri, advertised in update messages
-no comments-


draft-dong-mpls-rsvp-te-plr-designation
Jie Dong, 8min (18:33, start: 18:41, stop: 18:50)

Lou: to minimize complexity, choose which solution rather than have two

Curtis: would simplify management if you reflect in IGP the nodes and links
that do not require protection


draft-kompella-mpls-entropy-label
Shane, 5min (18:41, start: 18:50, stop: 18:56)

Lucy: why ELI in stack?

Shane: when receiving incoming packet, to not misinterpret entropy label
& to make sure it is stripped off

Lucy: but egress PE does not need to understand

George: to the list


draft-boutros-mpls-lsp-ping-ttl-tlv
Sami, 8min (18:46, start: 18:56, stop: 18:59)

Italo: very difficult to use ttl for oam in certain conditions.
TTL changes in certain conditions (frr for example)

Loa: how many read?
Loa: very few, 5 or 6


draft-ietf-mpls-tp-oam-framework
Dave, 8min (18:54, start: 19:00, stop: 19:09)

Nurit: slide depicts layer violation. we said it is the mip that sends the message.

Dan: on the ttl, there is nothing you can do about it, data plane draft is in RFC Editor queue


draft-ietf-mpls-tp-oam-analysis
Nurit, 5min (19:02, start: 19:09, stop: 19:13)

Sasha: what are the plans for the doc?
Nurit: progress and publish as Informational RFC


draft-ietf-mpls-tp-fault
George, 7min (19:07, start: 19:13, stop: 19:23)

Alessandro: well done document, but a lot of options, some of them do not apply to mpls-tp
Suggest indicating which of the options apply to mpls and which to mpls-tp.

George: the draft is written to allow this

... discussion taken to the list.


draft-ietf-mpls-tp-cc-cv-rdi
Dave, 8min (19:14, start: 19:24, stop: 19:32)

Italo: draft has taken very wrong direction. I have sent comments.
I do not know what to do anymore.

Dave: may be we can get together.

Alessandro: why 2 different ways, depending on the application?

Dave: nothing prevents you from using a single mode.


update to draft-ietf-mpls-tp-cc-cv-rdi
George, 8min (19:22, start: 19:32, stop: 19:40)

-no comments/questions-


**** End of Monday Session ****


draft-boutros-mpls-tp-li-lb
Sami, 7 min (09:00, start: 09:02, stop: 09:07)

merges two drafts on same topics.
Loa: for the next steps of this draft, take it to the list


draft-ietf-mpls-tp-on-demand-cv
Eric G, 8min (09:07, start: 09:07, stop: 09:14)

replaces draft-nitinb-mpls-tp-lsp-ping-extensions


draft-ietf-mpls-tp-identifiers
George, 8min (09:15, start: 09:15, stop: 09:24)

not in LC anymore, work to be done and then again in LC


draft-he-mpls-tp-csf
Jia He, 8min (09:23, start: 09:24, stop: 09:38)

Loa: how is period negotiation being done?
Jia: client application specific

Luca: what is the layer is this supposed to serve?
Jia: pw, lsp, section
Luca: all these layers have that function already

Sasha: same comment as Luca

Jia: in the next steps we will investigate more the usage of CSF with other tools

Nurit: would be valuable to have a positioning written in the draft wrt to pw static status message


draft-ietf-mpls-tp-loss-delay
Dan, 5min (09:31, start: 09:38, stop: 09:46)

Kam: regarding time stamp format negotiation, it is more about configuration
and must not be piggybacked to the OAM packet.
Dan: we can discuss

Rahul: would like this to be applicable to mpls not only mpls-tp
Dan: there is nothing really specific for MPLS-TP in the draft
Rahul: PHP needs to be clarified as it is not clear that everything will work with PHP.
Dan: we can discuss


Eric G: you should make sure relationship with loopback is clear
Dan: yes


draft-xiao-mpls-tp-lm-counting-extension
Xiao Min, 5min (09:36, start: 09:46, stop: 09:55)

Dan: instead of defining a new protocol, suggest you get in contact with loss/delay
draft authors and oam configuration drafts authors.

Maarten: No need to do this. More complex. oam is meant to check, not to configure.
We already have network management and control plane options to configure.
I think that defining a third option is a very bad idea.


draft-xiao-mpls-tp-throughput-estimation     
Xiao Min, 8min (09:41, start: 09:56, stop: 10:03)

Jia: there is another draft solving this problem

-no more time for comments/questions-


draft-ietf-mpls-tp-linear-protection
Yaacov, 5min (09:49, start: 10:03, stop: 10:08)

Italo: 1:1 and 1:N defined by ITU in G.808.1. Not only applicable to TDM but generic
and applicable to packets as well. G.808.1 also defines (1:1)^n that is applicable only to packets.


draft-ietf-ccamp-mpls-tp-cp-framework
Lou, 8min (09:54, start: 10:09, stop: 10:16)

Eric G: [missed]
Lou: [missed]


draft-fang-mpls-tp-use-cases-and-design
draft-fang-mpls-tp-security-framework
Luyuan, 12min (10:03, start: 10:16, stop: 10:28)

Nurit: please focus on what is specific to mpls-tp

-no more time for comments/questions-


draft-farrel-mpls-tp-mib-management-overview
Scott, 5min (10:15, start: 10:29, stop: 10:33)

-no questions/comments-


draft-fang-mpls-tp-oam-considerations
Alessandro, 8min (10:20, start: 10:33, stop: 10:49)

Luyuan: RFC 5921 is the mpls-tp definition. we realize the need for deployment
but we agreed not t-mpls anymore
Alessandro: indeed. this draft is about mpls-tp

Nurit: we need to evaluate tool by tool and draft-bhh has very little information

Alessandro: need to have certain background with Y.1731 to understand draft bhh.
If required I believe the authors would agree to detail procedures.

Nurit: better to have one solution for same problem

Luca: the fact that there is deployment in china does not make it by default a standard

Yang ?: in China we have CCSA that is working on this standard.

Rahul: incorrect to say that bfd/ping is not deployed

Alessandro: If you ask for equipment that complies with the requirements you do not find anything today.

Sasha: as said on list, trace route is explicitly not covered in bhh while it is required in 5860

Alessandro: it might not cover all the requirements but it covers the essential requirements


draft-sprecher-mpls-tp-migration
Nurit, 8min (10:28, start: 10:49, stop: 10:55)

Italo: T-MPLS is not a “pre-standard”. It was approved.

Stewart: Not all Recommendations were approved.

Maarten: interoperability/interworking is very important, mpls-tp will not take over everything


draft-zulr-mpls-tp-linear-protection-switching
Italo, 8min (10:36, start: 10:55, stop: 11:05)

Nurit: to the chairs. There is a WG document.
Would like the chairs to ask the editors of this doc to provide comments to existing wg document
and stop progressing that one.

George: that would indeed be normal ietf procedure.

Italo: but the issues we raise are not resolved

Nurit: We have addressed all comments, please read the wg document

Adrian: face to face time is for technical exchanges
with regards to process, people are allowed to write drafts,
draft are progressed as wg document based on wg consensus, ...


draft-bhh-mpls-tp-oam-y1731
Italo, 8min (09:00, start: 11:05, stop: 11:30)

Luca: Italo, based on Adrian's comment please go to technical points.

Sasha: Why do you say that Link tracing is an Ethernet-specific requirement? It is mentioned in RFC 5860
Italo: Link trace is not addressing Route tracing
Sasha: what is the meaning of MEL field? Is a ME Level relevant for mpls-tp?
Italo: you can set these bits to 111 for example

[missed]: this is useful tool for mpls-tp. this should be wg document

Dave A.: mpls-tp is not Ethernet so this draft will not catch properly the issues of mpls-tp

Rahul: mpls has RFCs solving most of the requirements. What is the technical rationale
for adopting this document?

Italo: there are many issues with the existing documents

Rahul: give me an example

Italo: for example fixed rate for bfd

Maarten: Support adopting this draft as WG document

Nurit: I second Rahul

Kam: This draft exists a long time already. Support adopting this draft as WG document.

Jia: very important and urgent need to have rapid solution. This technology is mature.

Rahul: ok for strong need. what are the tools: bfd, ping and draft frost. first two implemented and deployed.
third very well specified. so we have the tools

Nurit: should stop the political/commercial discussions

Rahul: requirements are in 5860, not elsewhere.
There might be more than one technical solution but we need very strong technical justification

George: two separate tools would lead to non-interoperability
also jwt says work to be done in ietf

Italo: the draft was brought at ietf. I do not understand the jwt point

Yoshinori: fully support the adoption of the draft

Ross: George, do we have time for this discussion?
This discussion has been going on and on.
We know that it is not always possible to have the ietf adopt something that vendors have
developed

Dave A.: this is not compatible with mpls architecture.

Italo: yes it is.

Luyuan: I oppose this doc becoming a WG document

Alessandro: I support this doc as WG document


**** End of Wednesday Session ****

draft-koike-mpls-tp-temporal-hitless-psm
Yoshinori, 8min

draft-zhang-mpls-tp-path-segment-monitoring
Fei, 5min

draft-villamizar-mpls-tp-multipath
Curtis, 8min

draft-liu-mpls-tp-p2mp-share-protection
Liu, 8min

draft-flh-mpls-tp-oam-diagnostic-test
Feng, 5min

draft-rkhd-mpls-tp-sd
Rafi, 5min