Skip to main content

Minutes IETF109: mpls
minutes-109-mpls-00

Meeting Minutes Multiprotocol Label Switching (mpls) WG
Title Minutes IETF109: mpls
State Active
Other versions plain text
Last updated 2020-12-07

minutes-109-mpls-00
MPLS WG minutes @IETF 109 (version 00)

Friday, November 20, 2020 (+07)
12:00-14:00 Friday Session I

1. Administrivia & WG Status
Tarek presents the WG state slides…

Regarding RMR draft:
Tarek: It’s controversial. It was in the IESG but returned back to the WG.
Loa: The chairs were discussing the state and about how to process the draft,
no conclusion yet, will keep discussing on it among the chairs, once
determined, a statement will be sent out by the chairs or doc shepherd.

Regarding the directed draft:
Tarek: It’s also controversial.It’s been lingering for a while. Nic will
arrange a conference call to discuss on how to handle it. Nic confirmed.

Regarding the andersson-mpls-iana-registries-stucture:
Loa: Discussed with IANA people, the current tool does not support one more
hierachy, will continue discuss with IANA and more people on this.

Loa: Received request to progress all SLF related drafts from the authors. That
means we need to do WGLC or WG adoption on relevant drafts. Stewart: ? Loa:
will check all SFL relevant drafts. Adrian: four people in the queue. Stewart:
two SFL drafts in the current since last IETF meeting. Loa: will handle them in
one or two weeks, they are next in line.

Kireeti: Comments about larp and nofrr. We are working on larp filling in
something(e.g., restart, robust, etc.) that we said we’d work on but have not
yet. For nofrr, we asked earlier allocation of codepoint. A response indicates
that we should make it WG doc firstly. We are working updates to address the
comments received from the mailing list. The question is: what else do we need
to do?

Tarek: According to the MPLS WG process, mpls-rt review first, and then decide
whether WG adoption will be issued. It will take weeks.

Loa: How big in terms of pages of nofrr draft?

Kireeti: 8-10 pages.

Loa:How important is the earlier allocation? Are the implementation going on?

Kireeti: Yes, we have a prototype. It’s related to microcode. It’s not just
prototype, we want to make it for real, esppeically in EVPN use case, there are
issues when the CE dies, you get a loop.

Loa: Will read the doc and speed up the process through WG chairs review
process.

Shraddha: Working an update on the inter-domain oam draft, mainly about the
iana registration stuff. The revision is done and ready for WG adoption. Trying
to give updates about the draft-ietf-mpls-epe-oam.

Tarek and Loa: Don’t hurry, it will be dicussed in the follow-up slides.

Greg: Confused by the datatraker web page that shows the p2mp-bfd draft is
marked as candidate WG adoption ?

Loa: Once start mpls-rt review or the chair starts to review a draft, we will
mark the relevant drafts as “candidate WG adoption”. It’s somehow indicates
that the draft is ready for WG adoption.

Loa:We also a TEAS RMR doc that also depends on the base RMR doc. We need to
coordinate with the TEAS WG chairs. They need to follow what we’re doing.

Loa:Asked the co-authors of osfpv3-code point draft to refresh the draft;
Nagendra:will update draft in one or two days.

Loa: Question to Stewart, what is your preference on the sequence (regarding
the draft-ietf-mpls-rfc6374-sfl and control doc)? Which one do you want to
progress firstly. Stewart Bryant: draft-ietf-mpls-rfc6374-sfl refers to the
control doc, means that you may need to progress both together. Loa: But it
will take a long to get the control doc to WGLC state from an individual draf.
May I start to do WGLC on draft-ietf-mpls-rfc6374-sfl? Stewart: Please go ahead
to do that.

2. MPLS Data Plane Encapsulation for In-situ OAM Data
https://datatracker.ietf.org/doc/draft-gandhi-mpls-ioam-sr-03

Rakesh presents the slides…

Greg Mirsky: Can you explain the interpreation of the two eSPLs? Why two eSPLs
are used for each use case? Rakesh Gandhi:they are used to indicate that there
will be iOAM data follows. Greg: But, only one eSPL for entropy label case.
Rakesh Gandhi: Try to solve the hashing issues, hence to use the iOAM and Flow
Indicator Label. Greg: You propose to allocate two eSPLs, what’s the second
eSPL use scenario? Rakesh Gandhi: Because we need two lables to identify
different types of ioam payload, can be discussed in WG mailing list. Greg:
Does it make sense to have only one label? Rakesh Gandhi: if WG thinks it is
fine, ok for me. Take the discussion to mailing list.

3. Label Switched Path (LSP) Ping/Traceroute for Segment Routing (SR) Path
Segment Identifiers (SIDs) with MPLS Data Planes
https://datatracker.ietf.org/doc/draft-xp-mpls-spring-lsp-ping-path-sid-00
Xiao Min presents the slides…

Xiang Ji: two questions, 1. Path SID is list of SIDs, how to align the FEC
stack with the label stack and do FEC check procedure? 2. We may need a type
filed in the sub-TLV to separate the type for IPv4 and IPv6. The current design
is not a good practice and not flexsible for future modifiction. It’s better to
align with other relevant RFCs (e.g., RFC8029?), not good way to use one
sub-TLV for IPv4 and IPv6, either to use two types or to differentiate the
type. Xiao Min: does not understand the question. Xiang: according RFC 8029,
the label number if the stack should match the number the FEC stack. how many
SID will be carried, just one Path SID, or carry all related labels + Path SID?
Xiao Min: later chekck the RFC8029, come back to mail. Zafar Ali: not to
complex the work to define new SID, why not just reuse the generic SID TLV,
suggest to draft-generalized oam for reference to design the sub-TLV. more
offline work together. MIN: the two drafs(Generic sub-TLV and this
draft)compliment to each other. the generalized-oam draft cannot be used to
valdiate the sync between data plane and control plane. This draft may be
needed as well. Zafar Ali: Personlly does not like the idea for validating
synchronizaiton, although it was designed at the very beginning. But anyway, we
should talk more about how to do data plane validity by using the generic lable
sub-TLV. Xiao: Let’s talk more offline. Mach Chen: What is the purpose to
validate the path segment? Xiao Min: The purpose is to check the Path SID that
is allocated to the ingress can be forwarded to the correct egress node. Then
the egress check whether the Path SID is that correct segment that’s allocated
the ingress node. Tarek: Then you can allocate it for per-policy, why per
candidate path and per segment list. Xiao Min: we follow the way defined in
draft-idr-path-segment Xiang Ji: this is more about control plane stuff, why
not just do it in control plane for validation? Min: maybe there is other
method to validate this, we will see. Cheng Li: it is valuable to do something
with path segment, will take time to chek the draft.

4. BFD for Multipoint Networks over Point-to-Multi-Point MPLS LSP
https://datatracker.ietf.org/doc/draft-mirsky-mpls-p2mp-bfd-12

Greg Mirsky presents the sldies…
No comments from the floor.

5. Egress TLV for Nil FEC in Label Switched Path Ping and Traceroute Mechanisms
https://datatracker.ietf.org/doc/draft-rathi-mpls-egress-tlv-for-nil-fec-01
Deepti N Rathi presents the slides…

Xiang Ji: conflict with SR generic FEC TLV. why not use the existing IPv4 and
IPv6 sub-TLV? how we handle the adj-SID if the last sid is not a prefix SID?
how to handle the Binding SID case? Another thinke, you have two TLVs(Egress
and FEC Stack TLV), how to align the FEC stack and Label Stack? According to
RFC8029, the number of labels and number of stacks should match, so this breaks
it. Deepti Rathi: For complete label stack, only one nil FEC is sent. Does not
make sense to send multiple nil fec. Nil label can be sent with one label or
multiple labels according to RFC 8029. Xiang: restate that the number of labels
and the number of FECs should match. Deepti: When using nil, that rule does not
need to be followed per the RFC. Xiang and Deepti keeping debate one the above
question… Tarek Saad: better to take it to ML. Zafar Ali: be good to aligh with
authors of draft-generic-fec-TLV,instead of introducing new FEC sub-TLV, why
not just reuse the sr generic sub-TLV, good to have discussion further. Deepti:
OK. Shraddha:You do not have a generic way of being able to travserse the data
path without having to validate the syn between data plane and control plane.
The SR generic sub-TLV may not work in this case. Tarek: suggest the authors of
the two drafts to dicuss further.

6. Segment Routing Generic TLV for MPLS Label Switched Path (LSP)
Ping/Traceroute Presenter: Nagendra (5 min)
https://datatracker.ietf.org/doc/draft-nainar-mpls-spring-lsp-ping-sr-generic-sid-04
Nagendra presents the udpates and asks for WG adoption Greg Mirsky: segment
must install adj SID info of the directly connected nodes? will be thousands of
neighbors. should be clearly stated and it is a tradeoff compared to the cost.
Nagendra Nainar: It’s not require to maintain all the adj sid assigned by all
the nodes, it’s only the adj sids assigned by the directly connected nodes. It
can rely on the existing IGP DB, it’s up to the implementaiotns. Xiang Ji: if
packets come from the backup interfaces, how to handle this situation? Nagendra
Nainar: haven’t thought about this. Will add some text later.

7. MPLS-based Service Function Path(SFP) Consistency Verification
https://datatracker.ietf.org/doc/draft-lm-mpls-sfc-path-verification-01

Yao Liu presents the slides...
No comments.

8. The Use of Path Segment in SR-MPLS and MPLS Interworking
https://datatracker.ietf.org/doc/draft-xiong-mpls-path-segment-sr-mpls-interworking-02

Yao Liu presents the slides...
Tarek: You will creat per-path state on the transit nodes, this is not aligh
with segment routeing that does not create per-path states on transit notes.
Yao Liu: Yes, but the states only on the border nodes, just like binding SID.
Tarrek: But Binding SID is not per-path state.

9. Export of MPLS-SR Label Type Information in IPFIX
https://datatracker.ietf.org/doc/draft-tgraf-ipfix-mpls-sr-label-05

Thomas Graf presents the slides...
Tarek: What will be left if you take SR SID out?
Thomas: just label type.
Tarek: would it provide protocol like ISIS,BGP?
Thomas: yes, that’s why the IE46 would provide, it defines which label protocol
provided the label.

10 Generic Transport Functions
https://datatracker.ietf.org/doc/draft-zzhang-tsvwg-generic-transport-functions-00

Kireeti Kompella presents the slides...
Stewart Bryant: Puting a type field in MPLS is architecture change to MPLS. We
need a proper discussion about that rather than sort of sneeaking it in. If we
separate the tyep from the fragmatentaion method, we should seriously condiser
upgrading RFC4623 to add additional field. RFC4623 is a standard way to do PW
fragmentation in this context. We should do the right thing for the mpls arch.
Kireeti: Explain more about the type field? Stewart: we have avoided having
next header in everything else we’ve done in mpls by making what follows a
function of the bottom label, now they are on the top. Kireeti: Need to
terminate the label stack to process GFH and come back to process the rest of
the stack. Just like putting a fake end of stack label in the stack. Stewart:
we need to understand what’s the consequence to do as that way. The meeting
time used up, Tarek ask to take the discussion to the list. Stewart and Kireeti
keep discussing on the mic…

End.