The MPLS WG Archive

[Igor Vulanovic <igor.vulanovic@alcatel.com>]

Hello,

I have a few questions/comments about the
latest draft version 8 for MPLS LSP Ping.
<draft-ietf-mpls-lsp-ping-08.txt>

regards,
Igor

1) Clarification of Mandatory vs. Optional TLVs

The draft is unclear about which TLVs are mandatory
and which are optional.  It is also unclear about
the format of the TLV "type" field.

On one hand, the draft suggests that each TLV has
a type (i.e. Target FEC TLV is type 1) which determines
whether or not that TLV is optional or mandatory.
This determination is based on whether the TLV
type is above or below 32768.
On the other hand, for example, the draft suggests that the
Target FEC TLV is mandatory in an echo request and
optional in an echo response.
Another example is the Vendor Enterprise TLV.  The
draft says that to determine if the Vendor Enterprise
TLV is mandatory/optional, one must look at the
values in Message Type, Reply Mode, Return Code and
Return Subcode.

It would seem that one can not rely only on the high
order bit in the TLV type to determine if the TLV is
mandatory/optional.

Perhaps the TLV definition should be enhanced as follows:

 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-----------------------------+-------------------------------+
|U|       Type                  |         Length                |
+-+-----------------------------+-------------------------------+

where the "U" bit indicates if the TLV is
  mandatory (i.e. U = 0) or
  optional  (i.e. U = 1)

In any case, I think that the draft would benefit from some
clarification in this regard.

2) Vendor Enterprise Code TLV

Section 3.6 of the draft describes the Vendor Enterprise Code TLV.
However, that section is not totally complete.  There is extra
information in section 7.1 regarding which fields can contain
values in the vendor private range.  It would be better to include
more information in section 3.6 or else reference section 7.1.

3) Addition of DS Flags in Downstream Mapping TLV

It seems strange to have a flag inside the Downstream
Mapping TLV which indicates a request to have an
Interface and Label TLV included in the echo reply.

Is there a better way to do this?

Would it make more sense to use the Global Flags inside the
fixed fields for this purpose?  There could be seperate flags:
 - one flag to request a Downstream Mapping TLV in the reply
 - one flag to request a Interface and Label TLV in the reply

The benefits would be:
 - better seperation of logic between TLVs
 - no longer the need for an empty Downstream Mapping TLV
   in the echo request
The most obvious drawbacks being:
 - backwards compatibility broken to equipment that expect
   a Downstream Mapping TLV in the echo request
- not a very scalable solution

4) NIL FEC

Why do we need more than one label in the Nil FEC TLV?
My understanding is that each FEC stack sub-TLV corresponds
to one label in the label stack.
Is this for the case where there are multiple back-to-back
reserved labels in the label stack?  Is the intent to be
able to represent those back-to-back labels in one single
Nil FEC sub-TLV?
Would it be simpler to just have one label in each Nil FEC
sub-TLV?  This way, each FEC sub-TLV always corresponds to
a single label in the label stack.

5) CR-LDP FEC Appendix A.1

There appears to be a typo here.  The length of the CR-LDP
FEC should be 8 instead of 6.
 

_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls