* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Mpls Status Pages

Multiprotocol Label Switching (Active WG)
Rtg Area: Alvaro Retana, Deborah Brungard, Martin Vigoureux | 1997-Mar-03 —  

IETF-105 mpls minutes

Session 2019-07-22 1550-1750: Viger - Audio stream - mpls chatroom
Session 2019-07-22 1810-1910: Viger - Audio stream - mpls chatroom


minutes-105-mpls-00 minutes

          MPLS WG Draft Agenda for IETF 105
          Session 1        15:50 - 17:50 ET Tuesday Afternoon Session
          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
          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
          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
          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
          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.

Generated from PyHt script /wg/mpls/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -