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

[Yimin Shen <[e-mail]>]

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:[e-mail]] 
Sent: Monday, March 24, 2014 11:07 PM
To: Yimin Shen; [e-mail]; [e-mail]
Subject: RE: Mail regarding draft-chen-mpls-source-label

Hi Yimin,

Please see my reply inline...

> -----Original Message-----
> From: Yimin Shen [mailto:[e-mail]]
> Sent: Saturday, March 22, 2014 2:40 AM
> To: Mach Chen; [e-mail]; 
> [e-mail]
> Subject: RE: Mail regarding draft-chen-mpls-source-label
> 
> Hi Mach,
> 
> 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
> 
> Thanks,
> 
> /Yimin
> 
> 
> -----Original Message-----
> From: Mach Chen [mailto:[e-mail]]
> Sent: Thursday, March 20, 2014 11:00 AM
> To: Yimin Shen; [e-mail]; 
> [e-mail]
> Subject: RE: Mail regarding draft-chen-mpls-source-label
> 
> 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:[e-mail]] On Behalf Of Yimin Shen
> > Sent: Thursday, March 20, 2014 12:03 AM
> > To: [e-mail]; [e-mail]
> > 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
> >
> >
> >
> >
> 
>