* 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, Martin Vigoureux, John Scudder | 1997-Mar-03 —  
Chairs
 
 
 


IETF-110 mpls minutes

Session 2021-03-08 1300-1500: Room 5 - mpls chatroom

Minutes

minutes-110-mpls-02 minutes



          MPLS WG Draft Agenda for IETF 110 (version 00)
          
          Monday, March 8, 2021 (UTC+1)
          13:00 -15:00 Monday Session I
          
          Slides:
          https://datatracker.ietf.org/meeting/110/session/mpls/
          Codimd for Notes Taking:
          https://codimd.ietf.org/notes-ietf-110-mpls/
          Meetecho:
          http://www.meetecho.com/ietf110/mpls/
          Jabber:
          xmpp:mpls@jabber.ietf.org?join
          
          1. Administrivia & WG Status
          Speaker: WG Chairs, 10(mins)
          
          Tarek went through the WG status, no questions from the floor.
          
          2. A YANG Model for MPLS MSD
          Draft: https://datatracker.ietf.org/doc/draft-qu-mpls-mpls-msd-yang/
          Speaker: Yingzhen Qu (10 mins)
          
          Tarek: I saw there was a MSD type, is it a dataplane type?
          
          Yingzhen: It’s a MSD type, there are two types defined. One is the base
          MPLS MSD that identifies the maximum number of labels on node can read,
          the other is the ERLD-MSD.
          
          3. Egress TLV for Nil FEC in Label Switched Path Ping and Traceroute
          Mechanisms
          Draft:
          https://datatracker.ietf.org/doc/draft-rathi-mpls-egress-tlv-for-nil-fec/
          Speaker: Deepti N Rathi (10 mins)
          
          No question from the floor.
          
          Deepti requested WG adoption, Tarek said that the request recorded and
          the chairs will discuss how to make it forward.
          
          4. PMS/Head-end based MPLS Ping and Traceroute in Inter-domain SR
          Networks
          Draft:
          https://datatracker.ietf.org/doc/draft-ninan-mpls-spring-inter-domain-oam
          Speaker: Shraddha/Kapil (5 mins)
          
          Mach:RFC7110 defines a Reply Path TLV that was designed to carry the
          specified return path of echo reply. It’s better to define extensions
          based on that TLV.
          
          Kapil: I do not see that RFC yet, We can discuss it through email. This
          is designed for SR network.
          
          Greg:Have you read the spring bfd document that introduce non-FEC
          TLV and define reserve path TLV, it can apply to SR network. RFC 7110
          combined with SPRING-BFD draft cover all the cases proposed here.
          
          Kapil: This draft also covers how to dynamically construct the stack.
          
          Greg: This is informational.
          
          Kapil: Will keep discussing with Mach and Greg this through email.
          
          5. LSP Ping/Traceroute for Prefix SID in Presence of
          Multi-Algorithm/Multi- Topology Networks
          Draft: https://datatracker.ietf.org/doc/draft-iqbal-spring-mpls-ping-algo
          Speaker: Nagendra Kumar Nainar (10 mins)
          
          Tarek:Does it cover all flex-algo or just user defined one?
          Nagendra: Cover all.
          
          6. MPLS-based Service Function Path(SFP) Consistency Verification
          Draft:
          https://datatracker.ietf.org/doc/draft-lm-mpls-sfc-path-verification/
          Speaker:Yao Liu (10 mins)
          
          Nagendra: Seems that the draft is targeting to both leagcy MPLS-based
          and SR-based SFC. I don’t think that the theroy can properly work for
          SR-based SFC.My question: How does it do validation in the case SR-based
          SFC?
          
          Yao: This draft only talks about MPLS-based SFC, the SR-based SFC is
          supposed to be in another draft.
          
          Nagendra: Want some clarification on SR-based SFC.
          
          Greg: Currently, the document covers only leagcy MPLS-based SFC(RFC
          8595). The solution for SR-based SFC is open for dicussing, needs feedacks
          and suggestion from the WG.
          
          Nagendra: This draft seems cover both MPLS and SR-based SFC.
          
          Loa: Regarding slide 4, existing sub-TLVs are normally defined for both
          TLV 1 and 21, does this also apply to these new defined sub-TLVs? I will
          take it to the list.
          
          Tarek: My question is about the multiple presense of the GAL in the
          stack, the draft proposes to carry multiple GALs in the stack, but this
          is different from what GAL/gACH was defined, where the GAL must be put
          at the bottom of the stack, gGAH immediately follows GAL. Are you going
          to update this?
          
          Yao: Yes. This is required in the document, we are also considering to
          use other SPLs. More discussions needed.
          
          Tarek: Some hardware will assume the specfic bits (first nibble of gACH)
          will follow the GAL, but you draft change that. This has to be throught
          of more.
          
          Yao: OK.
          
          Adrian (from chat) If I understand this draft, the intent is to use
          TTL–>0 to detect an OAM packet?
          
          7. MPLS Data Plane Encapsulation for In-situ OAM Data
          Focus the aspects not discussed in the joint meeting
          Draft: https://datatracker.ietf.org/doc/draft-gandhi-mpls-ioam-sr/
          Speaker: Rakesh Gandhi (10 mins)
          
          Rakesh requested WG adoption and pointed out this draft will be disscussed
          in the Joint Meeting.
          
          Kireeti:I just want to give a quick pointer forward to the draft I have
          below, regarding the SPL being used in this draft, and it aapplies to a
          few other drafts presented today. I would ask people to wait for those
          slides and what the proposal is and how that changes their requests for
          SPLs.
          
          Tarek: Regarding E2E SPL, since you are going to assign new gACH type
          this iOAM meta data, why not just reuse GAL?
          
          Rakesh: The way GAL defined for egress is that it will punt the packet
          to control. In the iOAM case, the meta data carried in the data packet,
          and the data packet should be forwarded to downsteam. The GAL is mainly
          designed for OAM packet that will be terminated at the egree. That is
          what GAL was defined, there are existing implementations. Once change
          that, there will be some implication on the existing network.
          
          TakeK: OK. How to handle when GAL and the new SPL are carried in the
          same packet? What’s the order and processing of the payload of MPLS?
          
          Rakesh: GAL is carried in OAM packet, the iOAM is carried in the data
          packet. There is no scenario that GAL and iOAM will be put in the same
          packet. If there is a scenario, we can talk about it.
          
          Tarek: I do not have use case yet, I am not sure that this will never
          happen unless you explicitly state (MUST NOT) in your proposal.
          
          Rakesh: We can explictly state that GAL is meant for OAM packet and this
          iOAM is meant for data packet.
          
          Tarek: OK, we can follow up on the list.
          
          Stewart(from chat):We need to discuss the whole subject area of MPLS
          metadata before we can consider anything for WG adoption. We need build
          the full matrix of possibilities.
          
          8. Carrying Virtual Transport Network Identifier in MPLS Packet
          Draft: https://datatracker.ietf.org/doc/draft-li-mpls-enhanced-vpn-vtn-id/
          
          Speaker:Jie Dong (10 mins)
          
          Tarek: What if the transit nodes can not read beyond the end of stack? Any
          considerations about this?
          
          Jie: I think this belong to the capability advertisement, each node need
          to advertise whether it can support the capability and process the VTN
          header after the label stack. Is that what your mean?
          
          Tarek: No, my question is about readable depth. If I cannot read beyond
          the readable depth, I can not reach the VTN ID. Other solutions carry
          the slice/aggregate ID in the stack, not end of the stack. I think that
          more consideration about where to carry the identifiers are needed.
          
          Jie: There are several opitons for carrying the IDs, each has its own
          pros and cons. Place it after the stack gives more flexable to define
          the format. Agree that more discussions on each candidate are needed.
          
          Stewart: Point 1: We should add this to the long list of metadata after
          the stack, we need to determine what we can do for the community. This is
          one of the reasons for the Friday’s Joint meeting. Point 2, regarding
          the first nible (0x0010) after the stack. Based the agreement with
          the INT area AD, we will take (0x0000 and 0x0001) , and we will not
          take more; now BIER took another one. If we want to take another one,
          we need to discuss this with INT. Which one we can safely take in order
          not to make confilcts.
          
          Jie: Thanks for the useful informatin, we do not consider that yet.
          
          Jeff:Needs to consider ELD as well.
          
          Jie: Agree.
          
          9. Using Entropy Label for Network Slice Identification in MPLS networks
          Draft:
          https://datatracker.ietf.org/doc/draft-decraene-mpls-slid-encoded-entropy-label-id/
          
          Speaker: Julien Meuric (10 mins)
          
          Stewart: RFC 6090 specifies that the TTL for the EL must be zero and is
          not used for forwarding. Need to make sure that we are not derogating
          any security promomises that we made in the past.
          
          Julien: OK, I see you point, I think it’s relevant to make sure it
          will not break anything. Are there any specific issue about this?
          
          Stewart: This was about makeing sure that we didn’t get rogue packets
          in the network. That’s why it was done and it is about whether one of
          those packet could ever get loose in the network with a high TTL and go
          somewhere strange. I think it needs a much bigger consensus that it is
          safe to remove that safety feature.
          
          Junlien: OK, that’s an open issue to be tackled. Encourage to discuss
          it on the mailing list.
          
          Jie Dong: The solution can avoid the increase of label stack depth,
          while has some limitations on serval aspects(e.g., Slice ID length,
          affection to existing functioin etc.). Does there needs a way to discover
          the capabiltiy of the new introduced function for transite nodes?
          
          Julien: The processing is transparent to the nodes, it’s not necessarily
          required, and not considered in the current document, maybe needed.
          
          Jie: It’s transparent for Entropy processing, but not for network
          slicing.
          
          Julien: Yes, that may an useful information when do slice selection.
          
          Jie: Suggest to use consistent terminology when talk about the same
          function.
          
          Julien: Agree.
          
          Jeff: If you use EL for forwarding, then you change the sematic and
          behavier of the EL that is optional for load sharing, because it just
          increases the entropy. Now, if it is used for forwarding, it’s mandatory
          to be read. It needs to make sure that it will be read for all nodes
          along a path. I’d like to see these points addressed in the draft.
          
          Julien: OK, I will share this with the authors.
          
          Tarek: I don’t think that the EL will be used for forwarding, it just
          carries the slice id information.
          
          Jeff: It’s for dataplane, it needs to be imposed and read by someone. It
          needs to be imposiable and readable.
          
          Tarek: Yes, totally agree that transit node should be abel to read it
          and it should be within the readable depth for relevant nodes.
          
          Jeff: RFC8662 gave in details on how to compute lables where to insert
          it and it would be great to see it addressed in the draft.
          
          Tarek: Yes, agree.
          
          Stewart: Capabiliy advertisment needed. And needs to know what Sliceing
          wants from MPLS before defining slice identifier for MPLS.
          
          Tarek: Agree.
          
          Greg: It’s risky to reuse the TTL field of EL for non-TTL purpose,
          capability advertisement needed, more condierations and discussions
          needed.
          
          Julien: Point taken.
          
          10. Multi-purpose Special Purpose Label for Forwarding Actions
          Focus the aspects not discussed in the joint meeting
          Draft: https://datatracker.ietf.org/doc/draft-kompella-mpls-mspl4fa/
          Speaker: Kireeti Kompella (10 mins)
          
          Kireeti did not go through the whole slides, just focused on several
          slides to introduce the key idea.
          
          Stewart: First, a bit worry that you put things in the SPL, while it
          should be put in the FEC. E.g., for the NO-FRR case, it would be to send
          the origial packet on the FEC that had the property that it was not to be
          FRR, and that would be consistent with the existing MPLS Arch and without
          extensions. Second, regarding the SPL must not be at the top of the stack,
          there are some case the SPL will be at the top of the stack, eg., GAL in
          PHP LSP. Need to be careful about backwards compatibility. Athough you
          meant the new ones must not be at the top of the stack. Third, regarding
          put other bits and data in the stack. The ITU wanted to do this before,
          it was sharply reprimanded. We need to justify why we changed our minds
          on this.
          
          Kireeti: I agree that the decsion we made needs to be refunded.We have
          changed a lot of things in the forwarding path.The idea of deep stacks,
          of looking beyond the stack, etc. was difficut to do.We don’t want to
          force that decision but we’ve already gone that path. Regarding SPL
          never apear on top of stack,the SPLs do twiddle with TC and TTL fields
          should not apear on the top of the stack. We have talk to brodcom asic,
          our asic guys about this. Backwards compatibility is important.
          
          Haoyu:This is similar to existing drafts that introduce MPLS extension
          header to MPLS. Encourage the WG to re-examine our proposals as well.
          
          Kireeti: I will find that draft and read it. The idea here is that SPLs
          with data in the stack and there is data beyond the stack. Rephased what
          idea proposed in the draft.
          
          Tarek: please follow up on the list.
          
          11 . Generic Delivery Functions
          Focus the aspects not discussed in the joint meeting
          Draft:https://datatracker.ietf.org/doc/draft-zzhang-intarea-generic-delivery-functions/
          
          Speaker:Jeffrey Zhang (10 mins)
          
          Jeffery: There will be a presentation on Firday (the Joint meeting with
          PALS and other WGs). The idea is that it is not only just for MPLS,
          but for other scenarios. Please read draft and comment!
          
          Session End.
          
          



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