Subject: [Status] [status] Question on MPLS OAM presentation

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Tue, 30 Jul 2013 12:50:00 +0000

Hello Ruediger,

http://www.ietf.org/proceedings/87/slides/slides-87-status-1.pdf

I read your slides, very interesting technique. I have couple of observations around how proposal applies to Adj-SID and a general question.

O-1: There seems to be a restriction on labels which can be imposed. For example, if you have Adj-SID followed by Node-SID somewhere in imposed label stack, then mis-forwarding of Adj-SID will not be detected as nexthop (whichever it may be) will forward based on next Node-SID at that point. Packet will most likely happily "resume" the traversal.

O-2: In a scenario where imposed label stack is all Adj-SIDs, proposal provides high probability of validation on hop basis, but not at interface basis. If there are parallel links between a pair of nodes, and if Adj-SID results in forwarding on wrong interface but still reaching intended nexthop, then this doesn't appear to be detectable.

Q-1: What is the "data" following the label stack? In particular, is it IP encapsulated?

Regards,
Nobo

---

From: <[email-masked]>
Date: Tue, 30 Jul 2013 16:04:32 +0200

Hello Nobo,

my replies in order of your questions:

Q1: you are in SR solution space, while my presentation is oriented at DTs implementation (based on available protocols). I didn't yet consider all possibilities of SR and Adjacency Labels are a challenge (to me). I'd spontaneously suggest an adapted MPLS OAM to tackle Q1. After execution of the adjacency segment, the misconfiguration would be detectable then, if the last hop MPLS trace echo response indicates how the adjacency label was intended to be used.

Q2: is this an SR issue or a general MPLS issue? I.e. if there are two IFs between LDP based routers of the same metric and ECMP enabled, would MPLS OAM detect a misrouted packet? If yes, then an adaptation to SR should be possible. If no, MPLS OAM needs to be updated.

Q3: the data in DTs system is IP framed. This is required to switch between IP paths. if the Entropy Label is applied to execute ECMP paths or bundled links, then the data format doesn't matter. IP stacks are of course supported by many end systems and software to administrate and evaluate IP packets is easily available.

These ared speedy replies. Last time I've read the MPLS OAM spec is long ago. Sorry if I missed any of your points entirely.

Regards,

Ruediger

-----Original Message-----
From: Nobo Akiya (nobo) [mailto:[email-masked]]
Sent: Tuesday, July 30, 2013 2:50 PM
To: Geib, Rüdiger
Cc: [email-masked]
Subject: [status] Question on MPLS OAM presentation

Hello Ruediger,

Regards,
Nobo

---

From: <[email-masked]>
Date: Tue, 30 Jul 2013 16:10:57 +0200

Hello Nobo,

Regards,

I just see, if MPLS OAM should be felt to be inappropriate, then call it SR OAM. Just for the case that someone points out that there's no more MPLS control plane (signaling). Label cross connect tables and ECMP will be present and MPLS OAM functions shouldn't be depricated.

Ruediger

-----Original Message-----
From: Nobo Akiya (nobo) [mailto:[email-masked]]
Sent: Tuesday, July 30, 2013 2:50 PM
To: Geib, Rüdiger
Cc: [email-masked]
Subject: [status] Question on MPLS OAM presentation

Hello Ruediger,

Regards,
Nobo

---

From: Gregory Mirsky <[email-masked]>
Date: Tue, 30 Jul 2013 14:21:26 +0000

Hi Ruediger,
What unites all flavours of MPLS (Topology Driven MPLS, a.k.a. IP(LDP)/MPLS, MPLS-TE, and MPLS-TP) is common data plane even though control plane might be different or absent all together (MPLS-TP). And since MPLS OAM is function of MPLS data plane it is equally applicable to MPLS network regardless of what its control plane is (almost as you should not use IP encapsulation in MPLS-TP network that doesn't use IP addressing). 
If data plane of SR is MPLS, then, IMHO, MPLS OAM must be applicable to SR.

	Regards,
		Greg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, July 30, 2013 4:11 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Status] [status] Question on MPLS OAM presentation - add on

Hello Nobo,

Regards,

Ruediger

-----Original Message-----
From: Nobo Akiya (nobo) [mailto:[email-masked]]
Sent: Tuesday, July 30, 2013 2:50 PM
To: Geib, Rüdiger
Cc: [email-masked]
Subject: [status] Question on MPLS OAM presentation

Hello Ruediger,

Regards,
Nobo

_______________________________________________
status mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/status

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Tue, 30 Jul 2013 14:55:41 +0000

Hello Ruediger, Greg,

I see the proposal to bring interesting addition/element to MPLS OAM in SR. With that said, I agree with Greg that there's value in adapting existing MPLS OAM suites (LSP ping/trace, Seamless BFD, etc) for SR.

