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

From: Eric Gray <[email-masked]>
Date: Tue, 23 Aug 2011 14:28:38 -0400

Forwarding in plain text...

________________________________

From: D'Alessandro Alessandro Gerardo [mailto:[email-masked]] 
Sent: Thursday, August 18, 2011 5:52 AM
To: [email-masked]
Cc: Loa Andersson
Subject: R: [CCAMP] MPLS working group last call on draft-ietf-mpls-tp-li-lb-03.txt

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 text 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 have been used "Lock message" and "LI message" 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

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] <mailto:[email-masked]> 

Sr Strategy and Standards Manager            [email-masked] <mailto:[email-masked]> 

Ericsson Inc                          phone: +46 10 717 52 13

                                              +46 767 72 92 13 _______________________________________________

CCAMP mailing list

[email-masked] <mailto:[email-masked]> 

https://www.ietf.org/mailman/listinfo/ccamp <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. 

rispetta l'ambienteRispetta l'ambiente. Non stampare questa mail se non è necessario.