Minutes IETF106: mpls
minutes-106-mpls-04
| Meeting Minutes | Multiprotocol Label Switching (mpls) WG | |
|---|---|---|
| Title | Minutes IETF106: mpls | |
| State | Active | |
| Other versions | plain text | |
| Last updated | 2019-12-05 |
minutes-106-mpls-04
MPLS WG Draft Agenda for IETF 106
Version: Nov 14, 2019
15:50 - 17:50 Monday Afternoon Session II
Location: Sophia
Slides: https://datatracker.ietf.org/meeting/106/session/mpls
Etherpad: https://etherpad.ietf.org/p/notes-ietf-106-mpls
Meetecho: http://www.meetecho.com/ietf106/mpls/
Audio stream: http://mp3.conf.meetecho.com/ietf/ietf1062.m3u
Jabber: xmpp:mpls@jabber.ietf.org?join
Available post session:
Recording: https://www.ietf.org/audio/ietf106/
YouTube: https://www.youtube.com/user/ietf/playlists
1. Agenda bashing, and status report
Stewart: SFL-ctrl draft is waiting for response from the co-authors, will
notify the WG once there are any progress.
About RMR draft
Deborah: The RMR LC finished, they authors need to respond to the Directorate
review comments, a bunch of comments need to be addressed bore the IESG
telechat.
Kreeti: Comments are mainly from security director, not difficult to address,
will address the comments soon.
SFL drafts:
Tarek: IPR poll is ongoing, will remind the co-authors and contributors to
reply the IPR poll.
2. The Use of Path Segment in SR-MPLS and MPLS Interworking
Rakesh: The Path Segment is already a SPRING WG document, what's the new here?
Is it intended to be an informational or standard track? Not clear to me.
Quan: Path segment is used to identify a tunnel, and use Path Segment for
stitching instead of using the binding SID. We think Binding SID is not
appropriate for the stitching model.
Loa: Please coordinate with the relevant authors to have a discussion during
the week and report back to the WG mailing list.
Weiqiang: It can support bidirectional stitching, it's useful for some operator
who have deployed path segment, with that it's convenient for them to perform
e2e monitoring.
Rakesh: We will talk more during the week, but the binding SID itself would
contain the label stack as well as the path segment, so the stitching really
happens between path segments and binding SID, but path segment here and path
segment there kind of thing.
Druv: The path segment is defined for path identification, now the draft tries
to use it for stitching, that is the crux of the argument. The path segment has
its own meaning. Using path segment for stitching that has already been done by
binding SID confuses me.
Rakesh: Regarding the bidirectional LSP, the draft does not bring anything new,
which has already been there in the path segment draft.
Quan: Thank you, will do further offline discussions with you.
3. Performance Measurement for Segment Routing Networks with MPLS Data Plane
Greg: How is this proposed return-path TLV different from the non-FEC TLV
proposed in BFD for SPRING? Because it proposes to use explicit segment list
for return path for BFD session.
Rakesh: The probe messages are crafted in the Query node with the TLV in the
payload, when this is saw, it has a choice, without this TLV, it would send a
reply out of band, through the IP UDP path.
Greg: I understand the mechanics, I'm asking how this is different from what's
proposed in BFD draft for SPRING.
Rakesh: There are many return path TLVs proposed for LSP Ping, or the BFD for
SPRING. The intent is the same, but we need the IANA code points for 6374 TLVs.
Greg: It's already proposed, so why not reference it and just use one construct
for BFD and PM.
Rakesh: Yes, it's the same construct according to you feedback, the reason why
is here is that we need to get all necessary code points listed in the 6374
types.
Stewart: We do need a way to ask for an allocation for this TLV.
Greg: You say that the block number is for alternate marking method with the
SFL?
Rakesh: How to mark/color is beyond the scope of this draft, the draft is for
the probe messages and it carries counters and it needs to identify the context
of the counter to see which block number it belongs to, that's what this TLV is
for.
Greg: So, this is not for alternate marking method?
Rakesh: Alternate Marking can by implemented by SFL or any other mechanisms,
outside the scope of this document. This draft is major for carrying the
measurement counters and relevant contexts, hence to correlate the counters and
the block numbers.
Loa: Please take the discussions to the mailing list.
Sam: How do you know you are actually getting the response from the right node?
Rakesh: RFC6374 does have a source address TLV.
Sam: In some cases, you may not know who is responding from the source?
Rakesh: Give an example to show how the source Address TLV can address Sam
question.
Sam: You are really based on the source address TLV?
Rakesh: Yes, it's already defined in RFC6374 for this purpose.
Sam: OK, I see.
Tarek: For ECMP case, you can't exercise all candidate paths, you responded
that you need entropy label. I want to know whether the Entropy Label is a MUST
in this case, because you can't not depend on other fields to do the hash, if
so, why not mention it in the draft?
Rakesh: It's already in the draft, not mention in this slides.
Stewart: 6374 and SFL draft talks a lot about this, a reference to them would
be good.
Rakesh: It's already in the draft.
4. Segment Routing with MPLS Data Plane Encapsulation for In-situ OAM Data
Adrian: You are asking for 4 new labels? That worries me, we have only got
eight currently free. An option is to use extended special purpose label, is it?
Rakesh: Yes, it is eSPL.
Adrian: Then, could you please redraw the picture to show that eSPL is used?
Rakesh: Sure.
5. Encapsulation For MPLS Performance Measurement with Alternate Marking Method
Weiqiang: Got some comments before the meeting, will update the draft
accordingly in the next version.
Stewart: You expect to the parser to look up two labels, this was discussed
extensively when we were looking at the T-MPLS OAM design. The conclusion of
this WG was that that did not conform to the MPLS architecture, the solution
was rejected in the past. You want to use wide domain label and specify the
same label has to be recognized by any node along the path. This is the area
that the SR people explored in depth and discovered that it actually was
impossible, because that different platforms have different range of labels,
which is why they have the complexity of the SR global label base. How is that
possible that we standardize a solution here that another WG has explored in
detailed and decided it's impossible to do implement on the deployed devices.
It's a violation of the MPLS architecture. The redefinition of the TTL is the
major architectural change, you cannot redefine the TTL. I have no idea about
the redefinition of the TC field. The DetNet work may want to use the TC bit
for their usage. In addition, it suggests to use eSPL, for, it's not sure
whether the SPL is worth to be allocated for this purpose. Finally, you need to
consider more about the security and privacy issues.
Weiqiang: Your comments are valuable and we totally agree with your comments.
We'll follow the MPLS principle. The TC field can be used by operators for
whatever purposes, for example, alternate marking.
Rakesh: This issue is already addressed by iOAM solution.
Weiqiang: No.
Greg: Will respond to the mailing list to explain why this issue is not
addressed by iOAM.
6. Updating the IANA MPLS LSP Ping Parameters
Loa presents the updates to the draft.
No comments from the floor.
7. Segment Routing Generic TLV for MPLS Label Switched Path (LSP)
Ping/Traceroute
Zafar presents the solution and updates.
Chris: A question about the Procedure page, if you add a link between 6 and 8,
how do you differentiate the request is from Node 7 or Node 6? There may be
some situations that the Node 8 cannot tell the difference with this scheme.
Zafar: Agree with the issue raised by Chris
Chris: So, it's a sort of a least common denominator approach to validate the
forwarding plane, so it kind of works in most of the situations but does not
work in some situations.
Zafar: You should have the label cache, for adjacency SID, not prefix SID,
advertised by the neighbor, those things should be there.
Chris: This seems to be a lot of the work goes into getting the forwarding
validation correct and this is sort of simplifying the control plane
validation, but that's actually not the hard part to do, so it seems like that
we're going through the trouble of this we should do it as robustly as possible
and not sort of a least common denominator approach.
Zafar: There are two approaches, this one (a little bit approach) and the
interface based approach where you can bound a specific interface on which you
should be receiving or a set of interfaces, but you are not concerned with like
which IGP allocates this, OSPF or ISIS, you are not concerned with those parts,
you're concerned with: this is the behavior from one in generating a ping that
you should be receiving on this interface is my forwarding plane is working
correctly. My point here is that we can define a FEC type that works in the
cases that you mentioned, which is rather than having the owners on node 8 to
do this of generating of this table that can be used to verify if I receive
this packet correctly. Which also means rather than having the agency SID in
the effect, we can have the label, the interface information of it as the end
point on which it should receive against that label stack.
Chris: It seems that we are defining two approaches for the worst cases? It's a
least common denominator approach, it needs more work to do, more testing. So,
I disagree with your initial statement. Existing approach works robustly and is
a better discipline, we could simply solve that problem.
Zafar: The problem is not about defining FEC, but also to get those parameter
fill in by an ingress node. Ability for an ingress node to grab all those
parameters to be able to send in the Ping message is not possible as always and
a lot of time you have to spend. And there is a draft in the agenda will shows
that. You have to get the information from the control plane and it is not a
good way for a human to enter all those parameters/information, sometime it's
not possible.
Tarek: I have sent a comment to the mailing list and encourage you to respond.
Here is another one. The label collision can happen on node 8, you have
multiple SR FECs correlate to the same label, and there is a SPRING draft that
handle such collisions. Now for the egress to do validation, the label is valid
and it will pick one of the FECs and bind to that label, but the ingress may
think it is validating a different FEC. So, unless the ingress fails the SR FEC
that is trying to validate it, it does not know what it's trying to validate,
it will see that it's a valid label but it may not be the correct valid label
that the ingress wants to validate. So, your approach has some holes.
Zafar: This approach focuses on the interface information rather than the label.
Shraddha: Regarding the information/parameters, it's very simple to collect the
whole topology and those information by IGP, and you know what each label means.
Zafar: You take the information from control plane and validate that
information on the node. The whole point is control plane vs. data plane
validation procedures get lost.
8. OSPFv3 CodePoint for MPLS LSP Ping
Loa: There is an existing code point for ospf, do you want to use it for
OSPFv2? If so, the registry name should be changed.
Carlos: The existing code point is not used in the deployment. We can rename
the existing one to OSPFv2 or with a more secure way to define two new code
points, one for v2, the other for v3. We can do either way.
Loa: I will take the safe way out and absolete the current code point, and add
two new code points: one for v2, the other for v3.
Carlos: Tend to agree with the two new code points way.
Tarek: Clarification question, OSPFv3 is specific to IPv6, why not rely on the
AFI on the message.
Carlos: No such a thing at all.
9. Overview updates of all MPLS YANG documents
Tarek present the overall updates of all MPLS YANG documents.
No comments from the floor.
10. Label Switched Path (LSP) Ping/Traceroute for Segment Routing (SR) Egress
Peer engineering Segment Identifiers (SIDs) with MPLS Data Planes
Zafar: Comments on the last second page, this (the Target FEC stack
definitions) is getting much more complex, we need to get simplification. The
amount of information is a burden on ingress and egress. You are trying to get
these information from the control plane to validate the forwarding behavior.
This is too complex, we need to find an easier way. We'd like to work with the
authors of this draft to find a simpler way, and we believe that there would be
one.
Shraddha: We already have a robust mechanism that works very well for so many
years. The generic solution is not going to be that robust and it might falsely
detect something, and sometime it may not even work.
Zafar: Insist on his simplify idea.
Chris: Comment on Zafar's simplify idea, given that those existing FECs have
been implemented, interoperability tested, deployed, I would strongly object to
define a second version of those for the same purposes. I see no reasons to do
that for the IGPs. And Shraddha agree.
Zafar: Repeat the simplify idea and the complex on the existing approach.
11. PMS/Head-end based MPLS Ping and Traceroute in Inter-AS SR Networks
Shraddha: Present the updates and ask for WG adoption.
Loa: For the EPE and the Inter-AS draft, which one is more close to WG adoption?
Shraddha: The EPE draft is closer, but I think we could accept both as WG
documents.
Greg: You introduced three family of SIDs: MPLS, IPv4 and IPv6, can you
envision that more than one families will be used in the return path?
Shraddha: I need to think more about that why if somebody would do that, but I
definitely think that IPv4 address and the SID is a very valid use case,
because SRGB just assigning the labels doesn't work.
Greg: If that is the case, I think that there should be some illustrations when
it will be helpful. Otherwise, the introduction of sub-TLVs creates an
overhead without good reason.
Shraddha: Sure, I'll add explanation to that.
12. LDP behavior on link-shut scenarios
Anush present the slides.
Chris: Clarification question, is this some like remote LFA? is there a target
LDP session involved here?
Anush: The session between the Node A and B is direct link LDP session.
Chris: Do you worry about the backup LDP going down or just the primary
neighbor session? I want to make sure that was the tLDP wasn't involved. Anush
agree.
Stephane: Is the link down event detected locally or received from a neighbor?
Anush: It's a local detection.
Stephane: Before, you may have received LSP from A. You don't have to wait for
B to detect the link locally. If B can receive LSP from A, you can also
converge, because you don't have any more connectivity.
Anush: "Bi" (bi-directional?) here means LDP at B, the events are seen from t1
to t4 by LDP.
Stephane: When you say that B remove LSP, do you assume that B is running order
control of LDP or independent?
Anush: It's order control.
Kamran: I think the problem statement is in the context of GR, right?
Anush: Yes.
Kamran: You draft recommend to update RFC5036, if this is a GR issue, it should
update the GR procedures rather than the LDP base procedures. Second comment,
rather than blocking sending of the shutdown messages, if you look at LDP
RFC5036, if you send a shutdown message, you can also send an extended status
TLV. That can give extra information to the receiver.
Anush: We're not recommending blocking shutdown messages, but I'm open to
suggestions so whatever you suggested.
Kamran: That's is different from what I read from the draft.
Tarek: I think one of the possible solutions you're presenting is to wait until
the hello's time out on their adjacency and then react and flush the labels,
remote labels that B will get from A. You delay flushing the labels on B until
the Hello times out. Right?
Anush: No, hello times out and when you tear down the session, but you haven't
received shutdown message yet. So you won't flush the label mapping if GR is
enabled.
Tarek: You are concerned about two cases, on is reacting on link down, and
another is reacting on a shutdown message. Anush agree. If you delay the action
until the hello times out for both your solutions, right? Anush agree. I think
RFC5036 does mention that, we might want to reread that text and see if they're
recommending waiting for the hellos to time out before taking action.
Anush: This was seen in a customer side, and our reading was while it suggests
that it's a critieria of bringing down session. It keeps options open to the
implementations. We can discuss more about it.
End of the session.