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

MPLS WG Status
Co-Chairs, 15 min

no comments/questions

draft-ietf-mpls-in-udp-07
Ross C., 10 min

Stewart Bryant: why do we need to say this? This is a solved problem.
David Black: self-contained documents is a virtue
Ross: it is a value to have this here.
Stewart: no intellectual value at all, just to get the document through.

Stewart: we have existing specs for MPLS over IP, including IPv6, so why a
problem here and not in existing spec? David B.: UDP go in many places where
MPLS over v6 won't

Stewart B.: anyone with PWE expertise attending the SEMI workshop?
David B.: talk to Brian Tremmel

draft-ietf-mpls-p2mp-loose-path-reopt-01 09:24
Rakesh G., 10 min

Loa: for the early allocation, it is required that you send us the request.

draft-bonica-mpls-self-ping-02 29
Ron B., 15 min

Kireeti: not only at LSP start but also when doing re-optimization
Himanshu: how come this problem has not shown up before?
Ron: LSP users now have BFD and notice the drops

Nobo: if you use BFD, it makes sure LSP is used only when bfd is up, then there
is no drop Ron: very good point, discussed in coming slides

Greg M.: works in most cases, does not help in bidir lsp contexts. how do you
tell your ingress to use the reverse direction ? Ron: no need to Greg: but you
are not verifying the reverse direction Ron: that is all I am trying to verify
Kireeti: this is definitely an approach for unidir lsp. might be worth looking
at the bidir indeed

Himanshu: can you repeat the BFD piece?
Ron: mentioned only because of customer BFD
Himanshu: why not use LER BFD?
Ron: this works when BFD is not there

Robin: how does this work?
Ron: the ingress sends an IP packet to itself through the lsp
Robin: if data plane is not ready this will fail
Ross: we are little low on time

Ron: ask to adopt as WG document
George: may be a bit a premature to ask for that

Himanshu: can you include why not use BFD at LER?
Ron: ok

draft-kompella-mpls-larp-02 42
Kireeti K., 10 min

Stewart B.: 4 bits of extensibility only?
Kireeti: if not enough we could add TLVs
Stewart B.: 4 bits does not look like scaling, we might regret this is few
weeks time

Loa: are my concerned solved wrt to WG adoption?
Kireeti: the big missing one is the "MPLS fabric", another was discussion in
the WG. I will address both.

draft-kompella-mpls-rmr-00 49
Kireeti K., 10 min

Stewart B. so there are 2 LSPs?
Kireeti: bidirectional in the RSVP sense (upstream label)

Stewart: not only node you need to deal with, need to deal with double link
failure Kireety: yes, good point. that was pointed on the list

Stewart: any danger that order of boot causes different behaviour?
Kireeti: yes, SDN having a more global view might help
Sharam: very similar to the China Mobile draft, except for the signalling, and
except that start at R0 and end at R1 Loa: there are two differences in fact:
signaling and sharing. So Kireeti you should talk to the authors about the
sharing piece. Sharam: also should we separate the data plane and control plane
part? Kireeti: value of having everything together Lou: we thought about this
topic and said, use linear protection in a given way. I'd be interested in you
saying why do we need to revisit that. Kireeti: I was one of those saying: what
is special about rings? Stewart: take a look at autonomics happening in OPS
area for nodes to join the ring Sharam: you might also need Section OAM also

draft-kini-mpls-spring-entropy-label-02 12
Jeff T., 15 min

Stewart: Is RLD per interface?
Jeff: per node
Stewart: but could be different on any interface
Jeff: agree, draft to come will discuss how permissions can be distributed

Greg: if RLD in system is 5 then you can place a label at depth of 5
Jeff: what it says is that EL should not be deeper than 5 otherwise you can not
load balance Kireeti: computation to get optimal placement of EL in stack is
non-trivial

Nobo: any idea on OAM support from this?

Carlos: algorithm sounds complex to cover all the possible cases
Kireeti: it is

Rob S.: I guess people will be looking at a network-wide minimum

Sharam: have you considered not using ELI?

   *** Friday *** 125/150

lessons learnt from discussions on draft-chen-mpls-source-label-06
Greg M., 10 min
draft-bryant-mpls-flow-ident-00
Stewart B., 10 min
discussion on what are the real problems and what is needed to solve them
all, 15 min

Kireeti: we have now more reserved labels
Stewart: yes but we need two each time now

Adrian (on implementations only supporting a few labels on the stack): there
are implems that can't push more than few labels in one go, implems that
need/want to do hash beyond BoS, and implementations that care about why there
are lots of labels George: and implementations that want/need to process many
labels

Kireeti: with entropy you cover the reach-down problem
Stewart: yes, but silicon cost

Sharam: why can't we use inferred loss measurement (ILM) ?, why do me need this
requirement? MEF says synthetic LM is mandatory, direct LM is optional.

Stewart: because we think SLM is not good enough in production networks.

draft-mirsky-mpls-bfd-directed-01
Gregory M., 10 min

Nobo: do you think we need a doc on how to use bfd on spring?
Greg: I think it is for SPRING WG to decide. But do not think segment routing
introduce any specific

Loa: Nobo are you talking about spring using MPLS data plane
George: yes

