Skip to main content

Minutes IETF110: mpls
minutes-110-mpls-02

Meeting Minutes Multiprotocol Label Switching (mpls) WG
Title Minutes IETF110: mpls
State Active
Other versions plain text
Last updated 2021-03-19

minutes-110-mpls-02
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.