Subject: Re: [mpls] Mail regarding draft-chen-mpls-source-label

From: Mach Chen <[email-masked]>
Date: Thu, 20 Mar 2014 15:00:00 +0000

Hi Yimin,

Thanks for your questions and comments!

Please see my reply inline...

> -----Original Message-----
> From: Mach Chen
> Sent: Thursday, March 20, 2014 10:45 PM
> To: Mach Chen
> Subject: FW: Mail regarding draft-chen-mpls-source-label
> 
> 
> 
> From: mpls [mailto:[email-masked]] On Behalf Of Yimin Shen
> Sent: Thursday, March 20, 2014 12:03 AM
> To: [email-masked]; [email-masked]
> Subject: [mpls] Mail regarding draft-chen-mpls-source-label
> 
> Hi authors,
> 
> Can you please clarify if SL is expected to be used only by egress node, or by
> intermediate node as well ?

The SL can be used by the egress and intermediate node, but for intermediate node, since the SL may not be on the top of the label stack, if it wants to use it, it needs to search the label stack to find the SL, just as to find an EL.

> 
> Section 3.2 "Traffic Matrix Measurement and Steering" describes a use case
> for intermediate node, but I think congestion should in general be resolved by
> control plane to reroute traffic based on a global view of network resources,
> rather than by data plane based on a SL. In your case, would the intermediate
> node move the traffic to an LSP that is different than the LSP intended by the
> ingress node ? I don't think it is the right thing to do.
> 
> Regarding the use case of section 3.3 "Source Filtering". If somebody is doing
> DoS attack, why would he put an SL in the packets ?

Regarding to these two use cases, as discussed with Curtis, there need more considerations, we will remove these two section in the next revision.

Thanks,
Mach

> Thanks,
> /Yimin

---

From: Yimin Shen <[email-masked]>
Date: Fri, 21 Mar 2014 18:39:36 +0000

Hi Mach,

For an intermediate node, SL would definitely NOT be at the top of _incoming_ label stack. You would have to install complex forwarding state in data plane to look for SL and process the packet differently based on the existence/non-existence of SL. It would get even more complicated if you need to put the SL back to the packets, in case other nodes downstream may also be expecting it. So I'd like to see a valid use case for this increased complexity and overhead.

Regarding the egress node use case, note that it is different than Entropy labels, where an EL is actually used by intermediate nodes and only popped by egress node. So, if your goal is simply to inform an egress node about the identity of a source node, the source node could just push one label to identify itself. This label could be configured or communicated between the egress node and the source node in any fashion. However in this draft, the source node would have to push 3 extra labels (for SL).

Thanks,

/Yimin

-----Original Message-----
From: Mach Chen [mailto:[email-masked]] 
Sent: Thursday, March 20, 2014 11:00 AM
To: Yimin Shen; [email-masked]; [email-masked]
Subject: RE: Mail regarding draft-chen-mpls-source-label

Hi Yimin,

> Can you please clarify if SL is expected to be used only by egress 
> node, or by intermediate node as well ?

> 
> Section 3.2 "Traffic Matrix Measurement and Steering" describes a use 
> case for intermediate node, but I think congestion should in general 
> be resolved by control plane to reroute traffic based on a global view 
> of network resources, rather than by data plane based on a SL. In your 
> case, would the intermediate node move the traffic to an LSP that is 
> different than the LSP intended by the ingress node ? I don't think it is the right thing to do.
> 
> Regarding the use case of section 3.3 "Source Filtering". If somebody 
> is doing DoS attack, why would he put an SL in the packets ?

Thanks,
Mach

---

From: Mach Chen <[email-masked]>
Date: Tue, 25 Mar 2014 03:06:32 +0000

Hi Yimin,

> From: Yimin Shen [mailto:[email-masked]]
> Sent: Saturday, March 22, 2014 2:40 AM
> To: Mach Chen; [email-masked]; [email-masked]
> For an intermediate node, SL would definitely NOT be at the top of _incoming_
> label stack.

Not exactly, if PHP is enabled, the penultimate LSR may see the SLI/SL pair. But anyway, this is not the crux.

