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

From: Sami Boutros <[email-masked]>
Date: Mon, 06 Jun 2011 22:15:41 -0700

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.

>    * 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.

>    * 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.

>    * 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.

>    * 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.

Thanks,

Sami

---

From: Gregory Mirsky <[email-masked]>
Date: Tue, 7 Jun 2011 19:52:39 -0400

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: [email-masked] [mailto:[email-masked]] On Behalf Of Sami Boutros
Sent: Monday, June 06, 2011 10:16 PM
To: Greg Mirsky; Siva Sivabalan(msiva); Rahul Aggarwal; [email-masked]; [email-masked]; [email-masked]; David Ward; [email-masked]; [email-masked]; Bitar, Nabil N; BUSI ITALO; LEVRAU, LIEVEN (LIEVEN); [email-masked]; [email-masked]; [email-masked]; [email-masked]
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.

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

---

From: Sami Boutros <[email-masked]>
Date: Sun, 19 Jun 2011 23:19:26 -0700

Hi Greg,

At 04:52 PM 6/7/2011, Gregory Mirsky wrote:
>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".

Sami: Agreed, will clarify the text to align more with the 
on-demand-cv draft that allows LSP Ping to be G-ACH encaped with or 
without IP address.

>Section 3.3 What is application of Informational Return Code?

Sami: No application so far.

>when negotiating CHAP Authentication?

Sami: We will use Request and Response messages with the same 
operation being authenticated, return codes will reflect 
authentication success/failures in case we get one.

>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.

Sami: Will address.

> to be consistent with terminology used.

Sami: Will address.

>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?

Sami: Will get rid of the MEP-IDs and use source/tgt identifiers 
defined in the on-demand-cv draft.

>Reference 9 is missing mention of RFC 1334.

Sami: Will add.

Thanks,

Sami

>----------
>To: Greg Mirsky; Siva Sivabalan(msiva); Rahul Aggarwal; 
>[email-masked]; [email-masked]; 
>[email-masked]; David Ward; [email-masked]; 
>[email-masked]; Bitar, Nabil N; BUSI ITALO; LEVRAU, LIEVEN 
>(LIEVEN); [email-masked]; [email-masked]; 
>[email-masked]; [email-masked]
>  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.
>
>section shared by both in-Band and LSP-Ping, we as well limited the 
># of TLVs used by LSP Ping.
>  GIM>> Great
>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.
>