> Q1: you are in SR solution space, while my presentation is oriented at DTs
> implementation (based on available protocols). I didn't yet consider all
> possibilities of SR and Adjacency Labels are a challenge (to me). I'd
> spontaneously suggest an adapted MPLS OAM to tackle Q1.

Agree.

> After execution
> of the adjacency segment, the misconfiguration would be detectable then,
> if the last hop MPLS trace echo response indicates how the adjacency label
> was intended to be used.

This can be detected with "receive info" returned from a hop after Adj-SID. With LSP ping, DSMAP/DDMAP  "I" flag set can do this, as well as MPLS label verification aspect of Seamless BFD.

> Q2: is this an SR issue or a general MPLS issue? I.e. if there are two IFs
> between LDP based routers of the same metric and ECMP enabled, would
> MPLS OAM detect a misrouted packet? If yes, then an adaptation to SR
> should be possible. If no, MPLS OAM needs to be updated.

Yes it is a general MPLS issue, and IMO definition of Adj-SID (strict forwarding) generates desire for this to be detected, if forwarding goes beyond strict boundary.

> Q3: the data in DTs system is IP framed. This is required to switch between
> IP paths. if the Entropy Label is applied to execute ECMP paths or bundled
> links, then the data format doesn't matter. IP stacks are of course supported
> by many end systems and software to administrate and evaluate IP packets
> is easily available.

I see. What is the destination IP address used in the proposal?

Regards,
Nobo

> From: Gregory Mirsky [mailto:[email-masked]]
> Sent: Tuesday, July 30, 2013 10:21 AM
> To: [email-masked]; Nobo Akiya (nobo)
> Cc: [email-masked]
> Subject: RE: [status] Question on MPLS OAM presentation - add on
> 
> Hi Ruediger,
> What unites all flavours of MPLS (Topology Driven MPLS, a.k.a. IP(LDP)/MPLS,
> MPLS-TE, and MPLS-TP) is common data plane even though control plane
> might be different or absent all together (MPLS-TP). And since MPLS OAM is
> function of MPLS data plane it is equally applicable to MPLS network
> regardless of what its control plane is (almost as you should not use IP
> encapsulation in MPLS-TP network that doesn't use IP addressing).
> I just see, if MPLS OAM should be felt to be inappropriate, then call it SR
> OAM. Just for the case that someone points out that there's no more MPLS
> control plane (signaling). Label cross connect tables and ECMP will be
> present and MPLS OAM functions shouldn't be depricated.
> 
> Ruediger
> 
> 
> I read your slides, very interesting technique. I have couple of observations
> around how proposal applies to Adj-SID and a general question.
> 
> O-1: There seems to be a restriction on labels which can be imposed. For
> example, if you have Adj-SID followed by Node-SID somewhere in imposed
> label stack, then mis-forwarding of Adj-SID will not be detected as nexthop
> (whichever it may be) will forward based on next Node-SID at that point.
> Packet will most likely happily "resume" the traversal.
> 
> O-2: In a scenario where imposed label stack is all Adj-SIDs, proposal
> provides high probability of validation on hop basis, but not at interface
> basis. If there are parallel links between a pair of nodes, and if Adj-SID
> results in forwarding on wrong interface but still reaching intended nexthop,
> then this doesn't appear to be detectable.
>

---

From: <[email-masked]>
Date: Tue, 30 Jul 2013 17:06:59 +0200

Hello Nobo,

[snip]

The solution I scetched in my slides works in an ECMP enabled environment. The aim is to supervise all possible LSPs. The IP-address follows MPLS-OAM mechanisms to execute a particular path between two LERs. We'd first detect the executed path using MPLS OAM (using downstream mapping TLV, I think). Thus we determine a particular IP-address to execute the LSP we wish to monitor. Then we ping along that path.

Regards,

Ruediger

Regards,
Nobo

---

From: Gregory Mirsky <[email-masked]>
Date: Tue, 30 Jul 2013 15:08:04 +0000

Hi Ruediger, Nobo, et al.,
I'll offer my view, tagged by GIM>>, on Q2 and snip the rest. 

	Regards,
		Greg

[...]

GIM>> If ECMP in SR assumes use of EL, then MPLS OAM would not have problem to be in-band to payload. In such case we'll have MEG per EL, even if MEG is implicit. Said that I agree that we need to move to describing how MPLS-TP OAM applies to MPLS networks. There we can have SR as use case study among other scenarios.

[...]

-----Original Message-----
From: Nobo Akiya (nobo) [mailto:[email-masked]]
Sent: Tuesday, July 30, 2013 2:50 PM
To: Geib, Rüdiger
Cc: [email-masked]
Subject: [status] Question on MPLS OAM presentation

Hello Ruediger,

Regards,
Nobo