Subject: RE: [mpls] Last Call on "LSP Ping"

From: "David Allan" <[email-masked]>
Date: Fri, 18 Mar 2005 13:40:57 -0500

IMO the additions for nested implicit NULLs could be clearer....(my usual
hobby horse...;-)

In section 4.4

There is an implied pre-processing step where FECs for which implicit NULL
was offered require insertion into the stack prior to processing. IMO
explicitly describing this allows us to remove the "are assumed to
correspond..." language which is rather fuzzy....

So existing text is....

"   X matches up the labels in the received label stack with the FECs
   contained in the FEC stack.  The matching is done beginning at the
   bottom of both stacks, and working up.  For reporting purposes the
   bottom of stack is consided to be stack-depth of 1.  This is to
   establish an absolute reference for the case where the stack may have
   more labels than are in the FEC stack.

   If there are more FECs than labels, the extra FECs are assumed to
   correspond to Implicit Null Labels.  Thus for the processing below,
   there is never the case where there is a FEC with no corresponding
   label.  Further the label operation associated with an assumed Null
   Label is 'pop and continue processing'."

Proposed revision....

"   X matches up the labels in the received label stack with the FECs
   contained in the FEC stack.  The matching is done beginning at the
   bottom of both stacks, and working up.  For reporting purposes the
   bottom of stack is consided to be stack-depth of 1.  This is to
   establish an absolute reference for the case where the stack may have
   more labels than are in the FEC stack.

   Where a FEC is encountered for which an implicit NULL was offered,
   an implicit NULL is inserted a the corresponding position into the 
   received label stack. Thus for 
   the processing below, there is never the case where there is a FEC 
   with no corresponding label."

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of George Swallow
> Sent: Wednesday, March 16, 2005 1:44 PM
> To: [email-masked]
> Subject: [mpls] Last Call on "LSP Ping"
> 
> 
> This begins a two week last call on:
> 
>         Detecting MPLS Data Plane Failures
>          <draft-ietf-mpls-lsp-ping-08.txt>
> 
> The last call ends on March 30, 24:00 UTC.
> 
> ...George
> 
> ==============================================================
> ==========
> George Swallow             Cisco Systems                  
> (978) 936-1398
>                            1414 Massachusetts Avenue
>                            Boxborough, MA 01719
> 
> 
> 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mpls
> 
> 

_______________________________________________
mpls mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls

---

From: Igor Vulanovic <[email-masked]>
Date: Mon, 28 Mar 2005 15:56:01 -0500

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.