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

[Greg Mirsky <[e-mail]>]

Dear Authors and All,
please find my comments to the latest version:

   - Introduction Is LI/LB mechanism applicable to MPLS-TP Sections?
   - Introduction RE: LI/LB signaling methods in-band and LSP Ping are
   discussed as opposites. Isn’t LSP Ping an in-band methods too?
   - Section 3.5 Each individual LI/LB Request can carry or not to carry
   Authentication TLV? LSP Ping MPLS-TP OAM Configuration does not control
   whether LI/LB session Authenticated or not.
   - Section 4. What is the rationale to allow use of different methods to
   do LI/LB in one session? I think that model of LI/LB session with predefined
   parameters, e.g. Authentication, might be even duration, and etc. will be
   useful and beneficial.
   - Section 4.3 Control over the Loopback mode is done entirely based on
   the TTL value. I think this is too weak and can be strengthen by combining
   with match to a destination MIP ID. I suggest to make use of destination MIP
   ID mandatory for LB request. Then we can use Cause code 1 “Fail to match
   target MIP/MEP ID” in NACK. Thus Section 6.1 General Procedures will be
   modified too.
   - Sections 6.3 and further logically are based on Section 6.2 and should
   be enumerated 6.2.1, 6.2.2, …
   - Section 6.3 bullet 2 refers to source MEP ID but none of presented
   formats or previous descriptions mentions use of Source MEP ID in Lock
   Request in-band encapsulation.
   - Same issue with 6.3.b – Target MEP ID.
   - MEP-ID and MEP-A might be confusing. Suggest to use “MEP ID” and
   “MEP-A” to differentiate type of identifier and node specified.
   - Section 6.3 refers to an example “the OAM traffic, e.g. cv and cc
   packets” I think that more likely that DM and LM packets will be sent under
   LI/LB.
   - Section 7 I think that order in which Authentication is used is not
   adequate for procedures like LI/LB that can severely affect services.

  Your feedback is greatly appreciated.

Regards,
Greg


On Sun, Jun 19, 2011 at 11:19 PM, Sami Boutros <[e-mail]> wrote:

>  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]<[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
>
>
>
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls
>
>