> You would have to install complex forwarding state in data plane to
> look for SL and process the packet differently based on the
> existence/non-existence of SL. It would get even more complicated if you need
> to put the SL back to the packets, in case other nodes downstream may also be
> expecting it. So I'd like to see a valid use case for this increased complexity and
> overhead.

Firstly, based on my experience, I do not think that this is "complicated" as you said. It depends on how scalable your implementation is. To find a SL, there is no difference from finding an EL. The other thing (e.g., ACL and counting) is mature and proved technologies.

Intermediate LSR processing SL is mainly for segment performance measurement that is very useful in fault localization, and this is the requirement from SPs (please see: http://tools.ietf.org/html/draft-deng-ippm-wireless-01) and I also heard such requirements from many other service providers. So the use case is valid imho.

In addition, the draft just says:
"There is no change in forwarding behavior for transit LSRs.  But if a
   transit LSR can recognize the SLI, it can use the SL to collect
   traffic throughput and/or measure the performance of the LSP."

This means that processing SL in transit LSRs is optional, means that your devices are unable to process it or you do not need it, that is fine. 

> 
> Regarding the egress node use case, note that it is different than Entropy labels,
> where an EL is actually used by intermediate nodes and only popped by egress

As said above, the intermediate LSRs may expect to see the SL.
 
> node. So, if your goal is simply to inform an egress node about the identity of a
> source node, the source node could just push one label to identify itself. This

How does the egress LSR knows whether a label is for source identifying? Are you talking about establishing a PW-like LSP over the LSP?

> label could be configured or communicated between the egress node and the
> source node in any fashion. However in this draft, the source node would have to
> push 3 extra labels (for SL).

There are only SLI/SL inserted, where is the 3rd?

Thanks,
Mach
> The SL can be used by the egress and intermediate node, but for intermediate
> node, since the SL may not be on the top of the label stack, if it wants to use it, it
> needs to search the label stack to find the SL, just as to find an EL.
> 
> >
> Regarding to these two use cases, as discussed with Curtis, there need more
> considerations, we will remove these two section in the next revision.
> 
> Thanks,
> Mach
> 
> >
> > Thanks,
> >
> > /Yimin
> >
> >
> >
> >
> 
>

---

From: Shahram Davari <[email-masked]>
Date: Tue, 25 Mar 2014 03:24:02 +0000

Hi

So far I haven't seen any valid use car that would only be possible by adding this 3 labels. For VPLS LM you could always use Synthetic loss measurement. Just saying Synthetic LM is not as accurate as direct LM is not a good justification for adding 3 labels. 

Regards,
Shahram

> On Mar 21, 2014, at 11:39 AM, "Yimin Shen" <[email-masked]> wrote:
> 
> Hi Mach,
> 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: Gregory Mirsky <[email-masked]>
Date: Tue, 25 Mar 2014 04:52:41 +0000

Hi Shahram,
many thanks for your interest and comments. I'd point that SLM is clearly out-of-service OAM tool. SLI/SL may be used to perform in-service active LM as well as passive LM. Then there is DM and SLI/SL again can be used to perform in-service both active and passive DM.
As for use case that " that would only be possible by adding" these three labels I can think of the following:
*       OAM on mp2mp/mp2p LSP

        Regards,
                Greg

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of Shahram Davari
Sent: Monday, March 24, 2014 8:24 PM
To: Yimin Shen
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls] Mail regarding draft-chen-mpls-source-label

Hi

Regards,
Shahram

> On Mar 21, 2014, at 11:39 AM, "Yimin Shen" <[email-masked]<mailto:[email-masked]>> wrote:
>
> Hi Mach,
>
> To: Yimin Shen; [email-masked]<mailto:[email-masked]>;
> [email-masked]<mailto:[email-masked]>
>> To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
>> be resolved by control plane to reroute traffic based on a global
>> view of network resources, rather than by data plane based on a SL.
>> In your case, would the intermediate node move the traffic to an LSP
>> that is different than the LSP intended by the ingress node ? I don't think it is the right thing to do.
>>
> [email-masked]<mailto:[email-masked]>

_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls

---

From: "S. Davari" <[email-masked]>
Date: Mon, 24 Mar 2014 22:01:00 -0700

