Subject: RE: Latest MPLS Ping draft...

From: "Brian Hassink" <[email-masked]>
Date: Tue, 15 Oct 2002 15:00:47 -0400

Whoops, one other comment...

I noticed there is no checksum field in the main header. Should it be called out that there is an assumption that the underlying transport (which is UDP for the request and two of the reply modes) will ensure the integrity of the MPLS ping packet? Could there ever be a reply-mode where this isn't the case?

Cheers,
Brian
---
[email-masked]

-----Original Message-----
From: Brian Hassink 
Sent: Tuesday, October 15, 2002 2:45 PM
To: [email-masked]
Subject: Latest MPLS Ping draft...

Hello,

A few thoughts/suggestions/questions on the latest MPLS Ping draft...

I'm wondering if it wouldn't be better to move the return code from the main header to the TLV header, or add a return code to the TLV header? I think there may be a couple of good reasons for doing this...

o As more message types and TLV types are defined, more return codes will be required, possibly leading to overloaded meanings and a loss of scope.
o If multiple TLVs are bundled in a request, a single return code may not be sufficient to return the full results of the request.

I think the return code in the main header could be used for more general results, such as "no error", "unsupported version", "malformed request", "reply too big", etc, and the return code in the TLV header could be used for results specific to that TLV.

Also, couldn't a (optional) "timestamp" TLV be defined rather than having this information as mandatory fields in the main header?

Lastly, it's not clear to me which FEC applies to a tunnel that has been setup manually (i.e. static tunnels)?

Cheers,
Brian
---
[email-masked]

---

From: "Markus Hennig" <[email-masked]>
Date: Wed, 16 Oct 2002 12:38:54 +0200

Hello all,

my 2c to the lsp-ping-01 draft:

What about target FEC types with more then the defined IPv[4|6] prefix 
(for example the prefix and(!) source and destination IPv[4|6] ports, 
maybe also a tcp/udp flag)?

I wonder why this isn't a point of discussion at all...

Markus

---

From: "David Allan" <[email-masked]>
Date: Wed, 16 Oct 2002 16:14:59 -0400

Apologies for the format of the last post....

Hi:

There were a comment I raised previously that was not addressed...

section 4.5: Non-compliant routers. In general the topic of TTL came up
earlier, as there is no explicit mention of that happens when testing a path
that uses the uniform instead of the pipe model. Consistent with the
expectation of non-compliant routers, shouldn't any LSP PING request that
TTL exhausts and is not payload of the top label simply be discarded. If
agreement breaks out, this should be documented.

And some new questions:

Section 2: Motivations: A bit more discussion of what consistutes a
"reasonable time" and what factors affect this would be useful. In some
applications such as LDP/ECMP etc. detection time would appear to be in
proportion to network diameter.

Section 3: When discussing "no reply" processing, the suggestion is that the
egress router may track sequence numbers etc. This looks rather optimistic
and is not exactly consistent with the application of port rate limiting at
the egress and how use of LSP ping with MP2P will work when deployed.
Similarly, the ingress issuing multiple messages with the same sequence
number in hope that the egress will respond to one of them seems rather
perverse. Presumably the egress can similarly reply to all of them hoping
the ingress will see one of them. How does one track this (lets see, I got 3
fives and 2 sevens) Seems to me that a superior approach (and one that does
not welcome really dumb replay attacks at some point in the future) is that
the sequence number always increments, and the receivers discard duplicates.
Otherwise one end may actually implement only monitonic increase of sequence
numbers while the other end resends multiples, seems to me there is an
interoperability issue here if one expects to infer anything meaningful from
sequence number tracking.

The reply codes still strike me as incomplete as an ENUM instead of a bit
map or some other format that allows multiple outcomes for a probe.

Section 4.1: It seems to be a bit of a misnomer to call an RSVP Session ID
object an FEC. Could we user another term if it is simply any configuration
or administered attribute of an LSP that should be verified?

I presume the use of internal loopback address range is to address ECMP, and
anything periodically pinging should be monotonically increasing the
address. This is great if there is only one instance of ECMP downstream of
the ping source. Any comments on when multiple ECMP points are traversed by
the PING packet. Currently ECMP is proprietary, so I am not sure if this can
be characterized or one can be sure that this will actually test everything.

I can't envision using traceroute mode with don't reply, but that appears to
be a valid option.

Section 4.3: Some useful guidelines as to IP addresses NOT to respond to
might be a good idea.

Section 5.3: Other than being modelled on ICMP, it has otherwise not been
mentioned. Why the reference to using explicit NULL with ICMP here?

cheers
Dave

---

From: [email-masked]
Date: Fri, 18 Oct 2002 11:49:21 +0100

Some general and specific observations on the latest draft 01.  

