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

[Sami Boutros <[e-mail]>]

Hi Greg,

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

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.

>Section 3.5 Which Operation and Return Code values should be used 
>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.

>    * In 6.3.g it might be "back to MEP-A' in place of "back to A" 
> 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

>     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