Minutes IETF105: mpls
minutes-105-mpls-00

MPLS WG Draft Agenda for IETF 105

Session 1        15:50 - 17:50 ET Tuesday Afternoon Session II
Location:        Viger

Slides:        https://datatracker.ietf.org/meeting/105/session/mpls
Etherpad:        https://etherpad.tools.ietf.org/p/notes-ietf-105-mpls
Meetecho:        http://www.meetecho.com/ietf105/mpls/
Audio stream:        http://mp3.conf.meetecho.com/ietf/ietf1053.m3u
Jabber:        xmpp:mpls@jabber.ietf.org?join

        Available post session:
Recording:        https://www.ietf.org/audio/ietf105/
YouTube:        https://www.youtube.com/user/ietf/playlists

1.      Agenda bashing, and status

Loa and Tarek introduce the current status of WG.

2.      draft-hegde-mpls-spring-epe-oam

Shraddha Hegde presents the slides.

Shraddha Hegde: Which WG should this draft be progressed, MPLS or SPRING?

Bruno Decraene(SPRING WG co-chair): There is a similar draft in SPRING WG, and
there seems an agreement to merge the two drafts. The definition of the FEC
should be discussed in SPRING. Because this draft will asked MPLS code point, I
am fine to progress this draft in MPLS WG.

Loa Andersson: Report to one WG for each meeting, technical discussion should
be in both WGs (MPLS and SPRING).No necessary to present in both WG.

Bruno Decraene: A reminder can be sent to other WG when discussing the FEC
definition or changes.

Sam Aldrin: Are you mandating that this draft depends on another draft? Is
another draft is part of the solution?

Shraddha Hegde: This draft mainly talks about the definitions of FECs. If you
are talking about e2e solution, there needs a way to send response back. We
have the next presentation to cover how to send response back to the source.

Zafar Ali: For the PeerSet SID FEC, you need to carry all the relevant
information of interfaces, there will be a lot of information, how much
parameters used as the input? There are too much. I am concern about the
complexity involved with this draft. With the current solution, one FEC for
each new defined SID, there will be a corresponding FEC sub-TLV to be defined.
This is complex.  Maybe we can just define one FEC that can cover all types of
SIDs.

Shraddha Hegde: It is not necessary for the user to input all the local/remote
interfaces information. These information is advertised by BGP-LS, there is an
entity that learns all these information and knows how to handle it.

Loa Andersson: Asked Zafar to send questions and comments to the list.

Zafar: You rely on FECs to carry the information, that's the problem...

Greg: There is a typo regarding 4/6, it should be 4/16. The local and the
remote address should be the same family, suggest to highlight that. And
Sharaddha agreed. It's better to describe how to explose all the candidate ECMP
paths.

Loa Andersson: Since time limitation, asked Greg to send comments to the list.

3.      draft-ninan-spring-mpls-inter-as-oam

Mukul Srivastava went through the
slides(https://datatracker.ietf.org/meeting/105/materials/slides-105-mpls-sessa-ietf-105-interas-oam-sr-network-00).

Greg Mirsky: There are still discussions on BFD directed draft. Which uses the
similar idea. There is another individual draft in SPRING, which uses explicit
SIDs list to carry the reverse path a BFD session.

Shraddha: Is that used for LSP Ping (Question to Greg)?

Sam: I am OK with the scenarios, but the fundamental question is how the
response gets back to the ingress, if the path broken.

Loa: Encourage Sam and the authors to continue discussion offline.

Zafar: Response to Greg's comment: this idea (specify the reverse path with
explicit SIDs stack) is OK for Ping, but may not for BFD.

4.      draft-cheng-mpls-inband-pm-encapsulation

Fengwei Qin presents the slides on behalf the authors.

Tarek Saad: SFL approach solves this.

Rakesh Gandhi: IOAM can possibly do the same thing.

Fengwei: I will let the authors to answer the questions.

5.      draft-gandhi-spring-ioam-sr-mpls

Rakesh Gandhi presents the slides on behalf the authors.

Tarek Saad: Global label is allocated in the whole network - makes it
replacement for the SPL.

Greg: Characteristic of MPLS or SR-MPLS how do you distinguish ingress.

6.      draft-xiong-mpls-path-segment-sr-mpls-interworking

Greg Mirsky presents the slides on behalf the authors.

Dhruv Dhody: Why not use binding label instead of path segment?

Tarek: Is the path segment maintained e2e?

Greg: Yes.

Rakesh: The same approach exists in another draft - encourage you to look into
it.

7.      draft-andersson-mpls-lsp-ping-registries-update

Loa Andersson presents the slides.

Kireeti: Experimental RFC required was needed at the time. Agree RFC required
is the correct one.

Greg: Some allocation (popular) make 0 and 255 reserved and not use them.

8.      draft-nainar-mpls-spring-lsp-ping-sr-generic-sid

Zafar Ali presents the slides.

Mukkul: You are trying to pack a lot of information in one thing, which I would
not agree. Adj-SID are advertised in BGP-LS.

Greg: ECMP is challenging. But how is you method?

Shraddha: Nil-FEC is there that can do the same thing.

Tarek: Generalizing is OK but not on expense of no passing enough data for the
egress to validate - in some cases, you are relying on populating the interface
mapping table from config or controller?

Zafar: very complex FECs - prefer generic FEC.

9.      draft-ietf-mpls-sfl-framework-04 and draft-ietf-mpls-rfc6374-sfl

Loa introduces the current status. Three SFL related drafts that expired
recently, the main author (Stewart) may not have enough time to continue to
progress the drafts. Stewart will introduce the status and issue. I prefer
simple solution.

Stewart: SFL framework draft is in good shape, it does need much work and could
go through to last call. The solution draft is in pretty good shape, it could
go through to WG last call except one thing. Will pick up the work next week
when I get the resource again. There are many options for control plane
solutions. George and I had a draft, it does not require to touch any of the
MPLS control planes. Someone asked the RSVP, LDP, IGP based solutions, but I
have no energy and resource to work those solutions. There are three options to
progress the work: 1) keep tag/label field as reserved for future work; 2) go
with the current control plane solution; 3) wait for others to write all
relevant control drafts.

Tarek: How about using a controller for SFL allocation?

Stewart: This solution has merit, since it does not require to touch any
control plane protocols.

Adrian: 1) All 3 are expired? yes 2) if no implementation, then why take to
WGLC?

Stewart: Some people said that want them to be published as RFCs.

Loa: No implementation for now does not mean there will be no implementations
in the future.

Stewart: I heard from people that they want RFC and they may build on it.

Ryan: Similar action is mirroring SID. I think operators would be interested...

Loa: Any idea how to proceed? I personally think we can go along with the
current simple control solution. And make it possible that it can be extensible
for different control planes.

Stewart: Will look through the drafts and make sure they match the instructions.

George Swallow: Do we have a requesting process I-D in the initial exchange? If
we did, someone may want RSVP-TE, LDP¡­, then the requirement returns back to
RSVP.

Stewart: Talk to you offline.