Skip to main content

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

Meeting Minutes Multiprotocol Label Switching (mpls) WG
Date and time 2014-03-06 15:20
Title Minutes for MPLS at IETF-89
State Active
Other versions plain text
Last updated 2014-03-12

minutes-89-mpls-1
*** highlights start ***
+ WG chairs need to clarify next steps for draft-ietf-mpls-tp-te-mib
+ take discussion on draft-chen-mpls-source-label-02 to the list.
+ WG Chairs to discuss with ADs the positioning of
draft-chen-mpls-source-label-02 wrt on-going work in other groups + take
discussion on draft-li-mpls-p2mp-te-alt-path-01 to the list + Clarify intended
status of draft-tsaad-mpls-p2mp-loose-path-reopt-00 +
draft-cui-mpls-tp-mfp-use-case-and-requirements-01: continue discussion on the
list and flush out requirements + WG Chairs to launch 1-week WG LC on
draft-ietf-mpls-ldp-multi-topology-11 ***  highlights  end ***

-Tuesday-

WG Status
WG Chairs, 15 min

Lou Berger: heads-up, FRR for bidirectional co-routed LSPs will be presented on
CCAMP (Friday) There will be a discussion on where does this item fits as MPLS
has designed FRR

        * Criteria for getting agenda slots
          George Swallow, 5 min (no slides)

          George highlighted the priorities according which the MPLS WG Chairs
          accept and order items on the agenda

        * MPLS WG processes
          Loa Andersson, 5 min

          -no comment/question-

draft-tiruveedhula-mpls-mldp-mib-02
Vishnu Pavan, 15 min

-no comment/question-

draft-kompella-larp-00
Kireeti Kompella, 10 min

Dan Frost: I like the work. But the problem space is much larger: general
problem of mpls-uni Are you aware of draft-ietf-mpls-gach-adv? And have you
considered using that as a potential alternative to using ARP?

Kireeti K.: no, not aware and have not considered using that for this
We selected ARP because every server has ARP. We do not want a full blown
routing protocol but something Plug and Play

Dan F. Makes sense. draft-ietf-mpls-gach-adv is super simple.
ARP is super well known. Advantage of gach is a bit more extensible add TLVs)

Kireeti K.: good point. In ARP reply, can give you label, and also metric. so
can choose between two path in case multi-home but not want more complicated
than that

Stewart Bryant: As RTG advisor to sunset4. Concerned that we use a v4 only
solution. Solution should be agnostic. The solution should work equally well
with IPv4 and IPv6. This might point to draft-ietf-mpls-gach-adv or another
solution but not to ARP.

Kireeti K.: ok

Lucy Yong: should the server implement the full mpls specifications?

Kireeti K.: no, only add a label on the way out or capable to map label to vrf
on the way in. This is not forwarding.

Lucy Y.: is it between servers or ToRs?

Kireeti K.: single label stack that I have pictured. but for scalability
you might want to have ToR-to-ToR label and server-to-server label

End of the session. Meeting adjourned by Chairs.

-Thursday-

Discussion on read-only/read-write MIBs in MPLS and specifically on
draft-ietf-mpls-tp-te-mib Benoît Claise, 15 min

A bit of history: RFC3535 contains the answers to IAB's question to operators
on MIBs. Served as base to create netconf WG. Benoît presents the IESG statement

If good reason to use SNMP set, feel free. Will never have a DISCUSS on this.
Utilities for having SNMP set: consensus of the WG, extension of write module

Take it as advice for future work. Think about NetConf/YANG.

-Questions-

George Swallow: SNMP has became to slow in getting a lot of information.

Benoît C.: SNMP if fine for 5 minute counters.
If you want to extract a lot of data/with high frequency, you can use ipfix to
push a lot of data out of devices.

Sam Aldrin: I am authors of draft that was sent back from IESG

Benoît C. was not sent back from IESG. AD review led to some questions.

Sam A.: ok

Sam A.: we are not sure what we have to do as authors of
draft-ietf-mpls-tp-te-mib. Read only or not? Read-write because the original TE
mib is read-write capable and we extend that mib People said they implemented
the write part of the TE mib. So, how should we continue?

Benoît C.: the questions you need to get answers to are:
how many vendors are going to implement this? and how many NMS are going to use
this?

Sam A.: 3 of them said yes

George S.: Others said no. We still have to reach consensus.

Benoît C.: to help in decision, knowing that this module extends another one
you should try to know how many of have implemented the original module in
read-write.

?: if implementers exist, then it would make sense to have the new module in
read-write

Sam A.: we do not have data models and so on in the charter of mpls. Is that
going to be on charter?

Ross Callon: this question does not stop us from thinking of work we should be
doing.

Sam A.: one of reason to push snmp, is that no other way (in mpls) of doing
that.

Benoît C.: we're trying to organise a hands-on session to train people to
NetConf/YANG at next IETF meeting

George S.: any other question for Benoît?
any other question on the non-consensus regarding the TE writable MIB?

Kireeti K.: I wrote a te-mib. Was read-only then became writable. considerable
amount of work. We did not implemented the writable part