Hi Greg

Thanks for your reply. SLM can be used for in service measurement. And it works for Mp2p and mp2mp. So you don't really need the 3 extra labels.

Regards,.
Shahram

> On Mar 24, 2014, at 9:52 PM, Gregory Mirsky <[email-masked]> wrote:
> 
> Hi Shahram,
> OAM on mp2mp/mp2p LSP

---

From: Gregory Mirsky <[email-masked]>
Date: Tue, 25 Mar 2014 05:19:44 +0000

Hi Shahram,
many thanks for most expedient response.
Firstly, regarding in-service SLM. AFAIK, the difference between LM and SLM, at least in Y.1731, is that the former collects counters of “in-profile” frames while the latter only counts the test packets themselves. Given that, I can not agree that using SLM as in-service active measurement method is viable unless operator willing to sufficiently alter data traffic behavior.
Secondly, would be great if you can expand on “it works for Mp2p and mp2mp”. I’m very interested to learn from you how to do LM on mp2mp LSP with current MPLS OAM tools, i.e. without SLI/SL. And while we are at  this topic, would you kindly explain how SLM helps with DM over the same construct, i.e. mp2mp LSP.

                Regards,
                                Greg

From: S. Davari [mailto:[email-masked]]
Sent: Monday, March 24, 2014 10:01 PM
To: Gregory Mirsky
Cc: Shahram Davari; Yimin Shen; [email-masked]; [email-masked]
Subject: Re: [mpls] Mail regarding draft-chen-mpls-source-label

Hi Greg

Regards,.
Shahram

On Mar 24, 2014, at 9:52 PM, Gregory Mirsky <[email-masked]<mailto:[email-masked]>> wrote:
Hi Shahram,
many thanks for your interest and comments. I'd point that SLM is clearly out-of-service OAM tool. SLI/SL may be used to perform in-service active LM as well as passive LM. Then there is DM and SLI/SL again can be used to perform in-service both active and passive DM.
As for use case that " that would only be possible by adding" these three labels I can think of the following:
·         OAM on mp2mp/mp2p LSP

        Regards,
                Greg

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of Shahram Davari
Sent: Monday, March 24, 2014 8:24 PM
To: Yimin Shen
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] Mail regarding draft-chen-mpls-source-label

Hi

Regards,
Shahram

---

From: "S. Davari" <[email-masked]>
Date: Mon, 24 Mar 2014 22:50:11 -0700

Hi Greg

In profile simply means green packets and by generate green SLM packets you could achieve the same results.

MEF explains how SLM is used for non p2p services. 

And For Delay measurement you can just run DM. The source info can be in The payload of DM as TLV.

Regards,
Shahram

> On Mar 24, 2014, at 10:19 PM, Gregory Mirsky <[email-masked]> wrote:
> 
> Hi Shahram,

---

From: Gregory Mirsky <[email-masked]>
Date: Tue, 25 Mar 2014 06:06:13 +0000

Hi Shahram,
consider flow at 99% of its CIR. How would you perform  in-service measure with SLM?
AFAIK, MEF considers LM of E-LAN service as matrix of p2p measurements. It is interesting approach but not yet adopted by IETF.
Yes, you may do proprietary things with payload. Or use SLI/SL.

                Regards,
                                Greg

From: S. Davari [mailto:[email-masked]]
Sent: Monday, March 24, 2014 10:50 PM
To: Gregory Mirsky
Cc: Shahram Davari; Yimin Shen; [email-masked]; [email-masked]
Subject: Re: [mpls] Mail regarding draft-chen-mpls-source-label

Hi Greg

Regards,
Shahram

On Mar 24, 2014, at 10:19 PM, Gregory Mirsky <[email-masked]<mailto:[email-masked]>> wrote:
Hi Shahram,
many thanks for most expedient response.
Firstly, regarding in-service SLM. AFAIK, the difference between LM and SLM, at least in Y.1731, is that the former collects counters of “in-profile” frames while the latter only counts the test packets themselves. Given that, I can not agree that using SLM as in-service active measurement method is viable unless operator willing to sufficiently alter data traffic behavior.
Secondly, would be great if you can expand on “it works for Mp2p and mp2mp”. I’m very interested to learn from you how to do LM on mp2mp LSP with current MPLS OAM tools, i.e. without SLI/SL. And while we are at  this topic, would you kindly explain how SLM helps with DM over the same construct, i.e. mp2mp LSP.

                Regards,
                                Greg