General comments:
-----------------

1	There are (at least) 3 phases to consider:
(i)	automatic detection of defects
(ii)	automatic consequent actions on detecting defects (these may differ
between different defect types)
(iii)	ad hoc diagnostic tools to investigate anomalous behaviour (esp
where such tools are either too complex/processing-intensive or are simply
not needed in the general 80/20 case)

The draft does not identify/specify any defects, and therefore by inference
does not give any (automatic) consequent actions.  This is not a criticism
per se, just an observation of its limitations.  It therefore falls more
naturally in the ad hoc diagnostics category.

2	IP/cnls networks cannot suffer from the same defects as a MPLS
network.  This is because an IP pkt contains full source/destination
addresses, ie each/every pkt contains it's own 'connectivity verification'
handle that is networkwide unique.  LDP LSPs however use only link-local
unique identifiers to effect hop-by-hop routing.  It is therefore possible
for MPLS networks to misdirect traffic that will not 'self-correct' any
misrouting (as it would in the IP case).  When using link-local identifiers
one should consider all these defects:
-	simple breaks
-	swapped connections
-	traffic from LSP A leaking into LSP B say (in simplest case
involving only 2 LSPs), which has 2 modes:
	* LSP A traffic is otherwise unaffected, ie despite misbranching
into LSP B, LSP A's traffic also carries on to its proper destination....so
there is no indication of problems on LSP A and only LSP B is affected
	* LSP A suffers a break, ie as a consequence of misbranching into
LSP B, LSP A's traffic does not carry on towards its proper destination, so
here both LSP A and LSP B are affected.

The need to specify these defects (in terms of entry/exit criteria and
consequent actions) is required in Y.1710 and very simple techniques are
given in Y.1711 as solutions for the p2p case.  These defects should ideally
also be specified for the mp2p case of LDP. Besides the obvious need for
operators to be able to detect/handle these defects automatically, there are
other reasons why this is required, such as:
-	the need to suppress traffic where necessary to protect customer
traffic confidentially, eg swapped LSPs;
-	in cases such as ATMoverMPLS the need to provide indications (from
the LSP sink point where the defect is detected/handled) to the client (ATM
here) network in order to suppress alarm storms at the sink points of the
client network trails (these may be in a different operator network to the
MPLS network and potentially terminate at many geographically diverse
locations);
-	to get some common ground for interworking between vendors and/or
between operators its clearly important to have common specifications for
defects and their handling.

If this is not possible (for whatever reasons, eg mechanisms defined or
network technology considered) then these limitations should be indicated so
that operators can understand the scope of application.

3	If we can't define standardised defects for whatever reasons, then
there are further limitations that should also be noted:
-	it will not be possible to specify standardised availability
entry/exit criteria
-	it will not be possible to specify standardised QoS objectives, and
in particular their apportionments across operator domains.....this arises
since one needs the availability 'up-time' datum against which QoS metric
collection is valid, ie collection of such metrics against long-term QoS
objectives should be suppressed during unavailability.

Note - the above are not meant as criticisms of the LSP-Ping mechanism per
se (indeed I think its a useful diagnostic tool), they are merely
observations of the limitations of its scope.....esp in the context of mp2p
LSP constructs, which is probably the more limiting factor here.

Specific comments on the draft:
-------------------------------

4	Towards the end of section 2 the draft talks about '....periodically
ping a FEC...' and 'If a ping fails...'.  I think its fine to leave these
undefined like this so long as we agree that LSP-Ping is really a
diagnostics tool, and will have limitations wrt its scope as a defect
detection/handling tool or for any consequential use in measuring
availability/QoS.  However, if this is not the case then I think
well-defined defect specifications (for the reasons given previously) will
be required .....if this is indeed possible.

5	I was not clear why the opening sentence of section 3 says '...a
(possibly) labelled UDP packet.' (a similar sentence appears at the start of
section 4.1).  I thought the intention was to exercise the data-plane of the
outgoing LSP and so the pkts MUST be labelled.  Can you please clarify what
is meant here?

6	In section 3 the 'Reply Mode' field is only specified for IPv4
packets.  Is there any reason the possible use of IPv6 packets has been
omitted here, ie when using LSP-Ping in an IPv6 network? 

7	Section 3.3 discusses the 'Pad TLV'......what is the intended use of
this?

8	In section 5 reliable return paths are discussed.  Agreed that
defect detection/diagnosis/handling is a problem when attempted as a
bidirectional function.  When used with RSVP signalled p2p LSPs, I note
there is an option to use the RSVP return LSP RESV message to carry back
information of other direction Pings.  Two observations:
-    forced coupling with a specific signalling protocol.....this is not a
good idea IMO, the data-plane defect handling ought to look after itself
independently of the control-plane routing/signalling protocols being used;
-    will only detect simple breaks, eg if pkts leaking out of forward
direction of LSP there will not be a return RSVP instantiated LSP (to
wherever they end up) to indicate this defect exists..........this will
require the LSR where the pkts end up to use an IP return mode to detect.
Given this, why bother with having a RSVP return mode in the 1st
place....just use the IP-only return mode in all cases?

