Subject: [CCAMP] 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: 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: 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

--