Subject: [spring] WG: New Version Notification for draft-geib-segment-routing-oam-usecase-00.txt

From: <[email-masked]>
Date: Wed, 5 Feb 2014 11:34:42 +0100

Stewart,

the OAM use case draft has just been submitted. Comments are welcome.

I'll publish an IPR statement as soon as the tool allows me to do so.

Regards,

Ruediger

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] 
Gesendet: Mittwoch, 5. Februar 2014 10:57
An: Geib, Rüdiger; Clarence Filsfils; Geib, Rüdiger; Clarence Filsfils
Betreff: New Version Notification for draft-geib-segment-routing-oam-usecase-00.txt

A new version of I-D, draft-geib-segment-routing-oam-usecase-00.txt
has been successfully submitted by Ruediger Geib and posted to the IETF repository.

Name:		draft-geib-segment-routing-oam-usecase
Revision:	00
Title:		Use case for a scalable and topology aware MPLS data plane monitoring system
Document date:	2014-02-05
Group:		Individual Submission
Pages:		10
URL:            http://www.ietf.org/internet-drafts/draft-geib-segment-routing-oam-usecase-00.txt
Status:         https://datatracker.ietf.org/doc/draft-geib-segment-routing-oam-usecase/
Htmlized:       http://tools.ietf.org/html/draft-geib-segment-routing-oam-usecase-00

Abstract:
   This document describes features and a use case of a path monitoring
   system.  Segment based routing enables a scalable and simple method
   to monitor data plane liveliness of the complete set of paths
   belonging to a single domain.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Wed, 5 Feb 2014 16:14:57 +0000

Hi Ruediger,

I'm very much looking forward to seeing how centralized path monitoring can evolve.

What are the IP src & UDP src/dst values for monitor packets, in relation to values used in LSP ping/trace to discover ECMP?

Reason for asking is:

- If one or more nodes of the SR network is using IP based load balancing:

If we use LSP treetrace (traceroute w/ multipath info) to discover the set of entropy values (IP dst) for ECMP, then those set of entropy values are expected to exercise specific ECMP path only when used with same IP src & UDP src/dst values used in LSP treetrace ... otherwise no guarantee in exercising in specific ECMP path (i.e. load balance of transit nodes may include IP src & UDP src/dst values). Perhaps all nodes are configured to _not_ look at UDP ports for load balancing? Then, as long as monitor packets use same IP src/dst as LSP treetrace, we are good.

- If all nodes of the SR network supports Entropy Label, and if all implementations do not include IP/UDP for load balancing when EL is in the label stack, then you won't have above issue.

I think it'll be great to clarify these details in the document, since expectation is conditional on load balancing techniques used in the network.

BTW, document references draft-kumar-* and draft-kini-* of LSP Ping SR extension drafts, but we have combined them into a single draft.

http://tools.ietf.org/html/draft-kumarkini-mpls-spring-lsp-ping-00

-Nobo