Lou B.: I think it is better to ask who is using the writable module of a MIB
than who has implemented it.

draft-ankur-mpls-upstream-mapping-00
Mahesh Jethanandani, 10 min

Himanshu Shah: you said you have an issue with data path Vs control. you still
have implicit verification when going one hop further down and getting response
back or not.

George S. (hat off): lsp-ping is DP verification (it has connectivity and is
sync with CP). because you get the packet back does not mean your DP and CP are
in sync.

Himanshu S.: same issue than with downstream map

Kireeti K.: when doing downstream people are happy with ping/traceroute. The
whole thing works. We can do upstream like presented, but it is not same
paradigm. This is different than doing one hop away from egress, two hop away
from egress and so on There are thus two options to do it.

George S.: A third option: proxy-ping

Kireeti K.: could do so when you reach egress when doing downstream

George S.: state machine would be cleaner with proxy-ping

Himanshu S.: other proposals are valid, but there is value in the current
proposal as you can find the fault if DP LFIB is corrupted

Sam A.: What do you do if you receive unknown tlv at the LSR?

Mahesh J.: Good question. If you need the upmap you won't be able to validate
the next node

Sam A.: It means you thus need the whole network to support this TLV

Mahesh J.: yes

draft-ietf-karp-bfd-analysis-01
Mahesh Jethanandani, 10 min

George S.: would it be sufficient to change the MyDiscriminator to bypass the
24days limit?

Mahesh J.: yes by changing the mydiscriminator you could keep the same sequence
number

Greg Mirsky: Why is text struck out on slide 2?

Mahesh J.: this is an error

Greg M.: Do you see the need and use for authentication in mpls/pw as important
as in ip?

Mahesh J.: based on feedbacks, within one mpls domain, no real need for
authentication.

Greg M.: so limited to multi-hop bfd

Kireeti K.: can be for single or multi hop between ASBR

Kireeti K.: bfd typically kick-off by lsp-ping with discriminators exchange, so
you could do an lsp-ping to change discriminator before you reach sequence
limit. Also, regarding the figures you show, you are in fact saying that
authentication is a DoS attack on yourself

Mahesh J.: it is

Shahram Davari: any number for non meticulous?

Mahesh J.: numbers would scale pretty much the same. maybe enough for most
customers. not for DoD.

Curtis Villamizar: GTSM. Reason that you do not see any authentication
deployments with BFD. Authentication makes the problem worse and this is
something KARP as WG simply does not get

George S.: what Curtis is saying is getting bad BFD packets and trying to
authenticate them wipes you out

Mahesh J.: authentication does not come for cheap. the fact that we did not put
any crypto engine in the data-plane is a problem in itself

Curtis V.: no, that's not the solution. turn on crypto engine and your power
budget explodes. DDoS would be producing extreme amount of heat and would lead
to shutting down the forwarding chip. Very effective DoS

Mahesh J.: yes DoS gets worse with authentication, but DoS is a problem by
itself with or without authentication

Jeff Tantsura: [missed]

Kireeti K.: we should bring back evil bit for mpls

Curtis V.: What can we do for KARP to stop doing that? Karp needs to get a clue
from OPS Area. This is a matter for the WG Chairs and ADs to get this
straighten-up

draft-chen-mpls-source-label-02
Mach Chen, 10 min

George S.: segment routing work is going on.
I think we should not adopt until that work moves along to avoid having
multiple mechanisms.

George S.: how many have read? (around 20)
how many not read? (approximately the same)
out of those that have read, how many liked the idea? (a bit less)
and how many disliked? (much less than 20)

George S.: somewhat evenly divided

Mach C.: draft may be useful for segment routing but more general. no tight
relationship with segment routing

Himanshu S.: don't you have the source information in the oam packet anyway?
Also, general purpose mechanism does not mean we should apply it everywhere.

Greg M. (replying to Himanshu): the source label makes it easier to use oam in
non tp networks, where you do not use source mep tlv also there is no
requirement for the SL to be globally unique, can be unique within the LSP

Himanshu S.: has to be unique per domain for a particular PE

Greg M.: you can impose that but not mandatory

George S.: so this is not for LDP, isn't it?

Greg M.: yes you could

George M.: no, I have no idea where does traffic come from when I receive it

Shahram D.: do not like this idea. It is not 2 labels but 3 labels just to
identify the source. Do inferred loss measurement. you do not need to do
precise loss measurement

Greg M.: using source mep tlv is better, is that it?

Shahram D.: yes

Luyuan Fang: I am open to technical discussion but what if someone does not use
source routing? This should not impose source routing.

George S.: Source routing or segment routing?

Luyuan F. segment routing sorry.

Mach C.: IGP advertisement is not a must for source label

Xiaohu Xu: there is no different issue on stack depth than with entropy label

George S.: add up to it

Curtis V.: I don't like it but I think it does something useful. Applicable to
anything that is mp2p. wrt Shahram concerns. Forwarding hardware does not have
to look beyond the first label. This is oam, it will be sent off-path to
something else that will parse the remaining labels.

