Subject: Re: [mpls-tp] Comments on draft-nitinb-mpls-tp-lsp-ping-bfd-procedures-02

From: Greg Mirsky <[email-masked]>
Date: Mon, 8 Mar 2010 14:44:55 -0800

Dear Nitin,
I think that you'll kind consider two more comments to the figures in the
document:

   - Figure 2 displays LSP-Ping ACH encapsulation over MPLS-TP LSP. The
   current caption suggests more generic interpretation of the figure.
   - Figure 2 and Figure 3 display GAL as part of a LSP-Ping and BFD control
   packet G-ACh encapsulation. The GAL is a label in the MPLS Label Stack which
   is constructed by Label Stack Elements. Perhaps GAL LSE might be clearer
   caption.

Regards,
Greg

On Wed, Feb 17, 2010 at 11:28 PM, Nitin Bahadur <[email-masked]> wrote:

> Hi Greg,
>
>   Thanks for reading the draft in detail. See inline below for responses to
> your comments.
>
> On 2/17/10 12:59 PM, "Greg Mirsky" <[email-masked]> wrote:
>
> Dear Authors and All,
> below are my comments to the document:
>
>  *   Abstract - "widely deployed" to replace "widely deployment"
>
> NB> Will fix that.
>
>
>  *   Section 2.1, Figure 2 - Section 3 RFC 5586 states that if ACH TLVs
> might be present then ACH TLV Header must be present. The Length of ACH TLV
> Header may set to zero in no ACH TLVs are actually present in the given
> packet. Said that I turn to figure 2 that presents LSP Ping packet with ACH
> format. The ACH TLV Header is not presented in the format even though
> presence of ACH TLVs is indicated. I think that proper LSP Ping with ACH
> format will look as:
>
>      0                           1                            2
>                3
>
>       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 2
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>       |                                    MPLS Label stack
>                |
>       |
>                            |
>
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |                                              GAL
>                         |
>
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |0 0 0 1|Version|   Reserved    |     LSP-Ping Channel Type     |
>
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |                                   ACH TLV Header
>                |
>
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |                                          ACH TLVs
>                    |
>
>       |
>                            |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>       |                                    LSP-Ping payload
>               |
>       |
>                            |
>
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> NB> You are right. I will fix that.
>
>
>  *   Section 2.3 discusses optional use of Source Address TLV but the
> sentence "Only 1 source address TLV MUST be present in a LSP-Ping packet."
> may be interpreted as the Source Address TLV is mandatory. I propose to
> change "MUST" to "MAY" in the sentence
>
> NB> Sure...will rephrase to avoid confusion.
>
>
>  *   Figure 3 - same comments regarding ACH TLV Header in the format as for
> Figure 2
>
>
> NB> Will fix.
>
> Thanks for your useful comments Greg.
>
> Nitin
>
>