> -----Original Message-----
> From: spring [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Wednesday, February 05, 2014 5:35 AM
> To: Stewart Bryant (stbryant)
> Cc: [email-masked]
> Subject: [spring] WG: New Version Notification for draft-geib-segment-
> routing-oam-usecase-00.txt
> 
> Stewart,
> 
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring

---

From: Gregory Mirsky <[email-masked]>
Date: Wed, 5 Feb 2014 21:10:14 +0000

Dear Ruediger, Nobo, others interested in SR OAM,
I think that both documents, draft-geib-segment-routing-oam-usecase- and draft-kumarkini-mpls-spring-lsp-ping-, are very useful but I have a feeling that there need to be a document that sums up requirements toward OAM in Segment Routing network. Can it be done before we have concise architectural document that describes a Segment Routing network? I believe that some requirements must be derived from draft-francois-spring-resiliency-use-case- and during its discussion.

Comments, suggestions, and offers to work on are welcome.

	Regards,
		Greg 

-----Original Message-----
From: spring [mailto:[email-masked]] On Behalf Of Nobo Akiya (nobo)
Sent: Wednesday, February 05, 2014 8:15 AM
To: [email-masked]; Stewart Bryant (stbryant)
Cc: [email-masked]
Subject: Re: [spring] New Version Notification for draft-geib-segment-routing-oam-usecase-00.txt

Hi Ruediger,

Reason for asking is:

-Nobo

---

From: <[email-masked]>
Date: Thu, 6 Feb 2014 09:17:48 +0100

Hi Nobo,

picking IP source addresses making full use of MPLS OAM treetrace capabilities is the simplest way of executing ECMP paths within MPLS networks. 

If one doesn't use MPLS OAM destination addresses, I'm not sure whether the full set of MPLS OAM capabilities can be used. There may be routers rejecting an MPLS traceroute with other IP destination addresses. I did not yet talk with network operation folks whether and which capabilities they require in the area. But I recall them having interest in learning why some packets end up in the default route for those packets which otherwise can't be routed. One should move ahead here with a clear set of requirements. Finding the path a particular packet with given IP source /dest addresses, given ports and a complete label stack executed is probably one - but that seems impossible. IP based ECMP is hardly standardised and that causes more issues, as you mention.

The entropy label and MPLS OAM with an entropy label based tree trace will solve the problem. But OAM advantages alone hardly are a sufficient motivation to migrate to such a solution, I guess.

Thanks for pointing out the combined draft. I'll incorporate that in the next version of my draft.

Regards,

Ruediger

-----Ursprüngliche Nachricht-----
Von: Nobo Akiya (nobo) [mailto:[email-masked]] 
Gesendet: Mittwoch, 5. Februar 2014 17:15
An: Geib, Rüdiger; Stewart Bryant (stbryant)
Cc: [email-masked]
Betreff: RE: New Version Notification for draft-geib-segment-routing-oam-usecase-00.txt

Hi Ruediger,

Reason for asking is:

-Nobo

---

From: <[email-masked]>
Date: Thu, 6 Feb 2014 09:29:07 +0100

Hi Greg,

sure. If you'd like to add stuff to the draft I'm editing, please be more precise. You'd of course need to convince Clarence and me, that this is an OAM use case - but otherwise: go ahead and propose some content with more details. 

Or submit your own draft in time - merging drafts is a commodity before starting architectural work.

Regards,

Ruediger

-----Ursprüngliche Nachricht-----
Von: Gregory Mirsky [mailto:[email-masked]] 
Gesendet: Mittwoch, 5. Februar 2014 22:10
An: Nobo Akiya (nobo); Geib, Rüdiger; Stewart Bryant (stbryant)
Cc: [email-masked]
Betreff: RE: New Version Notification for draft-geib-segment-routing-oam-usecase-00.txt

Dear Ruediger, Nobo, others interested in SR OAM, I think that both documents, draft-geib-segment-routing-oam-usecase- and draft-kumarkini-mpls-spring-lsp-ping-, are very useful but I have a feeling that there need to be a document that sums up requirements toward OAM in Segment Routing network. Can it be done before we have concise architectural document that describes a Segment Routing network? I believe that some requirements must be derived from draft-francois-spring-resiliency-use-case- and during its discussion.

	Regards,
		Greg 

-----Original Message-----
From: spring [mailto:[email-masked]] On Behalf Of Nobo Akiya (nobo)
Sent: Wednesday, February 05, 2014 8:15 AM
To: [email-masked]; Stewart Bryant (stbryant)
Cc: [email-masked]
Subject: Re: [spring] New Version Notification for draft-geib-segment-routing-oam-usecase-00.txt

Hi Ruediger,

Reason for asking is:

-Nobo

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Thu, 6 Feb 2014 19:48:48 +0000

Hi Ruediger, Greg,

[combining response in one]
 
> Hi Nobo,
> 
> picking IP source addresses making full use of MPLS OAM treetrace
> capabilities is the simplest way of executing ECMP paths within MPLS
> networks.
> 
> If one doesn't use MPLS OAM destination addresses, I'm not sure whether
> the full set of MPLS OAM capabilities can be used.

Exactly, we won't be able to. Hash "keys" used for discovering ECMP must be used to exercise the ECMP.
 
> There may be routers
> rejecting an MPLS traceroute with other IP destination addresses. I did not
> yet talk with network operation folks whether and which capabilities they
> require in the area. But I recall them having interest in learning why some
> packets end up in the default route for those packets which otherwise can't
> be routed.

RFC4379 requires use of 127/8/::ffff:127/8, so I'd be surprised if any other addresses can be used in MPLS echo request.

> One should move ahead here with a clear set of requirements.
> Finding the path a particular packet with given IP source /dest addresses,
> given ports and a complete label stack executed is probably one - but that
> seems impossible. IP based ECMP is hardly standardised and that causes
> more issues, as you mention.

For non-EL, two possibilities (I'm not arguing for any solution, just pointing them out).
1. If all LSRs load balanced on IP src/dst (and not ports), then using same set of IP src/dst for monitor packets should be possible.
2. Incorporate monitor packet as part of RFC4379 extension (i.e. uses same ports, 3503 dst port). Then it would be much easier to get ECMP discovery and exercise packets to traverse the same way, even if LSRs included ports.

> 
> The entropy label and MPLS OAM with an entropy label based tree trace
> will solve the problem. But OAM advantages alone hardly are a sufficient
> motivation to migrate to such a solution, I guess.

Agree. I believe details of EL on SR is still being "worked out", it'll be good to keep close watch on it.

> Dear Ruediger, Nobo, others interested in SR OAM, I think that both
> documents, draft-geib-segment-routing-oam-usecase- and draft-kumarkini-
> mpls-spring-lsp-ping-, are very useful but I have a feeling that there need to
> be a document that sums up requirements toward OAM in Segment
> Routing network. Can it be done before we have concise architectural
> document that describes a Segment Routing network? I believe that some
> requirements must be derived from draft-francois-spring-resiliency-use-
> case- and during its discussion.

I agree that having a generic use-case draft is a good idea

-Nobo

> What are the IP src & UDP src/dst values for monitor packets, in relation to
> values used in LSP ping/trace to discover ECMP?
> 
> Reason for asking is:
> 
> If we use LSP treetrace (traceroute w/ multipath info) to discover the set of
> entropy values (IP dst) for ECMP, then those set of entropy values are
> expected to exercise specific ECMP path only when used with same IP src &
> UDP src/dst values used in LSP treetrace ... otherwise no guarantee in
> exercising in specific ECMP path (i.e. load balance of transit nodes may
> include IP src & UDP src/dst values). Perhaps all nodes are configured to
> _not_ look at UDP ports for load balancing? Then, as long as monitor
> packets use same IP src/dst as LSP treetrace, we are good.
> 
> - If all nodes of the SR network supports Entropy Label, and if all
> implementations do not include IP/UDP for load balancing when EL is in the
> label stack, then you won't have above issue.
> 
> I think it'll be great to clarify these details in the document, since
> expectation is conditional on load balancing techniques used in the network.
> 
> BTW, document references draft-kumar-* and draft-kini-* of LSP Ping SR
> extension drafts, but we have combined them into a single draft.
> 
> > URL:            http://www.ietf.org/internet-drafts/draft-geib-segment-
> routing-
> > oam-usecase-00.txt

---

From: <[email-masked]>
Date: Fri, 7 Feb 2014 09:38:06 +0100

Hi Nobo,

my views in line.

Regards,

Ruediger

[Snip]

[Ruediger] >
> Finding the path a particular packet with given IP source /dest 
> addresses, given ports and a complete label stack executed is probably 
> one - but that seems impossible. IP based ECMP is hardly standardised 
> and that causes more issues, as you mention.

   [Nobo]
   For non-EL, two possibilities (I'm not arguing for any solution, 
   just pointing them out).
   1. If all LSRs load balanced on IP src/dst (and not ports), then using 
      same set of IP src/dst for monitor packets should be possible.
   2. Incorporate monitor packet as part of RFC4379 extension (i.e. uses 
      same ports, 3503 dst port). Then it would be much easier to get 
      ECMP discovery and exercise packets to traverse the same way, even 
      if LSRs included ports.

[Ruediger - being no router architecture expert]
Possibility 1. would require a standard on ECMP. It may be worth talking to 
providers, whether they'd prefer an EL based solution. Let's assume interest 
in how a packet with src/dest address and src/dest port numbers and so on 
are routed within an MPLS domain.

a) MPLS monitoring system: create an OAM packet which as a payload transports 
   the packet whose exact MPLS path is of interest. The MPLS OAM packet 
   IP address information is as specified by RFC 4379.
b) send an MPLS OAM packet to a router asking for the local label stack 
   created for that packet (including EL). This requires a suitable router 
   ICMP function, but may also be feasible via a management interface.