From: S. Davari [mailto:[email-masked]]
Sent: Monday, March 24, 2014 10:01 PM
To: Gregory Mirsky
Cc: Shahram Davari; Yimin Shen; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] Mail regarding draft-chen-mpls-source-label

Hi Greg

Regards,.
Shahram

        Regards,
                Greg

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of Shahram Davari
Sent: Monday, March 24, 2014 8:24 PM
To: Yimin Shen
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] Mail regarding draft-chen-mpls-source-label

Hi

Regards,
Shahram

---

From: Mach Chen <[email-masked]>
Date: Tue, 25 Mar 2014 06:12:28 +0000

Hi Shahram,

Everybody knows there is SLM, but SPs need passive LM and DM in some scenarios(please refer to : http://tools.ietf.org/html/draft-deng-ippm-wireless-01 and RFC6374). Both active and passive PM have their application scenarios. 

Again, to correct a mistake here, same as EL, there are only two labels needed. 

Best regards,
Mach

> From: Shahram Davari [mailto:[email-masked]]
> Sent: Tuesday, March 25, 2014 11:24 AM
> To: Yimin Shen
> Cc: Mach Chen; [email-masked]; [email-masked]
> So far I haven't seen any valid use car that would only be possible by adding this 3
> labels. For VPLS LM you could always use Synthetic loss measurement. Just
> saying Synthetic LM is not as accurate as direct LM is not a good justification for
> adding 3 labels.
> 
> Regards,
> Shahram
> 
> 
> label stack. You would have to install complex forwarding state in data plane to

---

From: "S. Davari" <[email-masked]>
Date: Mon, 24 Mar 2014 23:27:19 -0700

You don't need high rate SLM packets. Just send them at low rate. That is how SLM works.

Yes MEF defines it as Matrix of pair-wise measurement and it mandates only the SLM, while direct loss measurement is optional. SLM was designed to work in multi point services.

Regards,
Shahram

> On Mar 24, 2014, at 11:06 PM, Gregory Mirsky <[email-masked]> wrote:
> 
> Hi Shahram,

---

From: Mach Chen <[email-masked]>
Date: Tue, 25 Mar 2014 06:27:53 +0000

Hi Shahram,

Are you claiming that the active performance measurement is sufficient and passive performance measurement is not needed?

Best regards,
Mach

From: mpls [mailto:[email-masked]] On Behalf Of S. Davari
Sent: Tuesday, March 25, 2014 1:50 PM
To: Gregory Mirsky
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls] Mail regarding draft-chen-mpls-source-label

Hi Greg

Regards,
Shahram

                Regards,
                                Greg

Hi Greg

Regards,.
Shahram

        Regards,
                Greg

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of Shahram Davari
Sent: Monday, March 24, 2014 8:24 PM
To: Yimin Shen
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] Mail regarding draft-chen-mpls-source-label

Hi

Regards,
Shahram

---

From: "S. Davari" <[email-masked]>
Date: Mon, 24 Mar 2014 23:50:17 -0700 (PDT)

Hi,

You did not prove yet why active 
(Synthetic) measurement is not enough in MPLS networks. I would in fact 
 argue that by adding XL/SLI/SL to the data packets during the LM 
measurement the network can use a different ECMP path than when you are 
not using the XL/SLI/SL and therefore your measurement is only valid 
during the measurement interval and does not represent what the user 
experiences after the measurement is over.

Thx
Shahram

________________________________
 From: Mach Chen <[email-masked]>
To: S. Davari <[email-masked]>; Gregory Mirsky <[email-masked]> 
Cc: "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]> 
Sent: Monday, March 24, 2014 11:27:53 PM
Subject: RE: [mpls] Mail regarding draft-chen-mpls-source-label

Hi Shahram,

Best regards,
Mach
 
From:mpls [mailto:[email-masked]] On Behalf Of S. Davari
Sent: Tuesday, March 25, 2014 1:50 PM
To: Gregory Mirsky
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls] Mail regarding draft-chen-mpls-source-label
 
Hi Greg

 

Regards,
Shahram

>From:S. Davari [mailto:[email-masked]]

---

From: "S. Davari" <[email-masked]>
Date: Mon, 24 Mar 2014 23:50:57 -0700 (PDT)

Hi Mach,

The draft you refer to, refers
 to wireless backhaul, which as far as I know,  does not use multi-point
 service, and you could use normal P2P LM/DM. Regarding the number of 
labels, note that there are not many reserved labels left and as per 
following IETF draft pretty much no more reserved label can be assigned 
without the use of Extended Label Indiactor, which means you need 3 
labels: XL-SLI-SL

http://tools.ietf.org/html/draft-ietf-mpls-special-purpose-labels-06

Thx
Shahram

________________________________
 From: Mach Chen <[email-masked]>
To: Shahram Davari <[email-masked]>; Yimin Shen <[email-masked]> 
Cc: "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]> 
Sent: Monday, March 24, 2014 11:12:28 PM
Subject: Re: [mpls] Mail regarding draft-chen-mpls-source-label

Hi Shahram,

Best regards,
Mach

---

From: Mach Chen <[email-masked]>
Date: Tue, 25 Mar 2014 08:32:25 +0000

Hi Shahram,

IP/MPLS is commonly used in the mobile backhaul, and many of the networks use pure LDP based tunnel. The service is point-to-point (e.g., from CSG to RSG),  but the LDP based tunnel is actually MP2P model. And several customers require to support passive performance in their mobile backhaul network.

Regarding the number of labels, I agree if only the Extended special purpose label can be assigned, but if the normal special purpose label is assigned, then only two extra labels.

Best regards,
Mach

From: S. Davari [mailto:[email-masked]]
Sent: Tuesday, March 25, 2014 2:51 PM
To: Mach Chen; Shahram Davari; Yimin Shen
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls] Mail regarding draft-chen-mpls-source-label

Hi Mach,

The draft you refer to, refers to wireless backhaul, which as far as I know,  does not use multi-point service, and you could use normal P2P LM/DM. Regarding the number of labels, note that there are not many reserved labels left and as per following IETF draft pretty much no more reserved label can be assigned without the use of Extended Label Indiactor, which means you need 3 labels: XL-SLI-SL

Thx
Shahram

________________________________
From: Mach Chen <[email-masked]<mailto:[email-masked]>>
To: Shahram Davari <[email-masked]<mailto:[email-masked]>>; Yimin Shen <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>; "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Sent: Monday, March 24, 2014 11:12:28 PM
Subject: Re: [mpls] Mail regarding draft-chen-mpls-source-label

Hi Shahram,

Best regards,
Mach

> From: Shahram Davari [mailto:[email-masked]<mailto:[email-masked]>]
> Cc: Mach Chen; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
> > From: Mach Chen [mailto:[email-masked]<mailto:[email-masked]>]
> >> From: mpls [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Yimin Shen

---

From: Mach Chen <[email-masked]>
Date: Tue, 25 Mar 2014 10:06:16 +0000

Hi Shahram,

Mobile backhaul is the main target scenario where some of the services (e.g., some wireless signals between nodeB and RNC) are very sensitive to packet loss. Sometimes, although there are some packets loss, it may not be detected by SLM, this leads the Nodeb to detach from the RNC. This happened several times in the production network. Even worse, since SLM depends on inject extra packets to evaluate the performance, the SLM itself may sometime lead to or increase packet loss and result in negative impacts.

Best regards,
Mach

From: S. Davari [mailto:[email-masked]]
Sent: Tuesday, March 25, 2014 2:50 PM
To: Mach Chen; Gregory Mirsky
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls] Mail regarding draft-chen-mpls-source-label

Hi,

You did not prove yet why active (Synthetic) measurement is not enough in MPLS networks. I would in fact  argue that by adding XL/SLI/SL to the data packets during the LM measurement the network can use a different ECMP path than when you are not using the XL/SLI/SL and therefore your measurement is only valid during the measurement interval and does not represent what the user experiences after the measurement is over.

