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

From: Loa Andersson <[email-masked]>
Date: Mon, 15 Aug 2011 21:31:47 +0200

Working Group,

this is to start a working group last call on
draft-ietf-mpls-tp-li-lb-03.txt

Please send your comments to the mpls working group mailing list.

This last call ends on August 26th 2011.

Loa
for the mpls wg co-charirs

-- 

Loa Andersson                         email: [email-masked]
Sr Strategy and Standards Manager            [email-masked]
Ericsson Inc                          phone: +46 10 717 52 13
                                              +46 767 72 92 13

---

From: "Shahram Davari" <[email-masked]>
Date: Mon, 15 Aug 2011 13:32:57 -0700

Hi,

I have a general clarification question regarding this draft. It seems that the exact position of the Transmit, Loopback and receive MEP/MIP in the data-plane processing is not well defined, which could lead to unpredictable results. For example what is the expected behavior for Transmit, Receive and Loopback points:

- Transmit Before or after Ingress policing?
- Transmit and Loopback before or after Queuing/shaping?
- Loopback Before or after forwarding (Label Switching)?
- Loopback at Ingress Port (Down-MEP) or Egress port (Up-MEP)?
- Loopback before TTL decrement or after TTL decrement?
- Loopback before or after LSP termination at LSP terminating MEP?
- Loopback or not loopback ACH messages at terminating MEP?
- loopback or not Loopback VCCV messages at terminating MEP?
- loopback or not Loopback LSP OAM messages (such as BFD) with IP address = 127/8 at terminating MEP?
- loopback or not Loopback LSP-Ping messages not defined in this draft?

And many similar questions. I would appreciate the authors response and clarification.

Thanks
Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Loa Andersson
Sent: Monday, August 15, 2011 12:32 PM
To: [email-masked]; [email-masked]; MPLS-TP ad hoc team; [email-masked]; CCAMP
Subject: [mpls] MPLS working group last call on draft-ietf-mpls-tp-li-lb-03.txt

Working Group,

Loa

-- 

Loa Andersson                         email: [email-masked]
Sr Strategy and Standards Manager            [email-masked]
Ericsson Inc                          phone: +46 10 717 52 13
                                              +46 767 72 92 13
_______________________________________________
mpls mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls

---

From: "Shahram Davari" <[email-masked]>
Date: Mon, 15 Aug 2011 14:31:17 -0700

Hi,

A few more comments:

- How is a MIP put to Loopback mode? 
- How does the MIP get out of loopback?
- How does the Ingress MEP know that the Egress MEP has accepted its request for Lockout?
- How does the Ingress MEP know that the MIP is or is not in loopback mode?

previous versions of the draft addressed all these issues, but I am wondering how are these done without special messages and Acks.

Thx
Shahram

-----Original Message-----
From: Shahram Davari 
Sent: Monday, August 15, 2011 1:33 PM
To: 'Loa Andersson'; [email-masked]'; [email-masked]'; 'MPLS-TP ad hoc team'; [email-masked]'; 'CCAMP'
Subject: RE: [mpls] MPLS working group last call on draft-ietf-mpls-tp-li-lb-03.txt

Hi,

Thanks
Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Loa Andersson
Sent: Monday, August 15, 2011 12:32 PM
To: [email-masked]; [email-masked]; MPLS-TP ad hoc team; [email-masked]; CCAMP
Subject: [mpls] MPLS working group last call on draft-ietf-mpls-tp-li-lb-03.txt

Working Group,

Loa

--

---

From: D'Alessandro Alessandro Gerardo <[email-masked]>
Date: Thu, 18 Aug 2011 14:32:16 +0200

Dear all,
I have the following comments related to draft-ietf-mpls-tp-li-lb-03:

Abstract/introduction: “This document specifies one function and describes a second function … the second enables an operator to set, in loopback, a given node along
a transport path.”
➢ In my opinion the document's body does not reflect the abstract/introduction. Actually there is a very short reference to loopback function carried out by NMS that cannot be considered covered by the document (and the title should therefore refer to LI only) as in the previous version (-02).

Introduction: “The Lock function is operated from MEP to MEP on bidirectional (associated and co-routed) Label Switched Paths (LSPs), Pseudowires (including multi-segment Pseudowires).”
➢ why have not sections been covered as per RFC 5860?

Introduction: “control traffic (such as OAM messages dedicated to the transport path) can be mapped”
Section 4.1: “via management or control”; Section 5
➢ from rfc 5860 "Note that lock corresponds to an administrative status in which it is expected that only test traffic, if any, and OAM (dedicated to the PW, LSP, or Section) can be mapped on that PW, LSP, or Section".  What does "control traffic" mean in the document? is it something different from OAM as described in RFC 5860?

Introduction: “The Loopback function is operated from MEP to MEP on bidirectional (associated and co-routed) Label Switched Paths (LSPs), Pseudowires (including multi-segment Pseudowires).”
➢ (why have not sections been covered?

Introduction: “traffic sent by the source will be received by that source.”
➢ A question for clarification: Does the loopback function here described cover all traffic types (customer traffic, OAM traffic, Control traffic, etc) as per RFC 5860?

Introduction: “The Loopback can be performed using a management plane”
➢ is management plane approach the only one foreseen? "can" seems suggesting other ways as for example the usage of OAM messages as proposed in the previous version. Could the author explain the reasons for excluding such an approach (loopback function by OAM) from this version? With respect to the document description, being the loopback function performed by NMS & due to the fact that "NMS MUST insure that the two MEPS are locked before performing the loopback function" I don't see any advantage in considering the loopback function in this document because it is evident that there is a limited advantage in using LI messages (i.e. Lock and Loopback can be easily performed by NMS)

Section 3.2: “When a lock is applied, a refresh timer is chosen”
➢ the lock you refer here is on one side only or does it refer to both sides (e.g. when NMS lock MEP-A of a transport path, then when the first LI message is sent, the refresh value cannot be changed for the duration of the lock on the MEP-A)

section 3.2: “MEP Source ID TLV”
➢ only Global-ID MEP are described. They are a subset of MEP ID specified in the draft-Identifier.

section 4: “lock is used to request a MEP …”
➢ it is not clear the way “LOCK” is used. Is it “Lock Instruct message” or “NMS command” or are you referring to a “ME state”?

Section 4.1: “Unlock is used to request a MEP…”
➢ Same comment as above… is it an “NMS command” or are you referring to a “state”?

Section 4.1: “When a MEP is unlocked via management or control it MUST cease sending LI messages.”
➢ from section 4 seems there are MEPs that are locked receiving LI messages but such MEPs seem do not generating any LI messages. suggest rewording because it seems that also MEP-D ceases sending LI messages

section 5: “When an LSP is locked, the management or control function is expected to lock both ends.”
➢ my interpretation is that both ends are locked by the same entity (either NMS or OAM). Is it right?

Section 5: “LI messages may be lost during looping or maintenance operations, thus locking both ends is required, before such operations occur.”
➢ does it mean that when Loopback function is used,  both ends should be locked by NMS?

Section 5: “When a transport path is put in loopback, traffic sent from the sender MEP will be looped back to that sender MEP.”
➢ if loopback is performed at a MIP, how can LI messages reach the far end MEP to preserve the LOCK state at MEP-D? it seems that LI should be performed by NMS at the two ends to avoid race condition between the two tools (Lock Instruct and Loopback) or to avoid complicated tools (selectively filtering LI messages at Loopback points)

section 6.3: “If no label binding exists or there is no associated transport path back to the originator … Processing ceases.”
➢ why should we have such restriction? does the protocol foresees a LI message back to MEP-A?

section 6.3: “Otherwise the message is processed”
➢ should the text be enriched (e.g. “and the MEP-D is locked.”) ?
➢ how does MEP-A know that MEP-D was successfully locked? It seems you propose a one-way handshake protocol

➢ Through the document “Lock message” and “LI message” have been used interchangeable. Should be aligned

Best regards,
Alessandro
------------------------------------------------------------------
Telecom Italia
Alessandro D'Alessandro
Transport Innovation
Via Reiss Romoli, 274 - 10148 Torino
phone:  +39 011 228 5887
mobile: +39 335 766 9607
fax: +39 06 418 639 07

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per conto di Loa Andersson
Inviato: lunedì 15 agosto 2011 21:32
A: [email-masked]; [email-masked]; MPLS-TP ad hoc team; [email-masked]; CCAMP
Oggetto: [CCAMP] MPLS working group last call on draft-ietf-mpls-tp-li-lb-03.txt

Working Group,

this is to start a working group last call on draft-ietf-mpls-tp-li-lb-03.txt

Loa

--

Loa Andersson                         email: [email-masked]
Sr Strategy and Standards Manager            [email-masked]
Ericsson Inc                          phone: +46 10 717 52 13
                                              +46 767 72 92 13 _______________________________________________
CCAMP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ccamp

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

---

From: Yoshinori Koike <[email-masked]>
Date: Fri, 26 Aug 2011 05:45:41 +0900

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.

(3) More details about the configuration of data-plane loopback point(s) 
should be clarified.

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. If the point 
could be set by OAM message, the method and protocol needs to be 
specified in this draft.

Best regards,

Yoshinori Koike

---

From: Sami Boutros <[email-masked]>
Date: Sat, 27 Aug 2011 19:14:31 -0700

Hi Shahram,

The hard loopback function is expected to be done by the management 
plane as mentioned in the draft.

I see most of the comments are related to either a HW/SW 
implementation or a basic MPLS forwarding concept that would apply.

Please see comments inline..

At 01:32 PM 8/15/2011, Shahram Davari wrote:
>Hi,
>
>I have a general clarification question regarding this draft. It 
>seems that the exact position of the Transmit, Loopback and receive 
>MEP/MIP in the data-plane processing is not well defined, which 
>could lead to unpredictable results. For example what is the 
>expected behavior for Transmit, Receive and Loopback points:
>

Sami: It is expected that test traffic will be sent after putting the 
LSP in Loopback by management plane, how this test traffic be queued 
or shaped will purely depend on the implementation of the policy of 
the interfaces and is not something we should mention in the draft.

>- Loopback Before or after forwarding (Label Switching)?

Sami: When you set a Loopback you are impacting the Fwding plane at 
the point of Loopback to send traffic back..

>- Loopback at Ingress Port (Down-MEP) or Egress port (Up-MEP)?

Sami: This would depend on the Management plane setting up the Fwding 
and HW implementation of the box..

>- Loopback before TTL decrement or after TTL decrement?

Sami: This is basic MPLS forwarding, MPLS would decrement TTL as 
packets ingress a box.

>- Loopback before or after LSP termination at LSP terminating MEP?

Sami: When you loopback at terminating MEP, then this would mean that 
the label crossconnect set by Management plane would not terminate 
the LSP, I would expect an operator will know how to set the MPLS 
Xconnect at the LB point.

>- loopback or not Loopback LSP-Ping messages not defined in this draft?

Sami: This is again basic MPLS forwarding, i.e. when you set an MPLS 
Xconnect at the loopback point, packets will be inspected only if the 
TTL expire.

Thanks,

Sami

---

From: Sami Boutros <[email-masked]>
Date: Sat, 27 Aug 2011 19:18:49 -0700

>- How does the MIP get out of loopback?

Sami: As mentioned in the draft this is done by Management plane.

>- How does the Ingress MEP know that the MIP is or is not in loopback mode?

Sami: Since this is done via Management plane, then the operator need 
to make sure that the LSP is locked before putting the circuit in Loopback.

>previous versions of the draft addressed all these issues, but I am 
>wondering how are these done without special messages and Acks.

Sami: We revisited the previous drafts, and the consensus among 
authors was to send a periodic message for the lockout and not rely 
on the request ack technique, primarily to make it more robust, and 
consistent with the Fault reporting mechanisms in the Fault draft and 
PSC drafts too.

Thanks,

Sami

>To: 'Loa Andersson'; [email-masked]'; [email-masked]'; 
>'MPLS-TP ad hoc team'; [email-masked]'; 'CCAMP'
>pwe3 mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/pwe3

---

From: Sami Boutros <[email-masked]>
Date: Sat, 27 Aug 2011 19:56:32 -0700

At 05:32 AM 8/18/2011, D'Alessandro Alessandro Gerardo wrote:
>Abstract/introduction: â€œThis document 
>specifies one function and describes a second 
>function … the second enables an operator to 
>set, in looopback, a given node along
>a transport path.â€
>âž¢ In my opinion the document's body does not 
>reflect the abstract/introduction. Actually 
>there is a very short reference to loopback 
>function carried out by NMS that cannot be 
>considered covered by the document (and the 
>title should therefore refer to LI only) as in the previous version (-02).

Sami: All versions had li-lb in the name, agree 
we can add a short section on the reasons to why 
LB function must be done by NMS.

>Introduction: â€œThe Lock function is operated 
>from MEP to MEP on bidirectional (associated and 
>co-routed) Label Switched Paths (LSPs), 
>Pseudowires (including multi-segment Pseudowires).â€
>âž¢ why have not sections been covered as per RFC 5860?

Sami: We can add sections to the coverage.

>Introduction: â€œcontrol traffic (such as OAM 
>messages dedicated to the transport path) can be mappedâ€
>Section 4.1: â€œvia management or controlâ€; Section 5
>âž¢ from rfc 5860 "Note that lock corresponds to 
>an administrative status in which it is expected 
>that only test traffic, if any, and OAM 
>(dedicated to the PW, LSP, or Section) can be 
>mapped on that PW, LSP, or Section".  What does 
>"control traffic" mean in the document? is it 
>something different from OAM as described in RFC 5860?

Sami: It is mainly OAM, we can update the text.

>Introduction: â€œThe Loopback function is 
>operated from MEP to MEP on bidirectional 
>(associated and co-routed) Label Switched Paths 
>(LSPs), Pseudowires (including multi-segment Pseudowires).â€
>âž¢ (why have not sections been covered?

Sami: Will address adding sections to the coverage.

>Introduction: â€œtraffic sent by the source will 
>be received by that source.â€
>âž¢ A question for clarification: Does the 
>loopback function here described cover all 
>traffic types (customer traffic, OAM traffic, 
>Control traffic, etc) as per RFC 5860?

Sami: Yes.

>Introduction: â€œThe Loopback can be performed using a management planeâ€
>âž¢ is management plane approach the only one 
>foreseen? "can" seems suggesting other ways as 
>for example the usage of OAM messages as 
>proposed in the previous version. Could the 
>author explain the reasons for excluding such an 
>approach (loopback function by OAM) from this 
>version? With respect to the document 
>description, being the loopback function 
>performed by NMS & due to the fact that "NMS 
>MUST insure that the two MEPS are locked before 
>performing the loopback function" I don't see 
>any advantage in considering the loopback 
>function in this document because it is evident 
>that there is a limited advantage in using LI 
>messages (i.e. Lock and Loopback can be easily performed by NMS)

Sami: The LI messages is as mentioned in Section 
5, "The purpose of the LI message is to ensure 
the tight coordination of locking and unlocking 
the two ends." , keep in mind an LSP is not only 
locked to perform Loopback this function is 
needed to take an LSP out of service, as for the 
reasons why only NMS for Loopback function and 
not using an OAM message, we will add a short 
section explaining the reasons for that.

>Section 3.2: â€œWhen a lock is applied, a refresh timer is chosenâ€
>âž¢ the lock you refer here is on one side only 
>or does it refer to both sides (e.g. when NMS 
>lock MEP-A of a transport path, then when the 
>first LI message is sent, the refresh value 
>cannot be changed for the duration of the lock on the MEP-A)

Sami: Correct the Lock refresh is one side only.

>section 3.2: â€œMEP Source ID TLVâ€
>âž¢ only Global-ID MEP are described. They are a 
>subset of MEP ID specified in the draft-Identifier.

Sami: We are using all formats defined  MEP 
Source ID TLV: This is the "CC/CV MEP ID TLV" defined in [cc-cv-rdi] draft.

>section 4: â€œlock is used to request a MEP …â€
>âž¢ it is not clear the way â€œLLOCKâ€ is used. 
>Is it â€œLock Instruct messageâ€ or â€œNMS 
>commandâ€ or are you referring to a â€œME stateâ€?

Sami: I believe the text is clear, when NMS 
request a MEP to Lock, then the LI messages will 
be sent periodically by this MEP, the receiver 
MEP will be locked as long as it is receiving the 
LI messages and they didn't timeout i.e. being refreshed.

>Section 4.1: â€œUnlock is used to request a MEP…â€
>âž¢ Same comment as above… is it an â€œNMS 
>commandâ€ oor are you referring to a â€œstateâ€?

Sami: Can you be more specific or suggest a text that will make things clear?

>Section 4.1: â€œWhen a MEP is unlocked via 
>management or control it MUST cease sending LI messages.â€
>âž¢ from section 4 seems there are MEPs that are 
>locked receiving LI messages but such MEPs seem 
>do not generating any LI messages. suggest 
>rewording because it seems that also MEP-D ceases sending LI messages

Sami: a MEP will send LI messages iff it has been 
request by Management plane to do so, the text is 
very clear about that, and it would cease to send 
LI messages upon Management request. In the 
example in section 6.3/6.4 MEP-D wasn't requested 
by Management to Lock, it was locked because of 
the LI messages received from MEP-A.

>section 5: â€œWhen an LSP is locked, the 
>management or control function is expected to lock both ends.â€
>âž¢ my interpretation is that both ends are 
>locked by the same entity (either NMS or OAM). Is it right?

Sami: A MEP can be locked because it was 
requested by NMS to lock and as such it is 
sending LI OAM messages, and/or it is receiving 
OAM LI messages from the other End. A MEP is 
unlocked when there is no NMS request and no LI OAM messages received.

>Section 5: â€œLI messages may be lost during 
>looping or maintenance operations, thus locking 
>both ends is required, before such operations occur.â€
>âž¢ does it mean that when Loopback function is 
>used,  both ends should be locked by NMS?

Sami: Correct.

>Section 5: â€œWhen a transport path is put in 
>loopback, traffic sent from the sender MEP will 
>be looped back to that sender MEP.â€
>âž¢ if loopback is performed at a MIP, how can 
>LI messages reach the far end MEP to preserve 
>the LOCK state at MEP-D? it seems that LI should 
>be performed by NMS at the two ends to avoid 
>race condition between the two tools (Lock 
>Instruct and Loopback) or to avoid complicated 
>tools (selectively filtering LI messages at Loopback points)

Sami: This is why we say in introduction 
"Management plane MUST insure that the two MEPs 
are locked before performing the loopback function."

>section 6.3: â€œIf no label binding exists or 
>there is no associated transport path back to 
>the originator … Processing ceases.â€
>âžž¢ why should we have such restriction? does 
>the protocol foresees a LI message back to MEP-A?

Sami: Not sure I get the restriction, we don't 
claim that we will lock unidirectional LSPs.

>section 6.3: â€œOtherwise the message is processedâ€
>âž¢ should the text be enriched (e.g. â€œand the MEP-D is locked.â€) ?
>âž¢ how does MEP-A know that MEP-D was 
>successfully locked? It seems you propose a one-way handshake protocol

Sami: Correct, this is exactly the same like the 
fault mechanisms described in the fault draft.

>âž¢ Through the document â€œLock messageâ€ and 
>â€œLI messageâ€ have been used interchangeable. Should be aligned

Sami: Will address.

Thanks,

Sami

>Da: [email-masked] 
>[mailto:[email-masked]] Per conto di Loa Andersson
>Inviato: lunedÃ¬ 15 agosto 2011 21:32
>A: [email-masked]; [email-masked]; 
>MPLS-TP ad hoc team; [email-masked]; CCAMP
>Questo messaggio e i suoi allegati sono 
>indirizzati esclusivamente alle persone 
>indicate. La diffusione, copia o qualsiasi altra 
>azione derivante dalla conoscenza di queste 
>informazioni sono rigorosamente vietate. Qualora 
>abbiate ricevuto questo documento per errore 
>siete cortesemente pregati di darne immediata 
>comunicazione al mittente e di provvedere alla sua distruzione, Grazie.
>
>This e-mail and any attachments is confidential 
>and may contain privileged information intended 
>for the addressee(s) only. Dissemination, 
>copying, printing or use by anybody else is 
>unauthorised. If you are not the intended 
>recipient, please delete this message and any 
>attachments and advise the sender by return e-mail, Thanks.
>
>mpls mailing list [email-masked] https://www.ietf.org/mailman/listinfo/mpls

---

From: Loa Andersson <[email-masked]>
Date: Sun, 28 Aug 2011 10:42:32 +0200

Working Group,

this last call has ended! There has been comments can the authors
please address comments and publish a new version of the draft.

/Loa

--

---

From: Sami Boutros <[email-masked]>
Date: Sun, 28 Aug 2011 08:48:51 -0700

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

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

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

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

Thanks,

Sami

---

From: Yoshinori Koike <[email-masked]>
Date: Tue, 30 Aug 2011 05:08:32 +0900

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

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

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?

LSPs, and on multi-segment Pseudowires."

>> 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.
>>
>> 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: Can you please be more specific? is this part of the text you

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

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)"

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.

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

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

Best regards,

Yoshinori

---

From: Sami Boutros <[email-masked]>
Date: Mon, 29 Aug 2011 16:51:59 -0700

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

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

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

>function(one side or both side) needs to be configured.

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.

Sami: Correct.

>[YK] Thank you for the clarification.

Sami: Thanks for your comments.

Sami