c) router returns the label stack to the OAM monitoring system.
d) Create RFC 4379_as_is packets to trace the MPLS path starting form the 
   router (return address is that of the MPLS Monitor). This packet should 
   be sent from the MPLS Monitor using a proper label stack.

The approach could be expanded to layer 2 packets. The benefit is applicability 
of the RFC 4379 IP addressing.

Now what is required for an "original IP source/dest" info? The MPLS traceroute 
probably neither should send an echo reply to the origin address, nor would it 
be able to (unless it is an MPLS internal address). The way out may be to 
add some payload informing the router where to send the packet. 

Another option is to work with a), b) and c) also in IP based ECMP case. Step d) 
however would work with an MPLS OAM packet similar to a) and b). Use standard MPLS 
OAM addresses to execute the particular ECMP path of the packet, but carry the IP 
addresses determining the path next hop along a traced route as payload of 
the MPLS echo request. I think in this step, MPLS OAM is preferable against 
a management based approach, as MPLS OAM could be automated. This requires 
no additional function, if b) is built anyway for SR.

Leaves us with the question, whether a) and  b) is a suitable approach. 

[snip]

---

From: "Nagendra Kumar Nainar (naikumar)" <[email-masked]>
Date: Fri, 7 Feb 2014 18:51:35 +0000