BTW - when we are dealing with p2p entities, like an ER LSP, consideration
should be given to the use of the less complex and more powerful techniques
given in Y.1711....esp so in case of non-IP client layers.

That's all the comments I have for now.

thanks and regards, Neil

---

From: "Brian Hassink" <[email-masked]>
Date: Mon, 21 Oct 2002 17:08:36 -0400

Please see followup comments inline below...

Cheers,
Brian Hassink
---

-----Original Message-----
From: Kireeti Kompella [mailto:[email-masked]]
Sent: Monday, October 21, 2002 4:36 PM
To: Brian Hassink
Cc: [email-masked]
Subject: Re: Latest MPLS Ping draft...

On Tue, 15 Oct 2002, Brian Hassink wrote:

> I'm wondering if it wouldn't be better to move the return code from the
> main header to the TLV header, or add a return code to the TLV header? I
> think there may be a couple of good reasons for doing this...

Read section 3.4, and the documentation for value 0 for the return code.

[BH] Ok, I'll buy that. I think that if this "protocol" evolves to support other inband OAM functions, that a more granular error reporting mechanism will be required. However the "error" TLV ends up getting defined, there will likely be a result per TLV, or set of associated TLVs, and I figured allowing for a return code within the TLV may result in less correlation and processing overhead.

> Also, couldn't a (optional) "timestamp" TLV be defined rather than
> having this information as mandatory fields in the main header?

Any particular reason?  One could make TLVs of all fields, not just the
timestamp fields.

[BH] I think that measuring delay/RTT is not necessarily something you want to combine with testing/validating connectivity. And again, if this "protocol" evolves to support other inband OAM functions, then it may become even less relevant to a given function. 

> Lastly, it's not clear to me which FEC applies to a tunnel that has
> been setup manually (i.e. static tunnels)?

There isn't one at present.  One could add one, if it is deemed useful.

[BH] Seems like at pretty useful thing to be able to do. Static tunnels are used in networks and I would think the reasons for monitoring them would be the same as if they were signaled.

As for checksums, UDP does have a checksum; most underlying transport
does as well.  If some new reply mode is introduced which doesn't have
a native checksum, a checksum TLV can be added -- however, I would wait
until a concrete reason is given, so that the figh ... um, discussions
about which particular checksum methodology be used can have a concrete
basis.

[BH] Fair enough.

Kireeti.

---

From: [email-masked]
Date: Wed, 23 Oct 2002 13:31:20 +0100

Brian/Kireeti,

Please see my observations below.  regards, Neil

Brian Hassink wrote 21 October 2002 22:09
<snip>
> >[BH] Also, couldn't a (optional) "timestamp" TLV be defined rather than
> [KK]Any particular reason?  One could make TLVs of all fields, 
> not just the
> timestamp fields.
> 
> [BH] I think that measuring delay/RTT is not necessarily 
> something you want to combine with testing/validating 
> connectivity. And again, if this "protocol" evolves to 
> support other inband OAM functions, then it may become even 
> less relevant to a given function. 
NH=> I agree.  It's a sensible idea to decouple performance metric
measurements from defect detection/handling.....where the latter essentially
boils down to some *standardised* test of connectivity.  The reason why the
defect/connectivity testing needs to be 'standardised' is so that we can
compare apples with apples.....obviously important when running services
across multiple operator networks.  Similarly, it is also important to
standardise the definition of the performance metrics too, and also their
end-end and partitioned objective allowances so that operator's can set fair
allocations.  However, the specification of performance metrics and their
objective allocations can't be really addressed until the basic defect
detection/handling mechanisms are sorted.

There are further practical reasons for decoupling performance metrics from
defect detection/handling:

-	the one Brian has pointed out, ie it's not usual to to measure
performance metrics as a continuous-time function (80/20 rule).  The ability
to have on-demand performance metric measurements is useful for situations
like:
	* ad hoc trouble-shooting/diagnostics at a finer level than the
basic defect detection/handling;
	* on important paths where it is deemed important to have such
measurements running continuously;
	* sampling of network paths (according to some population selection
method) in order to get a feel for the general performance (of some metric x
say) of the network.

-	to make the definition of defect entry/exit criteria as simple as
possible.  If we do not do this then we can end up with complex
combinatorial problems of defining 'up' and 'down' states of a path/network,
ie as some aggregate function of varying levels of degradation across a set
performance metrics x, y, z say.

---

From: "David Allan" <[email-masked]>
Date: Wed, 23 Oct 2002 16:34:38 -0400

Hi Kireeti:

> > TTL exhausts and is not payload of the top label simply be discarded.
> 
> The most common instantiation of a non-compliant router is one whose
> software hasn't been upgraded to know about LSP ping.  It doesn't seem
> reasonable to make requests of such routers to know enough about LSP
> ping to discard LSP ping packets whose TTL has expired.
> 
> On the other hand, for a router that knows about LSP ping but say doesn't
> implement the traceroute mode, it may make sense to say what to do with
> ping packets whose TTL expired.  But since senders have to deal with
> TTL-expired ICMP anyway, it seems to somewhat redundant (IMO).
> 
> It would make sense to state that *compliant* routers that reply to
> a LSP "traceroute" SHOULD NOT also send a TTL-expired ICMP.  That work
> for you?

yes, that works... however I wasn't clear in that I munged two thoughts
together. IMHO an LSP PING PDU that is not associated with the top label
should be discarded when TTL expires (and that can happen in uniform model),
unless folks think we are doing GTTP as well here. 

> What constitutes "reasonable time" depends entirely on the SP and
> their customers.  I'd personally rather not go down that rathole.
> If you have text, you can bounce it off the mailing list and we can
> try to incorporate it.

I'll think about it. IMHO, the combination of ECMP, rate of change of the
127. address, number of sources pinging away, amount of ECMP encountered,
rate limiting at receivers etc. manifests itself in an unbounded detection
time for some problems. You are right that text to describe it is a rat
hole, so is bounding the detection time (which fits my definition of
reasonable).

> > fives and 2 sevens)
> Actually, "I got an answer to five and an answer to seven" is 
> sufficient (where "an" means at least one).

Understood ;-), but it still seems rather redundant, I can also just
increment and say I got answers to 6,7,8,12 and 15.
> 
> > Seems to me that a superior approach (and one that does
> An unstated goal is that (as far as possible) the receiver keep as
> little state as possible.  The sender needs to keep state, so 
> the sender can discard duplicates.  Note that the technique of sending 
> multiple pings with the same sequence number is not mandatory.

And in no reply mode, the receiver presumably may track sequence numbers,
and without a history of how many duplicates the sender sent, cannot infer
anything meaningful. IMHO use of duplicates inherently loses useful
information.

> See reply to other email.

OK, missed that.

> Note that LDP FECs are not FECs, but names of FECs (reminiscent of
> Alice's conversation with Tweedle-dee?  the Caterpillar? on names vs.
> what things are called).

You seem to be suggesting that in the LDP case the actual name of an LSP is
the specification of forwarding rules associated with it (or more directly,
the cumulative specification of forwarding rules that the sender chooses to
use), OK for LDP. So then what LSP-PING sends is not the FEC but the name of
the LSP, in the RSVP case it is sending the name. So the logic appears to be
reversed and the term should not be FEC but "name".

Shakespeare's rose is a rose is fine by me, if we are consistent. If we want
to call names FECs fine by me, but lets pin down one immutable definition
for this document at the beginning that identifies the current
interpretation of the term FEC at the time of writing. 

> > address.
> Yup.
> > This is great if there is only one instance of ECMP downstream of
> > the PING packet.
> Actually, this works (to the extent it works at all) with any number
> of ECMP points.  Do you have a counter-example?

The example that came to mind, is that I have multiple ECMP points I
traverse in sequence, and they have the same fan out, then what hashes to
choice "two" after the first, will pathologically hash to choice "two" at
all subsequent ECMP points. Mind you, if they all implement unique
algorithms or use additional local information to ensure a unique result,
this problem doesn't exist, but proving you actually can exercise all
potential paths from a single upstream point is a bit tricky.

> 
> > Currently ECMP is proprietary, so I am not sure if this can
> I am sure this won't test everything.  I am equally certain that the
> IETF is not the place to standardise ECMP (IMO) -- in fact, I don't
> personally believe that ECMP should be standardized.

I think some degree of specification (at least with respect to behavioural
properties) that vendors may choose to support or not support is useful for
providers. In particular when it impacts the testability of their network.
Thats the goal of the load balancing guidelines draft I posted not that long
ago. Folks who want certain testability may wish to cap the open endedness
of ECMP behavior, some may not.

> ?
There are no representations as to source addresses that should be
inadmissable, while we have lots of experience with ICMP on things that are
currently filtered (such as smurf attacks and the like). Current security
concerns seem to simply focus on DOS attacks associated with volume of
messaging and not attacks that get the network to actually generate that
volume....

> Will fix.
OK

thanks
Dave