?@NEC (question for clarification): which label goes first and which is at the
bottom Greg: order of labels is defined by head-end so that no re-ordering is
required

?@NEC:
Greg: yes the procedures can be reused

draft-esale-mpls-app-aware-tldp-01
Santosh E., 10 min

Andy (as PALS): looks interesting. PALS chairs will discuss with MPLS chairs to
decide whether this is a PALS or MPLS draft Stewart: might also imply RTGWG

Kamaran: Not only a PALS, thus we came in MPLS

Stewart: not a way to delay it, just to find the right home.

draft-grmas-bfd-rfc5884-clarifications-00
Prasad G., 10 min

Nobo: to anyone who has implemented, please take look at this draft to see if
we are not breaking anything here

Loa: should we steer any following discussion on bfd or mpls list?

Prasad: last ietf it was said that all e-mail on this draft should be copied on
both list

Nobo: I'd prefer to do it in bfd, but we'll copy mpls

draft-chandra-mpls-enhanced-frr-bypass-00
Chandrasekar R., 15 min

Tarek: did you consider refresh reduction?
Chandra: yes, we say that even if we do both srefresh, and state coupling (RSVP
session, LSPs) there are still issues in the specific case of facility FRR

Tarek: usefull case you are tackling here, but it seems to me you are not
solving the scalability issue, you still have the # of LSPs Chandra: if timer
is long enough and MP knows it is MP, the PLR can take time, so it still has to
do it for the # of LSPs but it can take time to do so

Kireeti: we are giving more time
Tarek: yes you are giving more time but we should look at the real bottle necks

Robin: in case no bypass?
Chandra: you simply delete the states

draft-fang-mpls-hsdn-for-hsdc-00
Luyuan F., 10 min

Sharam: how does a single label is enough to identify the 100 millions VMs ...
Luyuan: any overlay tech is possible
Sharam: you mean VXLAN?
Luyuan: yes, here we talk about underlay

Sharam: is label global to the network?
Luyuan: yes

Robin: interesting, are you asking for adoption?
Luyuan: not yet

Loa: cutting line

Tony: global identifier across all data centers?
Luyuan: yes, but does not go to the Internet

Tony: no label swapping?
Luyuan: no

Tony: how do you distribute that much states?
Luyuan: we directly program the fib

George: but I guess you still have an IGP running
Luyuan: we do not plan on removing everything

Tony: it would be good to describe how much states need to be synchronized
across controllers, you simplify data plane but overload control Luyuan: that
is easy since this is for our network

[discuss between tony and Fabio]

Jeff: how do you load balance?
Luyuan: we hash on IP header

?: where are the ttl, exp bits?
Luyuan: this is just a representation of the 20bits

draft-chen-mpls-ldp-yang-cfg-00
draft-chen-mpls-te-yang-cfg-00
draft-gandhi-mpls-te-yang-model-01
draft-zhang-mpls-tp-yang-oam-00
Authors, 30 min

Lou: what part will be given to GMPLS
Tarek: as WG we do not cover gmpls, but I believe gmpls would augment/extend
some modules Lou: seams reasonable, but maybe we should not see gmpls as
add-ons and address both at the same time

Loa: we have generic attempts coming from above, this is bottom up; they will
meet somewhere; there is need for coordination and some work will be in TEAS
Lou: you are right for TE, but I tend to think there should be a common RSVP-TE
model I am not saying in which WG this should be driven, this is a technical
comment

Greg: we're trying to have a model for data plane common to all signalling
protocol Lou: probably but that is not my comment George: Lou is concerned that
signalling is common

Lou: since Greg brought that point, there are also some subtle differences to
capture at the data plane George: I would disagree on the "subtle"

Rakesh: we think mldp should not be part of this document, this is already the
case for MIBs; would like feedback from chairs

George: yang is more than taking MIBs and putting them in yang; also where
there is commonality, there need to be one in yang

Kireeti: to emphasize what george said: we should not redo what we done for
mibs, we should exploit hierarchy. if commonality between ucast and mcast make
it common and then split deeper in hierarchy

Yuji: [...]

Martin: share your ideas on L3VPN with BESS

Kireeti: how do we organize the YANG models for MPLS, ucast/mcast are just the
tip of the iceberg. This is not about the coordination with other groups

Lou: two important things:
1/ do not repeat the mistake we made on mibs
2/ the structure you have interleaves DP and CP, may be it should not

Matt: only vendors involved in the team, would be great to have operators

George: we need a network view

Rajiv: in context of keeping DP/CP separated, OAM might be a beast, also LIME
work going on Might need an OAM container

Nobo: agree with Rajiv OAM might be tricky, separation might be along
on-demand/continuous

Nobo: is there a list for this specific effort?

Geogre: think it would be a great idea

Ina: will this be offline?

Lou: do you think this list will be smaller than the WG? I would suggest to do
it on the mpls list George: we can start that way and figure out if it is too
much traffic compared to the rest

Jeff: you can also use rtg-yang

?: do you have profiles per interface
Tarek: yes, missing slide

draft-cui-mpls-tp-mfp-use-case-and-requirements-03
Zhenlong C., 5 min

Loa: we will start the WG adoption process