Hi Reudiger,

a) MPLS monitoring system: create an OAM packet which as a payload
transports

<Nagendra> If I got it right, the intention is to have src/dst port static
and use the dst IP range varied to exercise ECMP path?.

Now what is required for an "original IP source/dest" info? The MPLS
traceroute
probably neither should send an echo reply to the origin address, nor
would it
be able to (unless it is an MPLS internal address). The way out may be to
add some payload informing the router where to send the packet.

<Nagendra> With non loopback address carried as destination address may
have challenge in having the router look into the payload. Setting IP
TTL=1 might help the router not to forward out, but will end up dropping
and just sending ICMP TTL expired. If the router perform a check on UDP
port before punting for ICMP error generation, this may be possible else
may have some backward compatibility problem.

Thanks,
Nagendra

---

From: <[email-masked]>
Date: Mon, 10 Feb 2014 09:11:59 +0100

Hi Nagendra,

     <Nagendra> With non loopback address carried as destination address 
     may have challenge in having the router look into the payload. Setting IP
     TTL=1 might help the router not to forward out, but will end up dropping 
     and just sending ICMP TTL expired. If the router perform a check on UDP 
     port before punting for ICMP error generation, this may be possible else 
     may have some backward compatibility problem.

We'd still need to figure out where this packet should returned to. If I'd like to trace the path of an arbitrary packet in an MPLS domain, then this packet must contain all ECMP relevant fields with original information (including ports if ECMP relevant, as Nobo pointed out)

- at the label edge router in a domain applying EL.
- at all LER/LSR in a domain applying IP based ECMP.

The resulting MPLS path may be checked with a standard OAM packet containing the label stack and executing the ECMP route as the original packet would.

The problem is that LER (and LSR) need to understand what to do with that packet: consult control plane how it would be routed and return this information to an OAM system. 

Another idea may be to use a reserved label at bottom of stack to inform a router how to process that packet: If a router receives that label, above control plane and ECMP routing decision should be captured for the IP packet following the label and the result returned to a router global settable "OAM" address/port. Default would be drop, unless processing of these packets is enabled by command (to have a little security).

Would that make sense, be feasible and be worth the effort?

Regards,

Rudi

-----Ursprüngliche Nachricht-----
Von: Nagendra Kumar Nainar (naikumar) [mailto:[email-masked]] 

Hi [Rudi],

   [Rudi]

<Nagendra> If I got it right, the intention is to have src/dst port static and use the dst IP range varied to exercise ECMP path?.

     [Rudi]
     Now what is required for an "original IP source/dest" info? The MPLS traceroute 
     probably neither should send an echo reply to the origin address, nor would it 
     be able to (unless it is an MPLS internal address). The way out may be to add 
     some payload informing the router where to send the packet.

<Nagendra> With non loopback address carried as destination address may have challenge in having the router look into the payload. Setting IP
TTL=1 might help the router not to forward out, but will end up dropping and just sending ICMP TTL expired. If the router perform a check on UDP port before punting for ICMP error generation, this may be possible else may have some backward compatibility problem.

Thanks,
Nagendra