Mach C.: [missed]

Stewart B.: if only for OAM, why not put an ip address in the oam payload, or a
shim header?

Mach C.: this is not only for OAM.

Andy Malis: I know providers having already 4 active labels on the stack. Stack
depth is not an argument anymore not to do things and this drat enables you to
do stuff that you can not do otherwise.

Kireeti K.: regarding deep label stack, yes we need to do more, but increasing
the stack depth should not be considered lightly.

George S.: modify my statement: we will discuss with our ADs on the next steps.

Curtis V.: I thought it was only for OAM. If it is also for data packets then I
really do not like it.

Ross C.: Please continue discussion on the list

draft-li-mpls-p2mp-te-alt-path-01
Zhenbin Li, 10 min

Lou B., Curtis V., George S.: discuss on behaviour of nodes supporting or not
the alternate TSPEC, on over-provisioning, preemption, and on and whether or
not bandwidth is reserved in the data-plane.

Lou B. looks like a new way for doing over-booking.

Ross C.: Please continue discussion on the list

draft-li-mpls-global-label-framework-01
Zhenbin Li, 10 min

Curtis V.: trying to do mp2p with a global label

Zhenbin L.: yes

Curtis V.: you are loosing the characteristics of LDP

Ali Sajassi: there was a similar presentation in L2VPN
Looks like a solution looking for a problem. There are no issues in L2VPN.
Current solutions are sufficient.

Zhenbin L.: there are issues

Ali S.: issues in the past. now solved with evpn and pbb-evpn.

Ali S.: with respect to other areas that you mention, are there any issues
currently that need global label?

Zhenbin L.: several years ago there was no sdn and so separation of control and
forwarding

Ali S.: we already have solutions, so we do not have problems

Stewart B.: I do not know how you make global labels work from a practical
point of view. Idea came up in early discussion of segment routing but because
of deployed hardware decided for an offset scheme enabling global numbers in
the control plane but local labels So unless you plan on running an offset
scheme, this won't work on existing hardware.

Luyuan F.: I do not like the idea of global labels. Global IDs do not scale.
And in SDN you do not want to set global ideas neither.

Quintin Zhao: We are not getting rid of local labels, only using a range for
global labels.

Stewart B.: that is a fundamental architecture change

Curtis V.: I see no advantage and see a lot of disadvantages so unless you can
show some advantage, please put this away.

draft-tsaad-mpls-p2mp-loose-path-reopt-00
Zafar Ali, 10 min

Ross C.: who has read? fairly small number (4)
Might want to take discussion on the list

George S.: Do you need to allocate a bit?

Zafar A.: yes

George S.: what is the allocation policy?

Lou: if going forward, I think it should be PS

George (w/ chair hat on): was about to say the same thing

Zafar A.: draft has already been through the process, can we skip the steps?

George S.: draft is new, so we need to treat it same way as the other

Curtis V.: operators are reluctant to reserve twice as much bandwidth as you
need thus the success of FRR. So reserving 3 or 4 more ... Does anybody need
this?

Zafar A.: this is not about protection

Adrian Farrel: you are asking codepoints out of standard track registry so we
have to sort that out Also, look at IPR for 4736 as you build on it

draft-cui-mpls-tp-mfp-use-case-and-requirements-01
Zhenlong Cui, 10 min 17:23

?: is it for multiple simultaneous failures?

Zhenlong C.: yes

George S.: can backup path be shared?

Zhenlong C.: yes

George S.: then is m:n

Sam A.: how different from m:n with n=1? m:n is super set so why this
so why this is a separate requirement?

Himanshu S.: indeed m:n is a super set, but m:n very difficult while m:1 doable

Sam A.: we are talking requirements not solutions. What is specific in m:1 from
a requirement point of view? Except for configuration there is no new
requirements as I see. Also what do you mean when requiring shared mesh
protection? You should also consider linear and ring topologies.

Zhenlong C.: ok

Himanshu S.: Sam has a good point, we should look into it.
We are seing requirements for m:1

Rolf Winter: requirement is how to reduce cost associated with n>1

?: a document exists on SMP

Greg M.: encourage you to start with requirements and use-case as I am not
familiar with such multiple failure scenarios

Shahram D.: can m be anything?

Zhenlong C.: yes

Rolf W.: we do not want to limit m to 2. It might boil down to that
operationally, but we do not want to limit that in the solution specification

Himanshu S.: should look into what hardware and software can support

Adrian F.: draft is quite short, it should be augmented to cover what has been
talked about. Also should cover rate of failures. 1:1 as a way to simplify m:1.
I like the simplicity of looking first as linear protection.

George S.: continue on the list and flush out requirements.
Too early for show of hands.

draft-ietf-mpls-ldp-multi-topology-11
Quintin Zhao, 10 min

George S.: we'll do a short 1-week WG LC

* How to write a good RFC

  Experience feedback on document quality
  Adrian Farrel, 10 min

Adrian presented recommendations for improving MPLS WG document quality. See
slides for details.