Thx
Shahram

To: S. Davari <[email-masked]<mailto:[email-masked]>>; Gregory Mirsky <[email-masked]<mailto:[email-masked]>>

Hi Shahram,

Best regards,
Mach

Hi Greg

Regards,
Shahram

                Regards,
                                Greg

Hi Greg

Regards,.
Shahram

•         OAM on mp2mp/mp2p LSP

        Regards,
                Greg

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of Shahram Davari
Sent: Monday, March 24, 2014 8:24 PM
To: Yimin Shen
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] Mail regarding draft-chen-mpls-source-label

Hi

Regards,
Shahram

---

From: "S. Davari" <[email-masked]>
Date: Tue, 25 Mar 2014 03:08:11 -0700

Hi Mach

Since the service is P2P, each bas station has its own PW. Therefore there is no need to identify each BS using yet another label. 

Regards,
Shahram

> On Mar 25, 2014, at 1:32 AM, Mach Chen <[email-masked]> wrote:
> 
> Hi Shahram,
>

---

From: "S. Davari" <[email-masked]>
Date: Tue, 25 Mar 2014 07:55:36 -0700

Hi Mach

What I was arguing is that China mobile uses p2p LSP and PW and does not use any MP2P or MP2MP LSP. So China mobile can use RFC6374 or G.8131 to measure loss and delay over the Backhaul.

Secondly if very very small packet loss is also important to be detected then I suggest using the CW sequence number to detect such loss without adding complexity to the network.

Basically what you are doing is like adding 3 more wheels to a car so that you can recognize it easier when it is moving. While The right method is to read the license plate.

Regards,
Shahram

> On Mar 25, 2014, at 3:06 AM, Mach Chen <[email-masked]> wrote:
> 
> Hi Shahram,
>

---

From: Mach Chen <[email-masked]>
Date: Wed, 26 Mar 2014 02:23:46 +0000

Hi Shahram

The problem is that not all the networks deploy PW to transport the service, there are quite number of networks use L3VPN and other techniques.

Best regards,
Mach

From: S. Davari [mailto:[email-masked]]
Sent: Tuesday, March 25, 2014 6:08 PM
To: Mach Chen
Cc: Shahram Davari; Yimin Shen; [email-masked]; [email-masked]
Subject: Re: [mpls] Mail regarding draft-chen-mpls-source-label

Hi Mach

Regards,
Shahram

On Mar 25, 2014, at 1:32 AM, Mach Chen <[email-masked]<mailto:[email-masked]>> wrote:
Hi Shahram,

Best regards,
Mach

Hi Mach,

Thx
Shahram

Hi Shahram,

Best regards,
Mach

---

From: Mach Chen <[email-masked]>
Date: Wed, 26 Mar 2014 02:25:46 +0000

Hi Shahram,

I am not talking about a specific SP, I am not sure whether you really know the current status of the MBB network.

Best regards,
Mach

From: S. Davari [mailto:[email-masked]]
Sent: Tuesday, March 25, 2014 10:56 PM
To: Mach Chen
Cc: Gregory Mirsky; [email-masked]; [email-masked]
Subject: Re: [mpls] Mail regarding draft-chen-mpls-source-label

Hi Mach

Regards,
Shahram

On Mar 25, 2014, at 3:06 AM, Mach Chen <[email-masked]<mailto:[email-masked]>> wrote:
Hi Shahram,

Best regards,
Mach

Hi,

Thx
Shahram

Hi Shahram,

Best regards,
Mach

Hi Greg

Regards,
Shahram

                Regards,
                                Greg

Hi Greg

Regards,.
Shahram

        Regards,
                Greg

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of Shahram Davari
Sent: Monday, March 24, 2014 8:24 PM
To: Yimin Shen
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] Mail regarding draft-chen-mpls-source-label

Hi

Regards,
Shahram

---

From: Mach Chen <[email-masked]>
Date: Wed, 26 Mar 2014 02:32:23 +0000

Hi Shahram,

