Subject: Re: [mpls] MPLS working group last call on draft-ietf-mpls-tp-li-lb-03.txt

From: <[email-masked]>
Date: Fri, 2 Sep 2011 19:01:38 +0200

Hi Yoshinori and Sami,

Please allow me to jump in, adding 2 cents inline below marked with [MP].

Thanks,
Manuel

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Sami Boutros
> Sent: Tuesday, August 30, 2011 1:52 AM
> To: Yoshinori Koike
> Cc: [email-masked]; [email-masked]; MPLS-TP ad hoc team;
> [email-masked]
> Subject: Re: [mpls] MPLS working group last call on draft-ietf-mpls-tp-li-
> lb-03.txt
>
> Hi Yoshinori,
>
> Please see my comments inline.
>
> At 01:08 PM 8/29/2011, Yoshinori Koike wrote:
> >Dear Sami,
> >
> >Thank you for the reply and clarification. See inline marked with
> >[YK], please.
> >
> >(2011/08/29 0:48), Sami Boutros wrote:
> >>Yoshinori,
> >>
> >>Is this the proposed text you are referring too? If so we can add some
> >>of this text ..
> >>
> >>Start of text...
> >>Data plane loopback is an out-of-service function, as required
> >>in section 2.2.5 of RFC 5860 [11]. This function permits all
> >>traffic(including user data and OAM, with the exception of the
> >>disable loopback command). The traffic is originated from
> >>one internal point at the ingress of a transport path within a
> >>interface or inserted from input port of an interface by the
> >>external test equipment to be looped back unmodified (other than
> >>normal per hop processing such as TTL decrement). All the traffic
> >>are loop backed in the direction of the point of origin by an
> >>interface at either an intermediate node or a terminating node.
> >>
> >>It should be noted that data plane loopback function itself is
> >>applied between data-plane loopback points within interfaces
> >>which is different from MIP/MEP.
> >>End of text...
> >
> >[YK]
> >Correct. However, it will be better to align with the text in
> >section 6.3 of oam-framework-draft. My suggestion is to merge the
> >following two parts.
> >
> >"It should be noted that data plane loopback function itself is
> >applied to data plane loopback points that can resides on different
> >interfaces from MIPs/MEPs."
> >
> >"all traffic (including both payload and OAM) received on the looped
> >back interface is sent on the reverse direction of the transport
> >path. The traffic is looped back unmodified other than normal per
> >hop processing such as TTL decrement."
>
> Sami: Sure will add this too.
>
> >In addition to adding the text, I think the following sentences need
> >to be modified to avoid a misunderstanding or a contradiction. ("The
> >loopback function is operated by NMS" would be a correct sentence.)
> >Is my understanding correct?
>
> Sami: Correct.
>
> >"The Loopback function is operated from MEP to MEP on bidirectional
> >(associated and co-routed) Label Switched Paths (LSPs), Pseudowires
> >(including multi-segment Pseudowires). The Loopback function is
> >additionally operated from MEP to MIP on co-routed bidirectional
> >LSPs, and on multi-segment Pseudowires."
> >
> >>Please see Comments inline..
> >>At 01:45 PM 8/25/2011, Yoshinori Koike wrote:
> >>>Dear authors,
> >>>
> >>>I added ITU-T mailing lists to ask to put my comments in ITU-T liaison
> >>>to IETF in order to draw attention also in ITU-T.
> >>>
> >>>I think it's valid and indispensable to answer the questions and
> >>>comments from Mr. Sharam Davari attached at the bottom. I would like
> >>>to make additional comments related to them.
> >>>
> >>>(1) The following sentences in section 1.Introduction should be
> >>>modified by adding clear definition of data-plane loopback point which
> >>>doesn't coincide with MIP or MEP. I think the descriptions need to be
> >>>carefully aligned with the oam-framework draft.
> >>>
> >>>"The Loopback function is operated from MEP to MEP on bidirectional
> >>>(associated and co-routed) Label Switched Paths (LSPs), Pseudowires
> >>>(including multi-segment Pseudowires). The Loopback function is
> >>>additionally operated from MEP to MIP on co-routed bidirectional
> >>>LSPs, and on multi-segment Pseudowires. The Loopback is a function
> >>>that enables a MEP to request a MEP or a MIP to enter a loopback
> >>>state."
> >>>
> >>>As I proposed in the following last call comments #3 on oam-framework
> >>>draft, in my understanding, MIP or MEP is different from data-plane
> >>>loopback point.
> >>>
> >>>http://www.ietf.org/mail-archive/web/mpls-tp/current/msg04887.html
> >>>
> >>>MIP&MEP are related only to OAM packets. On the other hand, data-plan
> >>>loopback points are related to both OAM packets and data packets.
> >>>Therefore, I think that the two points are clearly different from the
> >>>functional perspective. The current definitions of MIP and MEP in
> >>>li-lb draft go beyond the original definitions of MIP and MEP.
> >>>
> >>>(2) All the question for clarifications from Mr. Sharam Davari should
> >>>be clarified in the context of the definition of data-plane LB point.
> >
> >[YK] I hope that your clarification in the reply to him will be
> >appropriately reflected in the next version considering his feedback.
>
> Sami: I will see what can apply, one thing we don't want to do is to
> describe how MPLS forwarding works and how to handle MPLS Fwding
> exception, or how to apply a policy on a given HW?
>
> >>>(3) More details about the configuration of data-plane loopback
> >>>point(s) should be clarified.
> >>
> >>Sami: Can you please be more specific? is this part of the text you
> >>wanto add above?
> >
> >[YK] The following sentence in oam-framework is more useful than my
> >proposed text. I would like to see more detailed explanation about
> >configuration. It seems useful to show an example of a series of
> >configuration to apply data-plan loopback function including test traffic.
> >
> >"Instead, test traffic is inserted at the ingress of the MEG. This
> >test traffic can be generated from an internal process residing
> >within the ingress node or injected by external test equipment
> >connected to the ingress node."
>
> Sami: Wouldn't this be an implementation detail?

[MP:] As it was already introduced in the OAM Framework, it would need to be expanded somewhere. This is the right place to do that IMHO.
An application scenario example would be very helpful and can be provided without any node internals.
I.E. it would be sufficient to add two example network scenario diagrams, where:
1) an abstract test traffic processor resides within an ingress node
2) test traffic is generated by an "abstract" external test generator, that is connected to the ingress node

