Subject: [mpls] I-D ACTION:draft-ietf-mpls-lsp-ping-08.txt

From: [email-masked]
Date: Tue, 22 Feb 2005 16:05:19 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF.

	Title		: Detecting MPLS Data Plane Failures
	Author(s)	: K. Kompella, G. Swallow
	Filename	: draft-ietf-mpls-lsp-ping-08.txt
	Pages		: 42
	Date		: 2005-2-22
	
This document describes a simple and efficient mechanism that can be
used to detect data plane failures in Multi-Protocol Label Switching
(MPLS) Label Switched Paths (LSPs).  There are two parts to this
document: information carried in an MPLS 'echo request' and 'echo
reply' for the purposes of fault detection and isolation; and
mechanisms for reliably sending the echo reply.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-ping-08.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-mpls-lsp-ping-08.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-mpls-lsp-ping-08.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
mpls mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls

---

From: Gatot Susilo <[email-masked]>
Date: Fri, 25 Feb 2005 12:37:25 -0500

Hi,

I would like to have some comments/questions to the draft.

1/ Mandatory/Optional TLVs.

I would think this is applicable only for top level TLVs. Am I wrong
?

This should be made clear in the draft. Moreover, throughout draft
not all top level TLVs are explicitly stated whether the TLV is mandatory
or optional. Summarizing whether the TLV is mandatory/optional along with
the TLV list will make it less ambiguity/error-prone. Therefore, I would
like to propose some text changes:

In the section 3:

"A description of the Type and Values of level TLVs of LSP Ping
..."

until the end of section, should be replaced as follows:

"A description of the Types and Values of top level TLVs for LSP
Ping are given below:

Type #  Type  Value Field

------  ----  -----------

1
M  Target FEC Stack

2
O  Downstream Mapping

3
M  Pad

4
O  Error Code

5
O  Vendor Enterprise Code

6
O  TBD

7
O  IPv4 Interface and Label Stack Object

8
O  IPv6 Interface and Label Stack Object

9
O  Errored TLVs

10
O  Reply TOS Byte

(M) These are mandatory TLVs. The high order bit of Type field

MUST be set to 0, which yields types less than
32768.

These TLVs MUST either be supported by an implementation
or result

in the return code of 2 ("One or more of the
TLVs was not

understood" being sent in the echo response").

(O) These are optional TLVs. The high order bit of Type field

MUST be set to 1, which yields types greater
than or equal to 32768.

These TLVs SHOULD be ignored if the implementation
does not

understand or support them.

"

2/ IPv4/IPv6 Interface and Label Stack Object

Section 3.7.1 and 3.7.2 indicates that the downstream interface addess
may be set to either the downstream LSR's interface address or the index
assigned by the downstream LSR to the interface when address type is IPv4/IPv6
or unnumbered respectively. When the originating node receives the MPLS
echo reply, the originating node will not be able to tell what the downstream
LSR has set to the downstream interface address field. In this case, I
would like to propose that "Address Type" field should be added in these
TLVs. This is similar to the downstream mapping TLV of which "Address Type"
is explicitly specified.

3/ Typo on length of CR-LDP FEC

Appendix A.1 indicates that the length of CR-LDP FEC is 6 instead of
8.

4/ Non-Compliant Routers

In section 4.8, it mentioned about ALLROUTERs multicast address. What
is the value ?

Moreover, why do we need to set "Validate FEC Stack" flag to 0?
I would think that we can continue validating FEC stack. The only thing
that we can skip is validating the downstream mapping TLV. So I would propose
that:

When the downstream IP address field is set to ALLROUTERs multicast
address, the downstream mapping tlv MUST not be validated. The FEC stack
SHOULD be validated as if the downstream mapping tlv is not present.

5/ Section 7.2 TLVs (i.e. overlapping value with optional TLVs)

Snipet from section 7.2:

"It is requested that IANA maintain registries for the Type field
of top-level TLV as well as for sub-TLVs. The valid range for each of these
is 0-65535"

As mentioned in the section 3, the high order bit of Type field is used
to indicate whether the TLV is optional or mandatory. Presumably the high
order bit mandatory/optional flag is only used by top-level TLV and Type
0 should be considered as invalid, then should it say something like this.

"The Type field of top-level TLVs has valid range from 1 to 32767 inclusive.

The Type field of sub-TLVs has valid range from 1 to 65535 inclusive."

Moreover, all vendor specific top-level TLVs are considered as optional
TLVs. Hence, the high order bit of Type field of these TLVs must be set
to 1.

Cheers,

/Gatot