For you refer, there is another draft (http://tools.ietf.org/html/draft-zheng-l3vpn-pm-analysis-02 ) talks about the requirement and gaps of performance measurement of L3VPN.

Best regards,
Mach

From: Mach Chen
Sent: Wednesday, March 26, 2014 10:26 AM
To: 'S. Davari'
Cc: Gregory Mirsky; [email-masked]; [email-masked]
Subject: RE: [mpls] Mail regarding draft-chen-mpls-source-label

Hi Shahram,

Best regards,
Mach

From: S. Davari [mailto:[email-masked]]
Sent: Tuesday, March 25, 2014 10:56 PM
To: Mach Chen
Cc: Gregory Mirsky; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] Mail regarding draft-chen-mpls-source-label

Hi Mach

Regards,
Shahram

Best regards,
Mach

Hi,

Thx
Shahram

Hi Shahram,

Best regards,
Mach

Hi Greg

Regards,
Shahram

                Regards,
                                Greg

Hi Greg

Regards,.
Shahram

        Regards,
                Greg

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of Shahram Davari
Sent: Monday, March 24, 2014 8:24 PM
To: Yimin Shen
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] Mail regarding draft-chen-mpls-source-label

Hi

Regards,
Shahram

---

From: Shahram Davari <[email-masked]>
Date: Wed, 26 Mar 2014 03:12:28 +0000

Hi Mach

In L3VPN you could modify the VPN label distribution and distribute A unique VPN label to each remote VRF.

This would solve your problem by just software upgrade without need for new hardware.

Regards,
Shahram

On Mar 25, 2014, at 7:33 PM, "Mach Chen" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Shahram

Best regards,
Mach

Hi Mach

Regards,
Shahram

Best regards,
Mach

Hi Mach,

Thx
Shahram

Hi Shahram,

Best regards,
Mach

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 26 Mar 2014 03:15:15 +0000

What about if a route reflector is deployed?

发件人: mpls [mailto:[email-masked]] 代表 Shahram Davari
发送时间: 2014年3月26日 11:12
收件人: Mach Chen
抄送: [email-masked]; [email-masked]
主题: Re: [mpls] Mail regarding draft-chen-mpls-source-label

Hi Mach

Regards,
Shahram

Best regards,
Mach

Hi Mach

Regards,
Shahram

Best regards,
Mach

Hi Mach,

Thx
Shahram

Hi Shahram,

Best regards,
Mach

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 26 Mar 2014 11:33:34 +0000

Shahram

If you need to do true packet loss measurements in a MP2P system, then 
you need some form of source identifier in the label stack.

SLM is OK as a guide to QoS, but in high quality optical systems which 
have tiny packet loss rates it is quite limited in what it can do.

Stewart

---

From: "S. Davari" <[email-masked]>
Date: Wed, 26 Mar 2014 07:14:22 -0700

My suggestion is if a service is very sensitive  to packet loss and you want to measure very small packet loss then use P2P LSP rather than MP2P LSP and you can even do TE.

Regards,
Shahram

> On Mar 26, 2014, at 4:33 AM, Stewart Bryant <[email-masked]> wrote:
> 
> If you need to do true packet loss measurements in a MP2P system, then you need some form of source identifier in the label stack.
> 
> SLM is OK as a guide to QoS, but in high quality optical systems which have tiny packet loss rates it is quite limited in what it can do.
> 
> Stewart
> 
>

---

From: Yimin Shen <[email-masked]>
Date: Thu, 27 Mar 2014 12:53:57 +0000

Hi Mach,

- For an intermediate node, dealing with SL is different than dealing with EL. In the EL case, the node doesn't need to know if there is actually an EL present in the label stack, and hence it doesn't look for EL. All the node does is simply to hash on the label stack to do load balancing. However in your case, the node would really have to search for SL, and if it is found, interpret it, process it, and potentially insert it back to label stack. This is the complexity you would impose on data plane. Hence my concerns about the applicability for intermediate nodes.

- Regarding 3 labels. This would be XL (15), followed by ESPL (which you call SLI), and followed by SL, according to draft-ietf-mpls-special-purpose-labels.

- IMO, all you need is just an indicator of the source node, and as some comments have pointed out, there could be potential solutions using regular labels. Alternatively, this draft could extend the scope by considering both special purpose labels and regular labels as well.

