Minutes for MPLS at IETF-90
minutes-90-mpls-1

   WG status 09:00
   chairs, 15 min

Adrian (on the ldp-applicability-label-adv): I have asked the RFC editor to
move the references as Informative Loa: make sure Kamran is fine with that
Kamran: I talked to Adrian, and I am

Adrian: on mpls-in-udp. I was behind on synchronizing with OPS ADs.
I just did

Loa: any volunteers for taking up editorship of mpls-tp-1ton-protection?

Adrian (on #4012 Errata): I discussed with IANA/RFC Editor, best thing would be
to bis the RFC

   Discussion on "MPLS Architectural Principles" 09:18
   George, 30 min

Kireeti: mpls is a proactive control plane, you do not wait for
the dataplane packets to arrive

Kireeti (on the label stack): it is a lesson we do not seem to be able to
learn, we continue to have proposals with fixed 2-label stacks

Stewart: some bad ideas turn out to be good ideas

Adrian: I know of a couple of global labels, one is called IPv4, the other IPv6

Kireeti (on global labels): the fact that an entity can decide of its own
labels as opposed to being imposed to you, is very powerfull also

Ross (managing time): we are not going to reach conclusion on global labels now

Adrian: could you comment on PIDs?

Richard Li: something missing from presentation.
Basis is that MPLS is used for forwarding swap/push/pop, but MPLS is now used
for services

George: accoustics really bad, we do not have time, let's discuss this to the
list

Richard: the presentation calls for lot's of discussion

Loa: please continue the discussion on the list

Stewart: would be really usefull if that presentation was written in some form
of Informational draft

   draft-bryant-mpls-oam-udp-return-02 10:02
   Stewart, 10 min

Eric O.: did you mean 6374?
Stewart: yes

Loa: I am fine with what you ask. in fact it is the authors who do the early
allocation request to the chairs and ADs

Yaakov: in relation to previous presentation.
This is needed because LSPs are unidirectional

Greg: in IPPM you have one way measurement

   draft-mirsky-mpls-bfd-directed-00
   Greg, 10 min

Stewart: a simpler alternative, forward and return path as a single segment
list and then run bfd echo mode

Greg: idea has been discussed, but 5885 has put bfd echo out of scope
but we are looking at this

Sam: assume the return path fails

Greg: the practical way, is to establish bidrectional co-routed
and so you'll interpret a unidirectional failure as bidir deffect

Sam: but how do you make sure it is bidirectional co-routed?

[...]

Ross: take it to the list

Nobo: there is value in looking into Echo, but also for classical bfd

Loa: Label Stack Element. what do you put here?

Greg: this is the mechanism to transport it. what is placed is operator
dependant

Stewart: [...]

Tarek: have you considered a list of segment IDs rather than a list of LSEs

Greg: [...]

[?]

   draft-akiya-mpls-lsp-ping-lag-multipath-00 10:28
   Nobo, 10 min

Sam: restating comment on list

Nobo: taken into account. you'll see it in next revision

   draft-ravisingh-mpls-el-for-seamless-mpls-02 10:36
   Ravi, 10 min

Nobo: the document describes 2 different topics:
entropy labels with concatenated labels: really usefull
but the second part is really more of an optimization
Could we split?

Ravi: optimization is relevant in relation to the first part

George: we should have a wider discussion on list

Ross: [...]

   draft-vgovindan-mpls-extended-bfd-disc-tlv-00 10:43
   Prasad, 10 min

George: this should be discussed on both mpls and bfd lists

Sharam: why can't we use different discriminators?

Prasad: in bfd-mpls, if discriminator changes the session goes away

   draft-cheng-mpls-tp-shared-ring-protection-02 10:48
   Weiqiang Cheng, 15 min

Stewart: I can't fight you documenting what you have deployed in field
but this gets complicated. why do we need complex ring protections?
use routing if non trivial context

Weiqiang: from my experience it is a feasible/simple one

Eric: RFC6974; applicability of linear protection to ring
you should demonstrate why this technology is not good enough

Ross: in case we progress this as WG document, the relationship
would have to be written indeed. But on the other hand there are other means to
progress a document, especially when it documents deployed technonology: use
independent submission

Sharam: I do not view this as complex

Stewart: I agree to what Ross said.

Weiqiang: [...]

Ross: of the two possible ways to progress the document, any preference?

Weiqiang: will talk offline

   draft-ietf-mpls-rsvp-egress-protection-01 11:07
   Huaimo, 10 min

The document is stable. here is an implementation. ready for WG LC

Loa:  [...]

   draft-ietf-mpls-rsvp-ingress-protection-01 11:10
   Ravi, 10 min

Tarek: after the failure, would the p2mp tunnel fec persist?
and if it changes what are the impacts?

Huaimo: the fec will persist, as it will be used by backup ingress

Tarek: two nodes will then assume the same identify?
you should make this clear in draft

Nobo: bfd can not make distinction between node and link failure
we discussed that. thanks for taking into account that in the document

   draft-tsaad-mpls-p2mp-loose-path-reopt-02
   Tarek, 10 min

robin: [...]

George: how many have read? (few)
those that have read how many think it is usefull: (less)

George: it seems we need a bit more discussion

   draft-mirsky-mpls-residence-time-02
   Greg, 10 min

Sharam: most hardware do send packet to cpu at ttl expiry
this is a problem for your approach

Greg: the cpu to which is goes is implementation dependent

Sharam: what I meant is that the path your packet takes might now
be different from the delay request-response which does not go
to cpu

Greg: you could carry any message in the TLV so
you could acheive consistency

Yaakov: you will nevertheless impact a lot of flows

George: lot's of chips out there won't support this

Greg: then they should not advertise the capability

Yaakov: if mpls advances that draft please cross-review it in TICTOC

   draft-kompella-mpls-larp-01
   Kireeti, 10 min

Yacov: draft lacks motivation
uncomfortable with touching ARP.
Is there no other way?

Kireeti: bgp, LDP-DOD. both heavyweight and need configuration
backward compatibility section. drop unknown hardware type

Luyuan: usefull mechanism. might be good to support label stack

Ross: valuable discuss, take it to the list

   draft-li-mpls-global-label-framework-02
   Robin, 10 min

Nobo: identify the real problems rather than list what could be the uses-cases

   draft-li-mpls-seamless-mpls-mbh-00
   Robin, 10 min

Sharam: terminology on slide 12 is wrong
Network should be PW and transport should be LSP
Also, add L2

Robin: agree

   draft-raza-mpls-oam-ipv6-rao-00
   Kamran, 10 min

sharam: why do you need Router Alert at all?

Kamram: as a last resort

Adrian: please read 6398

   draft-esale-mpls-appl-aware-ldp-targeted-session-00
   Santosh Easale, 10 min

Robin: interesting and usefull
maybe another UC: mLDP node protection

Santosh: good suggestion

Kamran: [...]

Ross: we need something like this

[...]: we implemented rLFA. usefull draft

   draft-li-mpls-proxy-te-lsp-01
   Xia, 10 min

Ross: indeed solicit comments on the list and do not wait for chairs to do it

   draft-cui-mpls-tp-mfp-use-case-and-requirements-02
   Zhenlong, 10 min

Loa: why n>=m ?
I will ask question on the list

Greg: is it Informational?

Zhenlong: not a solution, just a requirement draft

Sharam: we had a case of 1:4

   draft-li-mpls-serv-driven-co-lsp-fmwk-03
   Shunwan, 10 min

Tarek: there are other ways to do bidir-corouted lsps ...
please note also a WG draft exists in ccamp

robin:  [...]

Ross: is this draft specific to rsvp-te?
if so we may need to differ this because of new WGs

Lou: I think you are right
part of this already exists, part of this is in scope of ccamp

Adrian: do not delay work because of the re-org
cross work with ccamp

Nobo: which entity decides of actions and how they happen is missing from draft

Robin:  [...]

   draft-li-ccamp-role-based-automesh-02
   Greg, 10 min

Lou: presented in mpls because AD said implementors of 4972 might
be in mpls

George: need a good application binding for these mesh groups