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

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mpls
Subject:    Re: [mpls] Mail regarding draft-chen-mpls-source-label
From:       Mach Chen <mach.chen () huawei ! com>
Date:       2014-03-28 3:48:53
Message-ID: F73A3CB31E8BE34FA1BBE3C8F0CB2AE25D99546F () SZXEMA510-MBX ! china ! huawei ! com
[Download RAW message or body]

Hi Yimin,

Please see my reply inline...

> -----Original Message-----
> From: Yimin Shen [mailto:yshen@juniper.net]
> Sent: Thursday, March 27, 2014 8:54 PM
> To: Mach Chen; draft-chen-mpls-source-label@tools.ietf.org; mpls@ietf.org
> Subject: RE: Mail regarding draft-chen-mpls-source-label
> 
> 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.

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

> 
> 
> Thanks,
> 
> /Yimin
> 
> 
> -----Original Message-----
> From: Mach Chen [mailto:mach.chen@huawei.com]
> Sent: Monday, March 24, 2014 11:07 PM
> To: Yimin Shen; draft-chen-mpls-source-label@tools.ietf.org; mpls@ietf.org
> Subject: RE: Mail regarding draft-chen-mpls-source-label
> 
> Hi Yimin,
> 
> Please see my reply inline...
> 
> > -----Original Message-----
> > From: Yimin Shen [mailto:yshen@juniper.net]
> > Sent: Saturday, March 22, 2014 2:40 AM
> > To: Mach Chen; draft-chen-mpls-source-label@tools.ietf.org;
> > mpls@ietf.org
> > 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:mach.chen@huawei.com]
> > Sent: Thursday, March 20, 2014 11:00 AM
> > To: Yimin Shen; draft-chen-mpls-source-label@tools.ietf.org;
> > mpls@ietf.org
> > 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:mpls-bounces@ietf.org] On Behalf Of Yimin Shen
> > > Sent: Thursday, March 20, 2014 12:03 AM
> > > To: draft-chen-mpls-source-label@tools.ietf.org; mpls@ietf.org
> > > 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
> > >
> > >
> > >
> > >
> >
> >
> 
> 
> 

_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls
[prev in list] [next in list] [prev in thread] [next in thread] 