Re: [mpls] LC comments to draft-ietf-mpls-tp-li-lb-01

[Gregory Mirsky <[e-mail]>]

Hi Sami,
thank you for your response. Please find my notes below and in-lined with tag GIM>>:

 *
second paragraph of Introduction refers to use of LSP-Ping "either over GACh or using native IP addressing". I think that this is in reference to different encapsulations of LSP-Ping and the text might benefit from the clarification and note that with either type of encapsulation an LSP-Ping is always transported in-band over MPLS-TP network. Considering that characterizing G-ACh encapsulation as exclusively "in-band option" for LI-LB transport might be misleading. Perhaps it can be referred as "G-ACh option".
 *
Section 3.3 What is application of Informational Return Code?
 *
Section 3.5 Which Operation and Return Code values should be used when negotiating CHAP Authentication?
 *
section 3.6.2 states that "only LI-LB response TLV might be present in LSP Ping Echo request message". I think it is a typo and this clarification is in regard to LSP Ping Echo reply message, not request.
 *   In 6.3.g it might be "back to MEP-A' in place of "back to A" to be consistent with terminology used.
 *
I find draft-ietf-mpls-tp-ach-tlv-02 expired and IANA's ACH TLV Registry is empty. The document doesn't request IANA allocation of ACH TLV types for Source MEP-ID, Destination MEP-ID, Destination MIP-ID, and Authentication. How these ACH TLV types will be defined?
 *
Reference 9 is missing mention of RFC 1334.

    Regards,
        Greg

________________________________
From: [e-mail] [mailto:[e-mail]] On Behalf Of Sami Boutros
Sent: Monday, June 06, 2011 10:16 PM
To: Greg Mirsky; Siva Sivabalan(msiva); Rahul Aggarwal; [e-mail]; [e-mail]; [e-mail]; David Ward; [e-mail]; [e-mail]; Bitar, Nabil N; BUSI ITALO; LEVRAU, LIEVEN (LIEVEN); [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Re: [mpls] LC comments to draft-ietf-mpls-tp-li-lb-01

Hi Greg,

Here are responses to your comments please let us know if you are OK with the Responses.


 *   section 3.2 I think that there are mandatory TLVs for LI-LB and optional. Mandatory TLV for LI might be Source MEP-ID, Destination MEP-ID, while for LB Source MEP-ID and MIP-ID. Optional, e.g. Authentication TLV.

Response-1: Correct.
 GIM>> I don't find Source and Destination MEP-ID, MIP-ID TLVs being discussed or referenced even though section 6.3 refers to validation of Source and Destination/target MEP-IDs.

 *   section 3.3.5 describes Return Code in Return TLV for LSP-ping option of LI-LB signaling. For in-band option Return Code has different values and values listed in this section are for field Cause Code. I think it would be beneficial to have some uniformity across LI-LB signalling options and in Return TLV have both Return Code and Cause Code fields with values identical for in-band and LSP-Ping options.

Response-2: Addressed in latest version -02 where we made this section shared by both in-Band and LSP-Ping, we as well limited the # of TLVs used by LSP Ping.
 GIM>> Great

 *   section 3.3.6 defines Authentication TLV for LSP-Ping option. Authentication of LB request but in-band option doesn't have provision to indicate that Authentication is in use. I propose to allocate MSB of Reserved field as Authentication flag.

Response-3: Addressed in latest version -02 by making authentication TLV common to both in-band and LSP Ping.
 GIM>> Agree

 *   section 6.3 mentions that Authentication may be used both in Lock request and Lock response. I think that if Authentication was present in Lock request and accepted by remote MEP, then Lock response must have Authentication. Similar is applicable to use of Authentication in Unlock request/response, and Setting/Removing LB .

Response-4: We described authentication procedures in more details in section 3.5 of latest draft version, please have a look to see if it addresses your concern.
GIM>> I was thinking of allocating an Authnetication (A) flag from Reserved field to indicate whether Authentication is in use for given LB and LI. Note, that setting of A flag on LI Lock request or LB Set request defines use of Authentication not only in corresponding replies but in Unlock/Unset as well.

 *   section 6.5.b I think that there's no guarantee that sender of LI request will not generate false positive after remote MEP locks the LSP. Perhaps, if proactive OAM is enabled, the remote MEP should send LI reply but it might stop sending OAM messages after 3*TxPeriod interval.

Response-5:  Addressed in section 6.3 last paragraph

MEP-D will lock the LSP, resulting in that all traffic from D to A, including all OAM traffic, stops.

a. MEP-A will detect a discontinuation in the OAM traffic, e.g. cv and cc packets, but since it has been informed that the LSP will be locked it will take no action(s).
b. When MEP-A receives the LI ACK, MEP-A discontinues sending other OAM traffic, e.g. cv and cc packets. MEP-D will detect this, but since it is in Locked state it will take no action.
GIM>> Thank you.

Thanks,

Sami