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

[Sami Boutros <[e-mail]>]

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