Thanks,

/Yimin

-----Original Message-----
From: Mach Chen [mailto:[email-masked]] 
Sent: Monday, March 24, 2014 11:07 PM
To: Yimin Shen; [email-masked]; [email-masked]
Subject: RE: Mail regarding draft-chen-mpls-source-label

Hi Yimin,

> For an intermediate node, SL would definitely NOT be at the top of 
> _incoming_ label stack.

> existence/non-existence of SL. It would get even more complicated if 
> you need to put the SL back to the packets, in case other nodes 
> downstream may also be expecting it. So I'd like to see a valid use 
> case for this increased complexity and overhead.

> 
> Regarding the egress node use case, note that it is different than 
> Entropy labels, where an EL is actually used by intermediate nodes and 
> only popped by egress

> node. So, if your goal is simply to inform an egress node about the 
> identity of a source node, the source node could just push one label 
> to identify itself. This

> label could be configured or communicated between the egress node and 
> the source node in any fashion. However in this draft, the source node 
> would have to push 3 extra labels (for SL).

Thanks,
Mach
> The SL can be used by the egress and intermediate node, but for 
> intermediate node, since the SL may not be on the top of the label 
> stack, if it wants to use it, it needs to search the label stack to find the SL, just as to find an EL.
> 
> >
> > Section 3.2 "Traffic Matrix Measurement and Steering" describes a 
> > use case for intermediate node, but I think congestion should in 
> > general be resolved by control plane to reroute traffic based on a 
> > global view of network resources, rather than by data plane based on 
> > a SL. In your case, would the intermediate node move the traffic to 
> > an LSP that is different than the LSP intended by the ingress node ? 
> > I don't think it is the right
> thing to do.
> >
> > Regarding the use case of section 3.3 "Source Filtering". If 
> > somebody is doing DoS attack, why would he put an SL in the packets ?
> 
> Regarding to these two use cases, as discussed with Curtis, there need 
> more considerations, we will remove these two section in the next revision.
> 
> Thanks,
> Mach
> 
> >
> > Thanks,
> >
> > /Yimin
> >
> >
> >
> >
> 
>

---

From: Mach Chen <[email-masked]>
Date: Fri, 28 Mar 2014 03:48:53 +0000

Hi Yimin,

> Sent: Thursday, March 27, 2014 8:54 PM
> - For an intermediate node, dealing with SL is different than dealing with EL. In
> the EL case, the node doesn't need to know if there is actually an EL present in
> the label stack, and hence it doesn't look for EL. All the node does is simply to
> hash on the label stack to do load balancing. However in your case, the node
> would really have to search for SL, and if it is found, interpret it, process it, and
> potentially insert it back to label stack. This is the complexity you would impose
> on data plane. Hence my concerns about the applicability for intermediate nodes.

As said below, it's optional for an intermediate node to process SL. 

> 
> - Regarding 3 labels. This would be XL (15), followed by ESPL (which you call SLI),
> and followed by SL, according to draft-ietf-mpls-special-purpose-labels.

Sure, but the preference is to request a normal special purpose label. 

> 
> - IMO, all you need is just an indicator of the source node, and as some
> comments have pointed out, there could be potential solutions using regular
> labels. Alternatively, this draft could extend the scope by considering both special
> purpose labels and regular labels as well.

Regarding other potential solutions, we're open to hear and discuss. 

Thanks,
Mach

> Firstly, based on my experience, I do not think that this is "complicated" as you
> said. It depends on how scalable your implementation is. To find a SL, there is no
> difference from finding an EL. The other thing (e.g., ACL and counting) is mature
> and proved technologies.
> 
> Intermediate LSR processing SL is mainly for segment performance measurement
> that is very useful in fault localization, and this is the requirement from SPs
> (please see: http://tools.ietf.org/html/draft-deng-ippm-wireless-01) and I also
> heard such requirements from many other service providers. So the use case is
> valid imho.
> 
> This means that processing SL in transit LSRs is optional, means that your devices
> are unable to process it or you do not need it, that is fine.
> 
> >
> How does the egress LSR knows whether a label is for source identifying? Are
> you talking about establishing a PW-like LSP over the LSP?
>