The MPLS WG Archive

[Gatot Susilo <gatot.susilo@alcatel.com>]

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

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