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

[Sami Boutros <[e-mail]>]

At 05:32 AM 8/18/2011, D'Alessandro Alessandro Gerardo wrote:
>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 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

>Best regards,
>Alessandro
>------------------------------------------------------------------
>Telecom Italia
>Alessandro D'Alessandro
>Transport Innovation
>Via Reiss Romoli, 274 - 10148 Torino
>phone:  [phone]
>mobile: [phone]
>fax: [phone]
>
>
>-----Messaggio originale-----
>Da: [e-mail] 
>[mailto:[e-mail]] Per conto di Loa Andersson
>Inviato: lunedì 15 agosto 2011 21:32
>A: [e-mail]; [e-mail]; 
>MPLS-TP ad hoc team; [e-mail]; 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: [e-mail]
>Sr Strategy and Standards Manager            [e-mail]
>Ericsson Inc                          phone: [phone]
> 
>[phone] _______________________________________________
>CCAMP mailing list
>[e-mail]
>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.
>
>_______________________________________________ 
>mpls mailing list [e-mail] https://www.ietf.org/mailman/listinfo/mpls