>
> >Another part I wanted to refer to is the following part.
> >
> >"If the data plane loopback point is set somewhere at intermediate
> >point in bidirectional transport path, the side of loop back
> >function(one side or both side) needs to be configured.
> >(end of proposed texts)"
>
> Sami: Sure we can add this to describe more the Loopback function.
>
> >Regarding an intermediate loopback point, there could be two sides
> >which can loopback the traffic. Probably the side needs to be
> >configured from NMS, because from an intermediate point, there are
> >two possible point at which test traffic is inserted in a transport
> >path. Or both sides are automatically set for loopback mode.
>
> Sami: An NMS can set both sides to loopback if it wants too, so will
> use the text you propose above.
>
> >>>This is related to my comment #4 also in the above last call comments
> >>>#4 on oam-framework draft. In particular, it should be clarified how
> >>>to designate or specify a data-plane loopback point, if there are more
> >>>than one data-plane loopback points within a node. I think that this
> >>>is also related to one of the last call comments from Alessandro.
> >>
> >>Sami: I assume this is covered in your text above, correct?
> >
> >[YK] I understood that any data-plane loopback points is
> >enabled/disabled by NMS. If so, the identifiers are never exchanged
> >through the OAM protocol and they are only related to management
> >objects. Is that correct?
>
> Sami: Correct.
>
> >>>If the point could be set by OAM message, the method and protocol
> >>>needs to be specified in this draft.
> >>
> >>Sami: We decided not to use an OAM message to set the Loopback point, it
> >>is only done via Management.
> >
> >[YK] Thank you for the clarification.
>
> Sami: Thanks for your comments.
>
> Sami
>
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls