subject:"Re\: \[spring\] \[mpls\] Special purpose labels in draft\-hegde\-spring\-traffic\-accounting\-for\-sr\-paths"

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

2017-11-27 Thread Carlos Pignataro (cpignata)

...@olddog.co.uk>> wrote:
Hi,

I understand that you doubt that this thread will yield anything productive, 
but there are a couple of things you're raising that need to be nailed down.

Probably the most important of these is the concern that you express that 
maintaining counters in the network goes against the beauty of the SR 
architecture because it means holding state at transit nodes. This seems to be 
a debate about the perfection of an architecture versus the manageability of 
the network. Don't get me wrong, I love a beautiful architecture, but only if 
the network can be operated successfully.

So, we should start at the top of the document and work our way down. I assume 
that you don't have any issues with Section 1: it seems to say what you are 
saying about the statelessness of SR. Section 2 is probably where you start to 
be unhappy: it sets an objective (to be able to count packets per flow) and 
sets some requirements on any solution.

That is, I think you believe that it is not necessary (or not desirable?) to 
count packets in an SR network and assign those counts to the SR paths that 
generated those packet flows. So the challenge for you is to say whether the 
problem described in Figure 1 is:
- not a concern in network management
- can be solved by other means without counting traffic at
   transit nodes (Note Well that other ways of counting
   traffic at transit nodes are still counting traffic at transit
   nodes).

But one other point I want to pick up on is your claim that "the draft also 
talks about needs to break an SR Path into sub-paths". Sub-paths that are 
achieved through an expansion of a Binding SID are just part of the landscape 
and (of course) thy have to be coped with. The draft doesn't introduce 
sub-paths, it just observes that they exist.

Lastly, the conversation on the number of labels as a multiplier seems to have 
gotten out of hand. Why not just agree that you original statement of 
"increased by up to 3x" was an exaggeration?

Cheers,
Adrian

> -Original Message-
> From: Zafar Ali (zali) [mailto:z...@cisco.com<mailto:z...@cisco.com>]
> Sent: 20 November 2017 23:36
> To: adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>
> Cc: 'spring'; 'mpls'
> Subject: Re: [mpls] [spring] Special purpose labels in 
> draft-hegde-spring-traffic-
> accounting-for-sr-paths
>
> Hi Adrian,
>
> Some comments are provided in-line.
>
> Please note that, we all want to let this lingering tread die and follow-up 
> on the
> next steps noted during this email exchange. I will be happy to have a webEx 
> call
> and discuss it further, offline.
>
> Thanks
>
> Regards … Zafar
>
> On 11/18/17, 9:08 AM, "Adrian Farrel" 
> <adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>> wrote:
>
> 
>
> >>> procedure (in draft-hegde-spring-traffic-accounting-for-sr-paths) that
> breaks SR
> >>> Architecture, highly unscalable and complicated to implement.
> >>
> >> [JD]  Do you have any evidence to justify any of your assertions, 
> above?
> >
> > Please note that in draft-hegde-spring-traffic-accounting-for-sr-paths:
> >
> > •The transit node needs to be able to recognize the special label, 
> read
> >the SR Path Identification label and update the counter against 
> such
> >“states”.
>
> >Possibly worth noting that existing devices are capable of maintaining 
> > many
> counters and updating them at line speed.
>
> >Several people have noted that ipfix is a process used for accounting in
> networks. That approach may have to find the bottom of stack and then match
> the packet that follows.
>
> >Other approaches (e.g., to ECMP) involve finding the bottom of stack and
> hashing on the header of the payload.
>
> >Some hardware cannot perform either mechanism. This usually results from 
> > a
> trade between low cost, high performance, and features. Generally you can't
> have all three.
>
> The question is not about if the hardware is able to perform such operations 
> but
> regarding breaking the very beauty of SR – no states at the transit/ egress 
> nodes.
> In the context of label stack size explosion, the draft also talks about 
> needs to
> break an SR Path into sub-paths – thereby creating yet additional states in 
> the
> network for accounting reasons (see more detail on this in the following).
> Furthermore, SR-MPLS is designed for SDN – the architecture calls for
> simplification of the network not adding complexity in the network fabric. 
> Please
> also note that a network may have a large number of SR Path, thereby creating
> another dimension for sc

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

2017-11-27 Thread Greg Mirsky

at you express that
>> maintaining counters in the network goes against the beauty of the SR
>> architecture because it means holding state at transit nodes. This seems to
>> be a debate about the perfection of an architecture versus the
>> manageability of the network. Don't get me wrong, I love a beautiful
>> architecture, but only if the network can be operated successfully.
>>
>> So, we should start at the top of the document and work our way down. I
>> assume that you don't have any issues with Section 1: it seems to say what
>> you are saying about the statelessness of SR. Section 2 is probably where
>> you start to be unhappy: it sets an objective (to be able to count packets
>> per flow) and sets some requirements on any solution.
>>
>> That is, I think you believe that it is not necessary (or not desirable?)
>> to count packets in an SR network and assign those counts to the SR paths
>> that generated those packet flows. So the challenge for you is to say
>> whether the problem described in Figure 1 is:
>> - not a concern in network management
>> - can be solved by other means without counting traffic at
>>transit nodes (Note Well that other ways of counting
>>traffic at transit nodes are still counting traffic at transit
>>nodes).
>>
>> But one other point I want to pick up on is your claim that "the draft
>> also talks about needs to break an SR Path into sub-paths". Sub-paths that
>> are achieved through an expansion of a Binding SID are just part of the
>> landscape and (of course) thy have to be coped with. The draft doesn't
>> introduce sub-paths, it just observes that they exist.
>>
>> Lastly, the conversation on the number of labels as a multiplier seems to
>> have gotten out of hand. Why not just agree that you original statement of
>> "increased by up to 3x" was an exaggeration?
>>
>> Cheers,
>> Adrian
>>
>> > -Original Message-
>> > From: Zafar Ali (zali) [mailto:z...@cisco.com]
>> > Sent: 20 November 2017 23:36
>> > To: adr...@olddog.co.uk
>> > Cc: 'spring'; 'mpls'
>> > Subject: Re: [mpls] [spring] Special purpose labels in
>> draft-hegde-spring-traffic-
>> > accounting-for-sr-paths
>> >
>> > Hi Adrian,
>> >
>> > Some comments are provided in-line.
>> >
>> > Please note that, we all want to let this lingering tread die and
>> follow-up on the
>> > next steps noted during this email exchange. I will be happy to have a
>> webEx call
>> > and discuss it further, offline.
>> >
>> > Thanks
>> >
>> > Regards … Zafar
>> >
>> > On 11/18/17, 9:08 AM, "Adrian Farrel" <adr...@olddog.co.uk> wrote:
>> >
>> > 
>> >
>> > >>> procedure (in draft-hegde-spring-traffic-accounting-for-sr-paths)
>> that
>> > breaks SR
>> > >>> Architecture, highly unscalable and complicated to implement.
>> > >>
>> > >> [JD]  Do you have any evidence to justify any of your
>> assertions, above?
>> > >
>> > > Please note that in draft-hegde-spring-traffic-acc
>> ounting-for-sr-paths:
>> > >
>> > > •The transit node needs to be able to recognize the special
>> label, read
>> > >the SR Path Identification label and update the counter
>> against such
>> > >“states”.
>> >
>> > >Possibly worth noting that existing devices are capable of
>> maintaining many
>> > counters and updating them at line speed.
>> >
>> > >Several people have noted that ipfix is a process used for
>> accounting in
>> > networks. That approach may have to find the bottom of stack and then
>> match
>> > the packet that follows.
>> >
>> > >Other approaches (e.g., to ECMP) involve finding the bottom of
>> stack and
>> > hashing on the header of the payload.
>> >
>> > >Some hardware cannot perform either mechanism. This usually
>> results from a
>> > trade between low cost, high performance, and features. Generally you
>> can't
>> > have all three.
>> >
>> > The question is not about if the hardware is able to perform such
>> operations but
>> > regarding breaking the very beauty of SR – no states at the transit/
>> egress nodes.
>> > In the context of label stack size explosion, the draft also talks
&g

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

2017-11-26 Thread Carlos Pignataro (cpignata)

Actually, draft-ietf-spring-sr-oam-requirement should fade away and not 
progress.

Please see 
https://mailarchive.ietf.org/arch/msg/spring/x8f_1aM4WsPlWzuqsPmL53wF_m4

Martin, can you please update the datatracker state to reflect this, as per 
your email above?

As it relates to this thread:

  *   draft-ietf-spring-sr-oam-requirement contains such a high-level list of 
requirements that is not practically useful.
  *   Those requirements speak to protocol solutions and not to operational 
problems to be solved.
  *   REQ#13 is too generic to be useful. It says *nothing* about transit 
measurements of any kind.
  *   This discussion indicates things other than “ that OAM requirements 
document is useful”.

Thanks,

—
Carlos Pignataro, car...@cisco.com<mailto:car...@cisco.com>


On Nov 16, 2017, at 4:15 AM, Greg Mirsky 
<gregimir...@gmail.com<mailto:gregimir...@gmail.com>> wrote:

Hi Sasha,
many thanks.
I'd point to SR OAM 
Requirements<https://tools.ietf.org/html/draft-ietf-spring-sr-oam-requirement-03>
 (regrettably expired):

   REQ#13:  SR OAM MUST have the ability to measure Packet loss, Packet
Delay or Delay variation using Active (using synthetic
probe) and Passive (using data stream) mode.


I think that our discussion indicates that OAM requirements document is useful 
at least for as long as we're developing OAM toolset. And the document will 
benefit from clarification to reflect our discussion that PM may be performed 
both e2e and over SPME.


Regards,

Greg

On Thu, Nov 16, 2017 at 4:11 PM, Alexander Vainshtein 
<alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com>> 
wrote:
Greg,
I concur with your position: let’s first  of all agree that ability to measure 
traffic carried by an SR-TE LSP in a specific transit node is a require OAM 
function for SR.

I have looked up the SR OAM Use 
Cases<https://datatracker.ietf.org/doc/draft-ietf-spring-oam-usecase/?include_text=1>
 draft, and I did not find any relevant use cases there.
The only time measurements are mentioned is a reference to an expired 
implementation 
report<https://tools.ietf.org/html/draft-leipnitz-spring-pms-implementation-report-00>
 draft discussing delay measurements.  Since delay measurements are in any case 
based on synthetic traffic, and are always end-to-end (one-way or two-way), 
this reference is not relevant, IMHO, for this discussion.

I have added the authors of the SR OAM Use Cases draft to tis thread.

Regards,
Sasha

Office: +972-39266302<tel:+972%203-926-6302>
Cell:  +972-549266302<tel:+972%2054-926-6302>
Email:   
alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com>

From: mpls [mailto:mpls-boun...@ietf.org<mailto:mpls-boun...@ietf.org>] On 
Behalf Of Greg Mirsky
Sent: Thursday, November 16, 2017 4:28 AM
To: Xuxiaohu <xuxia...@huawei.com<mailto:xuxia...@huawei.com>>
Cc: draft-hegde-spring-traffic-accounting-for-sr-paths 
<draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org<mailto:draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>>;
 spring <spring@ietf.org<mailto:spring@ietf.org>>; Zafar Ali (zali) 
<z...@cisco.com<mailto:z...@cisco.com>>; mpls 
<m...@ietf.org<mailto:m...@ietf.org>>
Subject: Re: [mpls] [spring] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

Dear All,
I cannot imagine that operators will agree to deploy network that lacks 
critical OAM tools to monitor performance and troubleshoot the network. True, 
some will brave the challenge and be the early adopters but even they will 
likely request that the OAM toolbox be sufficient to support their operational 
needs. I see that this work clearly describes the problem and why ability to 
quantify the flow behavior at internal nodes is important for efficient network 
operation. First let's discuss whether the case and requirement towards OAM is 
real and valid. Then we can continue to discussion of what measurement method 
to use.

Regards,
Greg

On Thu, Nov 16, 2017 at 10:05 AM, Xuxiaohu 
<xuxia...@huawei.com<mailto:xuxia...@huawei.com>> wrote:
Concur. Although it has some values, it's not cost-efficient from my point of 
view. Network simplicity should be the first priority object. Hence we would 
have to make some compromise.

Best regards,
Xiaohu




徐小虎 Xuxiaohu
M：+86-13910161692<tel:+86-13910161692>
E：xuxia...@huawei.com<mailto:xuxia...@huawei.com>
产品与解决方案-网络战略与业务发展部
Products & Solutions-Network Strategy & Business Development Dept
发件人： Zafar Ali (zali)
收件人： Greg 
Mirsky<gregimir...@gmail.com<mailto:gregimir...@gmail.com>>;draft-hegde-spring-traffic-accounting-for-sr-paths<draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org<mailto:draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>>;mpls<m...

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

2017-11-26 Thread Carlos Pignataro (cpignata)

s per flow) and 
sets some requirements on any solution.

That is, I think you believe that it is not necessary (or not desirable?) to 
count packets in an SR network and assign those counts to the SR paths that 
generated those packet flows. So the challenge for you is to say whether the 
problem described in Figure 1 is:
- not a concern in network management
- can be solved by other means without counting traffic at
   transit nodes (Note Well that other ways of counting
   traffic at transit nodes are still counting traffic at transit
   nodes).

But one other point I want to pick up on is your claim that "the draft also 
talks about needs to break an SR Path into sub-paths". Sub-paths that are 
achieved through an expansion of a Binding SID are just part of the landscape 
and (of course) thy have to be coped with. The draft doesn't introduce 
sub-paths, it just observes that they exist.

Lastly, the conversation on the number of labels as a multiplier seems to have 
gotten out of hand. Why not just agree that you original statement of 
"increased by up to 3x" was an exaggeration?

Cheers,
Adrian

> -Original Message-
> From: Zafar Ali (zali) [mailto:z...@cisco.com<mailto:z...@cisco.com>]
> Sent: 20 November 2017 23:36
> To: adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>
> Cc: 'spring'; 'mpls'
> Subject: Re: [mpls] [spring] Special purpose labels in 
> draft-hegde-spring-traffic-
> accounting-for-sr-paths
>
> Hi Adrian,
>
> Some comments are provided in-line.
>
> Please note that, we all want to let this lingering tread die and follow-up 
> on the
> next steps noted during this email exchange. I will be happy to have a webEx 
> call
> and discuss it further, offline.
>
> Thanks
>
> Regards … Zafar
>
> On 11/18/17, 9:08 AM, "Adrian Farrel" 
> <adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>> wrote:
>
> 
>
> >>> procedure (in draft-hegde-spring-traffic-accounting-for-sr-paths) that
> breaks SR
> >>> Architecture, highly unscalable and complicated to implement.
> >>
> >> [JD]  Do you have any evidence to justify any of your assertions, 
> above?
> >
> > Please note that in draft-hegde-spring-traffic-accounting-for-sr-paths:
> >
> > •The transit node needs to be able to recognize the special label, 
> read
> >the SR Path Identification label and update the counter against 
> such
> >“states”.
>
> >Possibly worth noting that existing devices are capable of maintaining 
> > many
> counters and updating them at line speed.
>
> >Several people have noted that ipfix is a process used for accounting in
> networks. That approach may have to find the bottom of stack and then match
> the packet that follows.
>
> >Other approaches (e.g., to ECMP) involve finding the bottom of stack and
> hashing on the header of the payload.
>
> >Some hardware cannot perform either mechanism. This usually results from 
> > a
> trade between low cost, high performance, and features. Generally you can't
> have all three.
>
> The question is not about if the hardware is able to perform such operations 
> but
> regarding breaking the very beauty of SR – no states at the transit/ egress 
> nodes.
> In the context of label stack size explosion, the draft also talks about 
> needs to
> break an SR Path into sub-paths – thereby creating yet additional states in 
> the
> network for accounting reasons (see more detail on this in the following).
> Furthermore, SR-MPLS is designed for SDN – the architecture calls for
> simplification of the network not adding complexity in the network fabric. 
> Please
> also note that a network may have a large number of SR Path, thereby creating
> another dimension for scaling limitations.
>
> The proposed procedure also does not work for node protection in the network.
> The draft essentially calls for ALL nodes to implement procedure proposed in 
> the
> document; I am quoting from the draft.
>
> “When using extensions
>described in this document for traffic accounting and with node-
>protection enabled in the network, it is RECOMMENDED to make sure all
>the nodes in the network support the extension.”
>
> 
>
> > •The draft proposes to push (up to) 3 Labels for each segment in 
> the SR
> >Path. That means that label stack is increased up to 3x times! 
> This is a
> >serious a scaling issue.
>
> >John asked for evidence and you provided a misunderstanding or misreading
> of our draft.
> >The document proposes adding 2 or 3 labels per SR Path (noting as

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

2017-11-26 Thread Carlos Pignataro (cpignata)

Hi, Sasha,

Just like Rüdiger stated, “SR OAM Use Case” describes a centralized system that 
is topology-aware to perform data plane monitoring and measurement (including 
delay measurement between arbitrary points).

“End-to-end liveness monitoring and measurements”, as you write, is not the 
correct description.

Key elements of “SR OAM Use Case” include the realization of a centralized PM 
server instead of modifying packets. It also allows for measurements between 
arbitrary points using arbitrary segment lists, with probes from the server and 
to the server. It does not concern itself with end-to-end measurements per se.

And “SR OAM Use Case” is not intended to be a collection of potential use cases 
either. Orthogonal to this thread.

Thanks,

—
Carlos Pignataro, car...@cisco.com<mailto:car...@cisco.com>

On Nov 16, 2017, at 4:51 AM, Alexander Vainshtein 
<alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com>> 
wrote:

Ruediger hi!
I understand that measurement of actual traffic carried in a SR-TE path via a 
transit link has not been considered in the SR OAM Use Cases draft. It only 
dealt with end-to-end liveness monitoring and measurements, and this is clearly 
stated in the Intro section.

But, from my POV, these measurements represent a valid OAM use case 
nevertheless.

Regards,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   
alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com>

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of 
ruediger.g...@telekom.de<mailto:ruediger.g...@telekom.de>
Sent: Thursday, November 16, 2017 11:19 AM
To: Alexander Vainshtein 
<alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com>>
Cc: 
draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org<mailto:draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>;
 spring@ietf.org<mailto:spring@ietf.org>; m...@ietf.org<mailto:m...@ietf.org>; 
Michael Gorokhovsky 
<michael.gorokhov...@ecitele.com<mailto:michael.gorokhov...@ecitele.com>>; 
draft-ietf-spring-oam-usec...@ietf.org<mailto:draft-ietf-spring-oam-usec...@ietf.org>;
 xuxia...@huawei.com<mailto:xuxia...@huawei.com>; 
z...@cisco.com<mailto:z...@cisco.com>; 
gregimir...@gmail.com<mailto:gregimir...@gmail.com>
Subject: Re: [spring] [mpls] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

Sasha,

the purpose of the SR OAM Use Case is to illustrate how Segment Routing enables 
new ways to perform OAM tasks. Like delay measurements.

What is discussed here are new OAM requirements caused by SR. To me, these are 
part of an own or a different draft. The scope of the SR OAM Use Case never was 
intended to cover them.

Regards,

Ruediger

Von: Alexander Vainshtein [mailto:alexander.vainsht...@ecitele.com]
Gesendet: Donnerstag, 16. November 2017 09:12
An: Greg Mirsky <gregimir...@gmail.com<mailto:gregimir...@gmail.com>>
Cc: draft-hegde-spring-traffic-accounting-for-sr-paths 
<draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org<mailto:draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>>;
 spring <spring@ietf.org<mailto:spring@ietf.org>>; Zafar Ali (zali) 
<z...@cisco.com<mailto:z...@cisco.com>>; mpls 
<m...@ietf.org<mailto:m...@ietf.org>>; Xuxiaohu 
<xuxia...@huawei.com<mailto:xuxia...@huawei.com>>; Michael Gorokhovsky 
<michael.gorokhov...@ecitele.com<mailto:michael.gorokhov...@ecitele.com>>;draft-ietf-spring-oam-usec...@ietf.org<mailto:draft-ietf-spring-oam-usec...@ietf.org>
Betreff: RE: [mpls] [spring] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

Greg,
I concur with your position: let’s first  of all agree that ability to measure 
traffic carried by an SR-TE LSP in a specific transit node is a require OAM 
function for SR.

I have looked up the SR OAM Use 
Cases<https://datatracker.ietf.org/doc/draft-ietf-spring-oam-usecase/?include_text=1>
 draft, and I did not find any relevant use cases there.
The only time measurements are mentioned is a reference to an expired 
implementation 
report<https://tools.ietf.org/html/draft-leipnitz-spring-pms-implementation-report-00>
 draft discussing delay measurements.  Since delay measurements are in any case 
based on synthetic traffic, and are always end-to-end (one-way or two-way), 
this reference is not relevant, IMHO, for this discussion.

I have added the authors of the SR OAM Use Cases draft to tis thread.

Regards,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   
alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com>

From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of Greg Mirsky
Sent: Thursday, November 16, 2017 4:28 AM
To: Xuxiaohu <xuxia...@huawei.com<mailto:xuxia...@huawei.com>>
Cc: draft-hegde-spring-traf

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

2017-11-22 Thread Robert Raszuk

k. Don't get me wrong, I love a beautiful
>> architecture, but only if the network can be operated successfully.
>>
>> So, we should start at the top of the document and work our way down. I
>> assume that you don't have any issues with Section 1: it seems to say what
>> you are saying about the statelessness of SR. Section 2 is probably where
>> you start to be unhappy: it sets an objective (to be able to count packets
>> per flow) and sets some requirements on any solution.
>>
>> That is, I think you believe that it is not necessary (or not desirable?)
>> to count packets in an SR network and assign those counts to the SR paths
>> that generated those packet flows. So the challenge for you is to say
>> whether the problem described in Figure 1 is:
>> - not a concern in network management
>> - can be solved by other means without counting traffic at
>>transit nodes (Note Well that other ways of counting
>>traffic at transit nodes are still counting traffic at transit
>>nodes).
>>
>> But one other point I want to pick up on is your claim that "the draft
>> also talks about needs to break an SR Path into sub-paths". Sub-paths that
>> are achieved through an expansion of a Binding SID are just part of the
>> landscape and (of course) thy have to be coped with. The draft doesn't
>> introduce sub-paths, it just observes that they exist.
>>
>> Lastly, the conversation on the number of labels as a multiplier seems to
>> have gotten out of hand. Why not just agree that you original statement of
>> "increased by up to 3x" was an exaggeration?
>>
>> Cheers,
>> Adrian
>>
>> > -Original Message-
>> > From: Zafar Ali (zali) [mailto:z...@cisco.com]
>> > Sent: 20 November 2017 23:36
>> > To: adr...@olddog.co.uk
>> > Cc: 'spring'; 'mpls'
>> > Subject: Re: [mpls] [spring] Special purpose labels in
>> draft-hegde-spring-traffic-
>> > accounting-for-sr-paths
>> >
>> > Hi Adrian,
>> >
>> > Some comments are provided in-line.
>> >
>> > Please note that, we all want to let this lingering tread die and
>> follow-up on the
>> > next steps noted during this email exchange. I will be happy to have a
>> webEx call
>> > and discuss it further, offline.
>> >
>> > Thanks
>> >
>> > Regards … Zafar
>> >
>> > On 11/18/17, 9:08 AM, "Adrian Farrel" <adr...@olddog.co.uk> wrote:
>> >
>> > 
>> >
>> > >>> procedure (in draft-hegde-spring-traffic-accounting-for-sr-paths)
>> that
>> > breaks SR
>> > >>> Architecture, highly unscalable and complicated to implement.
>> > >>
>> > >> [JD]  Do you have any evidence to justify any of your
>> assertions, above?
>> > >
>> > > Please note that in draft-hegde-spring-traffic-acc
>> ounting-for-sr-paths:
>> > >
>> > > •The transit node needs to be able to recognize the special
>> label, read
>> > >the SR Path Identification label and update the counter
>> against such
>> > >“states”.
>> >
>> > >Possibly worth noting that existing devices are capable of
>> maintaining many
>> > counters and updating them at line speed.
>> >
>> > >Several people have noted that ipfix is a process used for
>> accounting in
>> > networks. That approach may have to find the bottom of stack and then
>> match
>> > the packet that follows.
>> >
>> > >Other approaches (e.g., to ECMP) involve finding the bottom of
>> stack and
>> > hashing on the header of the payload.
>> >
>> > >Some hardware cannot perform either mechanism. This usually
>> results from a
>> > trade between low cost, high performance, and features. Generally you
>> can't
>> > have all three.
>> >
>> > The question is not about if the hardware is able to perform such
>> operations but
>> > regarding breaking the very beauty of SR – no states at the transit/
>> egress nodes.
>> > In the context of label stack size explosion, the draft also talks
>> about needs to
>> > break an SR Path into sub-paths – thereby creating yet additional
>> states in the
>> > network for accounting reasons (see more detail on this in the
>> following).
>> > Furthermore, SR-MPLS is designed for SDN – the architectur

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

2017-11-22 Thread Jeff Tantsura

u start to be unhappy: it sets an objective (to be able to count packets 
>>> per flow) and sets some requirements on any solution.
>>> 
>>> That is, I think you believe that it is not necessary (or not desirable?) 
>>> to count packets in an SR network and assign those counts to the SR paths 
>>> that generated those packet flows. So the challenge for you is to say 
>>> whether the problem described in Figure 1 is:
>>> - not a concern in network management
>>> - can be solved by other means without counting traffic at
>>>transit nodes (Note Well that other ways of counting
>>>traffic at transit nodes are still counting traffic at transit
>>>nodes).
>>> 
>>> But one other point I want to pick up on is your claim that "the draft also 
>>> talks about needs to break an SR Path into sub-paths". Sub-paths that are 
>>> achieved through an expansion of a Binding SID are just part of the 
>>> landscape and (of course) thy have to be coped with. The draft doesn't 
>>> introduce sub-paths, it just observes that they exist.
>>> 
>>> Lastly, the conversation on the number of labels as a multiplier seems to 
>>> have gotten out of hand. Why not just agree that you original statement of 
>>> "increased by up to 3x" was an exaggeration?
>>> 
>>> Cheers,
>>> Adrian
>>> 
>>> > -Original Message-
>>> > From: Zafar Ali (zali) [mailto:z...@cisco.com]
>>> > Sent: 20 November 2017 23:36
>>> > To: adr...@olddog.co.uk
>>> > Cc: 'spring'; 'mpls'
>>> > Subject: Re: [mpls] [spring] Special purpose labels in 
>>> > draft-hegde-spring-traffic-
>>> > accounting-for-sr-paths
>>> >
>>> > Hi Adrian,
>>> >
>>> > Some comments are provided in-line.
>>> >
>>> > Please note that, we all want to let this lingering tread die and 
>>> > follow-up on the
>>> > next steps noted during this email exchange. I will be happy to have a 
>>> > webEx call
>>> > and discuss it further, offline.
>>> >
>>> > Thanks
>>> >
>>> > Regards … Zafar
>>> >
>>> > On 11/18/17, 9:08 AM, "Adrian Farrel" <adr...@olddog.co.uk> wrote:
>>> >
>>> > 
>>> >
>>> > >>> procedure (in draft-hegde-spring-traffic-accounting-for-sr-paths) 
>>> > that
>>> > breaks SR
>>> > >>> Architecture, highly unscalable and complicated to implement.
>>> > >>
>>> > >> [JD]  Do you have any evidence to justify any of your assertions, 
>>> > above?
>>> > >
>>> > > Please note that in 
>>> > draft-hegde-spring-traffic-accounting-for-sr-paths:
>>> > >
>>> > > •The transit node needs to be able to recognize the special 
>>> > label, read
>>> > >the SR Path Identification label and update the counter 
>>> > against such
>>> > >“states”.
>>> >
>>> > >Possibly worth noting that existing devices are capable of 
>>> > > maintaining many
>>> > counters and updating them at line speed.
>>> >
>>> > >Several people have noted that ipfix is a process used for 
>>> > > accounting in
>>> > networks. That approach may have to find the bottom of stack and then 
>>> > match
>>> > the packet that follows.
>>> >
>>> > >Other approaches (e.g., to ECMP) involve finding the bottom of stack 
>>> > > and
>>> > hashing on the header of the payload.
>>> >
>>> > >Some hardware cannot perform either mechanism. This usually results 
>>> > > from a
>>> > trade between low cost, high performance, and features. Generally you 
>>> > can't
>>> > have all three.
>>> >
>>> > The question is not about if the hardware is able to perform such 
>>> > operations but
>>> > regarding breaking the very beauty of SR – no states at the transit/ 
>>> > egress nodes.
>>> > In the context of label stack size explosion, the draft also talks about 
>>> > needs to
>>> > break an SR Path into sub-paths – thereby creating yet additional states 
>>> > in the
>>> > network for ac

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

2017-11-22 Thread Martin Horneffer

afar Ali (zali) [mailto:z...@cisco.com
<mailto:z...@cisco.com>]
> Sent: 20 November 2017 23:36
> To: adr...@olddog.co.uk <mailto:adr...@olddog.co.uk>
> Cc: 'spring'; 'mpls'
> Subject: Re: [mpls] [spring] Special purpose labels in
draft-hegde-spring-traffic-
> accounting-for-sr-paths
>
> Hi Adrian,
>
> Some comments are provided in-line.
>
> Please note that, we all want to let this lingering tread die
and follow-up on the
> next steps noted during this email exchange. I will be happy to
have a webEx call
> and discuss it further, offline.
>
> Thanks
>
> Regards … Zafar
>
> On 11/18/17, 9:08 AM, "Adrian Farrel" <adr...@olddog.co.uk
<mailto:adr...@olddog.co.uk>> wrote:
>
> 
>
>     >>> procedure (in
draft-hegde-spring-traffic-accounting-for-sr-paths) that
> breaks SR
>     >>> Architecture, highly unscalable and complicated to
implement.
>     >>
>     >> [JD]  Do you have any evidence to justify any of your
assertions, above?
>     >
>     > Please note that in
draft-hegde-spring-traffic-accounting-for-sr-paths:
>     >
>     > •    The transit node needs to be able to recognize the
special label, read
>     >        the SR Path Identification label and update the
counter against such
>     >        “states”.
>
> >    Possibly worth noting that existing devices are capable of
maintaining many
> counters and updating them at line speed.
>
> >    Several people have noted that ipfix is a process used for
accounting in
> networks. That approach may have to find the bottom of stack and
then match
> the packet that follows.
>
> >    Other approaches (e.g., to ECMP) involve finding the bottom
of stack and
> hashing on the header of the payload.
>
> >    Some hardware cannot perform either mechanism. This usually
results from a
> trade between low cost, high performance, and features.
Generally you can't
> have all three.
>
> The question is not about if the hardware is able to perform
such operations but
> regarding breaking the very beauty of SR – no states at the
transit/ egress nodes.
> In the context of label stack size explosion, the draft also
talks about needs to
> break an SR Path into sub-paths – thereby creating yet
additional states in the
> network for accounting reasons (see more detail on this in the
following).
> Furthermore, SR-MPLS is designed for SDN – the architecture
calls for
> simplification of the network not adding complexity in the
network fabric. Please
> also note that a network may have a large number of SR Path,
thereby creating
> another dimension for scaling limitations.
>
> The proposed procedure also does not work for node protection in
the network.
> The draft essentially calls for ALL nodes to implement procedure
proposed in the
> document; I am quoting from the draft.
>
> “When using extensions
>    described in this document for traffic accounting and with node-
>    protection enabled in the network, it is RECOMMENDED to make
sure all
>    the nodes in the network support the extension.”
>
> 
>
>     > •    The draft proposes to push (up to) 3 Labels for each
segment in the SR
>     >        Path. That means that label stack is increased up
to 3x times! This is a
>     >        serious a scaling issue.
>
> >    John asked for evidence and you provided a misunderstanding
or misreading
> of our draft.
> >    The document proposes adding 2 or 3 labels per SR Path
(noting as John did,
> that this is our own term).
> >    That is not what you say, so perhaps you could retract or
provide a pointer to
> the text.
>
> >    Thus, "increased up to 3x times" applies only with the
single case where the
> imposed label stack has exactly one label *and* the three label
option is applied.
> So, while  what you say is true, it is clearly (and wilfully?)
exaggerating the
> severity of impact, and it is doubtful that 4-label stack is
actually a problem.
>
> There are many scenarios that will require SR-Path-Stats Labels
(up to 3 labels) to
> be present multiple times in the label stack. These scenarios
are not uncommon.
> The following scenarios as noted in the draft.
x`x>
>   “The head-end nod

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

2017-11-22 Thread Stewart Bryant

Comments inline:

On 20/11/2017 23:36, Zafar Ali (zali) wrote:

Hi Adrian,

Some comments are provided in-line.

Please note that, we all want to let this lingering tread die and follow-up on 
the next steps noted during this email exchange. I will be happy to have a 
webEx call and discuss it further, offline.

No, some of us would  like to resolve the issue since it raises 
interesting architectural issues with SR.

Thanks

Regards … Zafar

On 11/18/17, 9:08 AM, "Adrian Farrel"  wrote:

 >>> procedure (in draft-hegde-spring-traffic-accounting-for-sr-paths) that breaks SR

 >>> Architecture, highly unscalable and complicated to implement.
 >>
 >> [JD]  Do you have any evidence to justify any of your assertions, above?
 >
 > Please note that in draft-hegde-spring-traffic-accounting-for-sr-paths:
 >
 > •The transit node needs to be able to recognize the special label, 
read
 >the SR Path Identification label and update the counter against 
such
 >“states”.

Possibly worth noting that existing devices are capable of maintaining many 
counters and updating them at line speed.

Several people have noted that ipfix is a process used for accounting in 
networks. That approach may have to find the bottom of stack and then match the 
packet that follows.

Other approaches (e.g., to ECMP) involve finding the bottom of stack and 
hashing on the header of the payload.

Some hardware cannot perform either mechanism. This usually results from a 
trade between low cost, high performance, and features. Generally you can't 
have all three.

The question is not about if the hardware is able to perform such operations 
but regarding breaking the very beauty of SR – no states at the transit/ egress 
nodes.

Well, it's more about minimum state. Zero state at egress only applies 
for some classes of traffic.

Whilst the intent is for zero state in the transit nodes, this cannot be 
at the expense of not being able to manage the network.

In the context of label stack size explosion, the draft also talks about needs 
to break an SR Path into sub-paths – thereby creating yet additional states in 
the network for accounting reasons (see more detail on this in the following). 
Furthermore, SR-MPLS is designed for SDN – the architecture calls for 
simplification of the network not adding complexity in the network fabric.

No. SR is not and never has been solely for SDN. On day one there was 
the concept that the ingress could compute the path.

Please also note that a network may have a large number of SR Path, thereby 
creating another dimension for scaling limitations.

The proposed procedure also does not work for node protection in the network. 
The draft essentially calls for ALL nodes to implement procedure proposed in 
the document; I am quoting from the draft.

“When using extensions
described in this document for traffic accounting and with node-
protection enabled in the network, it is RECOMMENDED to make sure all
the nodes in the network support the extension.”

If all nodes support this (as recommended), then all nodes support it so 
it works during re-route. Indeed this is more important during reroute 
since that is when you expect hot spots to form.

The dynamic counter concept is no different to dynamic counters needed 
in IPFIX, so it is a concept that a lot of routers already have.

 > •The draft proposes to push (up to) 3 Labels for each segment in the SR

 >Path. That means that label stack is increased up to 3x times! 
This is a
 >serious a scaling issue.

Maybe there needs to be a change in the text, but what is required is 
three labels per ingress being monitored. This is something where SR 
really introduces confusion for the OAM systems and we need to work this 
through. In "classic" MPLS each label represented a layer in the 
network. SR breaks that model, with sadly little comment on this in the 
architecture. So we do need to think this through a bit, and understand 
whether we need to have a rule stating that there can only be one source 
identifier in the stack - meaning that SI can only be BoS and that if 
you want to record the source when you introduce a new layer you need to 
terminate the old stack and start a new one.

John asked for evidence and you provided a misunderstanding or misreading 
of our draft.
The document proposes adding 2 or 3 labels per SR Path (noting as John did, 
that this is our own term).
That is not what you say, so perhaps you could retract or provide a pointer 
to the text.

Thus, "increased up to 3x times" applies only with the single case where 
the imposed label stack has exactly one label *and* the three label option is applied. 
So, while  what you say is true, it is clearly (and wilfully?) exaggerating the severity 
of impact, and it is

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

2017-11-21 Thread Zafar Ali (zali)

Hi Adrian,

I could not agree more with Robert. Martin Horneffer, Stephane Litkowski and 
others have shared similar view from their operation experiences.

Nailing down on minor details will just create additional rat-holes. Before 
jumping into solutions, what we need to do is to formally document what can be 
achieved using the existing tools and counters, and use it to perform gap 
analysis (please stay tuned on it).

Thanks

Regards … Zafar



From: <rras...@gmail.com> on behalf of Robert Raszuk <rob...@raszuk.net>
Date: Tuesday, November 21, 2017 at 1:34 PM
To: "adr...@olddog.co.uk" <adr...@olddog.co.uk>
Cc: "Zafar Ali (zali)" <z...@cisco.com>, "m...@ietf.org" <m...@ietf.org>, 
spring <spring@ietf.org>
Subject: Re: [spring] [mpls] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

Hi Adrian,

I am not going to defend beauty of any architecture. I think there is much 
bigger fundamental misunderstanding how in practice someone will use SR-MPLS 
and I think this is the root cause for this little thread and different 
perspectives of its participants.

So SR-MPLS is not RSVP-TE and there is no EROs. The set of SIDs are no more 
then hints on how to steer the packets within connection less paradigm (same as 
IP tunnel so to say with less encap overhead) via one or more of IGP segments.

The less SIDs you add to the packet the better !

Yes that requires to be smart (or to have smart central controller) to add only 
a very few labels/SIDs to accomplish the network traffic distribution 
objectives. I clearly see folks thinking of SR-MPLS like a RSVP-TE analogy with 
EROs, but this is IMO fundamentally wrong. Only that you can do it (to build 
SR-MPLS paths all the way via your domain) does not make it a good idea. No 
where in SR architecture I see any pre-asssumption that last IGP segment will 
be connected to domain egress node (with the exception of EPE but this is 
different app).

In fact as some may recall we are 17 years after RSVP-TE shipping code and only 
very few networks ever deployed it for all unicast traffic end to end for many 
reasons. Most folks used it for FRR or for hot spot bypass.

Now as far as OAM sure it is great to have it both for IP networks and MPLS-LDP 
networks and SR-MPLS networks. Especially iOAM is very useful. But this is not 
really related to SR-MPLS architecture.

With that I think the draft makes set of assumptions which are far from how 
SR-MPLS should be deployed and this does make it rather problematic. It is just 
like draft describing use of BGP for data centers ... now everyone is using BGP 
for all data centers or even other types of networks regardless if this is even 
applicable or best choice for a given cluster scale they are building :).

Counters are great, more counters are even better, but I fail to see the value 
for yet again counting traffic arriving via specific IGP segments when we are 
already counting packets arriving via given IGP topology. My recommendation 
would be to solve it for MPLS-LDP in MPLS WG first (which after all is one 
example where flooding domain wide labels in IGP replaces) and then SR-MPLS 
will inherit the same solution.

Cheers,
Robert.


On Tue, Nov 21, 2017 at 6:56 PM, Adrian Farrel 
<adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>> wrote:
Hi,

I understand that you doubt that this thread will yield anything productive, 
but there are a couple of things you're raising that need to be nailed down.

Probably the most important of these is the concern that you express that 
maintaining counters in the network goes against the beauty of the SR 
architecture because it means holding state at transit nodes. This seems to be 
a debate about the perfection of an architecture versus the manageability of 
the network. Don't get me wrong, I love a beautiful architecture, but only if 
the network can be operated successfully.

So, we should start at the top of the document and work our way down. I assume 
that you don't have any issues with Section 1: it seems to say what you are 
saying about the statelessness of SR. Section 2 is probably where you start to 
be unhappy: it sets an objective (to be able to count packets per flow) and 
sets some requirements on any solution.

That is, I think you believe that it is not necessary (or not desirable?) to 
count packets in an SR network and assign those counts to the SR paths that 
generated those packet flows. So the challenge for you is to say whether the 
problem described in Figure 1 is:
- not a concern in network management
- can be solved by other means without counting traffic at
   transit nodes (Note Well that other ways of counting
   traffic at transit nodes are still counting traffic at transit
   nodes).

But one other point I want to pick up on is your claim that "the draft also 
talks about needs to break an SR Path into sub-paths". Sub-paths that are 
achie

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

2017-11-21 Thread Robert Raszuk

Hi Adrian,

I am not going to defend beauty of any architecture. I think there is much
bigger fundamental misunderstanding how in practice someone will use
SR-MPLS and I think this is the root cause for this little thread and
different perspectives of its participants.

So SR-MPLS is not RSVP-TE and there is no EROs. The set of SIDs are no more
then hints on how to steer the packets within connection less paradigm
(same as IP tunnel so to say with less encap overhead) via one or more of
IGP segments.

*The less SIDs you add to the packet the better !*

Yes that requires to be smart (or to have smart central controller) to add
only a very few labels/SIDs to accomplish the network traffic distribution
objectives. I clearly see folks thinking of SR-MPLS like a RSVP-TE analogy
with EROs, but this is IMO fundamentally wrong. Only that you can do it (to
build SR-MPLS paths all the way via your domain) does not make it a good
idea. No where in SR architecture I see any pre-asssumption that last IGP
segment will be connected to domain egress node (with the exception of EPE
but this is different app).

In fact as some may recall we are 17 years after RSVP-TE shipping code and
only very few networks ever deployed it for all unicast traffic end to end
for many reasons. Most folks used it for FRR or for hot spot bypass.

Now as far as OAM sure it is great to have it both for IP networks and
MPLS-LDP networks and SR-MPLS networks. Especially iOAM is very useful. But
this is not really related to SR-MPLS architecture.

With that I think the draft makes set of assumptions which are far from how
SR-MPLS should be deployed and this does make it rather problematic. It is
just like draft describing use of BGP for data centers ... now everyone is
using BGP for all data centers or even other types of networks regardless
if this is even applicable or best choice for a given cluster scale they
are building :).

Counters are great, more counters are even better, but I fail to see the
value for yet again counting traffic arriving via specific IGP segments
when we are already counting packets arriving via given IGP topology. My
recommendation would be to solve it for MPLS-LDP in MPLS WG first (which
after all is one example where flooding domain wide labels in IGP replaces)
and then SR-MPLS will inherit the same solution.

Cheers,
Robert.

On Tue, Nov 21, 2017 at 6:56 PM, Adrian Farrel <adr...@olddog.co.uk> wrote:

> Hi,
>
> I understand that you doubt that this thread will yield anything
> productive, but there are a couple of things you're raising that need to be
> nailed down.
>
> Probably the most important of these is the concern that you express that
> maintaining counters in the network goes against the beauty of the SR
> architecture because it means holding state at transit nodes. This seems to
> be a debate about the perfection of an architecture versus the
> manageability of the network. Don't get me wrong, I love a beautiful
> architecture, but only if the network can be operated successfully.
>
> So, we should start at the top of the document and work our way down. I
> assume that you don't have any issues with Section 1: it seems to say what
> you are saying about the statelessness of SR. Section 2 is probably where
> you start to be unhappy: it sets an objective (to be able to count packets
> per flow) and sets some requirements on any solution.
>
> That is, I think you believe that it is not necessary (or not desirable?)
> to count packets in an SR network and assign those counts to the SR paths
> that generated those packet flows. So the challenge for you is to say
> whether the problem described in Figure 1 is:
> - not a concern in network management
> - can be solved by other means without counting traffic at
>transit nodes (Note Well that other ways of counting
>traffic at transit nodes are still counting traffic at transit
>nodes).
>
> But one other point I want to pick up on is your claim that "the draft
> also talks about needs to break an SR Path into sub-paths". Sub-paths that
> are achieved through an expansion of a Binding SID are just part of the
> landscape and (of course) thy have to be coped with. The draft doesn't
> introduce sub-paths, it just observes that they exist.
>
> Lastly, the conversation on the number of labels as a multiplier seems to
> have gotten out of hand. Why not just agree that you original statement of
> "increased by up to 3x" was an exaggeration?
>
> Cheers,
> Adrian
>
> > -Original Message-----
> > From: Zafar Ali (zali) [mailto:z...@cisco.com]
> > Sent: 20 November 2017 23:36
> > To: adr...@olddog.co.uk
> > Cc: 'spring'; 'mpls'
> > Subject: Re: [mpls] [spring] Special purpose labels in
> draft-hegde-spring-traffic-
> > accounting-for-sr-paths
> >
> > Hi

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

2017-11-21 Thread Adrian Farrel

Hi,

I understand that you doubt that this thread will yield anything productive, 
but there are a couple of things you're raising that need to be nailed down.

Probably the most important of these is the concern that you express that 
maintaining counters in the network goes against the beauty of the SR 
architecture because it means holding state at transit nodes. This seems to be 
a debate about the perfection of an architecture versus the manageability of 
the network. Don't get me wrong, I love a beautiful architecture, but only if 
the network can be operated successfully.

So, we should start at the top of the document and work our way down. I assume 
that you don't have any issues with Section 1: it seems to say what you are 
saying about the statelessness of SR. Section 2 is probably where you start to 
be unhappy: it sets an objective (to be able to count packets per flow) and 
sets some requirements on any solution. 

That is, I think you believe that it is not necessary (or not desirable?) to 
count packets in an SR network and assign those counts to the SR paths that 
generated those packet flows. So the challenge for you is to say whether the 
problem described in Figure 1 is:
- not a concern in network management
- can be solved by other means without counting traffic at
   transit nodes (Note Well that other ways of counting
   traffic at transit nodes are still counting traffic at transit
   nodes).

But one other point I want to pick up on is your claim that "the draft also 
talks about needs to break an SR Path into sub-paths". Sub-paths that are 
achieved through an expansion of a Binding SID are just part of the landscape 
and (of course) thy have to be coped with. The draft doesn't introduce 
sub-paths, it just observes that they exist.

Lastly, the conversation on the number of labels as a multiplier seems to have 
gotten out of hand. Why not just agree that you original statement of 
"increased by up to 3x" was an exaggeration?

Cheers,
Adrian

> -Original Message-
> From: Zafar Ali (zali) [mailto:z...@cisco.com]
> Sent: 20 November 2017 23:36
> To: adr...@olddog.co.uk
> Cc: 'spring'; 'mpls'
> Subject: Re: [mpls] [spring] Special purpose labels in 
> draft-hegde-spring-traffic-
> accounting-for-sr-paths
> 
> Hi Adrian,
> 
> Some comments are provided in-line.
> 
> Please note that, we all want to let this lingering tread die and follow-up 
> on the
> next steps noted during this email exchange. I will be happy to have a webEx 
> call
> and discuss it further, offline.
> 
> Thanks
> 
> Regards … Zafar
> 
> On 11/18/17, 9:08 AM, "Adrian Farrel" <adr...@olddog.co.uk> wrote:
> 
> 
> 
> >>> procedure (in draft-hegde-spring-traffic-accounting-for-sr-paths) that
> breaks SR
> >>> Architecture, highly unscalable and complicated to implement.
> >>
> >> [JD]  Do you have any evidence to justify any of your assertions, 
> above?
> >
> > Please note that in draft-hegde-spring-traffic-accounting-for-sr-paths:
> >
> > •The transit node needs to be able to recognize the special label, 
> read
> >the SR Path Identification label and update the counter against 
> such
> >“states”.
> 
> >Possibly worth noting that existing devices are capable of maintaining 
> > many
> counters and updating them at line speed.
> 
> >Several people have noted that ipfix is a process used for accounting in
> networks. That approach may have to find the bottom of stack and then match
> the packet that follows.
> 
> >Other approaches (e.g., to ECMP) involve finding the bottom of stack and
> hashing on the header of the payload.
> 
> >Some hardware cannot perform either mechanism. This usually results from 
> > a
> trade between low cost, high performance, and features. Generally you can't
> have all three.
> 
> The question is not about if the hardware is able to perform such operations 
> but
> regarding breaking the very beauty of SR – no states at the transit/ egress 
> nodes.
> In the context of label stack size explosion, the draft also talks about 
> needs to
> break an SR Path into sub-paths – thereby creating yet additional states in 
> the
> network for accounting reasons (see more detail on this in the following).
> Furthermore, SR-MPLS is designed for SDN – the architecture calls for
> simplification of the network not adding complexity in the network fabric. 
> Please
> also note that a network may have a large number of SR Path, thereby creating
> another dimension for scaling limitations.
> 
> The proposed procedure also does not work for node protection in the network.
> The draft essentially

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

2017-11-20 Thread Zafar Ali (zali)

Greg,

Looking forward to the modified proposal.

Thanks

Regards … Zafar

From: Greg Mirsky <gregimir...@gmail.com>
Date: Monday, November 20, 2017 at 10:53 PM
To: "Zafar Ali (zali)" <z...@cisco.com>
Cc: "adr...@olddog.co.uk" <adr...@olddog.co.uk>, "m...@ietf.org" 
<m...@ietf.org>, spring <spring@ietf.org>
Subject: Re: [mpls] [spring] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

Hi Zafar,
"overloading existing special label"? AFAIK, MPLS WG created Extended Special 
Label exactly for cases like we're discussing.
Of course, alternative proposal for SR-MPLS use case will be most helpful. As 
description of GAL-ACH based proposal. Stay tuned.

Regards,
Greg

On Mon, Nov 20, 2017 at 7:06 PM, Zafar Ali (zali) 
<z...@cisco.com<mailto:z...@cisco.com>> wrote:
Hi Greg,

Overloading existing special label, optimizing stack overheads in draft-hegde, 
etc. will not change the architectural direction of the proposal.

I feel additional discussion on this thread will be non-productive. Martin 
Horneffer, Robert Raszuk, Stephane Litkowski and others have shared from their 
operation experiences; their input cannot be ignored by the vendors. They and 
others have outlined some alternatives. We need to follow-up on additional 
documentation (on the alternatives including existing counters) to help us 
converge. Please stay tuned.

Thanks

Regards … Zafar

From: Greg Mirsky <gregimir...@gmail.com<mailto:gregimir...@gmail.com>>
Date: Monday, November 20, 2017 at 7:03 PM
To: "Zafar Ali (zali)" <z...@cisco.com<mailto:z...@cisco.com>>
Cc: "adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>" 
<adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>>, 
"m...@ietf.org<mailto:m...@ietf.org>" <m...@ietf.org<mailto:m...@ietf.org>>, 
spring <spring@ietf.org<mailto:spring@ietf.org>>
Subject: Re: [mpls] [spring] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

Hi Zafar,
I don't see how managing, using passive OAM, i.e. counting fly-by packets, at 
transient SR-MPLS nodes can be equated to breaking "no-forwarding state at 
transient LSR" model.I believe that practical is as important as aesthetic and 
that network cannot be operated without comprehensive OAM tool box. Of course, 
every tool in the box is optional and will not be deployed unless the need 
arises. If we agree on that, perhaps we can discuss new requirement to be added 
to the SR OAM Requirements document. And then, then consider how to address 
such requirement. I believe that two options were mentioned in the thread:

  *   described in draft-hegde-spring-traffic-accounting-for-sr-paths special 
purpose label (actually it may end up be extended special purpose label) and up 
to two labels;
  *   use GAL and ACH (perhaps somewhat similar to approach used in RFC 8169).
Regards,
Greg

On Mon, Nov 20, 2017 at 3:36 PM, Zafar Ali (zali) 
<z...@cisco.com<mailto:z...@cisco.com>> wrote:
Hi Adrian,

Some comments are provided in-line.

Please note that, we all want to let this lingering tread die and follow-up on 
the next steps noted during this email exchange. I will be happy to have a 
webEx call and discuss it further, offline.

Thanks

Regards … Zafar

On 11/18/17, 9:08 AM, "Adrian Farrel" 
<adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>> wrote:

>>> procedure (in draft-hegde-spring-traffic-accounting-for-sr-paths) that 
breaks SR
>>> Architecture, highly unscalable and complicated to implement.
>>
>> [JD]  Do you have any evidence to justify any of your assertions, above?
>
> Please note that in draft-hegde-spring-traffic-accounting-for-sr-paths:
>
> •The transit node needs to be able to recognize the special label, 
read
>the SR Path Identification label and update the counter against 
such
>“states”.

>Possibly worth noting that existing devices are capable of maintaining 
> many counters and updating them at line speed.

>Several people have noted that ipfix is a process used for accounting in 
> networks. That approach may have to find the bottom of stack and then match 
> the packet that follows.

>Other approaches (e.g., to ECMP) involve finding the bottom of stack and 
> hashing on the header of the payload.

>Some hardware cannot perform either mechanism. This usually results from a 
> trade between low cost, high performance, and features. Generally you can't 
> have all three.

The question is not about if the hardware is able to perform such operations 
but regarding breaking the very beauty of SR – no states at the transit/ egress 
nodes. In the context of label stack size explosion, the draft also talks about 
needs to break an

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

2017-11-20 Thread Greg Mirsky

Hi Zafar,
"overloading existing special label"? AFAIK, MPLS WG created Extended
Special Label exactly for cases like we're discussing.
Of course, alternative proposal for SR-MPLS use case will be most helpful.
As description of GAL-ACH based proposal. Stay tuned.

Regards,
Greg

On Mon, Nov 20, 2017 at 7:06 PM, Zafar Ali (zali) <z...@cisco.com> wrote:

> Hi Greg,
>
>
>
> Overloading existing special label, optimizing stack overheads in
> draft-hegde, etc. will not change the architectural direction of the
> proposal.
>
>
>
> I feel additional discussion on this thread will be non-productive. Martin
> Horneffer, Robert Raszuk, Stephane Litkowski and others have shared from
> their operation experiences; their input cannot be ignored by the vendors.
> They and others have outlined some alternatives. We need to follow-up on
> additional documentation (on the alternatives including existing counters)
> to help us converge. Please stay tuned.
>
>
>
> Thanks
>
>
>
> Regards … Zafar
>
>
>
>
>
> *From: *Greg Mirsky <gregimir...@gmail.com>
> *Date: *Monday, November 20, 2017 at 7:03 PM
> *To: *"Zafar Ali (zali)" <z...@cisco.com>
> *Cc: *"adr...@olddog.co.uk" <adr...@olddog.co.uk>, "m...@ietf.org" <
> m...@ietf.org>, spring <spring@ietf.org>
> *Subject: *Re: [mpls] [spring] Special purpose labels in
> draft-hegde-spring-traffic-accounting-for-sr-paths
>
>
>
> Hi Zafar,
>
> I don't see how managing, using passive OAM, i.e. counting fly-by packets,
> at transient SR-MPLS nodes can be equated to breaking "no-forwarding state
> at transient LSR" model.I believe that practical is as important as
> aesthetic and that network cannot be operated without comprehensive OAM
> tool box. Of course, every tool in the box is optional and will not be
> deployed unless the need arises. If we agree on that, perhaps we can
> discuss new requirement to be added to the SR OAM Requirements document.
> And then, then consider how to address such requirement. I believe that two
> options were mentioned in the thread:
>
>- described in draft-hegde-spring-traffic-accounting-for-sr-paths
>special purpose label (actually it may end up be extended special purpose
>label) and up to two labels;
>- use GAL and ACH (perhaps somewhat similar to approach used in RFC
>8169).
>
> Regards,
>
> Greg
>
>
>
>
>
> On Mon, Nov 20, 2017 at 3:36 PM, Zafar Ali (zali) <z...@cisco.com> wrote:
>
> Hi Adrian,
>
> Some comments are provided in-line.
>
> Please note that, we all want to let this lingering tread die and
> follow-up on the next steps noted during this email exchange. I will be
> happy to have a webEx call and discuss it further, offline.
>
> Thanks
>
> Regards … Zafar
>
> On 11/18/17, 9:08 AM, "Adrian Farrel" <adr...@olddog.co.uk> wrote:
>
> 
>
> >>> procedure (in draft-hegde-spring-traffic-accounting-for-sr-paths)
> that breaks SR
> >>> Architecture, highly unscalable and complicated to implement.
> >>
> >> [JD]  Do you have any evidence to justify any of your assertions,
> above?
> >
> > Please note that in draft-hegde-spring-traffic-
> accounting-for-sr-paths:
> >
> > •The transit node needs to be able to recognize the special
> label, read
> >the SR Path Identification label and update the counter
> against such
> >“states”.
>
> >Possibly worth noting that existing devices are capable of
> maintaining many counters and updating them at line speed.
>
> >Several people have noted that ipfix is a process used for accounting
> in networks. That approach may have to find the bottom of stack and then
> match the packet that follows.
>
> >Other approaches (e.g., to ECMP) involve finding the bottom of stack
> and hashing on the header of the payload.
>
> >Some hardware cannot perform either mechanism. This usually results
> from a trade between low cost, high performance, and features. Generally
> you can't have all three.
>
> The question is not about if the hardware is able to perform such
> operations but regarding breaking the very beauty of SR – no states at the
> transit/ egress nodes. In the context of label stack size explosion, the
> draft also talks about needs to break an SR Path into sub-paths – thereby
> creating yet additional states in the network for accounting reasons (see
> more detail on this in the following). Furthermore, SR-MPLS is designed for
> SDN – the architecture calls for simplification of the network not adding

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

2017-11-20 Thread Zafar Ali (zali)

Hi Greg,

Overloading existing special label, optimizing stack overheads in draft-hegde, 
etc. will not change the architectural direction of the proposal.

I feel additional discussion on this thread will be non-productive. Martin 
Horneffer, Robert Raszuk, Stephane Litkowski and others have shared from their 
operation experiences; their input cannot be ignored by the vendors. They and 
others have outlined some alternatives. We need to follow-up on additional 
documentation (on the alternatives including existing counters) to help us 
converge. Please stay tuned.

Thanks

Regards … Zafar

From: Greg Mirsky <gregimir...@gmail.com>
Date: Monday, November 20, 2017 at 7:03 PM
To: "Zafar Ali (zali)" <z...@cisco.com>
Cc: "adr...@olddog.co.uk" <adr...@olddog.co.uk>, "m...@ietf.org" 
<m...@ietf.org>, spring <spring@ietf.org>
Subject: Re: [mpls] [spring] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

Hi Zafar,
I don't see how managing, using passive OAM, i.e. counting fly-by packets, at 
transient SR-MPLS nodes can be equated to breaking "no-forwarding state at 
transient LSR" model.I believe that practical is as important as aesthetic and 
that network cannot be operated without comprehensive OAM tool box. Of course, 
every tool in the box is optional and will not be deployed unless the need 
arises. If we agree on that, perhaps we can discuss new requirement to be added 
to the SR OAM Requirements document. And then, then consider how to address 
such requirement. I believe that two options were mentioned in the thread:

  *   described in draft-hegde-spring-traffic-accounting-for-sr-paths special 
purpose label (actually it may end up be extended special purpose label) and up 
to two labels;
  *   use GAL and ACH (perhaps somewhat similar to approach used in RFC 8169).
Regards,
Greg

On Mon, Nov 20, 2017 at 3:36 PM, Zafar Ali (zali) 
<z...@cisco.com<mailto:z...@cisco.com>> wrote:
Hi Adrian,

Some comments are provided in-line.

Please note that, we all want to let this lingering tread die and follow-up on 
the next steps noted during this email exchange. I will be happy to have a 
webEx call and discuss it further, offline.

Thanks

Regards … Zafar

On 11/18/17, 9:08 AM, "Adrian Farrel" 
<adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>> wrote:

>>> procedure (in draft-hegde-spring-traffic-accounting-for-sr-paths) that 
breaks SR
>>> Architecture, highly unscalable and complicated to implement.
>>
>> [JD]  Do you have any evidence to justify any of your assertions, above?
>
> Please note that in draft-hegde-spring-traffic-accounting-for-sr-paths:
>
> •The transit node needs to be able to recognize the special label, 
read
>the SR Path Identification label and update the counter against 
such
>“states”.

>Possibly worth noting that existing devices are capable of maintaining 
> many counters and updating them at line speed.

>Several people have noted that ipfix is a process used for accounting in 
> networks. That approach may have to find the bottom of stack and then match 
> the packet that follows.

>Other approaches (e.g., to ECMP) involve finding the bottom of stack and 
> hashing on the header of the payload.

>Some hardware cannot perform either mechanism. This usually results from a 
> trade between low cost, high performance, and features. Generally you can't 
> have all three.

The question is not about if the hardware is able to perform such operations 
but regarding breaking the very beauty of SR – no states at the transit/ egress 
nodes. In the context of label stack size explosion, the draft also talks about 
needs to break an SR Path into sub-paths – thereby creating yet additional 
states in the network for accounting reasons (see more detail on this in the 
following). Furthermore, SR-MPLS is designed for SDN – the architecture calls 
for simplification of the network not adding complexity in the network fabric. 
Please also note that a network may have a large number of SR Path, thereby 
creating another dimension for scaling limitations.

The proposed procedure also does not work for node protection in the network. 
The draft essentially calls for ALL nodes to implement procedure proposed in 
the document; I am quoting from the draft.

“When using extensions
   described in this document for traffic accounting and with node-
   protection enabled in the network, it is RECOMMENDED to make sure all
   the nodes in the network support the extension.”

> •The draft proposes to push (up to) 3 Labels for each segment in the 
SR
>Path. That means that label stack is increased up to 3x times! 
This is a
>serious a scaling issue.

>John asked for evidence and yo

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

2017-11-20 Thread Greg Mirsky

Hi Zafar,
I don't see how managing, using passive OAM, i.e. counting fly-by packets,
at transient SR-MPLS nodes can be equated to breaking "no-forwarding state
at transient LSR" model.I believe that practical is as important as
aesthetic and that network cannot be operated without comprehensive OAM
tool box. Of course, every tool in the box is optional and will not be
deployed unless the need arises. If we agree on that, perhaps we can
discuss new requirement to be added to the SR OAM Requirements document.
And then, then consider how to address such requirement. I believe that two
options were mentioned in the thread:

   - described in draft-hegde-spring-traffic-accounting-for-sr-paths
   special purpose label (actually it may end up be extended special purpose
   label) and up to two labels;
   - use GAL and ACH (perhaps somewhat similar to approach used in RFC
   8169).

Regards,
Greg


On Mon, Nov 20, 2017 at 3:36 PM, Zafar Ali (zali)  wrote:

> Hi Adrian,
>
> Some comments are provided in-line.
>
> Please note that, we all want to let this lingering tread die and
> follow-up on the next steps noted during this email exchange. I will be
> happy to have a webEx call and discuss it further, offline.
>
> Thanks
>
> Regards … Zafar
>
> On 11/18/17, 9:08 AM, "Adrian Farrel"  wrote:
>
> 
>
> >>> procedure (in draft-hegde-spring-traffic-accounting-for-sr-paths)
> that breaks SR
> >>> Architecture, highly unscalable and complicated to implement.
> >>
> >> [JD]  Do you have any evidence to justify any of your assertions,
> above?
> >
> > Please note that in draft-hegde-spring-traffic-
> accounting-for-sr-paths:
> >
> > •The transit node needs to be able to recognize the special
> label, read
> >the SR Path Identification label and update the counter
> against such
> >“states”.
>
> >Possibly worth noting that existing devices are capable of
> maintaining many counters and updating them at line speed.
>
> >Several people have noted that ipfix is a process used for accounting
> in networks. That approach may have to find the bottom of stack and then
> match the packet that follows.
>
> >Other approaches (e.g., to ECMP) involve finding the bottom of stack
> and hashing on the header of the payload.
>
> >Some hardware cannot perform either mechanism. This usually results
> from a trade between low cost, high performance, and features. Generally
> you can't have all three.
>
> The question is not about if the hardware is able to perform such
> operations but regarding breaking the very beauty of SR – no states at the
> transit/ egress nodes. In the context of label stack size explosion, the
> draft also talks about needs to break an SR Path into sub-paths – thereby
> creating yet additional states in the network for accounting reasons (see
> more detail on this in the following). Furthermore, SR-MPLS is designed for
> SDN – the architecture calls for simplification of the network not adding
> complexity in the network fabric. Please also note that a network may have
> a large number of SR Path, thereby creating another dimension for scaling
> limitations.
>
> The proposed procedure also does not work for node protection in the
> network. The draft essentially calls for ALL nodes to implement procedure
> proposed in the document; I am quoting from the draft.
>
> “When using extensions
>described in this document for traffic accounting and with node-
>protection enabled in the network, it is RECOMMENDED to make sure all
>the nodes in the network support the extension.”
>
> 
>
> > •The draft proposes to push (up to) 3 Labels for each segment in
> the SR
> >Path. That means that label stack is increased up to 3x
> times! This is a
> >serious a scaling issue.
>
> >John asked for evidence and you provided a misunderstanding or
> misreading of our draft.
> >The document proposes adding 2 or 3 labels per SR Path (noting as
> John did, that this is our own term).
> >That is not what you say, so perhaps you could retract or provide a
> pointer to the text.
>
> >Thus, "increased up to 3x times" applies only with the single case
> where the imposed label stack has exactly one label *and* the three label
> option is applied. So, while  what you say is true, it is clearly (and
> wilfully?) exaggerating the severity of impact, and it is doubtful that
> 4-label stack is actually a problem.
>
> There are many scenarios that will require SR-Path-Stats Labels (up to 3
> labels) to be present multiple times in the label stack. These scenarios
> are not uncommon. The following scenarios as noted in the draft.
>
>   “The head-end node SHOULD insert the SR-
>Path-Stats Labels at a depth in the label stack such that the nodes
>in the SR path can access the SR-Path-Identifier for accounting.  The
>SR-Path-Stats Labels may be present multiple times in the

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

2017-11-20 Thread Zafar Ali (zali)

Hi John,

My response to Adrian’s email should also cover this email too. However, as I 
also noted in email to Adrian … we all want to let this lingering tread die and 
follow-up on the next steps noted during this email exchange. I will be happy 
to have a webEx call and discuss it further, offline.

Thanks

Regards … Zafar


From: "jdr...@juniper.net" <jdr...@juniper.net>
Date: Sunday, November 19, 2017 at 12:59 PM
To: "Zafar Ali (zali)" <z...@cisco.com>
Cc: draft-hegde-spring-traffic-accounting-for-sr-paths 
<draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>, spring 
<spring@ietf.org>, "m...@ietf.org" <m...@ietf.org>
Subject: RE: [spring] [mpls] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

Hi,

Comments inline

Yours Irrespectively,

John

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Zafar Ali (zali)
Sent: Saturday, November 18, 2017 1:12 AM
To: John E Drake <jdr...@juniper.net>
Cc: draft-hegde-spring-traffic-accounting-for-sr-paths 
<draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>; spring 
<spring@ietf.org>; mpls <m...@ietf.org>
Subject: Re: [spring] [mpls] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

Hi John,

Sorry for delay in the response; I was away from the emails. Please see in-line.

Thanks

Regards … Zafar


  procedure (in draft-hegde-spring-traffic-accounting-for-sr-paths) that 
breaks SR Architecture, highly unscalable and complicated to implement.

[JD]  Do you have any evidence to justify any of your assertions, above?

Please note that in draft-hegde-spring-traffic-accounting-for-sr-paths:

•The transit node needs to be able to recognize the special label, read the 
SR Path Identification label and update the counter against such “states”.

[JD]  I think I mentioned in a previous email that this is the type of 
capability used by RSVP-TE LSPs since the advent of MPLS

•The draft proposes to push (up to) 3 Labels for each segment in the SR 
Path. That means that label stack is increased up to 3x times! This is a 
serious a scaling issue.

[JD]  Um, no.  Two or three labels per SR segment list (aka MPLS label stack)

•The controller needs to keep track of transit node capability and push the 
additional per-path labels, accordingly. I.e., the controller also needs to 
maintain such information for the transit nodes.

[JD]  Absolutely not, whatever gave you that idea?  If a transit node 
understands the labels it can maintain and report the counters, otherwise it 
doesn’t, but the controller doesn’t need to know this a priori.




___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

2017-11-20 Thread Zafar Ali (zali)

Hi Adrian, 

Some comments are provided in-line. 

Please note that, we all want to let this lingering tread die and follow-up on 
the next steps noted during this email exchange. I will be happy to have a 
webEx call and discuss it further, offline. 

Thanks

Regards … Zafar 

On 11/18/17, 9:08 AM, "Adrian Farrel"  wrote:

>>> procedure (in draft-hegde-spring-traffic-accounting-for-sr-paths) that 
breaks SR
>>> Architecture, highly unscalable and complicated to implement. 
>>
>> [JD]  Do you have any evidence to justify any of your assertions, above? 
>
> Please note that in draft-hegde-spring-traffic-accounting-for-sr-paths: 
>
> •The transit node needs to be able to recognize the special label, 
read
>the SR Path Identification label and update the counter against 
such
>“states”. 

>Possibly worth noting that existing devices are capable of maintaining 
> many counters and updating them at line speed.

>Several people have noted that ipfix is a process used for accounting in 
> networks. That approach may have to find the bottom of stack and then match 
> the packet that follows. 

>Other approaches (e.g., to ECMP) involve finding the bottom of stack and 
> hashing on the header of the payload.

>Some hardware cannot perform either mechanism. This usually results from a 
> trade between low cost, high performance, and features. Generally you can't 
> have all three.

The question is not about if the hardware is able to perform such operations 
but regarding breaking the very beauty of SR – no states at the transit/ egress 
nodes. In the context of label stack size explosion, the draft also talks about 
needs to break an SR Path into sub-paths – thereby creating yet additional 
states in the network for accounting reasons (see more detail on this in the 
following). Furthermore, SR-MPLS is designed for SDN – the architecture calls 
for simplification of the network not adding complexity in the network fabric. 
Please also note that a network may have a large number of SR Path, thereby 
creating another dimension for scaling limitations. 

The proposed procedure also does not work for node protection in the network. 
The draft essentially calls for ALL nodes to implement procedure proposed in 
the document; I am quoting from the draft. 

“When using extensions
   described in this document for traffic accounting and with node-
   protection enabled in the network, it is RECOMMENDED to make sure all
   the nodes in the network support the extension.”

> •The draft proposes to push (up to) 3 Labels for each segment in the 
SR
>Path. That means that label stack is increased up to 3x times! 
This is a 
>serious a scaling issue.  

>John asked for evidence and you provided a misunderstanding or misreading 
> of our draft. 
>The document proposes adding 2 or 3 labels per SR Path (noting as John 
> did, that this is our own term). 
>That is not what you say, so perhaps you could retract or provide a 
> pointer to the text.

>Thus, "increased up to 3x times" applies only with the single case where 
> the imposed label stack has exactly one label *and* the three label option is 
> applied. So, while  what you say is true, it is clearly (and wilfully?) 
> exaggerating the severity of impact, and it is doubtful that  4-label stack 
> is actually a problem.

There are many scenarios that will require SR-Path-Stats Labels (up to 3 
labels) to be present multiple times in the label stack. These scenarios are 
not uncommon. The following scenarios as noted in the draft.   

  “The head-end node SHOULD insert the SR-
   Path-Stats Labels at a depth in the label stack such that the nodes
   in the SR path can access the SR-Path-Identifier for accounting.  The
   SR-Path-Stats Labels may be present multiple times in the label stack
   of a packet.”

 “It is possible to partially deploy this feature when not all the
   nodes in the network support the extensions defined in this document.
   In such scenarios, the special labels MUST NOT get exposed on the top
   of the label stack at a node that does not support the extensions
   defined in this document.  This may require multiple blocks of SR-
   Path-Stats Labels to be inserted in the packet header.”

> •The controller needs to keep track of transit node capability and
>   push the additional per-path labels, accordingly. I.e., the 
controller
>   also needs to maintain such information for the transit nodes. 

>In most cases, the controller/ingress only needs to care about the 
> capabilities of the egress nodes. That is, if the special purpose label 
> reaches the top of the stack it has to be able to handle it.

>The only time when the transit node issue arises is when there is a small 
> RLD. That information may need to be known by the controller

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

2017-11-19 Thread Stewart Bryant


Hi Mach

The hotspot avoidance idea woud seem to apply to both SR and reguar LDP 
since you can always manipulate the EL modify the ECMP split. If you had 
SR that would be more direct, but EL change would be applicable to 
legacy networks. Since instrumentation could be via IPFIX prettyy much 
any P-router can support this.


Stewart


On 17/11/2017 03:17, Mach Chen wrote:


Hi Stewart,

Indeed, the same idea can apply to both MPLS-SR and MPLS-LDP. For now, 
the requirements that I heard are from MPLS-SR.


Best regards,

Mach

*From:*Stewart Bryant [mailto:stewart.bry...@gmail.com]
*Sent:* Friday, November 17, 2017 10:45 AM
*To:* Mach Chen; stephane.litkow...@orange.com; Robert Raszuk; 
Alexander Vainshtein
*Cc:* mpls; spring; Clarence Filsfils; 
draft-hegde-spring-traffic-accounting-for-sr-paths; Michael 
Gorokhovsky; draft-ietf-spring-oam-usec...@ietf.org; Zafar Ali (zali)
*Subject:* Re: [mpls] [spring] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths



I would like to ask a fundamental question here.

Do we need transit counters for only MPLS-SR, or do we need it for 
MPLS-LDP as well?


If we need it for both, then we need to have this discussion in a 
general MPLS context and not in an MPLS-SR specific context.


At least some of the methods described here would work for both.

Also WRT the proposal to do ingress collection, if nodal paths are 
used, that only tells us the approximate path, not the hotspot which I 
understand to be the original goal.


- Stewart

On 16/11/2017 14:46, Mach Chen wrote:

Hi Stephane,

If you want to do transit measurement, you have to pay some cost.
The difference is how large the cost is, one, two or multiple labels.

For E2E measurement, it could be much easier. A single label
(could be local or global) is inserted immediately follow the last
label of the SR path. Since there is only one label, the path
label could be put into the stack at the beginning, no matter
whether the measurement is enable or not. With this, it will not
affect the entropy.

Best regards,

Mach

*From:*mpls [mailto:mpls-boun...@ietf.org] *On Behalf Of
*stephane.litkow...@orange.com <mailto:stephane.litkow...@orange.com>
*Sent:* Thursday, November 16, 2017 6:49 PM
*To:* Robert Raszuk; Alexander Vainshtein
*Cc:* mpls; spring; Clarence Filsfils;
draft-hegde-spring-traffic-accounting-for-sr-paths; Michael
Gorokhovsky; draft-ietf-spring-oam-usec...@ietf.org
<mailto:draft-ietf-spring-oam-usec...@ietf.org>; Zafar Ali (zali)
    *Subject:* Re: [mpls] [spring] Special purpose labels in
    draft-hegde-spring-traffic-accounting-for-sr-paths

Hi,

Yes today we do not have any CLI command on any router to get
paths statistics for LDP (I mean Ingress to Egress) as LDP is
based on MP2P LSPs, so a transit node does not have the knowledge
of the source. From an operational point of  view, what we do
today is that we collect netflow statistics on core routers, we
project the label stack onto the routing with an external tool to
get the Ingress to Egress LDP traffic including the mapping of the
flows on the links.

Now for RSVP, we do have such statistics as the LSP is P2P and has
states on every node.

Robert mentioned correctly that SR-TE (especially with MPLS
dataplane) has limited TE features (we cannot mimic all what RSVP
does in SRTE without adding too much complexity).

Thus, is it a problem (transit node stats) worth to be solved ? If
yes, where do we accept to put the complexity ? For a stats issue
I would rather prefer to move the complexity to an external tool
that can do correlations or whatever operations rather than
getting it in the forwarding plane…

IMO, that’s a “nice to have” problem to solve getting that we do
not have this for LDP and we know the limitations of SR-TE MPLS.

However, Ingress stats per SRTE LSP are for sure mandatory to get !

The main drawback I see with the proposed solution is that it
mimics what Entropy label does with a solution which is similar
and at the same time cannot replace entropy label as the provided
entropy is far from being sufficient (this is not the goal I know,
but I was looking for potential use case optimizations). So in a
network running entropy label and this mechanism, a router will
need to find the ELI/EL and hash, then find another special label
to build the stats (maybe tomorrow there will be a third one to
look at and a fourth one…). That starts to be a big overhead for
the forwarding plane.

Brgds,

Stephane

*From:*mpls [mailto:mpls-boun...@ietf.org] *On Behalf Of *Robert
Raszuk
*Sent:* Thursday, November 16, 2017 16:23
*To:* Alexander Vainshtein
*Cc:* spring; Clarence Filsfils; mpls; Michael Gorokhovsky;
draft-ietf-spring-oam-usec...@ietf.org
<mailto:draft-ietf-

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

2017-11-19 Thread Stewart Bryant



> On 17 Nov 2017, at 11:26 am, Robert Raszuk <rob...@raszuk.net> wrote:
> 
> Folks,
> 
> LDP LSPs follow pure dst based IGP SPT. So for each ip dst the path packet 
> takes is well known.
> 
Yes but ... it is subjected to ecmp and just as you may wish to tune the sr 
stack to avoid a hotspot, so you might wish to tune the EL to get a better 
traffic spread.

> What is there to record at each transit router hop other then what you 
> already have today from basic netflow counters ?
 
The traffic source.

Stewart


> 
> Thx
> R.
> 
>> On Nov 17, 2017 04:18, "Mach Chen" <mach.c...@huawei.com> wrote:
>> Hi Stewart,
>> 
>>  
>> 
>> Indeed, the same idea can apply to both MPLS-SR and MPLS-LDP. For now, the 
>> requirements that I heard are from MPLS-SR.
>> 
>>  
>> 
>> Best regards,
>> 
>> Mach
>> 
>>  
>> 
>> From: Stewart Bryant [mailto:stewart.bry...@gmail.com] 
>> Sent: Friday, November 17, 2017 10:45 AM
>> To: Mach Chen; stephane.litkow...@orange.com; Robert Raszuk; Alexander 
>> Vainshtein
>> Cc: mpls; spring; Clarence Filsfils; 
>> draft-hegde-spring-traffic-accounting-for-sr-paths; Michael Gorokhovsky; 
>> draft-ietf-spring-oam-usec...@ietf.org; Zafar Ali (zali)
>> Subject: Re: [mpls] [spring] Special purpose labels in 
>> draft-hegde-spring-traffic-accounting-for-sr-paths
>> 
>>  
>> 
>> 
>> I would like to ask a fundamental question here.
>> 
>> Do we need transit counters for only MPLS-SR, or do we need it for MPLS-LDP 
>> as well?
>> 
>> If we need it for both, then we need to have this discussion in a general 
>> MPLS context and not in an MPLS-SR specific context.
>> 
>> At least some of the methods described here would work for both.
>> 
>> Also WRT the proposal to do ingress collection, if nodal paths are used, 
>> that only tells us the approximate path, not the hotspot which I understand 
>> to be the original goal. 
>> 
>> - Stewart
>> 
>> On 16/11/2017 14:46, Mach Chen wrote:
>> 
>> Hi Stephane,
>> 
>>  
>> 
>> If you want to do transit measurement, you have to pay some cost. The 
>> difference is how large the cost is, one, two or multiple labels.
>> 
>>  
>> 
>> For E2E measurement, it could be much easier. A single label (could be local 
>> or global) is inserted immediately follow the last label of the SR path. 
>> Since there is only one label, the path label could be put into the stack at 
>> the beginning, no matter whether the measurement is enable or not. With 
>> this, it will not affect the entropy.
>> 
>>  
>> 
>> Best regards,
>> 
>> Mach
>> 
>>  
>> 
>> From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of 
>> stephane.litkow...@orange.com
>> Sent: Thursday, November 16, 2017 6:49 PM
>> To: Robert Raszuk; Alexander Vainshtein
>> Cc: mpls; spring; Clarence Filsfils; 
>> draft-hegde-spring-traffic-accounting-for-sr-paths; Michael Gorokhovsky; 
>> draft-ietf-spring-oam-usec...@ietf.org; Zafar Ali (zali)
>> Subject: Re: [mpls] [spring] Special purpose labels in 
>> draft-hegde-spring-traffic-accounting-for-sr-paths
>> 
>>  
>> 
>> Hi,
>> 
>>  
>> 
>> Yes today we do not have any CLI command on any router to get paths 
>> statistics for LDP (I mean Ingress to Egress) as LDP is based on MP2P LSPs, 
>> so a transit node does not have the knowledge of the source. From an 
>> operational point of  view, what we do today is that we collect netflow 
>> statistics on core routers, we project the label stack onto the routing with 
>> an external tool to get the Ingress to Egress LDP traffic including the 
>> mapping of the flows on the links.
>> 
>>  
>> 
>> Now for RSVP, we do have such statistics as the LSP is P2P and has states on 
>> every node.
>> 
>>  
>> 
>> Robert mentioned correctly that SR-TE (especially with MPLS dataplane) has 
>> limited TE features (we cannot mimic all what RSVP does in SRTE without 
>> adding too much complexity).
>> 
>>  
>> 
>> Thus, is it a problem (transit node stats) worth to be solved ? If yes, 
>> where do we accept to put the complexity ? For a stats issue I would rather 
>> prefer to move the complexity to an external tool that can do correlations 
>> or whatever operations rather than getting it in the forwarding plane…
>> 
>> IMO, that’s a “nice to have” problem to solve getting that we do not have 
>> this for

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

2017-11-19 Thread John E Drake

Hi,

Comments inline

Yours Irrespectively,

John

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Zafar Ali (zali)
Sent: Saturday, November 18, 2017 1:12 AM
To: John E Drake <jdr...@juniper.net>
Cc: draft-hegde-spring-traffic-accounting-for-sr-paths 
<draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>; spring 
<spring@ietf.org>; mpls <m...@ietf.org>
Subject: Re: [spring] [mpls] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

Hi John,

Sorry for delay in the response; I was away from the emails. Please see in-line.

Thanks

Regards … Zafar


  procedure (in draft-hegde-spring-traffic-accounting-for-sr-paths) that 
breaks SR Architecture, highly unscalable and complicated to implement.

[JD]  Do you have any evidence to justify any of your assertions, above?

Please note that in draft-hegde-spring-traffic-accounting-for-sr-paths:

•The transit node needs to be able to recognize the special label, read the 
SR Path Identification label and update the counter against such “states”.

[JD]  I think I mentioned in a previous email that this is the type of 
capability used by RSVP-TE LSPs since the advent of MPLS

•The draft proposes to push (up to) 3 Labels for each segment in the SR 
Path. That means that label stack is increased up to 3x times! This is a 
serious a scaling issue.

[JD]  Um, no.  Two or three labels per SR segment list (aka MPLS label stack)

•The controller needs to keep track of transit node capability and push the 
additional per-path labels, accordingly. I.e., the controller also needs to 
maintain such information for the transit nodes.

[JD]  Absolutely not, whatever gave you that idea?  If a transit node 
understands the labels it can maintain and report the counters, otherwise it 
doesn’t, but the controller doesn’t need to know this a priori.




___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

2017-11-18 Thread Adrian Farrel

Thanks for helping me break my resolution to leave this thread alone :-(

>>> procedure (in draft-hegde-spring-traffic-accounting-for-sr-paths) that 
>>> breaks SR
>>> Architecture, highly unscalable and complicated to implement. 
>>
>> [JD]  Do you have any evidence to justify any of your assertions, above? 
>
> Please note that in draft-hegde-spring-traffic-accounting-for-sr-paths: 
>
> •The transit node needs to be able to recognize the special label, read
>the SR Path Identification label and update the counter against such
>“states”. 

Possibly worth noting that existing devices are capable of maintaining many 
counters and updating them at line speed.

Several people have noted that ipfix is a process used for accounting in 
networks. That approach may have to find the bottom of stack and then match the 
packet that follows. 

Other approaches (e.g., to ECMP) involve finding the bottom of stack and 
hashing on the header of the payload.

Some hardware cannot perform either mechanism. This usually results from a 
trade between low cost, high performance, and features. Generally you can't 
have all three.
That hardware can't perform transit accounting with fine granularity (although 
you have promised us a solution within the next four months).

> •The draft proposes to push (up to) 3 Labels for each segment in the SR
>Path. That means that label stack is increased up to 3x times! This is 
> a 
>serious a scaling issue.  

John asked for evidence and you provided a misunderstanding or misreading of 
our draft. 
The document proposes adding 2 or 3 labels per SR Path (noting as John did, 
that this is our own term). 
That is not what you say, so perhaps you could retract or provide a pointer to 
the text.

Thus, "increased up to 3x times" applies only with the single case where the 
imposed label stack has exactly one label *and* the three label option is 
applied. So, while what you say is true, it is clearly (and wilfully?) 
exaggerating the severity of impact, and it is doubtful that  4-label stack is 
actually a problem.

> •The controller needs to keep track of transit node capability and
>   push the additional per-path labels, accordingly. I.e., the controller
>   also needs to maintain such information for the transit nodes. 

In most cases, the controller/ingress only needs to care about the capabilities 
of the egress nodes. That is, if the special purpose label reaches the top of 
the stack it has to be able to handle it.

The only time when the transit node issue arises is when there is a small RLD. 
That information may need to be known by the controller to enable correct ECMP 
behavior, and it is distributed in the IGP. 
If there is a desire to enable accounting at transit nodes with a small RLD 
then the Path ID can be inserted higher up the stack and *that* means that the 
controller has to be sensitive as to where in the network the special purpose 
label will rise to the top of the stack.

It seems to me that:
- Controllers are not particularly resource constrained: adding a flag per node
   (or even per link!) would not break any scaling behavior.
- Adding another flag to the IGP alongside the RLD is not significant scaling 
issue.

Cheer,
Adrian

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

2017-11-17 Thread Martin Horneffer


Hi Stewart,

a quick comment on this, from an operator's point of view: Yes, we do 
need the same measurements for LDP as well as for SR.


The exact kind of counter may be debatable. From what we have now, 
per-FEC counters (per-SID for SR) on every node seem like the best 
practical and existing solution.


Best regards, Martin


Am 17.11.17 um 03:45 schrieb Stewart Bryant:


I would like to ask a fundamental question here.

Do we need transit counters for only MPLS-SR, or do we need it for 
MPLS-LDP as well?


If we need it for both, then we need to have this discussion in a 
general MPLS context and not in an MPLS-SR specific context.


At least some of the methods described here would work for both.

Also WRT the proposal to do ingress collection, if nodal paths are 
used, that only tells us the approximate path, not the hotspot which I 
understand to be the original goal.


- Stewart

On 16/11/2017 14:46, Mach Chen wrote:


Hi Stephane,

If you want to do transit measurement, you have to pay some cost. The 
difference is how large the cost is, one, two or multiple labels.


For E2E measurement, it could be much easier. A single label (could 
be local or global) is inserted immediately follow the last label of 
the SR path. Since there is only one label, the path label could be 
put into the stack at the beginning, no matter whether the 
measurement is enable or not. With this, it will not affect the entropy.


Best regards,

Mach

*From:*mpls [mailto:mpls-boun...@ietf.org] *On Behalf Of 
*stephane.litkow...@orange.com

*Sent:* Thursday, November 16, 2017 6:49 PM
*To:* Robert Raszuk; Alexander Vainshtein
*Cc:* mpls; spring; Clarence Filsfils; 
draft-hegde-spring-traffic-accounting-for-sr-paths; Michael 
Gorokhovsky; draft-ietf-spring-oam-usec...@ietf.org; Zafar Ali (zali)
*Subject:* Re: [mpls] [spring] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths


Hi,

Yes today we do not have any CLI command on any router to get paths 
statistics for LDP (I mean Ingress to Egress) as LDP is based on MP2P 
LSPs, so a transit node does not have the knowledge of the source. 
From an operational point of  view, what we do today is that we 
collect netflow statistics on core routers, we project the label 
stack onto the routing with an external tool to get the Ingress to 
Egress LDP traffic including the mapping of the flows on the links.


Now for RSVP, we do have such statistics as the LSP is P2P and has 
states on every node.


Robert mentioned correctly that SR-TE (especially with MPLS 
dataplane) has limited TE features (we cannot mimic all what RSVP 
does in SRTE without adding too much complexity).


Thus, is it a problem (transit node stats) worth to be solved ? If 
yes, where do we accept to put the complexity ? For a stats issue I 
would rather prefer to move the complexity to an external tool that 
can do correlations or whatever operations rather than getting it in 
the forwarding plane…


IMO, that’s a “nice to have” problem to solve getting that we do not 
have this for LDP and we know the limitations of SR-TE MPLS.


However, Ingress stats per SRTE LSP are for sure mandatory to get !

The main drawback I see with the proposed solution is that it mimics 
what Entropy label does with a solution which is similar and at the 
same time cannot replace entropy label as the provided entropy is far 
from being sufficient (this is not the goal I know, but I was looking 
for potential use case optimizations). So in a network running 
entropy label and this mechanism, a router will need to find the 
ELI/EL and hash, then find another special label to build the stats 
(maybe tomorrow there will be a third one to look at and a fourth 
one…). That starts to be a big overhead for the forwarding plane.


Brgds,

Stephane

*From:*mpls [mailto:mpls-boun...@ietf.org] *On Behalf Of *Robert Raszuk
*Sent:* Thursday, November 16, 2017 16:23
*To:* Alexander Vainshtein
*Cc:* spring; Clarence Filsfils; mpls; Michael Gorokhovsky; 
draft-ietf-spring-oam-usec...@ietf.org 
<mailto:draft-ietf-spring-oam-usec...@ietf.org>; 
draft-hegde-spring-traffic-accounting-for-sr-paths; Zafar Ali (zali)
*Subject:* Re: [mpls] [spring] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths


Folks,

This thread started and the requirements reported clearly stated that 
all what we need is the ability to account per path traffic on egress 
nodes.


Now out of the sudden I see requirement popping up to be able to 
measure per path in transit nodes.


Well you can do it today with SRv6 if your hardware allows or you can 
do it with RSVP-TE.


SR-MPLS is replacing LDP and adds ability for limited TE. But SR-MPLS 
never intended to become connection oriented protocol nor architecture.


So I recommend we take a step back here. Or if you like first go and 
fix basic MPLS LDP LSPs to allow per end to end path accounting in 
transit nodes then come back here to ask for the same in S

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

2017-11-17 Thread Robert Raszuk

Stewart,

Cariden Mate based on the topology and netflow computes accurate live
trafic matrix from src to dst and includes transit points for years.

It even estimates load upon failure of a node or a link.

The entire discussion here clearly does not consider or is just not aware
about tools available for a long time for IP and LDP networks capacity
planning.

And when we rolled out RSVP-TE 17 years back Cariden proved that their
accuracy of adjusting the IGP metric to wisely distribute the traffic
across domain is almost as good (95% if I recall correctly) as entire
RSVP-TE machinery.

Ref:

https://www.google.com.sg/url?sa=t=web=j=http://ripe61.ripe.net/presentations/156-ripe61-bcp-planning-and-te.pdf=0ahUKEwjF59nKtsXXAhUGKY8KHZpPB9gQFggnMAE=AOvVaw3QvoSRcs1lFFrj1LEylTft

So before we load set of new requirements on forwarding plane please let's
at least be aware on what is possible today without those new hardware
extensions.

Many thx,
Robert.


On Nov 17, 2017 13:56, "Stewart Bryant" <stewart.bry...@gmail.com> wrote:



On 17 Nov 2017, at 11:26 am, Robert Raszuk <rob...@raszuk.net> wrote:

Folks,

LDP LSPs follow pure dst based IGP SPT. So for each ip dst the path packet
takes is well known.

Yes but ... it is subjected to ecmp and just as you may wish to tune the sr
stack to avoid a hotspot, so you might wish to tune the EL to get a better
traffic spread.

What is there to record at each transit router hop other then what you
already have today from basic netflow counters ?


The traffic source.

Stewart



Thx
R.

On Nov 17, 2017 04:18, "Mach Chen" <mach.c...@huawei.com> wrote:

> Hi Stewart,
>
>
>
> Indeed, the same idea can apply to both MPLS-SR and MPLS-LDP. For now, the
> requirements that I heard are from MPLS-SR.
>
>
>
> Best regards,
>
> Mach
>
>
>
> *From:* Stewart Bryant [mailto:stewart.bry...@gmail.com]
> *Sent:* Friday, November 17, 2017 10:45 AM
> *To:* Mach Chen; stephane.litkow...@orange.com; Robert Raszuk; Alexander
> Vainshtein
> *Cc:* mpls; spring; Clarence Filsfils; 
> draft-hegde-spring-traffic-accounting-for-sr-paths;
> Michael Gorokhovsky; draft-ietf-spring-oam-usec...@ietf.org; Zafar Ali
> (zali)
> *Subject:* Re: [mpls] [spring] Special purpose labels in
> draft-hegde-spring-traffic-accounting-for-sr-paths
>
>
>
>
> I would like to ask a fundamental question here.
>
> Do we need transit counters for only MPLS-SR, or do we need it for
> MPLS-LDP as well?
>
> If we need it for both, then we need to have this discussion in a general
> MPLS context and not in an MPLS-SR specific context.
>
> At least some of the methods described here would work for both.
>
> Also WRT the proposal to do ingress collection, if nodal paths are used,
> that only tells us the approximate path, not the hotspot which I understand
> to be the original goal.
>
> - Stewart
>
> On 16/11/2017 14:46, Mach Chen wrote:
>
> Hi Stephane,
>
>
>
> If you want to do transit measurement, you have to pay some cost. The
> difference is how large the cost is, one, two or multiple labels.
>
>
>
> For E2E measurement, it could be much easier. A single label (could be
> local or global) is inserted immediately follow the last label of the SR
> path. Since there is only one label, the path label could be put into the
> stack at the beginning, no matter whether the measurement is enable or not.
> With this, it will not affect the entropy.
>
>
>
> Best regards,
>
> Mach
>
>
>
> *From:* mpls [mailto:mpls-boun...@ietf.org <mpls-boun...@ietf.org>] *On
> Behalf Of *stephane.litkow...@orange.com
> *Sent:* Thursday, November 16, 2017 6:49 PM
> *To:* Robert Raszuk; Alexander Vainshtein
> *Cc:* mpls; spring; Clarence Filsfils; 
> draft-hegde-spring-traffic-accounting-for-sr-paths;
> Michael Gorokhovsky; draft-ietf-spring-oam-usec...@ietf.org; Zafar Ali
> (zali)
> *Subject:* Re: [mpls] [spring] Special purpose labels in
> draft-hegde-spring-traffic-accounting-for-sr-paths
>
>
>
> Hi,
>
>
>
> Yes today we do not have any CLI command on any router to get paths
> statistics for LDP (I mean Ingress to Egress) as LDP is based on MP2P LSPs,
> so a transit node does not have the knowledge of the source. From an
> operational point of  view, what we do today is that we collect netflow
> statistics on core routers, we project the label stack onto the routing
> with an external tool to get the Ingress to Egress LDP traffic including
> the mapping of the flows on the links.
>
>
>
> Now for RSVP, we do have such statistics as the LSP is P2P and has states
> on every node.
>
>
>
> Robert mentioned correctly that SR-TE (especially with MPLS dataplane) has
> limited TE features (we ca

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

2017-11-16 Thread John E Drake

Stewart,

The intent is to have a general MPLS capability, as I think the draft mentions, 
and the draft is targeted at the MPLS WG.

Yours Irrespectively,

John

From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of Stewart Bryant
Sent: Thursday, November 16, 2017 9:45 PM
To: Mach Chen <mach.c...@huawei.com>; stephane.litkow...@orange.com; Robert 
Raszuk <rob...@raszuk.net>; Alexander Vainshtein 
<alexander.vainsht...@ecitele.com>
Cc: mpls <m...@ietf.org>; spring <spring@ietf.org>; Clarence Filsfils 
<cfils...@cisco.com>; draft-hegde-spring-traffic-accounting-for-sr-paths 
<draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>; Michael 
Gorokhovsky <michael.gorokhov...@ecitele.com>; 
draft-ietf-spring-oam-usec...@ietf.org; Zafar Ali (zali) <z...@cisco.com>
Subject: Re: [mpls] [spring] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths


I would like to ask a fundamental question here.

Do we need transit counters for only MPLS-SR, or do we need it for MPLS-LDP as 
well?

If we need it for both, then we need to have this discussion in a general MPLS 
context and not in an MPLS-SR specific context.

At least some of the methods described here would work for both.

Also WRT the proposal to do ingress collection, if nodal paths are used, that 
only tells us the approximate path, not the hotspot which I understand to be 
the original goal.

- Stewart
On 16/11/2017 14:46, Mach Chen wrote:
Hi Stephane,

If you want to do transit measurement, you have to pay some cost. The 
difference is how large the cost is, one, two or multiple labels.

For E2E measurement, it could be much easier. A single label (could be local or 
global) is inserted immediately follow the last label of the SR path. Since 
there is only one label, the path label could be put into the stack at the 
beginning, no matter whether the measurement is enable or not. With this, it 
will not affect the entropy.

Best regards,
Mach

From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of 
stephane.litkow...@orange.com<mailto:stephane.litkow...@orange.com>
Sent: Thursday, November 16, 2017 6:49 PM
To: Robert Raszuk; Alexander Vainshtein
Cc: mpls; spring; Clarence Filsfils; 
draft-hegde-spring-traffic-accounting-for-sr-paths; Michael Gorokhovsky; 
draft-ietf-spring-oam-usec...@ietf.org<mailto:draft-ietf-spring-oam-usec...@ietf.org>;
 Zafar Ali (zali)
Subject: Re: [mpls] [spring] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

Hi,

Yes today we do not have any CLI command on any router to get paths statistics 
for LDP (I mean Ingress to Egress) as LDP is based on MP2P LSPs, so a transit 
node does not have the knowledge of the source. From an operational point of  
view, what we do today is that we collect netflow statistics on core routers, 
we project the label stack onto the routing with an external tool to get the 
Ingress to Egress LDP traffic including the mapping of the flows on the links.

Now for RSVP, we do have such statistics as the LSP is P2P and has states on 
every node.

Robert mentioned correctly that SR-TE (especially with MPLS dataplane) has 
limited TE features (we cannot mimic all what RSVP does in SRTE without adding 
too much complexity).

Thus, is it a problem (transit node stats) worth to be solved ? If yes, where 
do we accept to put the complexity ? For a stats issue I would rather prefer to 
move the complexity to an external tool that can do correlations or whatever 
operations rather than getting it in the forwarding plane…
IMO, that’s a “nice to have” problem to solve getting that we do not have this 
for LDP and we know the limitations of SR-TE MPLS.
However, Ingress stats per SRTE LSP are for sure mandatory to get !

The main drawback I see with the proposed solution is that it mimics what 
Entropy label does with a solution which is similar and at the same time cannot 
replace entropy label as the provided entropy is far from being sufficient 
(this is not the goal I know, but I was looking for potential use case 
optimizations). So in a network running entropy label and this mechanism, a 
router will need to find the ELI/EL and hash, then find another special label 
to build the stats (maybe tomorrow there will be a third one to look at and a 
fourth one…). That starts to be a big overhead for the forwarding plane.

Brgds,

Stephane


From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of Robert Raszuk
Sent: Thursday, November 16, 2017 16:23
To: Alexander Vainshtein
Cc: spring; Clarence Filsfils; mpls; Michael Gorokhovsky; 
draft-ietf-spring-oam-usec...@ietf.org<mailto:draft-ietf-spring-oam-usec...@ietf.org>;
 draft-hegde-spring-traffic-accounting-for-sr-paths; Zafar Ali (zali)
Subject: Re: [mpls] [spring] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

Folks,

This thread started and the requirements reported clearly stated that all what 
we n

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

2017-11-16 Thread Robert Raszuk

Folks,

LDP LSPs follow pure dst based IGP SPT. So for each ip dst the path packet
takes is well known.

What is there to record at each transit router hop other then what you
already have today from basic netflow counters ?

Thx
R.

On Nov 17, 2017 04:18, "Mach Chen" <mach.c...@huawei.com> wrote:

> Hi Stewart,
>
>
>
> Indeed, the same idea can apply to both MPLS-SR and MPLS-LDP. For now, the
> requirements that I heard are from MPLS-SR.
>
>
>
> Best regards,
>
> Mach
>
>
>
> *From:* Stewart Bryant [mailto:stewart.bry...@gmail.com]
> *Sent:* Friday, November 17, 2017 10:45 AM
> *To:* Mach Chen; stephane.litkow...@orange.com; Robert Raszuk; Alexander
> Vainshtein
> *Cc:* mpls; spring; Clarence Filsfils; 
> draft-hegde-spring-traffic-accounting-for-sr-paths;
> Michael Gorokhovsky; draft-ietf-spring-oam-usec...@ietf.org; Zafar Ali
> (zali)
> *Subject:* Re: [mpls] [spring] Special purpose labels in
> draft-hegde-spring-traffic-accounting-for-sr-paths
>
>
>
>
> I would like to ask a fundamental question here.
>
> Do we need transit counters for only MPLS-SR, or do we need it for
> MPLS-LDP as well?
>
> If we need it for both, then we need to have this discussion in a general
> MPLS context and not in an MPLS-SR specific context.
>
> At least some of the methods described here would work for both.
>
> Also WRT the proposal to do ingress collection, if nodal paths are used,
> that only tells us the approximate path, not the hotspot which I understand
> to be the original goal.
>
> - Stewart
>
> On 16/11/2017 14:46, Mach Chen wrote:
>
> Hi Stephane,
>
>
>
> If you want to do transit measurement, you have to pay some cost. The
> difference is how large the cost is, one, two or multiple labels.
>
>
>
> For E2E measurement, it could be much easier. A single label (could be
> local or global) is inserted immediately follow the last label of the SR
> path. Since there is only one label, the path label could be put into the
> stack at the beginning, no matter whether the measurement is enable or not.
> With this, it will not affect the entropy.
>
>
>
> Best regards,
>
> Mach
>
>
>
> *From:* mpls [mailto:mpls-boun...@ietf.org <mpls-boun...@ietf.org>] *On
> Behalf Of *stephane.litkow...@orange.com
> *Sent:* Thursday, November 16, 2017 6:49 PM
> *To:* Robert Raszuk; Alexander Vainshtein
> *Cc:* mpls; spring; Clarence Filsfils; 
> draft-hegde-spring-traffic-accounting-for-sr-paths;
> Michael Gorokhovsky; draft-ietf-spring-oam-usec...@ietf.org; Zafar Ali
> (zali)
> *Subject:* Re: [mpls] [spring] Special purpose labels in
> draft-hegde-spring-traffic-accounting-for-sr-paths
>
>
>
> Hi,
>
>
>
> Yes today we do not have any CLI command on any router to get paths
> statistics for LDP (I mean Ingress to Egress) as LDP is based on MP2P LSPs,
> so a transit node does not have the knowledge of the source. From an
> operational point of  view, what we do today is that we collect netflow
> statistics on core routers, we project the label stack onto the routing
> with an external tool to get the Ingress to Egress LDP traffic including
> the mapping of the flows on the links.
>
>
>
> Now for RSVP, we do have such statistics as the LSP is P2P and has states
> on every node.
>
>
>
> Robert mentioned correctly that SR-TE (especially with MPLS dataplane) has
> limited TE features (we cannot mimic all what RSVP does in SRTE without
> adding too much complexity).
>
>
>
> Thus, is it a problem (transit node stats) worth to be solved ? If yes,
> where do we accept to put the complexity ? For a stats issue I would rather
> prefer to move the complexity to an external tool that can do correlations
> or whatever operations rather than getting it in the forwarding plane…
>
> IMO, that’s a “nice to have” problem to solve getting that we do not have
> this for LDP and we know the limitations of SR-TE MPLS.
>
> However, Ingress stats per SRTE LSP are for sure mandatory to get !
>
>
>
> The main drawback I see with the proposed solution is that it mimics what
> Entropy label does with a solution which is similar and at the same time
> cannot replace entropy label as the provided entropy is far from being
> sufficient (this is not the goal I know, but I was looking for potential
> use case optimizations). So in a network running entropy label and this
> mechanism, a router will need to find the ELI/EL and hash, then find
> another special label to build the stats (maybe tomorrow there will be a
> third one to look at and a fourth one…). That starts to be a big overhead
> for the forwarding plane.
>
>
>
> Brgds,
>
>
>
> Step

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

2017-11-16 Thread Mach Chen

Hi Stewart,

Indeed, the same idea can apply to both MPLS-SR and MPLS-LDP. For now, the 
requirements that I heard are from MPLS-SR.

Best regards,
Mach

From: Stewart Bryant [mailto:stewart.bry...@gmail.com]
Sent: Friday, November 17, 2017 10:45 AM
To: Mach Chen; stephane.litkow...@orange.com; Robert Raszuk; Alexander 
Vainshtein
Cc: mpls; spring; Clarence Filsfils; 
draft-hegde-spring-traffic-accounting-for-sr-paths; Michael Gorokhovsky; 
draft-ietf-spring-oam-usec...@ietf.org; Zafar Ali (zali)
Subject: Re: [mpls] [spring] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths


I would like to ask a fundamental question here.

Do we need transit counters for only MPLS-SR, or do we need it for MPLS-LDP as 
well?

If we need it for both, then we need to have this discussion in a general MPLS 
context and not in an MPLS-SR specific context.

At least some of the methods described here would work for both.

Also WRT the proposal to do ingress collection, if nodal paths are used, that 
only tells us the approximate path, not the hotspot which I understand to be 
the original goal.

- Stewart
On 16/11/2017 14:46, Mach Chen wrote:
Hi Stephane,

If you want to do transit measurement, you have to pay some cost. The 
difference is how large the cost is, one, two or multiple labels.

For E2E measurement, it could be much easier. A single label (could be local or 
global) is inserted immediately follow the last label of the SR path. Since 
there is only one label, the path label could be put into the stack at the 
beginning, no matter whether the measurement is enable or not. With this, it 
will not affect the entropy.

Best regards,
Mach

From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of 
stephane.litkow...@orange.com<mailto:stephane.litkow...@orange.com>
Sent: Thursday, November 16, 2017 6:49 PM
To: Robert Raszuk; Alexander Vainshtein
Cc: mpls; spring; Clarence Filsfils; 
draft-hegde-spring-traffic-accounting-for-sr-paths; Michael Gorokhovsky; 
draft-ietf-spring-oam-usec...@ietf.org<mailto:draft-ietf-spring-oam-usec...@ietf.org>;
 Zafar Ali (zali)
Subject: Re: [mpls] [spring] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

Hi,

Yes today we do not have any CLI command on any router to get paths statistics 
for LDP (I mean Ingress to Egress) as LDP is based on MP2P LSPs, so a transit 
node does not have the knowledge of the source. From an operational point of  
view, what we do today is that we collect netflow statistics on core routers, 
we project the label stack onto the routing with an external tool to get the 
Ingress to Egress LDP traffic including the mapping of the flows on the links.

Now for RSVP, we do have such statistics as the LSP is P2P and has states on 
every node.

Robert mentioned correctly that SR-TE (especially with MPLS dataplane) has 
limited TE features (we cannot mimic all what RSVP does in SRTE without adding 
too much complexity).

Thus, is it a problem (transit node stats) worth to be solved ? If yes, where 
do we accept to put the complexity ? For a stats issue I would rather prefer to 
move the complexity to an external tool that can do correlations or whatever 
operations rather than getting it in the forwarding plane…
IMO, that’s a “nice to have” problem to solve getting that we do not have this 
for LDP and we know the limitations of SR-TE MPLS.
However, Ingress stats per SRTE LSP are for sure mandatory to get !

The main drawback I see with the proposed solution is that it mimics what 
Entropy label does with a solution which is similar and at the same time cannot 
replace entropy label as the provided entropy is far from being sufficient 
(this is not the goal I know, but I was looking for potential use case 
optimizations). So in a network running entropy label and this mechanism, a 
router will need to find the ELI/EL and hash, then find another special label 
to build the stats (maybe tomorrow there will be a third one to look at and a 
fourth one…). That starts to be a big overhead for the forwarding plane.

Brgds,

Stephane


From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of Robert Raszuk
Sent: Thursday, November 16, 2017 16:23
To: Alexander Vainshtein
Cc: spring; Clarence Filsfils; mpls; Michael Gorokhovsky; 
draft-ietf-spring-oam-usec...@ietf.org<mailto:draft-ietf-spring-oam-usec...@ietf.org>;
 draft-hegde-spring-traffic-accounting-for-sr-paths; Zafar Ali (zali)
Subject: Re: [mpls] [spring] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

Folks,

This thread started and the requirements reported clearly stated that all what 
we need is the ability to account per path traffic on egress nodes.

Now out of the sudden I see requirement popping up to be able to measure per 
path in transit nodes.

Well you can do it today with SRv6 if your hardware allows or you can do it 
with RSVP-TE.

SR-MPLS is replacing LDP and adds ability for limited TE. But SR-MPLS never

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

2017-11-16 Thread Robert Raszuk

Resending ..


Folks,

LDP LSPs follow pure dst based IGP SPT. So for each ip dst the path packet
takes is well known.

What is there to record at each transit router hop other then what you
already have today from basic netflow counters ?

Thx
R.







On Nov 17, 2017 04:18, "Mach Chen" <mach.c...@huawei.com> wrote:

> Hi Stewart,
>
>
>
> Indeed, the same idea can apply to both MPLS-SR and MPLS-LDP. For now, the
> requirements that I heard are from MPLS-SR.
>
>
>
> Best regards,
>
> Mach
>
>
>
> *From:* Stewart Bryant [mailto:stewart.bry...@gmail.com]
> *Sent:* Friday, November 17, 2017 10:45 AM
> *To:* Mach Chen; stephane.litkow...@orange.com; Robert Raszuk; Alexander
> Vainshtein
> *Cc:* mpls; spring; Clarence Filsfils; 
> draft-hegde-spring-traffic-accounting-for-sr-paths;
> Michael Gorokhovsky; draft-ietf-spring-oam-usec...@ietf.org; Zafar Ali
> (zali)
> *Subject:* Re: [mpls] [spring] Special purpose labels in
> draft-hegde-spring-traffic-accounting-for-sr-paths
>
>
>
>
> I would like to ask a fundamental question here.
>
> Do we need transit counters for only MPLS-SR, or do we need it for
> MPLS-LDP as well?
>
> If we need it for both, then we need to have this discussion in a general
> MPLS context and not in an MPLS-SR specific context.
>
> At least some of the methods described here would work for both.
>
> Also WRT the proposal to do ingress collection, if nodal paths are used,
> that only tells us the approximate path, not the hotspot which I understand
> to be the original goal.
>
> - Stewart
>
> On 16/11/2017 14:46, Mach Chen wrote:
>
> Hi Stephane,
>
>
>
> If you want to do transit measurement, you have to pay some cost. The
> difference is how large the cost is, one, two or multiple labels.
>
>
>
> For E2E measurement, it could be much easier. A single label (could be
> local or global) is inserted immediately follow the last label of the SR
> path. Since there is only one label, the path label could be put into the
> stack at the beginning, no matter whether the measurement is enable or not.
> With this, it will not affect the entropy.
>
>
>
> Best regards,
>
> Mach
>
>
>
> *From:* mpls [mailto:mpls-boun...@ietf.org <mpls-boun...@ietf.org>] *On
> Behalf Of *stephane.litkow...@orange.com
> *Sent:* Thursday, November 16, 2017 6:49 PM
> *To:* Robert Raszuk; Alexander Vainshtein
> *Cc:* mpls; spring; Clarence Filsfils; 
> draft-hegde-spring-traffic-accounting-for-sr-paths;
> Michael Gorokhovsky; draft-ietf-spring-oam-usec...@ietf.org; Zafar Ali
> (zali)
> *Subject:* Re: [mpls] [spring] Special purpose labels in
> draft-hegde-spring-traffic-accounting-for-sr-paths
>
>
>
> Hi,
>
>
>
> Yes today we do not have any CLI command on any router to get paths
> statistics for LDP (I mean Ingress to Egress) as LDP is based on MP2P LSPs,
> so a transit node does not have the knowledge of the source. From an
> operational point of  view, what we do today is that we collect netflow
> statistics on core routers, we project the label stack onto the routing
> with an external tool to get the Ingress to Egress LDP traffic including
> the mapping of the flows on the links.
>
>
>
> Now for RSVP, we do have such statistics as the LSP is P2P and has states
> on every node.
>
>
>
> Robert mentioned correctly that SR-TE (especially with MPLS dataplane) has
> limited TE features (we cannot mimic all what RSVP does in SRTE without
> adding too much complexity).
>
>
>
> Thus, is it a problem (transit node stats) worth to be solved ? If yes,
> where do we accept to put the complexity ? For a stats issue I would rather
> prefer to move the complexity to an external tool that can do correlations
> or whatever operations rather than getting it in the forwarding plane…
>
> IMO, that’s a “nice to have” problem to solve getting that we do not have
> this for LDP and we know the limitations of SR-TE MPLS.
>
> However, Ingress stats per SRTE LSP are for sure mandatory to get !
>
>
>
> The main drawback I see with the proposed solution is that it mimics what
> Entropy label does with a solution which is similar and at the same time
> cannot replace entropy label as the provided entropy is far from being
> sufficient (this is not the goal I know, but I was looking for potential
> use case optimizations). So in a network running entropy label and this
> mechanism, a router will need to find the ELI/EL and hash, then find
> another special label to build the stats (maybe tomorrow there will be a
> third one to look at and a fourth one…). That starts to be a big overhead
> for the forwarding plane.
>
>
>
> Brgds,
>
&

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

2017-11-16 Thread Jeff Tantsura

Hi,

 

Some comments after reading the thread:

 

/*rtgwg-chair hat on

I wonder, who are the mighty “we” who are better than unworthy “them”?  I find 
the wording rather unfortunate 

*/

 

 

The problem statement – Uniquely identify at any given node: (SID stack, *) or 
(*, source) or (SID stack, source)

    Data plane – metadata encoding (label(s), VNID, none, etc)

    Control plane – capability adv, context adv, potentially divided 
over flooding facility (IGP/BGP) and an NBI (BGP-LS/PCEP)

 

If we agree, there’s a problem to solve, we review every proposal made, 
pros/cons analysis.

If there’s none – we move on.

 

Thoughts?

 

Cheers,

Jeff    

From: mpls <mpls-boun...@ietf.org> on behalf of "Zafar Ali (zali)" 
<z...@cisco.com>
Date: Thursday, November 16, 2017 at 16:25
To: Xuxiaohu <xuxia...@huawei.com>, Greg Mirsky <gregimir...@gmail.com>
Cc: draft-hegde-spring-traffic-accounting-for-sr-paths 
<draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>, spring 
<spring@ietf.org>, mpls <m...@ietf.org>
Subject: Re: [mpls] [spring] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

 

Hi Folks, 

 

I also agree that it’s not a question on requirement but about a procedure (in 
draft-hegde-spring-traffic-accounting-for-sr-paths) that breaks SR 
Architecture, highly unscalable and complicated to implement. We can solve this 
problem without breaking the SR architecture. We plan to write a draft before 
the next IETF. 

 

Thanks

 

Regards … Zafar 

 

 

From: Xuxiaohu <xuxia...@huawei.com>
Date: Wednesday, November 15, 2017 at 9:54 PM
To: Greg Mirsky <gregimir...@gmail.com>
Cc: "Zafar Ali (zali)" <z...@cisco.com>, 
draft-hegde-spring-traffic-accounting-for-sr-paths 
<draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>, "m...@ietf.org" 
<m...@ietf.org>, spring <spring@ietf.org>
Subject: RE: [mpls] [spring] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

 

I fully agree with you that OAM tools are important. 

I just felt that the approach as proposed in the draft would enconter the same 
terrible issues as those associated with the MPLS-SR entropy label usage due to 
RLD and MSD hardware limitations. 

Best regards,
Xiaohu 




徐小虎 Xuxiaohu
M：+86-13910161692 
E：xuxia...@huawei.com
产品与解决方案-网络战略与业务发展部
Products & Solutions-Network Strategy & Business Development Dept

发件人： Greg Mirsky

收件人： Xuxiaohu<xuxia...@huawei.com>

抄送： Zafar Ali 
(zali)<z...@cisco.com>;draft-hegde-spring-traffic-accounting-for-sr-paths<draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>;mpls<m...@ietf.org>;spring<spring@ietf.org>

主题： Re: [mpls] [spring] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

时间： 2017-11-16 10:27:55

 

Dear All, 

I cannot imagine that operators will agree to deploy network that lacks 
critical OAM tools to monitor performance and troubleshoot the network. True, 
some will brave the challenge and be the early adopters but even they will 
likely request that the OAM toolbox be sufficient to support their operational 
needs. I see that this work clearly describes the problem and why ability to 
quantify the flow behavior at internal nodes is important for efficient network 
operation. First let's discuss whether the case and requirement towards OAM is 
real and valid. Then we can continue to discussion of what measurement method 
to use.

 

Regards,

Greg

 

On Thu, Nov 16, 2017 at 10:05 AM, Xuxiaohu <xuxia...@huawei.com> wrote:

Concur. Although it has some values, it's not cost-efficient from my point of 
view. Network simplicity should be the first priority object. Hence we would 
have to make some compromise.

Best regards,
Xiaohu 




徐小虎 Xuxiaohu
M：+86-13910161692 
E：xuxia...@huawei.com
产品与解决方案-网络战略与业务发展部
Products & Solutions-Network Strategy & Business Development Dept

发件人： Zafar Ali (zali)

收件人： Greg 
Mirsky<gregimir...@gmail.com>;draft-hegde-spring-traffic-accounting-for-sr-paths<draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>;mpls<m...@ietf.org>;spring<spring@ietf.org>

主题： Re: [mpls] [spring] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

时间： 2017-11-16 02:24:10

 

Hi, 

 

This draft breaks the SR architecture. I am quoting a snippet from abstract of 
SR Architecture document 
https://tools.ietf.org/html/draft-ietf-spring-segment-routing-13, which states:

“SR allows to enforce a flow through any topological path while maintaining 
per-flow state only at the ingress nodes to the SR domain.” 

 

In addition to creating states at transit and egress nodes, the procedure also 
affects the data plane and makes it unscalable. It also makes controller job 
much harder and error prune. In summary, I find the procedure very complex and

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

2017-11-16 Thread Mach Chen

Hi Stephane,

If you want to do transit measurement, you have to pay some cost. The 
difference is how large the cost is, one, two or multiple labels.

For E2E measurement, it could be much easier. A single label (could be local or 
global) is inserted immediately follow the last label of the SR path. Since 
there is only one label, the path label could be put into the stack at the 
beginning, no matter whether the measurement is enable or not. With this, it 
will not affect the entropy.

Best regards,
Mach

From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of 
stephane.litkow...@orange.com
Sent: Thursday, November 16, 2017 6:49 PM
To: Robert Raszuk; Alexander Vainshtein
Cc: mpls; spring; Clarence Filsfils; 
draft-hegde-spring-traffic-accounting-for-sr-paths; Michael Gorokhovsky; 
draft-ietf-spring-oam-usec...@ietf.org; Zafar Ali (zali)
Subject: Re: [mpls] [spring] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

Hi,

Yes today we do not have any CLI command on any router to get paths statistics 
for LDP (I mean Ingress to Egress) as LDP is based on MP2P LSPs, so a transit 
node does not have the knowledge of the source. From an operational point of  
view, what we do today is that we collect netflow statistics on core routers, 
we project the label stack onto the routing with an external tool to get the 
Ingress to Egress LDP traffic including the mapping of the flows on the links.

Now for RSVP, we do have such statistics as the LSP is P2P and has states on 
every node.

Robert mentioned correctly that SR-TE (especially with MPLS dataplane) has 
limited TE features (we cannot mimic all what RSVP does in SRTE without adding 
too much complexity).

Thus, is it a problem (transit node stats) worth to be solved ? If yes, where 
do we accept to put the complexity ? For a stats issue I would rather prefer to 
move the complexity to an external tool that can do correlations or whatever 
operations rather than getting it in the forwarding plane…
IMO, that’s a “nice to have” problem to solve getting that we do not have this 
for LDP and we know the limitations of SR-TE MPLS.
However, Ingress stats per SRTE LSP are for sure mandatory to get !

The main drawback I see with the proposed solution is that it mimics what 
Entropy label does with a solution which is similar and at the same time cannot 
replace entropy label as the provided entropy is far from being sufficient 
(this is not the goal I know, but I was looking for potential use case 
optimizations). So in a network running entropy label and this mechanism, a 
router will need to find the ELI/EL and hash, then find another special label 
to build the stats (maybe tomorrow there will be a third one to look at and a 
fourth one…). That starts to be a big overhead for the forwarding plane.

Brgds,

Stephane


From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of Robert Raszuk
Sent: Thursday, November 16, 2017 16:23
To: Alexander Vainshtein
Cc: spring; Clarence Filsfils; mpls; Michael Gorokhovsky; 
draft-ietf-spring-oam-usec...@ietf.org<mailto:draft-ietf-spring-oam-usec...@ietf.org>;
 draft-hegde-spring-traffic-accounting-for-sr-paths; Zafar Ali (zali)
Subject: Re: [mpls] [spring] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

Folks,

This thread started and the requirements reported clearly stated that all what 
we need is the ability to account per path traffic on egress nodes.

Now out of the sudden I see requirement popping up to be able to measure per 
path in transit nodes.

Well you can do it today with SRv6 if your hardware allows or you can do it 
with RSVP-TE.

SR-MPLS is replacing LDP and adds ability for limited TE. But SR-MPLS never 
intended to become connection oriented protocol nor architecture.

So I recommend we take a step back here. Or if you like first go and fix basic 
MPLS LDP LSPs to allow per end to end path accounting in transit nodes then 
come back here to ask for the same in SR-MPLS. Not the other way around.

Thx
r.


On Nov 16, 2017 16:12, "Alexander Vainshtein" 
<alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com>> 
wrote:
Greg,
I concur with your position: let’s first  of all agree that ability to measure 
traffic carried by an SR-TE LSP in a specific transit node is a require OAM 
function for SR.

I have looked up the SR OAM Use 
Cases<https://datatracker.ietf.org/doc/draft-ietf-spring-oam-usecase/?include_text=1>
 draft, and I did not find any relevant use cases there.
The only time measurements are mentioned is a reference to an expired 
implementation 
report<https://tools.ietf.org/html/draft-leipnitz-spring-pms-implementation-report-00>
 draft discussing delay measurements.  Since delay measurements are in any case 
based on synthetic traffic, and are always end-to-end (one-way or two-way), 
this reference is not relevant, IMHO, for this discussion.

I have added the authors of the SR OAM Use Ca

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

2017-11-16 Thread Mach Chen

Hi Stephane,

If you want to do transit measurement, you have to pay some cost. The 
difference is how large the cost is, one, two or multiple labels.

For E2E measurement, it could be much easier and simpler. A single label (could 
be local or global, as proposed in 
https://tools.ietf.org/html/draft-cheng-spring-path-segment ) is inserted 
immediately follow the last label of the SR path. Since there is only one 
label, the path label could be put into the stack at the beginning, no matter 
whether the measurement is enable or not. With this, it will not affect the 
entropy.

Best regards,
Mach


From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of 
stephane.litkow...@orange.com
Sent: Thursday, November 16, 2017 6:49 PM
To: Robert Raszuk; Alexander Vainshtein
Cc: mpls; spring; Clarence Filsfils; 
draft-hegde-spring-traffic-accounting-for-sr-paths; Michael Gorokhovsky; 
draft-ietf-spring-oam-usec...@ietf.org; Zafar Ali (zali)
Subject: Re: [mpls] [spring] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

Hi,

Yes today we do not have any CLI command on any router to get paths statistics 
for LDP (I mean Ingress to Egress) as LDP is based on MP2P LSPs, so a transit 
node does not have the knowledge of the source. From an operational point of  
view, what we do today is that we collect netflow statistics on core routers, 
we project the label stack onto the routing with an external tool to get the 
Ingress to Egress LDP traffic including the mapping of the flows on the links.

Now for RSVP, we do have such statistics as the LSP is P2P and has states on 
every node.

Robert mentioned correctly that SR-TE (especially with MPLS dataplane) has 
limited TE features (we cannot mimic all what RSVP does in SRTE without adding 
too much complexity).

Thus, is it a problem (transit node stats) worth to be solved ? If yes, where 
do we accept to put the complexity ? For a stats issue I would rather prefer to 
move the complexity to an external tool that can do correlations or whatever 
operations rather than getting it in the forwarding plane…
IMO, that’s a “nice to have” problem to solve getting that we do not have this 
for LDP and we know the limitations of SR-TE MPLS.
However, Ingress stats per SRTE LSP are for sure mandatory to get !

The main drawback I see with the proposed solution is that it mimics what 
Entropy label does with a solution which is similar and at the same time cannot 
replace entropy label as the provided entropy is far from being sufficient 
(this is not the goal I know, but I was looking for potential use case 
optimizations). So in a network running entropy label and this mechanism, a 
router will need to find the ELI/EL and hash, then find another special label 
to build the stats (maybe tomorrow there will be a third one to look at and a 
fourth one…). That starts to be a big overhead for the forwarding plane.

Brgds,

Stephane


From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of Robert Raszuk
Sent: Thursday, November 16, 2017 16:23
To: Alexander Vainshtein
Cc: spring; Clarence Filsfils; mpls; Michael Gorokhovsky; 
draft-ietf-spring-oam-usec...@ietf.org<mailto:draft-ietf-spring-oam-usec...@ietf.org>;
 draft-hegde-spring-traffic-accounting-for-sr-paths; Zafar Ali (zali)
Subject: Re: [mpls] [spring] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

Folks,

This thread started and the requirements reported clearly stated that all what 
we need is the ability to account per path traffic on egress nodes.

Now out of the sudden I see requirement popping up to be able to measure per 
path in transit nodes.

Well you can do it today with SRv6 if your hardware allows or you can do it 
with RSVP-TE.

SR-MPLS is replacing LDP and adds ability for limited TE. But SR-MPLS never 
intended to become connection oriented protocol nor architecture.

So I recommend we take a step back here. Or if you like first go and fix basic 
MPLS LDP LSPs to allow per end to end path accounting in transit nodes then 
come back here to ask for the same in SR-MPLS. Not the other way around.

Thx
r.


On Nov 16, 2017 16:12, "Alexander Vainshtein" 
<alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com>> 
wrote:
Greg,
I concur with your position: let’s first  of all agree that ability to measure 
traffic carried by an SR-TE LSP in a specific transit node is a require OAM 
function for SR.

I have looked up the SR OAM Use 
Cases<https://datatracker.ietf.org/doc/draft-ietf-spring-oam-usecase/?include_text=1>
 draft, and I did not find any relevant use cases there.
The only time measurements are mentioned is a reference to an expired 
implementation 
report<https://tools.ietf.org/html/draft-leipnitz-spring-pms-implementation-report-00>
 draft discussing delay measurements.  Since delay measurements are in any case 
based on synthetic traffic, and are always end-to-end (one-way or two-way

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

2017-11-16 Thread Robert Raszuk

> Hi,
>
>
>
> We are dealing with an SR network in which the data plane is MPLS rather
> than IP.
>
>
>
> Yours Irrespectively,
>
>
>
> John
>

I think this is very important to stop here for a moment and discuss ...
What is MPLS data plane ?

MPLS data plane can be connection less (constructed with LDP or IGP
extensions of domain wide labels) - that is really an IP based control
plane which controls the forwarding modulo tunnels to specific nodes
(SR-MPLS, GRE, VXLAN etc )

MPLS data plane can also be connection oriented (example using RSVP-TE)
which setup LSP across the network. Does not reserve nor guarantee anything
in the data plane (only if well done in the control plane - which btw some
folks still do not believe after so many years :-).

So here we are now really trying to take connection oriented model and push
it to connecton less paradigm.

Very bizarre ...

Best,
Robert.
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

2017-11-16 Thread John E Drake

ShaoWen,

We are not talking about per-flow counting but rather per SR Segment list 
counting.

Yours Irrespectively,

John

From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of ShaoWen Ma
Sent: Wednesday, November 15, 2017 9:43 PM
To: Robert Raszuk <rob...@raszuk.net>
Cc: draft-hegde-spring-traffic-accounting-for-sr-paths 
<draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>; spring 
<spring@ietf.org>; mpls <m...@ietf.org>; Zafar Ali (zali) <z...@cisco.com>
Subject: Re: [mpls] [spring] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

Hi Robert and all,
  SPRING try to get rid of per flow forwarding status. that's the design 
principal for whole network.
  and Shraddha just want to add back per flow Traffic statistics as request, 
which will only applied to interested flow.

  if you check the label stack for traffic statistics, that might be get some 
processing trouble to handle:
{300|200|100} with another label stack such as {400|300|200|100} on the same 
nodes.

  so path id do have it's value if customer want to check specific flow, by not 
impact all packet process on the transit router.

Best Regards
Shaowen Ma


On Thu, Nov 16, 2017 at 10:26 AM, Robert Raszuk 
<rob...@raszuk.net<mailto:rob...@raszuk.net>> wrote:
The architecture is fine. This is accounting state not forwarding state.

But no new labels are needed.

See on ingress you apply sr label stack based on some match of the fields of 
actual packet. So all you need is to do accounting on the very same fields of 
the packets on egress and you have path accounting required for you.

Besides this method also seamlessly works over non sr capable SFs as long as 
such SFs do not mess with the packet content of those tuples.

cheers,
r.

On Nov 16, 2017 10:05, "Xuxiaohu" 
<xuxia...@huawei.com<mailto:xuxia...@huawei.com>> wrote:
Concur. Although it has some values, it's not cost-efficient from my point of 
view. Network simplicity should be the first priority object. Hence we would 
have to make some compromise.

Best regards,
Xiaohu




徐小虎 Xuxiaohu
M：+86-13910161692<tel:+86-13910161692>
E：xuxia...@huawei.com<mailto:xuxia...@huawei.com>
产品与解决方案-网络战略与业务发展部
Products & Solutions-Network Strategy & Business Development Dept
发件人： Zafar Ali (zali)
收件人： Greg 
Mirsky<gregimir...@gmail.com<mailto:gregimir...@gmail.com>>;draft-hegde-spring-traffic-accounting-for-sr-paths<draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org<mailto:draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>>;mpls<m...@ietf.org<mailto:m...@ietf.org>>;spring<spring@ietf.org<mailto:spring@ietf.org>>
主题： Re: [mpls] [spring] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths
时间： 2017-11-16 02:24:10

Hi,

This draft breaks the SR architecture. I am quoting a snippet from abstract of 
SR Architecture document 
https://tools.ietf.org/html/draft-ietf-spring-segment-routing-13<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dspring-2Dsegment-2Drouting-2D13=DwMFaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE=pDf9Z_0bnb1M7ZTb9cuNMjqRvJMQ3j-OP-PYnk8mLsE=iLt83qz5E4U-p9yrmrynWZOsqFbqZtvO4kCko3KsFQs=>,
 which states:
“SR allows to enforce a flow through any topological path while maintaining 
per-flow state only at the ingress nodes to the SR domain.”

In addition to creating states at transit and egress nodes, the procedure also 
affects the data plane and makes it unscalable. It also makes controller job 
much harder and error prune. In summary, I find the procedure very complex and 
unscalable.

Thanks

Regards … Zafar


From: spring <spring-boun...@ietf.org<mailto:spring-boun...@ietf.org>> on 
behalf of Greg Mirsky <gregimir...@gmail.com<mailto:gregimir...@gmail.com>>
Date: Wednesday, November 15, 2017 at 11:10 AM
To: 
"draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org<mailto:draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>"
 
<draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org<mailto:draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>>,
 "m...@ietf.org<mailto:m...@ietf.org>" <m...@ietf.org<mailto:m...@ietf.org>>, 
"spring@ietf.org<mailto:spring@ietf.org>" 
<spring@ietf.org<mailto:spring@ietf.org>>
Subject: [spring] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

Hi Shraddha,
thank you for very well written and thought through draft. I have these 
questions I'd like to discuss:

  *   Have you thought of using not one special purpose label for both SR Path 
Identifier and SR Path Identifier+Source SID cases but request two special 
purpose labels, one for each case. Then the SR Path

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

2017-11-16 Thread John E Drake

Zafar,

Comment inline.

Yours Irrespectively,

John

From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of Zafar Ali (zali)
Sent: Thursday, November 16, 2017 3:25 AM
To: Xuxiaohu <xuxia...@huawei.com>; Greg Mirsky <gregimir...@gmail.com>
Cc: draft-hegde-spring-traffic-accounting-for-sr-paths 
<draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>; spring 
<spring@ietf.org>; mpls <m...@ietf.org>
Subject: Re: [mpls] [spring] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

Hi Folks,

I also agree that it’s not a question on requirement but about a procedure (in 
draft-hegde-spring-traffic-accounting-for-sr-paths) that breaks SR 
Architecture, highly unscalable and complicated to implement.

[JD]  Do you have any evidence to justify any of your assertions, above?

We can solve this problem without breaking the SR architecture. We plan to 
write a draft before the next IETF.

Thanks

Regards … Zafar


From: Xuxiaohu <xuxia...@huawei.com<mailto:xuxia...@huawei.com>>
Date: Wednesday, November 15, 2017 at 9:54 PM
To: Greg Mirsky <gregimir...@gmail.com<mailto:gregimir...@gmail.com>>
Cc: "Zafar Ali (zali)" <z...@cisco.com<mailto:z...@cisco.com>>, 
draft-hegde-spring-traffic-accounting-for-sr-paths 
<draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org<mailto:draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>>,
 "m...@ietf.org<mailto:m...@ietf.org>" <m...@ietf.org<mailto:m...@ietf.org>>, 
spring <spring@ietf.org<mailto:spring@ietf.org>>
Subject: RE: [mpls] [spring] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

I fully agree with you that OAM tools are important.

I just felt that the approach as proposed in the draft would enconter the same 
terrible issues as those associated with the MPLS-SR entropy label usage due to 
RLD and MSD hardware limitations.

Best regards,
Xiaohu



徐小虎 Xuxiaohu
M：+86-13910161692<tel:+86-13910161692>
E：xuxia...@huawei.com<mailto:xuxia...@huawei.com>
产品与解决方案-网络战略与业务发展部
Products & Solutions-Network Strategy & Business Development Dept
发件人： Greg Mirsky
收件人： Xuxiaohu<xuxia...@huawei.com<mailto:xuxia...@huawei.com>>
抄送： Zafar Ali 
(zali)<z...@cisco.com<mailto:z...@cisco.com>>;draft-hegde-spring-traffic-accounting-for-sr-paths<draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org<mailto:draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>>;mpls<m...@ietf.org<mailto:m...@ietf.org>>;spring<spring@ietf.org<mailto:spring@ietf.org>>
主题： Re: [mpls] [spring] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths
时间： 2017-11-16 10:27:55

Dear All,
I cannot imagine that operators will agree to deploy network that lacks 
critical OAM tools to monitor performance and troubleshoot the network. True, 
some will brave the challenge and be the early adopters but even they will 
likely request that the OAM toolbox be sufficient to support their operational 
needs. I see that this work clearly describes the problem and why ability to 
quantify the flow behavior at internal nodes is important for efficient network 
operation. First let's discuss whether the case and requirement towards OAM is 
real and valid. Then we can continue to discussion of what measurement method 
to use.

Regards,
Greg

On Thu, Nov 16, 2017 at 10:05 AM, Xuxiaohu 
<xuxia...@huawei.com<mailto:xuxia...@huawei.com>> wrote:
Concur. Although it has some values, it's not cost-efficient from my point of 
view. Network simplicity should be the first priority object. Hence we would 
have to make some compromise.

Best regards,
Xiaohu



徐小虎 Xuxiaohu
M：+86-13910161692<tel:+86-13910161692>
E：xuxia...@huawei.com<mailto:xuxia...@huawei.com>
产品与解决方案-网络战略与业务发展部
Products & Solutions-Network Strategy & Business Development Dept
发件人： Zafar Ali (zali)
收件人： Greg 
Mirsky<gregimir...@gmail.com<mailto:gregimir...@gmail.com>>;draft-hegde-spring-traffic-accounting-for-sr-paths<draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org<mailto:draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>>;mpls<m...@ietf.org<mailto:m...@ietf.org>>;spring<spring@ietf.org<mailto:spring@ietf.org>>
主题： Re: [mpls] [spring] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths
时间： 2017-11-16 02:24:10

Hi,

This draft breaks the SR architecture. I am quoting a snippet from abstract of 
SR Architecture document 
https://tools.ietf.org/html/draft-ietf-spring-segment-routing-13<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dspring-2Dsegment-2Drouting-2D13=DwMGaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=CRB2tJiQePk0cT-h5LGhEWH-s_x

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

2017-11-16 Thread Alexander Vainshtein

John,
I am fine with the name “SR Segment List ID”.

Regards,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   alexander.vainsht...@ecitele.com

From: John E Drake [mailto:jdr...@juniper.net]
Sent: Thursday, November 16, 2017 1:51 PM
To: Alexander Vainshtein <alexander.vainsht...@ecitele.com>; Greg Mirsky 
<gregimir...@gmail.com>
Cc: draft-hegde-spring-traffic-accounting-for-sr-paths 
<draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>; spring 
<spring@ietf.org>; mpls <m...@ietf.org>; Michael Gorokhovsky 
<michael.gorokhov...@ecitele.com>; draft-ietf-spring-oam-usec...@ietf.org; 
Zafar Ali (zali) <z...@cisco.com>
Subject: RE: [mpls] [spring] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

Sasha,

We did not use the term SR-TE LSP in our draft and I think it is misleading.  I 
suggested to Robert in another email that we use the term ‘SR Segment List’ 
since that is what the SR Architecture document describes.

Yours Irrespectively,

John

From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of Alexander Vainshtein
Sent: Thursday, November 16, 2017 3:12 AM
To: Greg Mirsky <gregimir...@gmail.com<mailto:gregimir...@gmail.com>>
Cc: draft-hegde-spring-traffic-accounting-for-sr-paths 
<draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org<mailto:draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>>;
 spring <spring@ietf.org<mailto:spring@ietf.org>>; mpls 
<m...@ietf.org<mailto:m...@ietf.org>>; Michael Gorokhovsky 
<michael.gorokhov...@ecitele.com<mailto:michael.gorokhov...@ecitele.com>>; 
draft-ietf-spring-oam-usec...@ietf.org<mailto:draft-ietf-spring-oam-usec...@ietf.org>;
 Zafar Ali (zali) <z...@cisco.com<mailto:z...@cisco.com>>
Subject: Re: [mpls] [spring] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

Greg,
I concur with your position: let’s first  of all agree that ability to measure 
traffic carried by an SR-TE LSP in a specific transit node is a require OAM 
function for SR.

I have looked up the SR OAM Use 
Cases<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dspring-2Doam-2Dusecase_-3Finclude-5Ftext-3D1=DwMGaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE=o9qv2My5eWygGvjkf_QsK_1IAw2Atjqea6_llVBKJEk=ifN9UpNTQHQoMWV6z0HBj3Wav-2yLAINnkkeydarDro=>
 draft, and I did not find any relevant use cases there.
The only time measurements are mentioned is a reference to an expired 
implementation 
report<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dleipnitz-2Dspring-2Dpms-2Dimplementation-2Dreport-2D00=DwMGaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE=o9qv2My5eWygGvjkf_QsK_1IAw2Atjqea6_llVBKJEk=-HwWyJMbl3Zaa1RER9PwlKM4mv41ifM5TXFe_aAtPFk=>
 draft discussing delay measurements.  Since delay measurements are in any case 
based on synthetic traffic, and are always end-to-end (one-way or two-way), 
this reference is not relevant, IMHO, for this discussion.

I have added the authors of the SR OAM Use Cases draft to tis thread.

Regards,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   
alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com>

From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of Greg Mirsky
Sent: Thursday, November 16, 2017 4:28 AM
To: Xuxiaohu <xuxia...@huawei.com<mailto:xuxia...@huawei.com>>
Cc: draft-hegde-spring-traffic-accounting-for-sr-paths 
<draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org<mailto:draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>>;
 spring <spring@ietf.org<mailto:spring@ietf.org>>; Zafar Ali (zali) 
<z...@cisco.com<mailto:z...@cisco.com>>; mpls 
<m...@ietf.org<mailto:m...@ietf.org>>
Subject: Re: [mpls] [spring] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

Dear All,
I cannot imagine that operators will agree to deploy network that lacks 
critical OAM tools to monitor performance and troubleshoot the network. True, 
some will brave the challenge and be the early adopters but even they will 
likely request that the OAM toolbox be sufficient to support their operational 
needs. I see that this work clearly describes the problem and why ability to 
quantify the flow behavior at internal nodes is important for efficient network 
operation. First let's discuss whether the case and requirement towards OAM is 
real and valid. Then we can continue to discussion of what measurement method 
to use.

Regards,
Greg

On Thu, Nov 16, 2017 at 10:05 AM, Xuxiaohu 
<xuxia...@huawei.com<mailto:xuxia...@huawei.com>> wrote:
Concur. Although it has some values, it's not cost-efficient from my point of 
view. Network simplicity should be the fir

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

2017-11-16 Thread John E Drake

Sasha,

We did not use the term SR-TE LSP in our draft and I think it is misleading.  I 
suggested to Robert in another email that we use the term ‘SR Segment List’ 
since that is what the SR Architecture document describes.

Yours Irrespectively,

John

From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of Alexander Vainshtein
Sent: Thursday, November 16, 2017 3:12 AM
To: Greg Mirsky <gregimir...@gmail.com>
Cc: draft-hegde-spring-traffic-accounting-for-sr-paths 
<draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>; spring 
<spring@ietf.org>; mpls <m...@ietf.org>; Michael Gorokhovsky 
<michael.gorokhov...@ecitele.com>; draft-ietf-spring-oam-usec...@ietf.org; 
Zafar Ali (zali) <z...@cisco.com>
Subject: Re: [mpls] [spring] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

Greg,
I concur with your position: let’s first  of all agree that ability to measure 
traffic carried by an SR-TE LSP in a specific transit node is a require OAM 
function for SR.

I have looked up the SR OAM Use 
Cases<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dspring-2Doam-2Dusecase_-3Finclude-5Ftext-3D1=DwMGaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE=o9qv2My5eWygGvjkf_QsK_1IAw2Atjqea6_llVBKJEk=ifN9UpNTQHQoMWV6z0HBj3Wav-2yLAINnkkeydarDro=>
 draft, and I did not find any relevant use cases there.
The only time measurements are mentioned is a reference to an expired 
implementation 
report<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dleipnitz-2Dspring-2Dpms-2Dimplementation-2Dreport-2D00=DwMGaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE=o9qv2My5eWygGvjkf_QsK_1IAw2Atjqea6_llVBKJEk=-HwWyJMbl3Zaa1RER9PwlKM4mv41ifM5TXFe_aAtPFk=>
 draft discussing delay measurements.  Since delay measurements are in any case 
based on synthetic traffic, and are always end-to-end (one-way or two-way), 
this reference is not relevant, IMHO, for this discussion.

I have added the authors of the SR OAM Use Cases draft to tis thread.

Regards,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   
alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com>

From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of Greg Mirsky
Sent: Thursday, November 16, 2017 4:28 AM
To: Xuxiaohu <xuxia...@huawei.com<mailto:xuxia...@huawei.com>>
Cc: draft-hegde-spring-traffic-accounting-for-sr-paths 
<draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org<mailto:draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>>;
 spring <spring@ietf.org<mailto:spring@ietf.org>>; Zafar Ali (zali) 
<z...@cisco.com<mailto:z...@cisco.com>>; mpls 
<m...@ietf.org<mailto:m...@ietf.org>>
Subject: Re: [mpls] [spring] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

Dear All,
I cannot imagine that operators will agree to deploy network that lacks 
critical OAM tools to monitor performance and troubleshoot the network. True, 
some will brave the challenge and be the early adopters but even they will 
likely request that the OAM toolbox be sufficient to support their operational 
needs. I see that this work clearly describes the problem and why ability to 
quantify the flow behavior at internal nodes is important for efficient network 
operation. First let's discuss whether the case and requirement towards OAM is 
real and valid. Then we can continue to discussion of what measurement method 
to use.

Regards,
Greg

On Thu, Nov 16, 2017 at 10:05 AM, Xuxiaohu 
<xuxia...@huawei.com<mailto:xuxia...@huawei.com>> wrote:
Concur. Although it has some values, it's not cost-efficient from my point of 
view. Network simplicity should be the first priority object. Hence we would 
have to make some compromise.

Best regards,
Xiaohu



徐小虎 Xuxiaohu
M：+86-13910161692<tel:+86-13910161692>
E：xuxia...@huawei.com<mailto:xuxia...@huawei.com>
产品与解决方案-网络战略与业务发展部
Products & Solutions-Network Strategy & Business Development Dept
发件人： Zafar Ali (zali)
收件人： Greg 
Mirsky<gregimir...@gmail.com<mailto:gregimir...@gmail.com>>;draft-hegde-spring-traffic-accounting-for-sr-paths<draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org<mailto:draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>>;mpls<m...@ietf.org<mailto:m...@ietf.org>>;spring<spring@ietf.org<mailto:spring@ietf.org>>
主题： Re: [mpls] [spring] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths
时间： 2017-11-16 02:24:10

Hi,

This draft breaks the SR architecture. I am quoting a snippet from abstract of 
SR Architecture document 
https://tools.ietf.org/html/draft-ietf-spring-segment-routing-13<https://urldefens

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

2017-11-16 Thread John E Drake

Hi,

We are dealing with an SR network in which the data plane is MPLS rather than 
IP.

Yours Irrespectively,

John

From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of Xuxiaohu
Sent: Thursday, November 16, 2017 1:47 AM
To: Jeff Tantsura <jefftant.i...@gmail.com>; Robert Raszuk <rob...@raszuk.net>
Cc: draft-hegde-spring-traffic-accounting-for-sr-paths 
<draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>; spring 
<spring@ietf.org>; Zafar Ali (zali) <z...@cisco.com>; mpls <m...@ietf.org>
Subject: Re: [mpls] [spring] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

Just an idea occurring in my mind: Maybe it's worthwhile to consider how to 
address this business demand by using the unified SR approach 
(https://datatracker.ietf.org/meeting/100/materials/slides-100-mpls-04-draft-xu-mpls-unified-source-routing-instruction-ietf100/).
 More specifically, use the source port of the UDP tunnel header to carry the 
path identity, just like the idea of using the unified SR approach to address 
the load-balancing issue associated with the MPLS-SR.




徐小虎 Xuxiaohu
M：+86-13910161692<tel:+86-13910161692>
E：xuxia...@huawei.com<mailto:xuxia...@huawei.com>
产品与解决方案-网络战略与业务发展部
Products & Solutions-Network Strategy & Business Development Dept
发件人： Xuxiaohu
收件人： Jeff 
Tantsura<jefftant.i...@gmail.com<mailto:jefftant.i...@gmail.com>>;Robert 
Raszuk<rob...@raszuk.net<mailto:rob...@raszuk.net>>
抄送： 
draft-hegde-spring-traffic-accounting-for-sr-paths<draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org<mailto:draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>>;spring<spring@ietf.org<mailto:spring@ietf.org>>;mpls<m...@ietf.org<mailto:m...@ietf.org>>;Zafar
 Ali (zali)<z...@cisco.com<mailto:z...@cisco.com>>;Greg 
Mirsky<gregimir...@gmail.com<mailto:gregimir...@gmail.com>>
主题： Re: [spring] [mpls] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths
时间： 2017-11-16 14:25:32


s/per flow/per path.



徐小虎 Xuxiaohu
M：+86-13910161692<tel:+86-13910161692>
E：xuxia...@huawei.com<mailto:xuxia...@huawei.com>
产品与解决方案-网络战略与业务发展部
Products & Solutions-Network Strategy & Business Development Dept
发件人： Xuxiaohu
收件人： Jeff 
Tantsura<jefftant.i...@gmail.com<mailto:jefftant.i...@gmail.com>>;Robert 
Raszuk<rob...@raszuk.net<mailto:rob...@raszuk.net>>
抄送： 
draft-hegde-spring-traffic-accounting-for-sr-paths<draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org<mailto:draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>>;Greg
 
Mirsky<gregimir...@gmail.com<mailto:gregimir...@gmail.com>>;spring<spring@ietf.org<mailto:spring@ietf.org>>;Zafar
 Ali 
(zali)<z...@cisco.com<mailto:z...@cisco.com>>;mpls<m...@ietf.org<mailto:m...@ietf.org>>
主题： Re: [spring] [mpls] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths
时间： 2017-11-16 11:21:46


If so, why not directly use RSVP-TE if the per flow state is needed?



徐小虎 Xuxiaohu
M：+86-13910161692<tel:+86-13910161692>
E：xuxia...@huawei.com<mailto:xuxia...@huawei.com>
产品与解决方案-网络战略与业务发展部
Products & Solutions-Network Strategy & Business Development Dept
发件人： Jeff Tantsura
收件人： Robert Raszuk<rob...@raszuk.net<mailto:rob...@raszuk.net>>
抄送： Xuxiaohu<xuxia...@huawei.com<mailto:xuxia...@huawei.com>>;Greg 
Mirsky<gregimir...@gmail.com<mailto:gregimir...@gmail.com>>;spring<spring@ietf.org<mailto:spring@ietf.org>>;mpls<m...@ietf.org<mailto:m...@ietf.org>>;Zafar
 Ali 
(zali)<z...@cisco.com<mailto:z...@cisco.com>>;draft-hegde-spring-traffic-accounting-for-sr-paths<draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org<mailto:draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>>
主题： Re: [spring] [mpls] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths
时间： 2017-11-16 11:09:13

Today, if you run RSVP-TE, you’d get (at least on high end platforms) counters 
per LSP.
Having the same functionality with SR seems rather logical.

Cheers,
Jeff

From: <rras...@gmail.com<mailto:rras...@gmail.com>> on behalf of Robert Raszuk 
<rob...@raszuk.net<mailto:rob...@raszuk.net>>
Date: Thursday, November 16, 2017 at 10:50
To: Jeff Tantsura <jefftant.i...@gmail.com<mailto:jefftant.i...@gmail.com>>
Cc: Xuxiaohu <xuxia...@huawei.com<mailto:xuxia...@huawei.com>>, Greg Mirsky 
<gregimir...@gmail.com<mailto:gregimir...@gmail.com>>, spring 
<spring@ietf.org<mailto:spring@ietf.org>>, mpls 
<m...@ietf.org<mailto:m...@ietf.org>>, "Zafar Ali (zali)" 
<z...@cisco.c

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

2017-11-16 Thread Alexander Vainshtein


Stephane,
Lots of thanks for formulating the questions that, from my POV, should be 
answered (one way or another). As I see it, they are:

1.   Is transit node per SR-TE LSP statistics a problem that should be 
solved?

2.   If yes:

a.   Is it a critical or “nice to have” issue? Or something in between?

b.   Should the solution be localized  in the NEs or moved to an external 
entity?
Regards,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   alexander.vainsht...@ecitele.com

From: stephane.litkow...@orange.com [mailto:stephane.litkow...@orange.com]
Sent: Thursday, November 16, 2017 12:49 PM
To: Robert Raszuk <rob...@raszuk.net>; Alexander Vainshtein 
<alexander.vainsht...@ecitele.com>
Cc: spring <spring@ietf.org>; Clarence Filsfils <cfils...@cisco.com>; mpls 
<m...@ietf.org>; Michael Gorokhovsky <michael.gorokhov...@ecitele.com>; 
draft-ietf-spring-oam-usec...@ietf.org; 
draft-hegde-spring-traffic-accounting-for-sr-paths 
<draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>; Zafar Ali (zali) 
<z...@cisco.com>
Subject: RE: [mpls] [spring] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

Hi,

Yes today we do not have any CLI command on any router to get paths statistics 
for LDP (I mean Ingress to Egress) as LDP is based on MP2P LSPs, so a transit 
node does not have the knowledge of the source. From an operational point of  
view, what we do today is that we collect netflow statistics on core routers, 
we project the label stack onto the routing with an external tool to get the 
Ingress to Egress LDP traffic including the mapping of the flows on the links.

Now for RSVP, we do have such statistics as the LSP is P2P and has states on 
every node.

Robert mentioned correctly that SR-TE (especially with MPLS dataplane) has 
limited TE features (we cannot mimic all what RSVP does in SRTE without adding 
too much complexity).

Thus, is it a problem (transit node stats) worth to be solved ? If yes, where 
do we accept to put the complexity ? For a stats issue I would rather prefer to 
move the complexity to an external tool that can do correlations or whatever 
operations rather than getting it in the forwarding plane…
IMO, that’s a “nice to have” problem to solve getting that we do not have this 
for LDP and we know the limitations of SR-TE MPLS.
However, Ingress stats per SRTE LSP are for sure mandatory to get !

The main drawback I see with the proposed solution is that it mimics what 
Entropy label does with a solution which is similar and at the same time cannot 
replace entropy label as the provided entropy is far from being sufficient 
(this is not the goal I know, but I was looking for potential use case 
optimizations). So in a network running entropy label and this mechanism, a 
router will need to find the ELI/EL and hash, then find another special label 
to build the stats (maybe tomorrow there will be a third one to look at and a 
fourth one…). That starts to be a big overhead for the forwarding plane.

Brgds,

Stephane


From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of Robert Raszuk
Sent: Thursday, November 16, 2017 16:23
To: Alexander Vainshtein
Cc: spring; Clarence Filsfils; mpls; Michael Gorokhovsky; 
draft-ietf-spring-oam-usec...@ietf.org<mailto:draft-ietf-spring-oam-usec...@ietf.org>;
 draft-hegde-spring-traffic-accounting-for-sr-paths; Zafar Ali (zali)
Subject: Re: [mpls] [spring] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

Folks,

This thread started and the requirements reported clearly stated that all what 
we need is the ability to account per path traffic on egress nodes.

Now out of the sudden I see requirement popping up to be able to measure per 
path in transit nodes.

Well you can do it today with SRv6 if your hardware allows or you can do it 
with RSVP-TE.

SR-MPLS is replacing LDP and adds ability for limited TE. But SR-MPLS never 
intended to become connection oriented protocol nor architecture.

So I recommend we take a step back here. Or if you like first go and fix basic 
MPLS LDP LSPs to allow per end to end path accounting in transit nodes then 
come back here to ask for the same in SR-MPLS. Not the other way around.

Thx
r.


On Nov 16, 2017 16:12, "Alexander Vainshtein" 
<alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com>> 
wrote:
Greg,
I concur with your position: let’s first  of all agree that ability to measure 
traffic carried by an SR-TE LSP in a specific transit node is a require OAM 
function for SR.

I have looked up the SR OAM Use 
Cases<https://datatracker.ietf.org/doc/draft-ietf-spring-oam-usecase/?include_text=1>
 draft, and I did not find any relevant use cases there.
The only time measurements are mentioned is a reference to an expired 
implementation 
report<https://tools.ietf.org/html/draft-leipnitz-spring-pms-implementation-report-00>

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

2017-11-16 Thread Greg Mirsky

Hi Sasha,
completely agree that the current version of the #13 does not reflect the
use case at hand. Thus my suggestion to edit #13, update the Requirements
document to reflect the use case and keep the SR OAM requirements document
alive, not necessary to publish, for similar occasions.
In regards to SPME, Dave's wording is perfect and I withdraw mine.

Regards,
Greg

On Thu, Nov 16, 2017 at 5:46 PM, Alexander Vainshtein <
alexander.vainsht...@ecitele.com> wrote:

> Greg,
>
> I do not think that the quoted requirement from the SR OAM Requirements
> draft is relevant for this discussion, because, from my POV, it does not
> refer to *ability to measure* *actual traffic carried in a specific SR-TE
> LSP across a specific link in the transit node*. And this is actually
> what draft-hegde is all about.
>
>
>
> I also do not see how SPME (an ill-begotten MPLS-TP construct) is relevant
> for this discussion.
>
>
>
> As for the added state in transit node: From mu POV ability to recognize
> specific SR-TE Path ID in the label stack of a packet and to update the
> counters allocated to this SR-TE Path is a forwarding plane state.
>
>
>
> My 2c,
>
> Sasha
>
>
>
> Office: +972-39266302 <+972%203-926-6302>
>
> Cell:  +972-549266302 <+972%2054-926-6302>
>
> Email:   alexander.vainsht...@ecitele.com
>
>
>
> *From:* Greg Mirsky [mailto:gregimir...@gmail.com]
> *Sent:* Thursday, November 16, 2017 11:15 AM
> *To:* Alexander Vainshtein <alexander.vainsht...@ecitele.com>
> *Cc:* draft-hegde-spring-traffic-accounting-for-sr-paths <
> draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>; spring <
> spring@ietf.org>; Zafar Ali (zali) <z...@cisco.com>; mpls <m...@ietf.org>;
> Xuxiaohu <xuxia...@huawei.com>; Michael Gorokhovsky <
> michael.gorokhov...@ecitele.com>; draft-ietf-spring-oam-usec...@ietf.org
> *Subject:* Re: [mpls] [spring] Special purpose labels in
> draft-hegde-spring-traffic-accounting-for-sr-paths
>
>
>
> Hi Sasha,
>
> many thanks.
>
> I'd point to SR OAM Requirements
> <https://tools.ietf.org/html/draft-ietf-spring-sr-oam-requirement-03>
> (regrettably expired):
>
>REQ#13:  SR OAM MUST have the ability to measure Packet loss, Packet
>
> Delay or Delay variation using Active (using synthetic
>
> probe) and Passive (using data stream) mode.
>
>
>
> I think that our discussion indicates that OAM requirements document is 
> useful at least for as long as we're developing OAM toolset. And the document 
> will benefit from clarification to reflect our discussion that PM may be 
> performed both e2e and over SPME.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Thu, Nov 16, 2017 at 4:11 PM, Alexander Vainshtein <
> alexander.vainsht...@ecitele.com> wrote:
>
> Greg,
>
> I concur with your position: let’s first  of all agree that ability to
> measure traffic carried by an SR-TE LSP in a specific transit node is a
> require OAM function for SR.
>
>
>
> I have looked up the SR OAM Use Cases
> <https://datatracker.ietf.org/doc/draft-ietf-spring-oam-usecase/?include_text=1>
> draft, and I did not find any relevant use cases there.
>
> The only time measurements are mentioned is a reference to an expired
> implementation report
> <https://tools.ietf.org/html/draft-leipnitz-spring-pms-implementation-report-00>
> draft discussing delay measurements.  Since delay measurements are in any
> case based on synthetic traffic, and are always end-to-end (one-way or
> two-way), this reference is not relevant, IMHO, for this discussion.
>
>
>
> I have added the authors of the SR OAM Use Cases draft to tis thread.
>
>
>
> Regards,
>
> Sasha
>
>
>
> Office: +972-39266302 <+972%203-926-6302>
>
> Cell:  +972-549266302 <+972%2054-926-6302>
>
> Email:   alexander.vainsht...@ecitele.com
>
>
>
> *From:* mpls [mailto:mpls-boun...@ietf.org] *On Behalf Of *Greg Mirsky
> *Sent:* Thursday, November 16, 2017 4:28 AM
> *To:* Xuxiaohu <xuxia...@huawei.com>
> *Cc:* draft-hegde-spring-traffic-accounting-for-sr-paths <
> draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>; spring <
> spring@ietf.org>; Zafar Ali (zali) <z...@cisco.com>; mpls <m...@ietf.org>
> *Subject:* Re: [mpls] [spring] Special purpose labels in
> draft-hegde-spring-traffic-accounting-for-sr-paths
>
>
>
> Dear All,
>
> I cannot imagine that operators will agree to deploy network that lacks
> critical OAM tools to monitor performance and troubleshoot the network.
> True, some will brave the challenge and be the early adopter

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

2017-11-16 Thread Alexander Vainshtein

Ruediger hi!
I understand that measurement of actual traffic carried in a SR-TE path via a 
transit link has not been considered in the SR OAM Use Cases draft. It only 
dealt with end-to-end liveness monitoring and measurements, and this is clearly 
stated in the Intro section.

But, from my POV, these measurements represent a valid OAM use case 
nevertheless.

Regards,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   alexander.vainsht...@ecitele.com

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of 
ruediger.g...@telekom.de
Sent: Thursday, November 16, 2017 11:19 AM
To: Alexander Vainshtein <alexander.vainsht...@ecitele.com>
Cc: draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org; 
spring@ietf.org; m...@ietf.org; Michael Gorokhovsky 
<michael.gorokhov...@ecitele.com>; draft-ietf-spring-oam-usec...@ietf.org; 
xuxia...@huawei.com; z...@cisco.com; gregimir...@gmail.com
Subject: Re: [spring] [mpls] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

Sasha,

the purpose of the SR OAM Use Case is to illustrate how Segment Routing enables 
new ways to perform OAM tasks. Like delay measurements.

What is discussed here are new OAM requirements caused by SR. To me, these are 
part of an own or a different draft. The scope of the SR OAM Use Case never was 
intended to cover them.

Regards,

Ruediger

Von: Alexander Vainshtein [mailto:alexander.vainsht...@ecitele.com]
Gesendet: Donnerstag, 16. November 2017 09:12
An: Greg Mirsky <gregimir...@gmail.com<mailto:gregimir...@gmail.com>>
Cc: draft-hegde-spring-traffic-accounting-for-sr-paths 
<draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org<mailto:draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>>;
 spring <spring@ietf.org<mailto:spring@ietf.org>>; Zafar Ali (zali) 
<z...@cisco.com<mailto:z...@cisco.com>>; mpls 
<m...@ietf.org<mailto:m...@ietf.org>>; Xuxiaohu 
<xuxia...@huawei.com<mailto:xuxia...@huawei.com>>; Michael Gorokhovsky 
<michael.gorokhov...@ecitele.com<mailto:michael.gorokhov...@ecitele.com>>; 
draft-ietf-spring-oam-usec...@ietf.org<mailto:draft-ietf-spring-oam-usec...@ietf.org>
Betreff: RE: [mpls] [spring] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

Greg,
I concur with your position: let’s first  of all agree that ability to measure 
traffic carried by an SR-TE LSP in a specific transit node is a require OAM 
function for SR.

I have looked up the SR OAM Use 
Cases<https://datatracker.ietf.org/doc/draft-ietf-spring-oam-usecase/?include_text=1>
 draft, and I did not find any relevant use cases there.
The only time measurements are mentioned is a reference to an expired 
implementation 
report<https://tools.ietf.org/html/draft-leipnitz-spring-pms-implementation-report-00>
 draft discussing delay measurements.  Since delay measurements are in any case 
based on synthetic traffic, and are always end-to-end (one-way or two-way), 
this reference is not relevant, IMHO, for this discussion.

I have added the authors of the SR OAM Use Cases draft to tis thread.

Regards,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   
alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com>

From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of Greg Mirsky
Sent: Thursday, November 16, 2017 4:28 AM
To: Xuxiaohu <xuxia...@huawei.com<mailto:xuxia...@huawei.com>>
Cc: draft-hegde-spring-traffic-accounting-for-sr-paths 
<draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org<mailto:draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>>;
 spring <spring@ietf.org<mailto:spring@ietf.org>>; Zafar Ali (zali) 
<z...@cisco.com<mailto:z...@cisco.com>>; mpls 
<m...@ietf.org<mailto:m...@ietf.org>>
Subject: Re: [mpls] [spring] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

Dear All,
I cannot imagine that operators will agree to deploy network that lacks 
critical OAM tools to monitor performance and troubleshoot the network. True, 
some will brave the challenge and be the early adopters but even they will 
likely request that the OAM toolbox be sufficient to support their operational 
needs. I see that this work clearly describes the problem and why ability to 
quantify the flow behavior at internal nodes is important for efficient network 
operation. First let's discuss whether the case and requirement towards OAM is 
real and valid. Then we can continue to discussion of what measurement method 
to use.

Regards,
Greg

On Thu, Nov 16, 2017 at 10:05 AM, Xuxiaohu 
<xuxia...@huawei.com<mailto:xuxia...@huawei.com>> wrote:
Concur. Although it has some values, it's not cost-efficient from my point of 
view. Network simplicity should be the first priority object. Hence we would 
have to make some compromise.

Best regards,

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

2017-11-16 Thread Alexander Vainshtein

Greg,
I do not think that the quoted requirement from the SR OAM Requirements draft 
is relevant for this discussion, because, from my POV, it does not refer to 
ability to measure actual traffic carried in a specific SR-TE LSP across a 
specific link in the transit node. And this is actually what draft-hegde is all 
about.

I also do not see how SPME (an ill-begotten MPLS-TP construct) is relevant for 
this discussion.

As for the added state in transit node: From mu POV ability to recognize 
specific SR-TE Path ID in the label stack of a packet and to update the 
counters allocated to this SR-TE Path is a forwarding plane state.

My 2c,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   alexander.vainsht...@ecitele.com

From: Greg Mirsky [mailto:gregimir...@gmail.com]
Sent: Thursday, November 16, 2017 11:15 AM
To: Alexander Vainshtein <alexander.vainsht...@ecitele.com>
Cc: draft-hegde-spring-traffic-accounting-for-sr-paths 
<draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>; spring 
<spring@ietf.org>; Zafar Ali (zali) <z...@cisco.com>; mpls <m...@ietf.org>; 
Xuxiaohu <xuxia...@huawei.com>; Michael Gorokhovsky 
<michael.gorokhov...@ecitele.com>; draft-ietf-spring-oam-usec...@ietf.org
Subject: Re: [mpls] [spring] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

Hi Sasha,
many thanks.
I'd point to SR OAM 
Requirements<https://tools.ietf.org/html/draft-ietf-spring-sr-oam-requirement-03>
 (regrettably expired):

   REQ#13:  SR OAM MUST have the ability to measure Packet loss, Packet

Delay or Delay variation using Active (using synthetic

probe) and Passive (using data stream) mode.



I think that our discussion indicates that OAM requirements document is useful 
at least for as long as we're developing OAM toolset. And the document will 
benefit from clarification to reflect our discussion that PM may be performed 
both e2e and over SPME.



Regards,

Greg

On Thu, Nov 16, 2017 at 4:11 PM, Alexander Vainshtein 
<alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com>> 
wrote:
Greg,
I concur with your position: let’s first  of all agree that ability to measure 
traffic carried by an SR-TE LSP in a specific transit node is a require OAM 
function for SR.

I have looked up the SR OAM Use 
Cases<https://datatracker.ietf.org/doc/draft-ietf-spring-oam-usecase/?include_text=1>
 draft, and I did not find any relevant use cases there.
The only time measurements are mentioned is a reference to an expired 
implementation 
report<https://tools.ietf.org/html/draft-leipnitz-spring-pms-implementation-report-00>
 draft discussing delay measurements.  Since delay measurements are in any case 
based on synthetic traffic, and are always end-to-end (one-way or two-way), 
this reference is not relevant, IMHO, for this discussion.

I have added the authors of the SR OAM Use Cases draft to tis thread.

Regards,
Sasha

Office: +972-39266302<tel:+972%203-926-6302>
Cell:  +972-549266302<tel:+972%2054-926-6302>
Email:   
alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com>

From: mpls [mailto:mpls-boun...@ietf.org<mailto:mpls-boun...@ietf.org>] On 
Behalf Of Greg Mirsky
Sent: Thursday, November 16, 2017 4:28 AM
To: Xuxiaohu <xuxia...@huawei.com<mailto:xuxia...@huawei.com>>
Cc: draft-hegde-spring-traffic-accounting-for-sr-paths 
<draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org<mailto:draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>>;
 spring <spring@ietf.org<mailto:spring@ietf.org>>; Zafar Ali (zali) 
<z...@cisco.com<mailto:z...@cisco.com>>; mpls 
<m...@ietf.org<mailto:m...@ietf.org>>
Subject: Re: [mpls] [spring] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

Dear All,
I cannot imagine that operators will agree to deploy network that lacks 
critical OAM tools to monitor performance and troubleshoot the network. True, 
some will brave the challenge and be the early adopters but even they will 
likely request that the OAM toolbox be sufficient to support their operational 
needs. I see that this work clearly describes the problem and why ability to 
quantify the flow behavior at internal nodes is important for efficient network 
operation. First let's discuss whether the case and requirement towards OAM is 
real and valid. Then we can continue to discussion of what measurement method 
to use.

Regards,
Greg

On Thu, Nov 16, 2017 at 10:05 AM, Xuxiaohu 
<xuxia...@huawei.com<mailto:xuxia...@huawei.com>> wrote:
Concur. Although it has some values, it's not cost-efficient from my point of 
view. Network simplicity should be the first priority object. Hence we would 
have to make some compromise.

Best regards,
Xiaohu



徐小虎 Xuxiaohu
M：+86-13910161692<tel:+86-13910161

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

2017-11-16 Thread Robert Raszuk

Greg,

It is easy to support req 13 counters but those are interface counters
without history to which sr-mpls path it belongs.

SR-MPLS is *NOT* connection oriented and since you are poping domain wide
labels you have no path history in transit nodes.

So if anyone here now attempts to make SR-MPLS to become connection
oriented and carry and inspect per path ID in transit nodes this is
fundamental change.

Perhaps SR-MPLS spec should explicitely clarify in version 12 that this is
not the intended objective of sr-mpls.

thx
r.


On Nov 16, 2017 17:15, "Greg Mirsky" <gregimir...@gmail.com> wrote:

Hi Sasha,
many thanks.
I'd point to SR OAM Requirements
<https://tools.ietf.org/html/draft-ietf-spring-sr-oam-requirement-03>
(regrettably expired):

   REQ#13:  SR OAM MUST have the ability to measure Packet loss, Packet
Delay or Delay variation using Active (using synthetic
probe) and Passive (using data stream) mode.


I think that our discussion indicates that OAM requirements document
is useful at least for as long as we're developing OAM toolset. And
the document will benefit from clarification to reflect our discussion
that PM may be performed both e2e and over SPME.


Regards,

Greg


On Thu, Nov 16, 2017 at 4:11 PM, Alexander Vainshtein <
alexander.vainsht...@ecitele.com> wrote:

> Greg,
>
> I concur with your position: let’s first  of all agree that ability to
> measure traffic carried by an SR-TE LSP in a specific transit node is a
> require OAM function for SR.
>
>
>
> I have looked up the SR OAM Use Cases
> <https://datatracker.ietf.org/doc/draft-ietf-spring-oam-usecase/?include_text=1>
> draft, and I did not find any relevant use cases there.
>
> The only time measurements are mentioned is a reference to an expired
> implementation report
> <https://tools.ietf.org/html/draft-leipnitz-spring-pms-implementation-report-00>
> draft discussing delay measurements.  Since delay measurements are in any
> case based on synthetic traffic, and are always end-to-end (one-way or
> two-way), this reference is not relevant, IMHO, for this discussion.
>
>
>
> I have added the authors of the SR OAM Use Cases draft to tis thread.
>
>
>
> Regards,
>
> Sasha
>
>
>
> Office: +972-39266302 <+972%203-926-6302>
>
> Cell:  +972-549266302 <+972%2054-926-6302>
>
> Email:   alexander.vainsht...@ecitele.com
>
>
>
> *From:* mpls [mailto:mpls-boun...@ietf.org] *On Behalf Of *Greg Mirsky
> *Sent:* Thursday, November 16, 2017 4:28 AM
> *To:* Xuxiaohu <xuxia...@huawei.com>
> *Cc:* draft-hegde-spring-traffic-accounting-for-sr-paths <
> draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>; spring <
> spring@ietf.org>; Zafar Ali (zali) <z...@cisco.com>; mpls <m...@ietf.org>
> *Subject:* Re: [mpls] [spring] Special purpose labels in
> draft-hegde-spring-traffic-accounting-for-sr-paths
>
>
>
> Dear All,
>
> I cannot imagine that operators will agree to deploy network that lacks
> critical OAM tools to monitor performance and troubleshoot the network.
> True, some will brave the challenge and be the early adopters but even they
> will likely request that the OAM toolbox be sufficient to support their
> operational needs. I see that this work clearly describes the problem and
> why ability to quantify the flow behavior at internal nodes is important
> for efficient network operation. First let's discuss whether the case and
> requirement towards OAM is real and valid. Then we can continue to
> discussion of what measurement method to use.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Thu, Nov 16, 2017 at 10:05 AM, Xuxiaohu <xuxia...@huawei.com> wrote:
>
> Concur. Although it has some values, it's not cost-efficient from my point
> of view. Network simplicity should be the first priority object. Hence we
> would have to make some compromise.
>
> Best regards,
> Xiaohu
>
>
>
> --
>
> 徐小虎 Xuxiaohu
> M：+86-13910161692
> E：xuxia...@huawei.com
> 产品与解决方案-网络战略与业务发展部
> Products & Solutions-Network Strategy & Business Development Dept
>
> *发件人：* Zafar Ali (zali)
>
> *收件人：* Greg Mirsky<gregimir...@gmail.com>;draft-hegde-spring-traffic-acc
> ounting-for-sr-paths for-sr-pa...@ietf.org>;mpls<m...@ietf.org>;spring<spring@ietf.org>
>
> *主**题：* Re: [mpls] [spring] Special purpose labels in
> draft-hegde-spring-traffic-accounting-for-sr-paths
>
> *时间：* 2017-11-16 02:24:10
>
>
>
> Hi,
>
>
>
> This draft breaks the SR architecture. I am quoting a snippet from
> abstract of SR Architecture document https://tools.ietf.org/html/dr
> aft-ietf-spring-segment-routing-13, which

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

2017-11-16 Thread Ruediger.Geib

Sasha,

the purpose of the SR OAM Use Case is to illustrate how Segment Routing enables 
new ways to perform OAM tasks. Like delay measurements.

What is discussed here are new OAM requirements caused by SR. To me, these are 
part of an own or a different draft. The scope of the SR OAM Use Case never was 
intended to cover them.

Regards,

Ruediger

Von: Alexander Vainshtein [mailto:alexander.vainsht...@ecitele.com]
Gesendet: Donnerstag, 16. November 2017 09:12
An: Greg Mirsky <gregimir...@gmail.com>
Cc: draft-hegde-spring-traffic-accounting-for-sr-paths 
<draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>; spring 
<spring@ietf.org>; Zafar Ali (zali) <z...@cisco.com>; mpls <m...@ietf.org>; 
Xuxiaohu <xuxia...@huawei.com>; Michael Gorokhovsky 
<michael.gorokhov...@ecitele.com>; draft-ietf-spring-oam-usec...@ietf.org
Betreff: RE: [mpls] [spring] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

Greg,
I concur with your position: let’s first  of all agree that ability to measure 
traffic carried by an SR-TE LSP in a specific transit node is a require OAM 
function for SR.

I have looked up the SR OAM Use 
Cases<https://datatracker.ietf.org/doc/draft-ietf-spring-oam-usecase/?include_text=1>
 draft, and I did not find any relevant use cases there.
The only time measurements are mentioned is a reference to an expired 
implementation 
report<https://tools.ietf.org/html/draft-leipnitz-spring-pms-implementation-report-00>
 draft discussing delay measurements.  Since delay measurements are in any case 
based on synthetic traffic, and are always end-to-end (one-way or two-way), 
this reference is not relevant, IMHO, for this discussion.

I have added the authors of the SR OAM Use Cases draft to tis thread.

Regards,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   
alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com>

From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of Greg Mirsky
Sent: Thursday, November 16, 2017 4:28 AM
To: Xuxiaohu <xuxia...@huawei.com<mailto:xuxia...@huawei.com>>
Cc: draft-hegde-spring-traffic-accounting-for-sr-paths 
<draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org<mailto:draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>>;
 spring <spring@ietf.org<mailto:spring@ietf.org>>; Zafar Ali (zali) 
<z...@cisco.com<mailto:z...@cisco.com>>; mpls 
<m...@ietf.org<mailto:m...@ietf.org>>
Subject: Re: [mpls] [spring] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

Dear All,
I cannot imagine that operators will agree to deploy network that lacks 
critical OAM tools to monitor performance and troubleshoot the network. True, 
some will brave the challenge and be the early adopters but even they will 
likely request that the OAM toolbox be sufficient to support their operational 
needs. I see that this work clearly describes the problem and why ability to 
quantify the flow behavior at internal nodes is important for efficient network 
operation. First let's discuss whether the case and requirement towards OAM is 
real and valid. Then we can continue to discussion of what measurement method 
to use.

Regards,
Greg

On Thu, Nov 16, 2017 at 10:05 AM, Xuxiaohu 
<xuxia...@huawei.com<mailto:xuxia...@huawei.com>> wrote:
Concur. Although it has some values, it's not cost-efficient from my point of 
view. Network simplicity should be the first priority object. Hence we would 
have to make some compromise.

Best regards,
Xiaohu



徐小虎 Xuxiaohu
M：+86-13910161692<tel:+86-13910161692>
E：xuxia...@huawei.com<mailto:xuxia...@huawei.com>
产品与解决方案-网络战略与业务发展部
Products & Solutions-Network Strategy & Business Development Dept
发件人： Zafar Ali (zali)
收件人： Greg 
Mirsky<gregimir...@gmail.com<mailto:gregimir...@gmail.com>>;draft-hegde-spring-traffic-accounting-for-sr-paths<draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org<mailto:draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>>;mpls<m...@ietf.org<mailto:m...@ietf.org>>;spring<spring@ietf.org<mailto:spring@ietf.org>>
主题： Re: [mpls] [spring] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths
时间： 2017-11-16 02:24:10

Hi,

This draft breaks the SR architecture. I am quoting a snippet from abstract of 
SR Architecture document 
https://tools.ietf.org/html/draft-ietf-spring-segment-routing-13, which states:
“SR allows to enforce a flow through any topological path while maintaining 
per-flow state only at the ingress nodes to the SR domain.”

In addition to creating states at transit and egress nodes, the procedure also 
affects the data plane and makes it unscalable. It also makes controller job 
much harder and error prune. In summary, I find the procedure very complex and 
unsca

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

2017-11-16 Thread Greg Mirsky

Hi Sasha,
many thanks.
I'd point to SR OAM Requirements
<https://tools.ietf.org/html/draft-ietf-spring-sr-oam-requirement-03>
(regrettably expired):

   REQ#13:  SR OAM MUST have the ability to measure Packet loss, Packet
Delay or Delay variation using Active (using synthetic
probe) and Passive (using data stream) mode.


I think that our discussion indicates that OAM requirements document
is useful at least for as long as we're developing OAM toolset. And
the document will benefit from clarification to reflect our discussion
that PM may be performed both e2e and over SPME.


Regards,

Greg


On Thu, Nov 16, 2017 at 4:11 PM, Alexander Vainshtein <
alexander.vainsht...@ecitele.com> wrote:

> Greg,
>
> I concur with your position: let’s first  of all agree that ability to
> measure traffic carried by an SR-TE LSP in a specific transit node is a
> require OAM function for SR.
>
>
>
> I have looked up the SR OAM Use Cases
> <https://datatracker.ietf.org/doc/draft-ietf-spring-oam-usecase/?include_text=1>
> draft, and I did not find any relevant use cases there.
>
> The only time measurements are mentioned is a reference to an expired
> implementation report
> <https://tools.ietf.org/html/draft-leipnitz-spring-pms-implementation-report-00>
> draft discussing delay measurements.  Since delay measurements are in any
> case based on synthetic traffic, and are always end-to-end (one-way or
> two-way), this reference is not relevant, IMHO, for this discussion.
>
>
>
> I have added the authors of the SR OAM Use Cases draft to tis thread.
>
>
>
> Regards,
>
> Sasha
>
>
>
> Office: +972-39266302 <+972%203-926-6302>
>
> Cell:  +972-549266302 <+972%2054-926-6302>
>
> Email:   alexander.vainsht...@ecitele.com
>
>
>
> *From:* mpls [mailto:mpls-boun...@ietf.org] *On Behalf Of *Greg Mirsky
> *Sent:* Thursday, November 16, 2017 4:28 AM
> *To:* Xuxiaohu <xuxia...@huawei.com>
> *Cc:* draft-hegde-spring-traffic-accounting-for-sr-paths <
> draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>; spring <
> spring@ietf.org>; Zafar Ali (zali) <z...@cisco.com>; mpls <m...@ietf.org>
> *Subject:* Re: [mpls] [spring] Special purpose labels in
> draft-hegde-spring-traffic-accounting-for-sr-paths
>
>
>
> Dear All,
>
> I cannot imagine that operators will agree to deploy network that lacks
> critical OAM tools to monitor performance and troubleshoot the network.
> True, some will brave the challenge and be the early adopters but even they
> will likely request that the OAM toolbox be sufficient to support their
> operational needs. I see that this work clearly describes the problem and
> why ability to quantify the flow behavior at internal nodes is important
> for efficient network operation. First let's discuss whether the case and
> requirement towards OAM is real and valid. Then we can continue to
> discussion of what measurement method to use.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Thu, Nov 16, 2017 at 10:05 AM, Xuxiaohu <xuxia...@huawei.com> wrote:
>
> Concur. Although it has some values, it's not cost-efficient from my point
> of view. Network simplicity should be the first priority object. Hence we
> would have to make some compromise.
>
> Best regards,
> Xiaohu
>
>
>
> --
>
> 徐小虎 Xuxiaohu
> M：+86-13910161692
> E：xuxia...@huawei.com
> 产品与解决方案-网络战略与业务发展部
> Products & Solutions-Network Strategy & Business Development Dept
>
> *发件人：* Zafar Ali (zali)
>
> *收件人：* Greg Mirsky<gregimir...@gmail.com>;draft-hegde-spring-traffic-
> accounting-for-sr-paths accounting-for-sr-pa...@ietf.org>;mpls<m...@ietf.org>;spring<
> spring@ietf.org>
>
> *主**题：* Re: [mpls] [spring] Special purpose labels in
> draft-hegde-spring-traffic-accounting-for-sr-paths
>
> *时间：* 2017-11-16 02:24:10
>
>
>
> Hi,
>
>
>
> This draft breaks the SR architecture. I am quoting a snippet from
> abstract of SR Architecture document https://tools.ietf.org/html/
> draft-ietf-spring-segment-routing-13, which states:
>
> “SR allows to enforce a flow through any topological path while
> maintaining per-flow state only at the ingress nodes to the SR domain.”
>
>
>
> In addition to creating states at transit and egress nodes, the procedure
> also affects the data plane and makes it unscalable. It also makes
> controller job much harder and error prune. In summary, I find the
> procedure very complex and unscalable.
>
>
>
> Thanks
>
>
>
> Regards … Zafar
>
>
>
>
>
> *From: *spring <spring-boun...@ietf.org> on behalf of Greg M

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

2017-11-16 Thread Alexander Vainshtein

Robert,
For the reference,  
draft-hegde-spring-traffic-accounting-for-sr-paths<https://tools.ietf.org/html/draft-hegde-spring-traffic-accounting-for-sr-paths-00>
 explicitly mentions per LSP measurements in transit nodes in Section 11 
“Scalability Considerations”.

Regards,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   alexander.vainsht...@ecitele.com

From: rras...@gmail.com [mailto:rras...@gmail.com] On Behalf Of Robert Raszuk
Sent: Thursday, November 16, 2017 10:23 AM
To: Alexander Vainshtein <alexander.vainsht...@ecitele.com>
Cc: Greg Mirsky <gregimir...@gmail.com>; 
draft-hegde-spring-traffic-accounting-for-sr-paths 
<draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>; spring 
<spring@ietf.org>; mpls <m...@ietf.org>; Michael Gorokhovsky 
<michael.gorokhov...@ecitele.com>; draft-ietf-spring-oam-usec...@ietf.org; 
Zafar Ali (zali) <z...@cisco.com>; Clarence Filsfils <cfils...@cisco.com>
Subject: Re: [mpls] [spring] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

Folks,

This thread started and the requirements reported clearly stated that all what 
we need is the ability to account per path traffic on egress nodes.

Now out of the sudden I see requirement popping up to be able to measure per 
path in transit nodes.

Well you can do it today with SRv6 if your hardware allows or you can do it 
with RSVP-TE.

SR-MPLS is replacing LDP and adds ability for limited TE. But SR-MPLS never 
intended to become connection oriented protocol nor architecture.

So I recommend we take a step back here. Or if you like first go and fix basic 
MPLS LDP LSPs to allow per end to end path accounting in transit nodes then 
come back here to ask for the same in SR-MPLS. Not the other way around.

Thx
r.


On Nov 16, 2017 16:12, "Alexander Vainshtein" 
<alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com>> 
wrote:
Greg,
I concur with your position: let’s first  of all agree that ability to measure 
traffic carried by an SR-TE LSP in a specific transit node is a require OAM 
function for SR.

I have looked up the SR OAM Use 
Cases<https://datatracker.ietf.org/doc/draft-ietf-spring-oam-usecase/?include_text=1>
 draft, and I did not find any relevant use cases there.
The only time measurements are mentioned is a reference to an expired 
implementation 
report<https://tools.ietf.org/html/draft-leipnitz-spring-pms-implementation-report-00>
 draft discussing delay measurements.  Since delay measurements are in any case 
based on synthetic traffic, and are always end-to-end (one-way or two-way), 
this reference is not relevant, IMHO, for this discussion.

I have added the authors of the SR OAM Use Cases draft to tis thread.

Regards,
Sasha

Office: +972-39266302<tel:+972%203-926-6302>
Cell:  +972-549266302<tel:+972%2054-926-6302>
Email:   
alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com>

From: mpls [mailto:mpls-boun...@ietf.org<mailto:mpls-boun...@ietf.org>] On 
Behalf Of Greg Mirsky
Sent: Thursday, November 16, 2017 4:28 AM
To: Xuxiaohu <xuxia...@huawei.com<mailto:xuxia...@huawei.com>>
Cc: draft-hegde-spring-traffic-accounting-for-sr-paths 
<draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org<mailto:draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>>;
 spring <spring@ietf.org<mailto:spring@ietf.org>>; Zafar Ali (zali) 
<z...@cisco.com<mailto:z...@cisco.com>>; mpls 
<m...@ietf.org<mailto:m...@ietf.org>>
Subject: Re: [mpls] [spring] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

Dear All,
I cannot imagine that operators will agree to deploy network that lacks 
critical OAM tools to monitor performance and troubleshoot the network. True, 
some will brave the challenge and be the early adopters but even they will 
likely request that the OAM toolbox be sufficient to support their operational 
needs. I see that this work clearly describes the problem and why ability to 
quantify the flow behavior at internal nodes is important for efficient network 
operation. First let's discuss whether the case and requirement towards OAM is 
real and valid. Then we can continue to discussion of what measurement method 
to use.

Regards,
Greg

On Thu, Nov 16, 2017 at 10:05 AM, Xuxiaohu 
<xuxia...@huawei.com<mailto:xuxia...@huawei.com>> wrote:
Concur. Although it has some values, it's not cost-efficient from my point of 
view. Network simplicity should be the first priority object. Hence we would 
have to make some compromise.

Best regards,
Xiaohu



徐小虎 Xuxiaohu
M：+86-13910161692<tel:+86-13910161692>
E：xuxia...@huawei.com<mailto:xuxia...@huawei.com>
产品与解决方案-网络战略与业务发展部
Products & Solutions-Network Strategy & Business Development Dept
发件人： Zafar Ali (zali)
收件人

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

2017-11-16 Thread Greg Mirsky

Hi Zafar, et.al,
as I'm the one who have started the thread I'd like to clarify and
reiterate my point Performance measurements are required not only e2e but
on a span, i.e. SPME, using MPLS-TO lingo. If we agree on that, then we are
ready to discuss how to support these measurements in SR-MPLS.

Regards, Greg

On Nov 16, 2017 4:25 PM, "Zafar Ali (zali)" <z...@cisco.com> wrote:

> Hi Folks,
>
>
>
> I also agree that it’s not a question on requirement but about a procedure
> (in draft-hegde-spring-traffic-accounting-for-sr-paths) that breaks SR
> Architecture, highly unscalable and complicated to implement. We can solve
> this problem without breaking the SR architecture. We plan to write a draft
> before the next IETF.
>
>
>
> Thanks
>
>
>
> Regards … Zafar
>
>
>
>
>
> *From: *Xuxiaohu <xuxia...@huawei.com>
> *Date: *Wednesday, November 15, 2017 at 9:54 PM
> *To: *Greg Mirsky <gregimir...@gmail.com>
> *Cc: *"Zafar Ali (zali)" <z...@cisco.com>, 
> draft-hegde-spring-traffic-accounting-for-sr-paths
> <draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>, "
> m...@ietf.org" <m...@ietf.org>, spring <spring@ietf.org>
> *Subject: *RE: [mpls] [spring] Special purpose labels in
> draft-hegde-spring-traffic-accounting-for-sr-paths
>
>
>
> I fully agree with you that OAM tools are important.
>
> I just felt that the approach as proposed in the draft would enconter the
> same terrible issues as those associated with the MPLS-SR entropy label
> usage due to RLD and MSD hardware limitations.
>
> Best regards,
> Xiaohu
>
>
>
> --
>
> 徐小虎 Xuxiaohu
> M：+86-13910161692
> E：xuxia...@huawei.com
> 产品与解决方案-网络战略与业务发展部
> Products & Solutions-Network Strategy & Business Development Dept
>
> *发件人：* Greg Mirsky
>
> *收件人：* Xuxiaohu<xuxia...@huawei.com>
>
> *抄送：* Zafar Ali (zali)<z...@cisco.com>;draft-hegde-spring-traffic-
> accounting-for-sr-paths accounting-for-sr-pa...@ietf.org>;mpls<m...@ietf.org>;spring<
> spring@ietf.org>
>
> *主**题**：* Re: [mpls] [spring] Special purpose labels in
> draft-hegde-spring-traffic-accounting-for-sr-paths
>
> *时间：* 2017-11-16 10:27:55
>
>
>
> Dear All,
>
> I cannot imagine that operators will agree to deploy network that lacks
> critical OAM tools to monitor performance and troubleshoot the network.
> True, some will brave the challenge and be the early adopters but even they
> will likely request that the OAM toolbox be sufficient to support their
> operational needs. I see that this work clearly describes the problem and
> why ability to quantify the flow behavior at internal nodes is important
> for efficient network operation. First let's discuss whether the case and
> requirement towards OAM is real and valid. Then we can continue to
> discussion of what measurement method to use.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Thu, Nov 16, 2017 at 10:05 AM, Xuxiaohu <xuxia...@huawei.com> wrote:
>
> Concur. Although it has some values, it's not cost-efficient from my point
> of view. Network simplicity should be the first priority object. Hence we
> would have to make some compromise.
>
> Best regards,
> Xiaohu
>
>
>
> ------------------
>
> 徐小虎 Xuxiaohu
> M：+86-13910161692
> E：xuxia...@huawei.com
> 产品与解决方案-网络战略与业务发展部
> Products & Solutions-Network Strategy & Business Development Dept
>
> *发件人：* Zafar Ali (zali)
>
> *收件人：* Greg Mirsky<gregimir...@gmail.com>;draft-hegde-spring-traffic-
> accounting-for-sr-paths accounting-for-sr-pa...@ietf.org>;mpls<m...@ietf.org>;spring<
> spring@ietf.org>
>
> *主**题**：* Re: [mpls] [spring] Special purpose labels in
> draft-hegde-spring-traffic-accounting-for-sr-paths
>
> *时间：* 2017-11-16 02:24:10
>
>
>
> Hi,
>
>
>
> This draft breaks the SR architecture. I am quoting a snippet from
> abstract of SR Architecture document https://tools.ietf.org/html/
> draft-ietf-spring-segment-routing-13, which states:
>
> “SR allows to enforce a flow through any topological path while
> maintaining per-flow state only at the ingress nodes to the SR domain.”
>
>
>
> In addition to creating states at transit and egress nodes, the procedure
> also affects the data plane and makes it unscalable. It also makes
> controller job much harder and error prune. In summary, I find the
> procedure very complex and unscalable.
>
>
>
> Thanks
>
>
>
> Regards … Zafar
>
>
>
>
>
> *From: *spring <spring-boun...@ietf.org> on behalf of Greg Mirsky <
> gregimir...

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

2017-11-16 Thread Zafar Ali (zali)

Hi Folks,

I also agree that it’s not a question on requirement but about a procedure (in 
draft-hegde-spring-traffic-accounting-for-sr-paths) that breaks SR 
Architecture, highly unscalable and complicated to implement. We can solve this 
problem without breaking the SR architecture. We plan to write a draft before 
the next IETF.

Thanks

Regards … Zafar


From: Xuxiaohu <xuxia...@huawei.com>
Date: Wednesday, November 15, 2017 at 9:54 PM
To: Greg Mirsky <gregimir...@gmail.com>
Cc: "Zafar Ali (zali)" <z...@cisco.com>, 
draft-hegde-spring-traffic-accounting-for-sr-paths 
<draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>, "m...@ietf.org" 
<m...@ietf.org>, spring <spring@ietf.org>
Subject: RE: [mpls] [spring] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

I fully agree with you that OAM tools are important.

I just felt that the approach as proposed in the draft would enconter the same 
terrible issues as those associated with the MPLS-SR entropy label usage due to 
RLD and MSD hardware limitations.

Best regards,
Xiaohu




徐小虎 Xuxiaohu
M：+86-13910161692<tel:+86-13910161692>
E：xuxia...@huawei.com<mailto:xuxia...@huawei.com>
产品与解决方案-网络战略与业务发展部
Products & Solutions-Network Strategy & Business Development Dept
发件人： Greg Mirsky
收件人： Xuxiaohu<xuxia...@huawei.com<mailto:xuxia...@huawei.com>>
抄送： Zafar Ali 
(zali)<z...@cisco.com<mailto:z...@cisco.com>>;draft-hegde-spring-traffic-accounting-for-sr-paths<draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org<mailto:draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>>;mpls<m...@ietf.org<mailto:m...@ietf.org>>;spring<spring@ietf.org<mailto:spring@ietf.org>>
主题： Re: [mpls] [spring] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths
时间： 2017-11-16 10:27:55

Dear All,
I cannot imagine that operators will agree to deploy network that lacks 
critical OAM tools to monitor performance and troubleshoot the network. True, 
some will brave the challenge and be the early adopters but even they will 
likely request that the OAM toolbox be sufficient to support their operational 
needs. I see that this work clearly describes the problem and why ability to 
quantify the flow behavior at internal nodes is important for efficient network 
operation. First let's discuss whether the case and requirement towards OAM is 
real and valid. Then we can continue to discussion of what measurement method 
to use.

Regards,
Greg

On Thu, Nov 16, 2017 at 10:05 AM, Xuxiaohu 
<xuxia...@huawei.com<mailto:xuxia...@huawei.com>> wrote:
Concur. Although it has some values, it's not cost-efficient from my point of 
view. Network simplicity should be the first priority object. Hence we would 
have to make some compromise.

Best regards,
Xiaohu




徐小虎 Xuxiaohu
M：+86-13910161692<tel:+86-13910161692>
E：xuxia...@huawei.com<mailto:xuxia...@huawei.com>
产品与解决方案-网络战略与业务发展部
Products & Solutions-Network Strategy & Business Development Dept
发件人： Zafar Ali (zali)
收件人： Greg 
Mirsky<gregimir...@gmail.com<mailto:gregimir...@gmail.com>>;draft-hegde-spring-traffic-accounting-for-sr-paths<draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org<mailto:draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>>;mpls<m...@ietf.org<mailto:m...@ietf.org>>;spring<spring@ietf.org<mailto:spring@ietf.org>>
主题： Re: [mpls] [spring] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths
时间： 2017-11-16 02:24:10

Hi,

This draft breaks the SR architecture. I am quoting a snippet from abstract of 
SR Architecture document 
https://tools.ietf.org/html/draft-ietf-spring-segment-routing-13, which states:
“SR allows to enforce a flow through any topological path while maintaining 
per-flow state only at the ingress nodes to the SR domain.”

In addition to creating states at transit and egress nodes, the procedure also 
affects the data plane and makes it unscalable. It also makes controller job 
much harder and error prune. In summary, I find the procedure very complex and 
unscalable.

Thanks

Regards … Zafar


From: spring <spring-boun...@ietf.org<mailto:spring-boun...@ietf.org>> on 
behalf of Greg Mirsky <gregimir...@gmail.com<mailto:gregimir...@gmail.com>>
Date: Wednesday, November 15, 2017 at 11:10 AM
To: 
"draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org<mailto:draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>"
 
<draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org<mailto:draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>>,
 "m...@ietf.org<mailto:m...@ietf.org>" <m...@ietf.org<mailto:m...@ietf.org>>, 
"spring@ietf.org<m

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

2017-11-16 Thread Robert Raszuk

Folks,

This thread started and the requirements reported clearly stated that all
what we need is the ability to account per path traffic on egress nodes.

Now out of the sudden I see requirement popping up to be able to measure
per path in transit nodes.

Well you can do it today with SRv6 if your hardware allows or you can do it
with RSVP-TE.

SR-MPLS is replacing LDP and adds ability for limited TE. But SR-MPLS never
intended to become connection oriented protocol nor architecture.

So I recommend we take a step back here. Or if you like first go and fix
basic MPLS LDP LSPs to allow per end to end path accounting in transit
nodes then come back here to ask for the same in SR-MPLS. Not the other way
around.

Thx
r.


On Nov 16, 2017 16:12, "Alexander Vainshtein" <
alexander.vainsht...@ecitele.com> wrote:

Greg,

I concur with your position: let’s first  of all agree that ability to
measure traffic carried by an SR-TE LSP in a specific transit node is a
require OAM function for SR.



I have looked up the SR OAM Use Cases
<https://datatracker.ietf.org/doc/draft-ietf-spring-oam-usecase/?include_text=1>
draft, and I did not find any relevant use cases there.

The only time measurements are mentioned is a reference to an expired
implementation report
<https://tools.ietf.org/html/draft-leipnitz-spring-pms-implementation-report-00>
draft discussing delay measurements.  Since delay measurements are in any
case based on synthetic traffic, and are always end-to-end (one-way or
two-way), this reference is not relevant, IMHO, for this discussion.



I have added the authors of the SR OAM Use Cases draft to tis thread.



Regards,

Sasha



Office: +972-39266302 <+972%203-926-6302>

Cell:  +972-549266302 <+972%2054-926-6302>

Email:   alexander.vainsht...@ecitele.com



*From:* mpls [mailto:mpls-boun...@ietf.org] *On Behalf Of *Greg Mirsky
*Sent:* Thursday, November 16, 2017 4:28 AM
*To:* Xuxiaohu <xuxia...@huawei.com>
*Cc:* draft-hegde-spring-traffic-accounting-for-sr-paths <
draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>; spring <
spring@ietf.org>; Zafar Ali (zali) <z...@cisco.com>; mpls <m...@ietf.org>
*Subject:* Re: [mpls] [spring] Special purpose labels in
draft-hegde-spring-traffic-accounting-for-sr-paths



Dear All,

I cannot imagine that operators will agree to deploy network that lacks
critical OAM tools to monitor performance and troubleshoot the network.
True, some will brave the challenge and be the early adopters but even they
will likely request that the OAM toolbox be sufficient to support their
operational needs. I see that this work clearly describes the problem and
why ability to quantify the flow behavior at internal nodes is important
for efficient network operation. First let's discuss whether the case and
requirement towards OAM is real and valid. Then we can continue to
discussion of what measurement method to use.



Regards,

Greg



On Thu, Nov 16, 2017 at 10:05 AM, Xuxiaohu <xuxia...@huawei.com> wrote:

Concur. Although it has some values, it's not cost-efficient from my point
of view. Network simplicity should be the first priority object. Hence we
would have to make some compromise.

Best regards,
Xiaohu



--

徐小虎 Xuxiaohu
M：+86-13910161692
E：xuxia...@huawei.com
产品与解决方案-网络战略与业务发展部
Products & Solutions-Network Strategy & Business Development Dept

*发件人：* Zafar Ali (zali)

*收件人：* Greg Mirsky<gregimir...@gmail.com>;draft-hegde-spring-traffic-
accounting-for-sr-paths;mpls<m...@ietf.org>;spring<spring@ietf.org
>

*主**题：* Re: [mpls] [spring] Special purpose labels in
draft-hegde-spring-traffic-accounting-for-sr-paths

*时间：* 2017-11-16 02:24:10



Hi,



This draft breaks the SR architecture. I am quoting a snippet from abstract
of SR Architecture document https://tools.ietf.org/html/
draft-ietf-spring-segment-routing-13, which states:

“SR allows to enforce a flow through any topological path while maintaining
per-flow state only at the ingress nodes to the SR domain.”



In addition to creating states at transit and egress nodes, the procedure
also affects the data plane and makes it unscalable. It also makes
controller job much harder and error prune. In summary, I find the
procedure very complex and unscalable.



Thanks



Regards … Zafar





*From: *spring <spring-boun...@ietf.org> on behalf of Greg Mirsky <
gregimir...@gmail.com>
*Date: *Wednesday, November 15, 2017 at 11:10 AM
*To: *"draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org" <
draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>, "m...@ietf.org"
<m...@ietf.org>, "spring@ietf.org" <spring@ietf.org>
*Subject: *[spring] Special purpose labels in draft-hegde-spring-traffic-
accounting-for-sr-paths



Hi Shraddha,

thank you for very well written and thought through draft. I have these
questions I'd lik

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

2017-11-16 Thread Alexander Vainshtein

Greg,
I concur with your position: let’s first  of all agree that ability to measure 
traffic carried by an SR-TE LSP in a specific transit node is a require OAM 
function for SR.

I have looked up the SR OAM Use 
Cases<https://datatracker.ietf.org/doc/draft-ietf-spring-oam-usecase/?include_text=1>
 draft, and I did not find any relevant use cases there.
The only time measurements are mentioned is a reference to an expired 
implementation 
report<https://tools.ietf.org/html/draft-leipnitz-spring-pms-implementation-report-00>
 draft discussing delay measurements.  Since delay measurements are in any case 
based on synthetic traffic, and are always end-to-end (one-way or two-way), 
this reference is not relevant, IMHO, for this discussion.

I have added the authors of the SR OAM Use Cases draft to tis thread.

Regards,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   alexander.vainsht...@ecitele.com

From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of Greg Mirsky
Sent: Thursday, November 16, 2017 4:28 AM
To: Xuxiaohu <xuxia...@huawei.com>
Cc: draft-hegde-spring-traffic-accounting-for-sr-paths 
<draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>; spring 
<spring@ietf.org>; Zafar Ali (zali) <z...@cisco.com>; mpls <m...@ietf.org>
Subject: Re: [mpls] [spring] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

Dear All,
I cannot imagine that operators will agree to deploy network that lacks 
critical OAM tools to monitor performance and troubleshoot the network. True, 
some will brave the challenge and be the early adopters but even they will 
likely request that the OAM toolbox be sufficient to support their operational 
needs. I see that this work clearly describes the problem and why ability to 
quantify the flow behavior at internal nodes is important for efficient network 
operation. First let's discuss whether the case and requirement towards OAM is 
real and valid. Then we can continue to discussion of what measurement method 
to use.

Regards,
Greg

On Thu, Nov 16, 2017 at 10:05 AM, Xuxiaohu 
<xuxia...@huawei.com<mailto:xuxia...@huawei.com>> wrote:
Concur. Although it has some values, it's not cost-efficient from my point of 
view. Network simplicity should be the first priority object. Hence we would 
have to make some compromise.

Best regards,
Xiaohu




徐小虎 Xuxiaohu
M：+86-13910161692<tel:+86-13910161692>
E：xuxia...@huawei.com<mailto:xuxia...@huawei.com>
产品与解决方案-网络战略与业务发展部
Products & Solutions-Network Strategy & Business Development Dept
发件人： Zafar Ali (zali)
收件人： Greg 
Mirsky<gregimir...@gmail.com<mailto:gregimir...@gmail.com>>;draft-hegde-spring-traffic-accounting-for-sr-paths<draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org<mailto:draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>>;mpls<m...@ietf.org<mailto:m...@ietf.org>>;spring<spring@ietf.org<mailto:spring@ietf.org>>
主题： Re: [mpls] [spring] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths
时间： 2017-11-16 02:24:10

Hi,

This draft breaks the SR architecture. I am quoting a snippet from abstract of 
SR Architecture document 
https://tools.ietf.org/html/draft-ietf-spring-segment-routing-13, which states:
“SR allows to enforce a flow through any topological path while maintaining 
per-flow state only at the ingress nodes to the SR domain.”

In addition to creating states at transit and egress nodes, the procedure also 
affects the data plane and makes it unscalable. It also makes controller job 
much harder and error prune. In summary, I find the procedure very complex and 
unscalable.

Thanks

Regards … Zafar


From: spring <spring-boun...@ietf.org<mailto:spring-boun...@ietf.org>> on 
behalf of Greg Mirsky <gregimir...@gmail.com<mailto:gregimir...@gmail.com>>
Date: Wednesday, November 15, 2017 at 11:10 AM
To: 
"draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org<mailto:draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>"
 
<draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org<mailto:draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>>,
 "m...@ietf.org<mailto:m...@ietf.org>" <m...@ietf.org<mailto:m...@ietf.org>>, 
"spring@ietf.org<mailto:spring@ietf.org>" 
<spring@ietf.org<mailto:spring@ietf.org>>
Subject: [spring] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

Hi Shraddha,
thank you for very well written and thought through draft. I have these 
questions I'd like to discuss:

  *   Have you thought of using not one special purpose label for both SR Path 
Identifier and SR Path Identifier+Source SID cases but request two special 
purpose labels, one for each case. Then the SR Path Identifier would not have 
to lose the bit fo

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

2017-11-15 Thread Robert Raszuk

Well I still do not think we need anything new on the wire for this but
apparently half folks here do not get it ;)

So for those who need it we can just insert 8 octets of vxlan between label
stack and packet and use vnid as path id.

thx
r.

On Nov 16, 2017 14:46, "Xuxiaohu" <xuxia...@huawei.com> wrote:

> Just an idea occurring in my mind: Maybe it's worthwhile to consider how
> to address this business demand by using the unified SR approach (
> https://datatracker.ietf.org/meeting/100/materials/slides-
> 100-mpls-04-draft-xu-mpls-unified-source-routing-instruction-ietf100/).
> More specifically, use the source port of the UDP tunnel header to carry
> the path identity, just like the idea of using the unified SR approach to
> address the load-balancing issue associated with the MPLS-SR.
>
>
>
>
> --
> 徐小虎 Xuxiaohu
> M：+86-13910161692
> E：xuxia...@huawei.com
> 产品与解决方案-网络战略与业务发展部
> Products & Solutions-Network Strategy & Business Development Dept
>
> *发件人： *Xuxiaohu
> *收件人： *Jeff Tantsura<jefftant.i...@gmail.com>;Robert Raszuk<
> rob...@raszuk.net>
> *抄送： *draft-hegde-spring-traffic-accounting-for-sr-paths hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>;spring<
> spring@ietf.org>;mpls<m...@ietf.org>;Zafar Ali (zali)<z...@cisco.com>;Greg
> Mirsky<gregimir...@gmail.com>
> *主题： *Re: [spring] [mpls] Special purpose labels in
> draft-hegde-spring-traffic-accounting-for-sr-paths
> *时间： *2017-11-16 14:25:32
>
>
> s/per flow/per path.
>
>
>
> --
> 徐小虎 Xuxiaohu
> M：+86-13910161692
> E：xuxia...@huawei.com
> 产品与解决方案-网络战略与业务发展部
> Products & Solutions-Network Strategy & Business Development Dept
>
> *发件人： *Xuxiaohu
> *收件人： *Jeff Tantsura<jefftant.i...@gmail.com>;Robert Raszuk<
> rob...@raszuk.net>
> *抄送： *draft-hegde-spring-traffic-accounting-for-sr-paths hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>;Greg Mirsky<
> gregimir...@gmail.com>;spring<spring@ietf.org>;Zafar Ali (zali)<
> z...@cisco.com>;mpls<m...@ietf.org>
> *主题： *Re: [spring] [mpls] Special purpose labels in
> draft-hegde-spring-traffic-accounting-for-sr-paths
> *时间： *2017-11-16 11:21:46
>
>
> If so, why not directly use RSVP-TE if the per flow state is needed?
>
>
>
> --
> 徐小虎 Xuxiaohu
> M：+86-13910161692
> E：xuxia...@huawei.com
> 产品与解决方案-网络战略与业务发展部
> Products & Solutions-Network Strategy & Business Development Dept
>
> *发件人： *Jeff Tantsura
> *收件人： *Robert Raszuk<rob...@raszuk.net>
> *抄送： *Xuxiaohu<xuxia...@huawei.com>;Greg Mirsky<gregimir...@gmail.com>;
> spring<spring@ietf.org>;mpls<m...@ietf.org>;Zafar Ali (zali)<
> z...@cisco.com>;draft-hegde-spring-traffic-accounting-for-sr-paths hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>
> *主题： *Re: [spring] [mpls] Special purpose labels in
> draft-hegde-spring-traffic-accounting-for-sr-paths
> *时间： *2017-11-16 11:09:13
>
> Today, if you run RSVP-TE, you’d get (at least on high end platforms)
> counters per LSP.
>
> Having the same functionality with SR seems rather logical.
>
>
>
> Cheers,
>
> Jeff
>
>
>
> *From: *<rras...@gmail.com> on behalf of Robert Raszuk <rob...@raszuk.net>
> *Date: *Thursday, November 16, 2017 at 10:50
> *To: *Jeff Tantsura <jefftant.i...@gmail.com>
> *Cc: *Xuxiaohu <xuxia...@huawei.com>, Greg Mirsky <gregimir...@gmail.com>,
> spring <spring@ietf.org>, mpls <m...@ietf.org>, "Zafar Ali (zali)" <
> z...@cisco.com>, draft-hegde-spring-traffic-accounting-for-sr-paths <
> draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>
> *Subject: *Re: [spring] [mpls] Special purpose labels in
> draft-hegde-spring-traffic-accounting-for-sr-paths
>
>
>
> As explained it is not needed to get all information required per path.
>
>
>
> Yes you may have N:1 mapping of flows to path so what is the problem ?
>
>
>
> thx
>
> r.
>
>
>
> On Nov 16, 2017 10:47, "Jeff Tantsura" <jefftant.i...@gmail.com> wrote:
>
> Robert,
>
>
>
> HW counters are rather precious resources, but that’s beside the point.
>
> An architecture is not an immutable object, on contrary, a very import
> property of a good architecture is flexibility and agility, ability to
> adapt when business need arises.
>
>
>
> Keeping semantics aside – what’s needed, is a metadata (here encoded as a
> label) that uniquely identifies a path, where FIB lookup would yield an
> “counter hit”, potentially counter creation if the packet is

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

2017-11-15 Thread Xuxiaohu

Just an idea occurring in my mind: Maybe it's worthwhile to consider how to 
address this business demand by using the unified SR approach 
(https://datatracker.ietf.org/meeting/100/materials/slides-100-mpls-04-draft-xu-mpls-unified-source-routing-instruction-ietf100/).
 More specifically, use the source port of the UDP tunnel header to carry the 
path identity, just like the idea of using the unified SR approach to address 
the load-balancing issue associated with the MPLS-SR.





徐小虎 Xuxiaohu
M：+86-13910161692<tel:+86-13910161692>
E：xuxia...@huawei.com<mailto:xuxia...@huawei.com>
产品与解决方案-网络战略与业务发展部
Products & Solutions-Network Strategy & Business Development Dept

发件人： Xuxiaohu
收件人： Jeff 
Tantsura<jefftant.i...@gmail.com<mailto:jefftant.i...@gmail.com>>;Robert 
Raszuk<rob...@raszuk.net<mailto:rob...@raszuk.net>>
抄送： 
draft-hegde-spring-traffic-accounting-for-sr-paths<draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org<mailto:draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>>;spring<spring@ietf.org<mailto:spring@ietf.org>>;mpls<m...@ietf.org<mailto:m...@ietf.org>>;Zafar
 Ali (zali)<z...@cisco.com<mailto:z...@cisco.com>>;Greg 
Mirsky<gregimir...@gmail.com<mailto:gregimir...@gmail.com>>
主题： Re: [spring] [mpls] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths
时间： 2017-11-16 14:25:32


s/per flow/per path.




徐小虎 Xuxiaohu
M：+86-13910161692<tel:+86-13910161692>
E：xuxia...@huawei.com<mailto:xuxia...@huawei.com>
产品与解决方案-网络战略与业务发展部
Products & Solutions-Network Strategy & Business Development Dept

发件人： Xuxiaohu
收件人： Jeff 
Tantsura<jefftant.i...@gmail.com<mailto:jefftant.i...@gmail.com>>;Robert 
Raszuk<rob...@raszuk.net<mailto:rob...@raszuk.net>>
抄送： 
draft-hegde-spring-traffic-accounting-for-sr-paths<draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org<mailto:draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>>;Greg
 
Mirsky<gregimir...@gmail.com<mailto:gregimir...@gmail.com>>;spring<spring@ietf.org<mailto:spring@ietf.org>>;Zafar
 Ali 
(zali)<z...@cisco.com<mailto:z...@cisco.com>>;mpls<m...@ietf.org<mailto:m...@ietf.org>>
主题： Re: [spring] [mpls] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths
时间： 2017-11-16 11:21:46


If so, why not directly use RSVP-TE if the per flow state is needed?




徐小虎 Xuxiaohu
M：+86-13910161692<tel:+86-13910161692>
E：xuxia...@huawei.com<mailto:xuxia...@huawei.com>
产品与解决方案-网络战略与业务发展部
Products & Solutions-Network Strategy & Business Development Dept

发件人： Jeff Tantsura
收件人： Robert Raszuk<rob...@raszuk.net<mailto:rob...@raszuk.net>>
抄送： Xuxiaohu<xuxia...@huawei.com<mailto:xuxia...@huawei.com>>;Greg 
Mirsky<gregimir...@gmail.com<mailto:gregimir...@gmail.com>>;spring<spring@ietf.org<mailto:spring@ietf.org>>;mpls<m...@ietf.org<mailto:m...@ietf.org>>;Zafar
 Ali 
(zali)<z...@cisco.com<mailto:z...@cisco.com>>;draft-hegde-spring-traffic-accounting-for-sr-paths<draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org<mailto:draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>>
主题： Re: [spring] [mpls] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths
时间： 2017-11-16 11:09:13

Today, if you run RSVP-TE, you’d get (at least on high end platforms) counters 
per LSP.
Having the same functionality with SR seems rather logical.

Cheers,
Jeff

From: <rras...@gmail.com> on behalf of Robert Raszuk <rob...@raszuk.net>
Date: Thursday, November 16, 2017 at 10:50
To: Jeff Tantsura <jefftant.i...@gmail.com>
Cc: Xuxiaohu <xuxia...@huawei.com>, Greg Mirsky <gregimir...@gmail.com>, spring 
<spring@ietf.org>, mpls <m...@ietf.org>, "Zafar Ali (zali)" <z...@cisco.com>, 
draft-hegde-spring-traffic-accounting-for-sr-paths 
<draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>
Subject: Re: [spring] [mpls] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

As explained it is not needed to get all information required per path.

Yes you may have N:1 mapping of flows to path so what is the problem ?

thx
r.

On Nov 16, 2017 10:47, "Jeff Tantsura" 
<jefftant.i...@gmail.com<mailto:jefftant.i...@gmail.com>> wrote:
Robert,

HW counters are rather precious resources, but that’s beside the point.
An architecture is not an immutable object, on contrary, a very import property 
of a good architecture is flexibility and agility, ability to adapt when 
business need arises.

Keeping semantics aside �C what’s needed, is a metadata (here encoded as a 
label) that uniquely i

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

2017-11-15 Thread Xuxiaohu


s/per flow/per path.




徐小虎 Xuxiaohu
M：+86-13910161692<tel:+86-13910161692>
E：xuxia...@huawei.com<mailto:xuxia...@huawei.com>
产品与解决方案-网络战略与业务发展部
Products & Solutions-Network Strategy & Business Development Dept

发件人： Xuxiaohu
收件人： Jeff 
Tantsura<jefftant.i...@gmail.com<mailto:jefftant.i...@gmail.com>>;Robert 
Raszuk<rob...@raszuk.net<mailto:rob...@raszuk.net>>
抄送： 
draft-hegde-spring-traffic-accounting-for-sr-paths<draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org<mailto:draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>>;Greg
 
Mirsky<gregimir...@gmail.com<mailto:gregimir...@gmail.com>>;spring<spring@ietf.org<mailto:spring@ietf.org>>;Zafar
 Ali 
(zali)<z...@cisco.com<mailto:z...@cisco.com>>;mpls<m...@ietf.org<mailto:m...@ietf.org>>
主题： Re: [spring] [mpls] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths
时间： 2017-11-16 11:21:46


If so, why not directly use RSVP-TE if the per flow state is needed?




徐小虎 Xuxiaohu
M：+86-13910161692<tel:+86-13910161692>
E：xuxia...@huawei.com<mailto:xuxia...@huawei.com>
产品与解决方案-网络战略与业务发展部
Products & Solutions-Network Strategy & Business Development Dept

发件人： Jeff Tantsura
收件人： Robert Raszuk<rob...@raszuk.net<mailto:rob...@raszuk.net>>
抄送： Xuxiaohu<xuxia...@huawei.com<mailto:xuxia...@huawei.com>>;Greg 
Mirsky<gregimir...@gmail.com<mailto:gregimir...@gmail.com>>;spring<spring@ietf.org<mailto:spring@ietf.org>>;mpls<m...@ietf.org<mailto:m...@ietf.org>>;Zafar
 Ali 
(zali)<z...@cisco.com<mailto:z...@cisco.com>>;draft-hegde-spring-traffic-accounting-for-sr-paths<draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org<mailto:draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>>
主题： Re: [spring] [mpls] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths
时间： 2017-11-16 11:09:13

Today, if you run RSVP-TE, you’d get (at least on high end platforms) counters 
per LSP.
Having the same functionality with SR seems rather logical.

Cheers,
Jeff

From: <rras...@gmail.com> on behalf of Robert Raszuk <rob...@raszuk.net>
Date: Thursday, November 16, 2017 at 10:50
To: Jeff Tantsura <jefftant.i...@gmail.com>
Cc: Xuxiaohu <xuxia...@huawei.com>, Greg Mirsky <gregimir...@gmail.com>, spring 
<spring@ietf.org>, mpls <m...@ietf.org>, "Zafar Ali (zali)" <z...@cisco.com>, 
draft-hegde-spring-traffic-accounting-for-sr-paths 
<draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>
Subject: Re: [spring] [mpls] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

As explained it is not needed to get all information required per path.

Yes you may have N:1 mapping of flows to path so what is the problem ?

thx
r.

On Nov 16, 2017 10:47, "Jeff Tantsura" 
<jefftant.i...@gmail.com<mailto:jefftant.i...@gmail.com>> wrote:
Robert,

HW counters are rather precious resources, but that’s beside the point.
An architecture is not an immutable object, on contrary, a very import property 
of a good architecture is flexibility and agility, ability to adapt when 
business need arises.

Keeping semantics aside �C what’s needed, is a metadata (here encoded as a 
label) that uniquely identifies a path, where FIB lookup would yield an 
“counter hit”, potentially counter creation if the packet is the first packet 
in the flow. Value of the label would be hashed in the counter ID that is 
unique and could be resolved by a management layer into accounting record.

Cheers,
Jeff

From: spring <spring-boun...@ietf.org<mailto:spring-boun...@ietf.org>> on 
behalf of Robert Raszuk <rob...@raszuk.net<mailto:rob...@raszuk.net>>
Date: Thursday, November 16, 2017 at 10:26
To: Xuxiaohu <xuxia...@huawei.com<mailto:xuxia...@huawei.com>>
Cc: Greg Mirsky <gregimir...@gmail.com<mailto:gregimir...@gmail.com>>, spring 
<spring@ietf.org<mailto:spring@ietf.org>>, mpls 
<m...@ietf.org<mailto:m...@ietf.org>>, "Zafar Ali (zali)" 
<z...@cisco.com<mailto:z...@cisco.com>>, 
draft-hegde-spring-traffic-accounting-for-sr-paths 
<draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org<mailto:draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>>
Subject: Re: [spring] [mpls] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

The architecture is fine. This is accounting state not forwarding state.

But no new labels are needed.

See on ingress you apply sr label stack based on some match of the fields of 
actual packet. So all you need is to do accounting on the very same fields of 
the packets on egress and you have path accounting required for

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

2017-11-15 Thread Jeff Tantsura

ATM would give us event better visibility ;-)

 

I’m not advocating for a particular solution, nor expressing my liking of 
anything proposed, just stating that there a business need, especially for 
those, migrating from RSVP-TE to SR.

There’s big difference between per LSP (not per flow) networking state and 
accounting in a system…

 

Perhaps obvious – the value of an architecture is not in its abstract beauty 
(which I fully appreciate) but in its usability and value created.

 

Cheers,

Jeff

From: Xuxiaohu <xuxia...@huawei.com>
Date: Thursday, November 16, 2017 at 11:21
To: Jeff Tantsura <jefftant.i...@gmail.com>, Robert Raszuk <rob...@raszuk.net>
Cc: Greg Mirsky <gregimir...@gmail.com>, spring <spring@ietf.org>, mpls 
<m...@ietf.org>, "Zafar Ali (zali)" <z...@cisco.com>, 
draft-hegde-spring-traffic-accounting-for-sr-paths 
<draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>
Subject: RE: [spring] [mpls] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

 


If so, why not directly use RSVP-TE if the per flow state is needed?


徐小虎 Xuxiaohu
M：+86-13910161692 
E：xuxia...@huawei.com
产品与解决方案-网络战略与业务发展部
Products & Solutions-Network Strategy & Business Development Dept

发件人： Jeff Tantsura

收件人： Robert Raszuk<rob...@raszuk.net>

抄送： Xuxiaohu<xuxia...@huawei.com>;Greg 
Mirsky<gregimir...@gmail.com>;spring<spring@ietf.org>;mpls<m...@ietf.org>;Zafar 
Ali 
(zali)<z...@cisco.com>;draft-hegde-spring-traffic-accounting-for-sr-paths<draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>

主题： Re: [spring] [mpls] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

时间： 2017-11-16 11:09:13

 

Today, if you run RSVP-TE, you’d get (at least on high end platforms) counters 
per LSP.

Having the same functionality with SR seems rather logical.

 

Cheers,

Jeff

 

From: <rras...@gmail.com> on behalf of Robert Raszuk <rob...@raszuk.net>
Date: Thursday, November 16, 2017 at 10:50
To: Jeff Tantsura <jefftant.i...@gmail.com>
Cc: Xuxiaohu <xuxia...@huawei.com>, Greg Mirsky <gregimir...@gmail.com>, spring 
<spring@ietf.org>, mpls <m...@ietf.org>, "Zafar Ali (zali)" <z...@cisco.com>, 
draft-hegde-spring-traffic-accounting-for-sr-paths 
<draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>
Subject: Re: [spring] [mpls] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

 

As explained it is not needed to get all information required per path.

 

Yes you may have N:1 mapping of flows to path so what is the problem ?

 

thx

r.

 

On Nov 16, 2017 10:47, "Jeff Tantsura" <jefftant.i...@gmail.com> wrote:

Robert,

 

HW counters are rather precious resources, but that’s beside the point.

An architecture is not an immutable object, on contrary, a very import property 
of a good architecture is flexibility and agility, ability to adapt when 
business need arises.  

 

Keeping semantics aside – what’s needed, is a metadata (here encoded as a 
label) that uniquely identifies a path, where FIB lookup would yield an 
“counter hit”, potentially counter creation if the packet is the first packet 
in the flow. Value of the label would be hashed in the counter ID that is 
unique and could be resolved by a management layer into accounting record.

 

Cheers,

Jeff

 

From: spring <spring-boun...@ietf.org> on behalf of Robert Raszuk 
<rob...@raszuk.net>
Date: Thursday, November 16, 2017 at 10:26
To: Xuxiaohu <xuxia...@huawei.com>
Cc: Greg Mirsky <gregimir...@gmail.com>, spring <spring@ietf.org>, mpls 
<m...@ietf.org>, "Zafar Ali (zali)" <z...@cisco.com>, 
draft-hegde-spring-traffic-accounting-for-sr-paths 
<draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>
Subject: Re: [spring] [mpls] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

 

The architecture is fine. This is accounting state not forwarding state.

 

But no new labels are needed.

 

See on ingress you apply sr label stack based on some match of the fields of 
actual packet. So all you need is to do accounting on the very same fields of 
the packets on egress and you have path accounting required for you.

 

Besides this method also seamlessly works over non sr capable SFs as long as 
such SFs do not mess with the packet content of those tuples.

 

cheers,

r.

 

On Nov 16, 2017 10:05, "Xuxiaohu" <xuxia...@huawei.com> wrote:

Concur. Although it has some values, it's not cost-efficient from my point of 
view. Network simplicity should be the first priority object. Hence we would 
have to make some compromise.

Best regards,
Xiaohu 

徐小虎 Xuxiaohu
M：+86-13910161692 
E：xuxia...@huawei.com
产品与解决方案-网络战略与业务发展部
Products & Solutions-Network Strategy & Business Developm

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

2017-11-15 Thread Chengli (IP Technology Research)

Shraddha,

I agree with your point of counters are needed for per flow fully, if we need 
to measure per flow in SR. 

For measuring performance, some states are needed, and it is good to not create 
new forwarding states or control states.  It is the same for both solutions.

But I still think 3 or 4(If the reserved label (0-15) can not be assigned ) 
labels are too many for label stack since the limit of MSD.

For 2 or 3 labels  solution, the limit will become global segments for 
identifying path.

Regards
Cheng


-Original Message-
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Shraddha Hegde
Sent: Thursday, November 16, 2017 11:11 AM
To: Robert Raszuk <rob...@raszuk.net>; Jeff Tantsura <jefftant.i...@gmail.com>
Cc: draft-hegde-spring-traffic-accounting-for-sr-paths 
<draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>; spring 
<spring@ietf.org>; Greg Mirsky <gregimir...@gmail.com>; mpls <m...@ietf.org>; 
Xuxiaohu <xuxia...@huawei.com>; Zafar Ali (zali) <z...@cisco.com>
Subject: Re: [spring] [mpls] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

Robert,

If we have to get the N:1 mapping then we need to count all the N flows on a 
transit router.
N is really huge number and it is really not practical to count every flow on a 
transit router.

There have also been comments about creating state in the network.
The proposed solution in the draft does not create per-path forwarding state 
and does not create any per-path control state in The network. It's only the 
counters that are getting created per-path which is most essential for OAM.

Rgds
Shraddha

-Original Message-
From: rras...@gmail.com [mailto:rras...@gmail.com] On Behalf Of Robert Raszuk
Sent: Thursday, November 16, 2017 10:51 AM
To: Jeff Tantsura <jefftant.i...@gmail.com>
Cc: Xuxiaohu <xuxia...@huawei.com>; Greg Mirsky <gregimir...@gmail.com>; spring 
<spring@ietf.org>; mpls <m...@ietf.org>; Zafar Ali (zali) <z...@cisco.com>; 
draft-hegde-spring-traffic-accounting-for-sr-paths 
<draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>
Subject: Re: [spring] [mpls] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

As explained it is not needed to get all information required per path.

Yes you may have N:1 mapping of flows to path so what is the problem ?

thx
r.

On Nov 16, 2017 10:47, "Jeff Tantsura" <jefftant.i...@gmail.com> wrote:

> Robert,
>
>
>
> HW counters are rather precious resources, but that’s beside the point.
>
> An architecture is not an immutable object, on contrary, a very import 
> property of a good architecture is flexibility and agility, ability to 
> adapt when business need arises.
>
>
>
> Keeping semantics aside – what’s needed, is a metadata (here encoded 
> as a
> label) that uniquely identifies a path, where FIB lookup would yield 
> an “counter hit”, potentially counter creation if the packet is the 
> first packet in the flow. Value of the label would be hashed in the 
> counter ID that is unique and could be resolved by a management layer 
> into accounting record.
>
>
>
> Cheers,
>
> Jeff
>
>
>
> *From: *spring <spring-boun...@ietf.org> on behalf of Robert Raszuk < 
> rob...@raszuk.net>
> *Date: *Thursday, November 16, 2017 at 10:26
> *To: *Xuxiaohu <xuxia...@huawei.com>
> *Cc: *Greg Mirsky <gregimir...@gmail.com>, spring <spring@ietf.org>, 
> mpls <m...@ietf.org>, "Zafar Ali (zali)" <z...@cisco.com>, 
> draft-hegde-spring-traffic-accounting-for-sr-paths < 
> draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>
> *Subject: *Re: [spring] [mpls] Special purpose labels in 
> draft-hegde-spring-traffic-accounting-for-sr-paths
>
>
>
> The architecture is fine. This is accounting state not forwarding state.
>
>
>
> But no new labels are needed.
>
>
>
> See on ingress you apply sr label stack based on some match of the 
> fields of actual packet. So all you need is to do accounting on the 
> very same fields of the packets on egress and you have path accounting 
> required for you.
>
>
>
> Besides this method also seamlessly works over non sr capable SFs as 
> long as such SFs do not mess with the packet content of those tuples.
>
>
>
> cheers,
>
> r.
>
>
>
> On Nov 16, 2017 10:05, "Xuxiaohu" <xuxia...@huawei.com> wrote:
>
> Concur. Although it has some values, it's not cost-efficient from my 
> point of view. Network simplicity should be the first priority object.
> Hence we would have to make some compromise.
>
> Best regards,
> Xiaohu
>
>
>
> --------------
>
> 徐小虎 Xuxiaohu

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

2017-11-15 Thread Xuxiaohu


If so, why not directly use RSVP-TE if the per flow state is needed?




徐小虎 Xuxiaohu
M：+86-13910161692<tel:+86-13910161692>
E：xuxia...@huawei.com<mailto:xuxia...@huawei.com>
产品与解决方案-网络战略与业务发展部
Products & Solutions-Network Strategy & Business Development Dept

发件人： Jeff Tantsura
收件人： Robert Raszuk<rob...@raszuk.net<mailto:rob...@raszuk.net>>
抄送： Xuxiaohu<xuxia...@huawei.com<mailto:xuxia...@huawei.com>>;Greg 
Mirsky<gregimir...@gmail.com<mailto:gregimir...@gmail.com>>;spring<spring@ietf.org<mailto:spring@ietf.org>>;mpls<m...@ietf.org<mailto:m...@ietf.org>>;Zafar
 Ali 
(zali)<z...@cisco.com<mailto:z...@cisco.com>>;draft-hegde-spring-traffic-accounting-for-sr-paths<draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org<mailto:draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>>
主题： Re: [spring] [mpls] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths
时间： 2017-11-16 11:09:13

Today, if you run RSVP-TE, you’d get (at least on high end platforms) counters 
per LSP.
Having the same functionality with SR seems rather logical.

Cheers,
Jeff

From: <rras...@gmail.com> on behalf of Robert Raszuk <rob...@raszuk.net>
Date: Thursday, November 16, 2017 at 10:50
To: Jeff Tantsura <jefftant.i...@gmail.com>
Cc: Xuxiaohu <xuxia...@huawei.com>, Greg Mirsky <gregimir...@gmail.com>, spring 
<spring@ietf.org>, mpls <m...@ietf.org>, "Zafar Ali (zali)" <z...@cisco.com>, 
draft-hegde-spring-traffic-accounting-for-sr-paths 
<draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>
Subject: Re: [spring] [mpls] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

As explained it is not needed to get all information required per path.

Yes you may have N:1 mapping of flows to path so what is the problem ?

thx
r.

On Nov 16, 2017 10:47, "Jeff Tantsura" 
<jefftant.i...@gmail.com<mailto:jefftant.i...@gmail.com>> wrote:
Robert,

HW counters are rather precious resources, but that’s beside the point.
An architecture is not an immutable object, on contrary, a very import property 
of a good architecture is flexibility and agility, ability to adapt when 
business need arises.

Keeping semantics aside �C what’s needed, is a metadata (here encoded as a 
label) that uniquely identifies a path, where FIB lookup would yield an 
“counter hit”, potentially counter creation if the packet is the first packet 
in the flow. Value of the label would be hashed in the counter ID that is 
unique and could be resolved by a management layer into accounting record.

Cheers,
Jeff

From: spring <spring-boun...@ietf.org<mailto:spring-boun...@ietf.org>> on 
behalf of Robert Raszuk <rob...@raszuk.net<mailto:rob...@raszuk.net>>
Date: Thursday, November 16, 2017 at 10:26
To: Xuxiaohu <xuxia...@huawei.com<mailto:xuxia...@huawei.com>>
Cc: Greg Mirsky <gregimir...@gmail.com<mailto:gregimir...@gmail.com>>, spring 
<spring@ietf.org<mailto:spring@ietf.org>>, mpls 
<m...@ietf.org<mailto:m...@ietf.org>>, "Zafar Ali (zali)" 
<z...@cisco.com<mailto:z...@cisco.com>>, 
draft-hegde-spring-traffic-accounting-for-sr-paths 
<draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org<mailto:draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>>
Subject: Re: [spring] [mpls] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

The architecture is fine. This is accounting state not forwarding state.

But no new labels are needed.

See on ingress you apply sr label stack based on some match of the fields of 
actual packet. So all you need is to do accounting on the very same fields of 
the packets on egress and you have path accounting required for you.

Besides this method also seamlessly works over non sr capable SFs as long as 
such SFs do not mess with the packet content of those tuples.

cheers,
r.

On Nov 16, 2017 10:05, "Xuxiaohu" 
<xuxia...@huawei.com<mailto:xuxia...@huawei.com>> wrote:
Concur. Although it has some values, it's not cost-efficient from my point of 
view. Network simplicity should be the first priority object. Hence we would 
have to make some compromise.

Best regards,
Xiaohu



徐小虎 Xuxiaohu
M：+86-13910161692<tel:+86-13910161692>
E：xuxia...@huawei.com<mailto:xuxia...@huawei.com>
产品与解决方案-网络战略与业务发展部
Products & Solutions-Network Strategy & Business Development Dept
发件人： Zafar Ali (zali)
收件人： Greg 
Mirsky<gregimir...@gmail.com<mailto:gregimir...@gmail.com>>;draft-hegde-spring-traffic-accounting-for-sr-paths<draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org<mailto:draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>>;mpls

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

2017-11-15 Thread Mach Chen

I totally agree with Jeff here.

Remember that several WGs in IETF are working on performance measurement, and 
even there is a dedicated PM WG (IPPM).

I am not sure SR is an exception.


Best regards,
Mach

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Jeff Tantsura
Sent: Thursday, November 16, 2017 11:09 AM
To: Robert Raszuk
Cc: draft-hegde-spring-traffic-accounting-for-sr-paths; spring; Greg Mirsky; 
mpls; Xuxiaohu; Zafar Ali (zali)
Subject: Re: [spring] [mpls] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

Today, if you run RSVP-TE, you’d get (at least on high end platforms) counters 
per LSP.
Having the same functionality with SR seems rather logical.

Cheers,
Jeff

From: <rras...@gmail.com<mailto:rras...@gmail.com>> on behalf of Robert Raszuk 
<rob...@raszuk.net<mailto:rob...@raszuk.net>>
Date: Thursday, November 16, 2017 at 10:50
To: Jeff Tantsura <jefftant.i...@gmail.com<mailto:jefftant.i...@gmail.com>>
Cc: Xuxiaohu <xuxia...@huawei.com<mailto:xuxia...@huawei.com>>, Greg Mirsky 
<gregimir...@gmail.com<mailto:gregimir...@gmail.com>>, spring 
<spring@ietf.org<mailto:spring@ietf.org>>, mpls 
<m...@ietf.org<mailto:m...@ietf.org>>, "Zafar Ali (zali)" 
<z...@cisco.com<mailto:z...@cisco.com>>, 
draft-hegde-spring-traffic-accounting-for-sr-paths 
<draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org<mailto:draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>>
Subject: Re: [spring] [mpls] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

As explained it is not needed to get all information required per path.

Yes you may have N:1 mapping of flows to path so what is the problem ?

thx
r.

On Nov 16, 2017 10:47, "Jeff Tantsura" 
<jefftant.i...@gmail.com<mailto:jefftant.i...@gmail.com>> wrote:
Robert,

HW counters are rather precious resources, but that’s beside the point.
An architecture is not an immutable object, on contrary, a very import property 
of a good architecture is flexibility and agility, ability to adapt when 
business need arises.

Keeping semantics aside – what’s needed, is a metadata (here encoded as a 
label) that uniquely identifies a path, where FIB lookup would yield an 
“counter hit”, potentially counter creation if the packet is the first packet 
in the flow. Value of the label would be hashed in the counter ID that is 
unique and could be resolved by a management layer into accounting record.

Cheers,
Jeff

From: spring <spring-boun...@ietf.org<mailto:spring-boun...@ietf.org>> on 
behalf of Robert Raszuk <rob...@raszuk.net<mailto:rob...@raszuk.net>>
Date: Thursday, November 16, 2017 at 10:26
To: Xuxiaohu <xuxia...@huawei.com<mailto:xuxia...@huawei.com>>
Cc: Greg Mirsky <gregimir...@gmail.com<mailto:gregimir...@gmail.com>>, spring 
<spring@ietf.org<mailto:spring@ietf.org>>, mpls 
<m...@ietf.org<mailto:m...@ietf.org>>, "Zafar Ali (zali)" 
<z...@cisco.com<mailto:z...@cisco.com>>, 
draft-hegde-spring-traffic-accounting-for-sr-paths 
<draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org<mailto:draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>>
Subject: Re: [spring] [mpls] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

The architecture is fine. This is accounting state not forwarding state.

But no new labels are needed.

See on ingress you apply sr label stack based on some match of the fields of 
actual packet. So all you need is to do accounting on the very same fields of 
the packets on egress and you have path accounting required for you.

Besides this method also seamlessly works over non sr capable SFs as long as 
such SFs do not mess with the packet content of those tuples.

cheers,
r.

On Nov 16, 2017 10:05, "Xuxiaohu" 
<xuxia...@huawei.com<mailto:xuxia...@huawei.com>> wrote:
Concur. Although it has some values, it's not cost-efficient from my point of 
view. Network simplicity should be the first priority object. Hence we would 
have to make some compromise.

Best regards,
Xiaohu


徐小虎 Xuxiaohu
M：+86-13910161692<tel:+86-13910161692>
E：xuxia...@huawei.com<mailto:xuxia...@huawei.com>
产品与解决方案-网络战略与业务发展部
Products & Solutions-Network Strategy & Business Development Dept
发件人： Zafar Ali (zali)
收件人： Greg 
Mirsky<gregimir...@gmail.com<mailto:gregimir...@gmail.com>>;draft-hegde-spring-traffic-accounting-for-sr-paths<draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org<mailto:draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>>;mpls<m...@ietf.org<mailto:m...@ietf.org>>;spring<spring@ietf.org<mailto:spring@ietf.org>>
主题： Re: [mpls] [spring] Special purpose labels in 
draft-hegde

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

2017-11-15 Thread David Allan I

So your point would be that this does not require a special label to achieve 
this. Nor do we need a redesign of stack processing at every node in the 
network to enable this functionality.

Cheers
Dave

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Jeff Tantsura
Sent: Thursday, November 16, 2017 11:09 AM
To: Robert Raszuk <rob...@raszuk.net>
Cc: draft-hegde-spring-traffic-accounting-for-sr-paths 
<draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>; spring 
<spring@ietf.org>; Greg Mirsky <gregimir...@gmail.com>; mpls <m...@ietf.org>; 
Xuxiaohu <xuxia...@huawei.com>; Zafar Ali (zali) <z...@cisco.com>
Subject: Re: [spring] [mpls] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

Today, if you run RSVP-TE, you’d get (at least on high end platforms) counters 
per LSP.
Having the same functionality with SR seems rather logical.

Cheers,
Jeff

From: <rras...@gmail.com<mailto:rras...@gmail.com>> on behalf of Robert Raszuk 
<rob...@raszuk.net<mailto:rob...@raszuk.net>>
Date: Thursday, November 16, 2017 at 10:50
To: Jeff Tantsura <jefftant.i...@gmail.com<mailto:jefftant.i...@gmail.com>>
Cc: Xuxiaohu <xuxia...@huawei.com<mailto:xuxia...@huawei.com>>, Greg Mirsky 
<gregimir...@gmail.com<mailto:gregimir...@gmail.com>>, spring 
<spring@ietf.org<mailto:spring@ietf.org>>, mpls 
<m...@ietf.org<mailto:m...@ietf.org>>, "Zafar Ali (zali)" 
<z...@cisco.com<mailto:z...@cisco.com>>, 
draft-hegde-spring-traffic-accounting-for-sr-paths 
<draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org<mailto:draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>>
Subject: Re: [spring] [mpls] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

As explained it is not needed to get all information required per path.

Yes you may have N:1 mapping of flows to path so what is the problem ?

thx
r.

On Nov 16, 2017 10:47, "Jeff Tantsura" 
<jefftant.i...@gmail.com<mailto:jefftant.i...@gmail.com>> wrote:
Robert,

HW counters are rather precious resources, but that’s beside the point.
An architecture is not an immutable object, on contrary, a very import property 
of a good architecture is flexibility and agility, ability to adapt when 
business need arises.

Keeping semantics aside – what’s needed, is a metadata (here encoded as a 
label) that uniquely identifies a path, where FIB lookup would yield an 
“counter hit”, potentially counter creation if the packet is the first packet 
in the flow. Value of the label would be hashed in the counter ID that is 
unique and could be resolved by a management layer into accounting record.

Cheers,
Jeff

From: spring <spring-boun...@ietf.org<mailto:spring-boun...@ietf.org>> on 
behalf of Robert Raszuk <rob...@raszuk.net<mailto:rob...@raszuk.net>>
Date: Thursday, November 16, 2017 at 10:26
To: Xuxiaohu <xuxia...@huawei.com<mailto:xuxia...@huawei.com>>
Cc: Greg Mirsky <gregimir...@gmail.com<mailto:gregimir...@gmail.com>>, spring 
<spring@ietf.org<mailto:spring@ietf.org>>, mpls 
<m...@ietf.org<mailto:m...@ietf.org>>, "Zafar Ali (zali)" 
<z...@cisco.com<mailto:z...@cisco.com>>, 
draft-hegde-spring-traffic-accounting-for-sr-paths 
<draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org<mailto:draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>>
Subject: Re: [spring] [mpls] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

The architecture is fine. This is accounting state not forwarding state.

But no new labels are needed.

See on ingress you apply sr label stack based on some match of the fields of 
actual packet. So all you need is to do accounting on the very same fields of 
the packets on egress and you have path accounting required for you.

Besides this method also seamlessly works over non sr capable SFs as long as 
such SFs do not mess with the packet content of those tuples.

cheers,
r.

On Nov 16, 2017 10:05, "Xuxiaohu" 
<xuxia...@huawei.com<mailto:xuxia...@huawei.com>> wrote:
Concur. Although it has some values, it's not cost-efficient from my point of 
view. Network simplicity should be the first priority object. Hence we would 
have to make some compromise.

Best regards,
Xiaohu

徐小虎 Xuxiaohu
M：+86-13910161692<tel:+86-13910161692>
E：xuxia...@huawei.com<mailto:xuxia...@huawei.com>
产品与解决方案-网络战略与业务发展部
Products & Solutions-Network Strategy & Business Development Dept
发件人： Zafar Ali (zali)
收件人： Greg 
Mirsky<gregimir...@gmail.com<mailto:gregimir...@gmail.com>>;draft-hegde-spring-traffic-accounting-for-sr-paths<draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org<mailto:draft-hegde-spring

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

2017-11-15 Thread Shraddha Hegde

Robert,

If we have to get the N:1 mapping then we need to count all the N flows on a 
transit router.
N is really huge number and it is really not practical to count every flow on a 
transit router.

There have also been comments about creating state in the network.
The proposed solution in the draft does not create per-path forwarding state 
and does not create any per-path control state in
The network. It's only the counters that are getting created per-path which is 
most essential for OAM.

Rgds
Shraddha

-Original Message-
From: rras...@gmail.com [mailto:rras...@gmail.com] On Behalf Of Robert Raszuk
Sent: Thursday, November 16, 2017 10:51 AM
To: Jeff Tantsura <jefftant.i...@gmail.com>
Cc: Xuxiaohu <xuxia...@huawei.com>; Greg Mirsky <gregimir...@gmail.com>; spring 
<spring@ietf.org>; mpls <m...@ietf.org>; Zafar Ali (zali) <z...@cisco.com>; 
draft-hegde-spring-traffic-accounting-for-sr-paths 
<draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>
Subject: Re: [spring] [mpls] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

As explained it is not needed to get all information required per path.

Yes you may have N:1 mapping of flows to path so what is the problem ?

thx
r.

On Nov 16, 2017 10:47, "Jeff Tantsura" <jefftant.i...@gmail.com> wrote:

> Robert,
>
>
>
> HW counters are rather precious resources, but that’s beside the point.
>
> An architecture is not an immutable object, on contrary, a very import 
> property of a good architecture is flexibility and agility, ability to 
> adapt when business need arises.
>
>
>
> Keeping semantics aside – what’s needed, is a metadata (here encoded 
> as a
> label) that uniquely identifies a path, where FIB lookup would yield 
> an “counter hit”, potentially counter creation if the packet is the 
> first packet in the flow. Value of the label would be hashed in the 
> counter ID that is unique and could be resolved by a management layer 
> into accounting record.
>
>
>
> Cheers,
>
> Jeff
>
>
>
> *From: *spring <spring-boun...@ietf.org> on behalf of Robert Raszuk < 
> rob...@raszuk.net>
> *Date: *Thursday, November 16, 2017 at 10:26
> *To: *Xuxiaohu <xuxia...@huawei.com>
> *Cc: *Greg Mirsky <gregimir...@gmail.com>, spring <spring@ietf.org>, 
> mpls <m...@ietf.org>, "Zafar Ali (zali)" <z...@cisco.com>, 
> draft-hegde-spring-traffic-accounting-for-sr-paths < 
> draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>
> *Subject: *Re: [spring] [mpls] Special purpose labels in 
> draft-hegde-spring-traffic-accounting-for-sr-paths
>
>
>
> The architecture is fine. This is accounting state not forwarding state.
>
>
>
> But no new labels are needed.
>
>
>
> See on ingress you apply sr label stack based on some match of the 
> fields of actual packet. So all you need is to do accounting on the 
> very same fields of the packets on egress and you have path accounting 
> required for you.
>
>
>
> Besides this method also seamlessly works over non sr capable SFs as 
> long as such SFs do not mess with the packet content of those tuples.
>
>
>
> cheers,
>
> r.
>
>
>
> On Nov 16, 2017 10:05, "Xuxiaohu" <xuxia...@huawei.com> wrote:
>
> Concur. Although it has some values, it's not cost-efficient from my 
> point of view. Network simplicity should be the first priority object. 
> Hence we would have to make some compromise.
>
> Best regards,
> Xiaohu
>
>
>
> --
>
> 徐小虎 Xuxiaohu
> M：+86-13910161692
> E：xuxia...@huawei.com
> 产品与解决方案-网络战略与业务发展部
> Products & Solutions-Network Strategy & Business Development Dept
>
> *发件人：* Zafar Ali (zali)
>
> *收件人：* Greg Mirsky<gregimir...@gmail.com>;draft-hegde-spring-traffic-
> accounting-for-sr-paths accounting-for-sr-pa...@ietf.org>;mpls<m...@ietf.org>;spring<
> spring@ietf.org>
>
> *主**题**：* Re: [mpls] [spring] Special purpose labels in 
> draft-hegde-spring-traffic-accounting-for-sr-paths
>
> *时间：* 2017-11-16 02:24:10
>
>
>
> Hi,
>
>
>
> This draft breaks the SR architecture. I am quoting a snippet from 
> abstract of SR Architecture document 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_ht
> ml_=DwIFaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=NyjLsr7JA
> 7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng=D8UZYa9EWpns6URXJvtBqZ5gX2lDpl7l5
> ZTaXTlEJGw=xB3z335gatRnndYZzanLmzNqezYOznxweYSwcOKuMMo=
> draft-ietf-spring-segment-routing-13, which states:
>
> “SR allows to enforce a flow through any topological path while 
> maintaining per-flow state only

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

2017-11-15 Thread Jeff Tantsura

Today, if you run RSVP-TE, you’d get (at least on high end platforms) counters 
per LSP.

Having the same functionality with SR seems rather logical.

 

Cheers,

Jeff

 

From: <rras...@gmail.com> on behalf of Robert Raszuk <rob...@raszuk.net>
Date: Thursday, November 16, 2017 at 10:50
To: Jeff Tantsura <jefftant.i...@gmail.com>
Cc: Xuxiaohu <xuxia...@huawei.com>, Greg Mirsky <gregimir...@gmail.com>, spring 
<spring@ietf.org>, mpls <m...@ietf.org>, "Zafar Ali (zali)" <z...@cisco.com>, 
draft-hegde-spring-traffic-accounting-for-sr-paths 
<draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>
Subject: Re: [spring] [mpls] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

 

As explained it is not needed to get all information required per path.

 

Yes you may have N:1 mapping of flows to path so what is the problem ?

 

thx

r.

 

On Nov 16, 2017 10:47, "Jeff Tantsura" <jefftant.i...@gmail.com> wrote:

Robert,

 

HW counters are rather precious resources, but that’s beside the point.

An architecture is not an immutable object, on contrary, a very import property 
of a good architecture is flexibility and agility, ability to adapt when 
business need arises.  

 

Keeping semantics aside – what’s needed, is a metadata (here encoded as a 
label) that uniquely identifies a path, where FIB lookup would yield an 
“counter hit”, potentially counter creation if the packet is the first packet 
in the flow. Value of the label would be hashed in the counter ID that is 
unique and could be resolved by a management layer into accounting record.

 

Cheers,

Jeff

 

From: spring <spring-boun...@ietf.org> on behalf of Robert Raszuk 
<rob...@raszuk.net>
Date: Thursday, November 16, 2017 at 10:26
To: Xuxiaohu <xuxia...@huawei.com>
Cc: Greg Mirsky <gregimir...@gmail.com>, spring <spring@ietf.org>, mpls 
<m...@ietf.org>, "Zafar Ali (zali)" <z...@cisco.com>, 
draft-hegde-spring-traffic-accounting-for-sr-paths 
<draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>
Subject: Re: [spring] [mpls] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

 

The architecture is fine. This is accounting state not forwarding state.

 

But no new labels are needed.

 

See on ingress you apply sr label stack based on some match of the fields of 
actual packet. So all you need is to do accounting on the very same fields of 
the packets on egress and you have path accounting required for you.

 

Besides this method also seamlessly works over non sr capable SFs as long as 
such SFs do not mess with the packet content of those tuples.

 

cheers,

r.

 

On Nov 16, 2017 10:05, "Xuxiaohu" <xuxia...@huawei.com> wrote:

Concur. Although it has some values, it's not cost-efficient from my point of 
view. Network simplicity should be the first priority object. Hence we would 
have to make some compromise.

Best regards,
Xiaohu 


徐小虎 Xuxiaohu
M：+86-13910161692 
E：xuxia...@huawei.com
产品与解决方案-网络战略与业务发展部
Products & Solutions-Network Strategy & Business Development Dept

发件人： Zafar Ali (zali)

收件人： Greg 
Mirsky<gregimir...@gmail.com>;draft-hegde-spring-traffic-accounting-for-sr-paths<draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>;mpls<m...@ietf.org>;spring<spring@ietf.org>

主题： Re: [mpls] [spring] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

时间： 2017-11-16 02:24:10

 

Hi, 

 

This draft breaks the SR architecture. I am quoting a snippet from abstract of 
SR Architecture document 
https://tools.ietf.org/html/draft-ietf-spring-segment-routing-13, which states:

“SR allows to enforce a flow through any topological path while maintaining 
per-flow state only at the ingress nodes to the SR domain.” 

 

In addition to creating states at transit and egress nodes, the procedure also 
affects the data plane and makes it unscalable. It also makes controller job 
much harder and error prune. In summary, I find the procedure very complex and 
unscalable. 

 

Thanks

 

Regards … Zafar 

 

 

From: spring <spring-boun...@ietf.org> on behalf of Greg Mirsky 
<gregimir...@gmail.com>
Date: Wednesday, November 15, 2017 at 11:10 AM
To: "draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org" 
<draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>, "m...@ietf.org" 
<m...@ietf.org>, "spring@ietf.org" <spring@ietf.org>
Subject: [spring] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

 

Hi Shraddha, 

thank you for very well written and thought through draft. I have these 
questions I'd like to discuss:

·  Have you thought of using not one special purpose label for both SR Path 
Identifier and SR Path Identifier+Source SID cases but request two sp

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

2017-11-15 Thread Xuxiaohu

I fully agree with you that OAM tools are important.

I just felt that the approach as proposed in the draft would enconter the same 
terrible issues as those associated with the MPLS-SR entropy label usage due to 
RLD and MSD hardware limitations.

Best regards,
Xiaohu





徐小虎 Xuxiaohu
M：+86-13910161692<tel:+86-13910161692>
E：xuxia...@huawei.com<mailto:xuxia...@huawei.com>
产品与解决方案-网络战略与业务发展部
Products & Solutions-Network Strategy & Business Development Dept

发件人： Greg Mirsky
收件人： Xuxiaohu<xuxia...@huawei.com<mailto:xuxia...@huawei.com>>
抄送： Zafar Ali 
(zali)<z...@cisco.com<mailto:z...@cisco.com>>;draft-hegde-spring-traffic-accounting-for-sr-paths<draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org<mailto:draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>>;mpls<m...@ietf.org<mailto:m...@ietf.org>>;spring<spring@ietf.org<mailto:spring@ietf.org>>
主题： Re: [mpls] [spring] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths
时间： 2017-11-16 10:27:55

Dear All,
I cannot imagine that operators will agree to deploy network that lacks 
critical OAM tools to monitor performance and troubleshoot the network. True, 
some will brave the challenge and be the early adopters but even they will 
likely request that the OAM toolbox be sufficient to support their operational 
needs. I see that this work clearly describes the problem and why ability to 
quantify the flow behavior at internal nodes is important for efficient network 
operation. First let's discuss whether the case and requirement towards OAM is 
real and valid. Then we can continue to discussion of what measurement method 
to use.

Regards,
Greg

On Thu, Nov 16, 2017 at 10:05 AM, Xuxiaohu 
<xuxia...@huawei.com<mailto:xuxia...@huawei.com>> wrote:
Concur. Although it has some values, it's not cost-efficient from my point of 
view. Network simplicity should be the first priority object. Hence we would 
have to make some compromise.

Best regards,
Xiaohu





徐小虎 Xuxiaohu
M：+86-13910161692<tel:+86-13910161692>
E：xuxia...@huawei.com<mailto:xuxia...@huawei.com>
产品与解决方案-网络战略与业务发展部
Products & Solutions-Network Strategy & Business Development Dept

发件人： Zafar Ali (zali)
收件人： Greg 
Mirsky<gregimir...@gmail.com<mailto:gregimir...@gmail.com>>;draft-hegde-spring-traffic-accounting-for-sr-paths<draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org<mailto:draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>>;mpls<m...@ietf.org<mailto:m...@ietf.org>>;spring<spring@ietf.org<mailto:spring@ietf.org>>
主题： Re: [mpls] [spring] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths
时间： 2017-11-16 02:24:10

Hi,

This draft breaks the SR architecture. I am quoting a snippet from abstract of 
SR Architecture document 
https://tools.ietf.org/html/draft-ietf-spring-segment-routing-13, which states:
“SR allows to enforce a flow through any topological path while maintaining 
per-flow state only at the ingress nodes to the SR domain.”

In addition to creating states at transit and egress nodes, the procedure also 
affects the data plane and makes it unscalable. It also makes controller job 
much harder and error prune. In summary, I find the procedure very complex and 
unscalable.

Thanks

Regards … Zafar


From: spring <spring-boun...@ietf.org<mailto:spring-boun...@ietf.org>> on 
behalf of Greg Mirsky <gregimir...@gmail.com<mailto:gregimir...@gmail.com>>
Date: Wednesday, November 15, 2017 at 11:10 AM
To: 
"draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org<mailto:draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>"
 
<draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org<mailto:draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>>,
 "m...@ietf.org<mailto:m...@ietf.org>" <m...@ietf.org<mailto:m...@ietf.org>>, 
"spring@ietf.org<mailto:spring@ietf.org>" 
<spring@ietf.org<mailto:spring@ietf.org>>
Subject: [spring] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

Hi Shraddha,
thank you for very well written and thought through draft. I have these 
questions I'd like to discuss:

  *   Have you thought of using not one special purpose label for both SR Path 
Identifier and SR Path Identifier+Source SID cases but request two special 
purpose labels, one for each case. Then the SR Path Identifier would not have 
to lose the bit for C flag.
  *   And how you envision to collect the counters along the path? Of course, a 
Controller may query LSR for all counters or counters for the particular flow 
(SR Path Identifier+Source SID). But in addition I'd propose to use in-band 
mechanism, perhaps another special purpose label, t

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

2017-11-15 Thread Robert Raszuk

As explained it is not needed to get all information required per path.

Yes you may have N:1 mapping of flows to path so what is the problem ?

thx
r.

On Nov 16, 2017 10:47, "Jeff Tantsura" <jefftant.i...@gmail.com> wrote:

> Robert,
>
>
>
> HW counters are rather precious resources, but that’s beside the point.
>
> An architecture is not an immutable object, on contrary, a very import
> property of a good architecture is flexibility and agility, ability to
> adapt when business need arises.
>
>
>
> Keeping semantics aside – what’s needed, is a metadata (here encoded as a
> label) that uniquely identifies a path, where FIB lookup would yield an
> “counter hit”, potentially counter creation if the packet is the first
> packet in the flow. Value of the label would be hashed in the counter ID
> that is unique and could be resolved by a management layer into accounting
> record.
>
>
>
> Cheers,
>
> Jeff
>
>
>
> *From: *spring <spring-boun...@ietf.org> on behalf of Robert Raszuk <
> rob...@raszuk.net>
> *Date: *Thursday, November 16, 2017 at 10:26
> *To: *Xuxiaohu <xuxia...@huawei.com>
> *Cc: *Greg Mirsky <gregimir...@gmail.com>, spring <spring@ietf.org>, mpls
> <m...@ietf.org>, "Zafar Ali (zali)" <z...@cisco.com>,
> draft-hegde-spring-traffic-accounting-for-sr-paths <
> draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>
> *Subject: *Re: [spring] [mpls] Special purpose labels in
> draft-hegde-spring-traffic-accounting-for-sr-paths
>
>
>
> The architecture is fine. This is accounting state not forwarding state.
>
>
>
> But no new labels are needed.
>
>
>
> See on ingress you apply sr label stack based on some match of the fields
> of actual packet. So all you need is to do accounting on the very same
> fields of the packets on egress and you have path accounting required for
> you.
>
>
>
> Besides this method also seamlessly works over non sr capable SFs as long
> as such SFs do not mess with the packet content of those tuples.
>
>
>
> cheers,
>
> r.
>
>
>
> On Nov 16, 2017 10:05, "Xuxiaohu" <xuxia...@huawei.com> wrote:
>
> Concur. Although it has some values, it's not cost-efficient from my point
> of view. Network simplicity should be the first priority object. Hence we
> would have to make some compromise.
>
> Best regards,
> Xiaohu
>
>
>
> --
>
> 徐小虎 Xuxiaohu
> M：+86-13910161692
> E：xuxia...@huawei.com
> 产品与解决方案-网络战略与业务发展部
> Products & Solutions-Network Strategy & Business Development Dept
>
> *发件人：* Zafar Ali (zali)
>
> *收件人：* Greg Mirsky<gregimir...@gmail.com>;draft-hegde-spring-traffic-
> accounting-for-sr-paths accounting-for-sr-pa...@ietf.org>;mpls<m...@ietf.org>;spring<
> spring@ietf.org>
>
> *主**题**：* Re: [mpls] [spring] Special purpose labels in
> draft-hegde-spring-traffic-accounting-for-sr-paths
>
> *时间：* 2017-11-16 02:24:10
>
>
>
> Hi,
>
>
>
> This draft breaks the SR architecture. I am quoting a snippet from
> abstract of SR Architecture document https://tools.ietf.org/html/
> draft-ietf-spring-segment-routing-13, which states:
>
> “SR allows to enforce a flow through any topological path while
> maintaining per-flow state only at the ingress nodes to the SR domain.”
>
>
>
> In addition to creating states at transit and egress nodes, the procedure
> also affects the data plane and makes it unscalable. It also makes
> controller job much harder and error prune. In summary, I find the
> procedure very complex and unscalable.
>
>
>
> Thanks
>
>
>
> Regards … Zafar
>
>
>
>
>
> *From: *spring <spring-boun...@ietf.org> on behalf of Greg Mirsky <
> gregimir...@gmail.com>
> *Date: *Wednesday, November 15, 2017 at 11:10 AM
> *To: *"draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org" <
> draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>, "
> m...@ietf.org" <m...@ietf.org>, "spring@ietf.org" <spring@ietf.org>
> *Subject: *[spring] Special purpose labels in draft-hegde-spring-traffic-
> accounting-for-sr-paths
>
>
>
> Hi Shraddha,
>
> thank you for very well written and thought through draft. I have these
> questions I'd like to discuss:
>
> ·  Have you thought of using not one special purpose label for both SR
> Path Identifier and SR Path Identifier+Source SID cases but request two
> special purpose labels, one for each case. Then the SR Path Identifier
> would not have to lose the bit for C flag.
>
> ·  And how you envision to

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

2017-11-15 Thread Robert Raszuk

I am not suggesting checking any label stack.

All info comes from packet behind label stack. Just like it is read on
ingress when/before you apply stack the same can be done on egress where
there is no more stack at all any more.

thx
r.

On Nov 16, 2017 10:43, "ShaoWen Ma" <mashao...@gmail.com> wrote:

Hi Robert and all,

  SPRING try to get rid of per flow forwarding status. that's the design
principal for whole network.
  and Shraddha just want to add back per flow Traffic statistics as
request, which will only applied to interested flow.

  if you check the label stack for traffic statistics, that might be get
some processing trouble to handle:
{300|200|100} with another label stack such as {400|300|200|100} on the
same nodes.

  so path id do have it's value if customer want to check specific flow, by
not impact all packet process on the transit router.

Best Regards
Shaowen Ma


On Thu, Nov 16, 2017 at 10:26 AM, Robert Raszuk <rob...@raszuk.net> wrote:

> The architecture is fine. This is accounting state not forwarding state.
>
> But no new labels are needed.
>
> See on ingress you apply sr label stack based on some match of the fields
> of actual packet. So all you need is to do accounting on the very same
> fields of the packets on egress and you have path accounting required for
> you.
>
> Besides this method also seamlessly works over non sr capable SFs as long
> as such SFs do not mess with the packet content of those tuples.
>
> cheers,
> r.
>
> On Nov 16, 2017 10:05, "Xuxiaohu" <xuxia...@huawei.com> wrote:
>
>> Concur. Although it has some values, it's not cost-efficient from my
>> point of view. Network simplicity should be the first priority object.
>> Hence we would have to make some compromise.
>>
>> Best regards,
>> Xiaohu
>>
>>
>>
>>
>> --
>> 徐小虎 Xuxiaohu
>> M：+86-13910161692
>> E：xuxia...@huawei.com
>> 产品与解决方案-网络战略与业务发展部
>> Products & Solutions-Network Strategy & Business Development Dept
>>
>> *发件人： *Zafar Ali (zali)
>> *收件人： *Greg Mirsky<gregimir...@gmail.com>;draft-hegde-spring-traffic-acc
>> ounting-for-sr-paths> or-sr-pa...@ietf.org>;mpls<m...@ietf.org>;spring<spring@ietf.org>
>> *主题： *Re: [mpls] [spring] Special purpose labels in
>> draft-hegde-spring-traffic-accounting-for-sr-paths
>> *时间： *2017-11-16 02:24:10
>>
>> Hi,
>>
>>
>>
>> This draft breaks the SR architecture. I am quoting a snippet from
>> abstract of SR Architecture document https://tools.ietf.org/html/dr
>> aft-ietf-spring-segment-routing-13, which states:
>>
>> “SR allows to enforce a flow through any topological path while
>> maintaining per-flow state only at the ingress nodes to the SR domain.”
>>
>>
>>
>> In addition to creating states at transit and egress nodes, the procedure
>> also affects the data plane and makes it unscalable. It also makes
>> controller job much harder and error prune. In summary, I find the
>> procedure very complex and unscalable.
>>
>>
>>
>> Thanks
>>
>>
>>
>> Regards … Zafar
>>
>>
>>
>>
>>
>> *From: *spring <spring-boun...@ietf.org> on behalf of Greg Mirsky <
>> gregimir...@gmail.com>
>> *Date: *Wednesday, November 15, 2017 at 11:10 AM
>> *To: *"draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org" <
>> draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>, "
>> m...@ietf.org" <m...@ietf.org>, "spring@ietf.org" <spring@ietf.org>
>> *Subject: *[spring] Special purpose labels in
>> draft-hegde-spring-traffic-accounting-for-sr-paths
>>
>>
>>
>> Hi Shraddha,
>>
>> thank you for very well written and thought through draft. I have these
>> questions I'd like to discuss:
>>
>>- Have you thought of using not one special purpose label for both SR
>>Path Identifier and SR Path Identifier+Source SID cases but request two
>>special purpose labels, one for each case. Then the SR Path Identifier
>>would not have to lose the bit for C flag.
>>- And how you envision to collect the counters along the path? Of
>>course, a Controller may query LSR for all counters or counters for the
>>particular flow (SR Path Identifier+Source SID). But in addition I'd
>>propose to use in-band mechanism, perhaps another special purpose label, 
>> to
>>trigger the LSR to send counters of the same flow with the timestamp
>>out-band to the predefined Collector.
>>- And t

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

2017-11-15 Thread Jeff Tantsura

Robert,

 

HW counters are rather precious resources, but that’s beside the point.

An architecture is not an immutable object, on contrary, a very import property 
of a good architecture is flexibility and agility, ability to adapt when 
business need arises.  

 

Keeping semantics aside – what’s needed, is a metadata (here encoded as a 
label) that uniquely identifies a path, where FIB lookup would yield an 
“counter hit”, potentially counter creation if the packet is the first packet 
in the flow. Value of the label would be hashed in the counter ID that is 
unique and could be resolved by a management layer into accounting record.

 

Cheers,

Jeff

 

From: spring <spring-boun...@ietf.org> on behalf of Robert Raszuk 
<rob...@raszuk.net>
Date: Thursday, November 16, 2017 at 10:26
To: Xuxiaohu <xuxia...@huawei.com>
Cc: Greg Mirsky <gregimir...@gmail.com>, spring <spring@ietf.org>, mpls 
<m...@ietf.org>, "Zafar Ali (zali)" <z...@cisco.com>, 
draft-hegde-spring-traffic-accounting-for-sr-paths 
<draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>
Subject: Re: [spring] [mpls] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

 

The architecture is fine. This is accounting state not forwarding state.

 

But no new labels are needed.

 

See on ingress you apply sr label stack based on some match of the fields of 
actual packet. So all you need is to do accounting on the very same fields of 
the packets on egress and you have path accounting required for you.

 

Besides this method also seamlessly works over non sr capable SFs as long as 
such SFs do not mess with the packet content of those tuples.

 

cheers,

r.

 

On Nov 16, 2017 10:05, "Xuxiaohu" <xuxia...@huawei.com> wrote:

Concur. Although it has some values, it's not cost-efficient from my point of 
view. Network simplicity should be the first priority object. Hence we would 
have to make some compromise.

Best regards,
Xiaohu 



徐小虎 Xuxiaohu
M：+86-13910161692 
E：xuxia...@huawei.com
产品与解决方案-网络战略与业务发展部
Products & Solutions-Network Strategy & Business Development Dept

发件人： Zafar Ali (zali)

收件人： Greg 
Mirsky<gregimir...@gmail.com>;draft-hegde-spring-traffic-accounting-for-sr-paths<draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>;mpls<m...@ietf.org>;spring<spring@ietf.org>

主题： Re: [mpls] [spring] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

时间： 2017-11-16 02:24:10

 

Hi, 

 

This draft breaks the SR architecture. I am quoting a snippet from abstract of 
SR Architecture document 
https://tools.ietf.org/html/draft-ietf-spring-segment-routing-13, which states:

“SR allows to enforce a flow through any topological path while maintaining 
per-flow state only at the ingress nodes to the SR domain.” 

 

In addition to creating states at transit and egress nodes, the procedure also 
affects the data plane and makes it unscalable. It also makes controller job 
much harder and error prune. In summary, I find the procedure very complex and 
unscalable. 

 

Thanks

 

Regards … Zafar 

 

 

From: spring <spring-boun...@ietf.org> on behalf of Greg Mirsky 
<gregimir...@gmail.com>
Date: Wednesday, November 15, 2017 at 11:10 AM
To: "draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org" 
<draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>, "m...@ietf.org" 
<m...@ietf.org>, "spring@ietf.org" <spring@ietf.org>
Subject: [spring] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

 

Hi Shraddha, 

thank you for very well written and thought through draft. I have these 
questions I'd like to discuss:

·  Have you thought of using not one special purpose label for both SR Path 
Identifier and SR Path Identifier+Source SID cases but request two special 
purpose labels, one for each case. Then the SR Path Identifier would not have 
to lose the bit for C flag.

·  And how you envision to collect the counters along the path? Of course, a 
Controller may query LSR for all counters or counters for the particular flow 
(SR Path Identifier+Source SID). But in addition I'd propose to use in-band 
mechanism, perhaps another special purpose label, to trigger the LSR to send 
counters of the same flow with the timestamp out-band to the predefined 
Collector.

·  And the last, have you considered ability to flush counters per flow. In 
Scalability Considerations you've stated that counters are maintained as long 
as collection of statistics is enabled. If that is on the node scope, you may 
have to turn off/on the collection to flush off some old counters. I think that 
finer granularity, per flow granularity would be useful for operators. Again, 
perhaps the flow itself may be used to signal the end of the measurement and 
trigger release of counters.

Regards,

Greg

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

2017-11-15 Thread Robert Raszuk

This discussion is about a form of iOAM in SR-MPLS . To your point where in
mpls architecture in general there is provisioning for iOAM ?

And last time I check mpls is still used here and there ;)

Good news is that SRv6 is natively solving this by keeping the SID stacks
intact to the egress.

thx
r.

On Nov 16, 2017 10:36, "Greg Mirsky" <gregimir...@gmail.com> wrote:

> Dear All,
> I cannot imagine that operators will agree to deploy network that lacks
> critical OAM tools to monitor performance and troubleshoot the network.
> True, some will brave the challenge and be the early adopters but even they
> will likely request that the OAM toolbox be sufficient to support their
> operational needs. I see that this work clearly describes the problem and
> why ability to quantify the flow behavior at internal nodes is important
> for efficient network operation. First let's discuss whether the case and
> requirement towards OAM is real and valid. Then we can continue to
> discussion of what measurement method to use.
>
> Regards,
> Greg
>
> On Thu, Nov 16, 2017 at 10:05 AM, Xuxiaohu <xuxia...@huawei.com> wrote:
>
>> Concur. Although it has some values, it's not cost-efficient from my
>> point of view. Network simplicity should be the first priority object.
>> Hence we would have to make some compromise.
>>
>> Best regards,
>> Xiaohu
>>
>>
>>
>>
>> --
>> 徐小虎 Xuxiaohu
>> M：+86-13910161692
>> E：xuxia...@huawei.com
>> 产品与解决方案-网络战略与业务发展部
>> Products & Solutions-Network Strategy & Business Development Dept
>>
>> *发件人： *Zafar Ali (zali)
>> *收件人： *Greg Mirsky<gregimir...@gmail.com>;draft-hegde-spring-traffic-acc
>> ounting-for-sr-paths> for-sr-pa...@ietf.org>;mpls<m...@ietf.org>;spring<spring@ietf.org>
>> *主题： *Re: [mpls] [spring] Special purpose labels in
>> draft-hegde-spring-traffic-accounting-for-sr-paths
>> *时间： *2017-11-16 02:24:10
>>
>> Hi,
>>
>>
>>
>> This draft breaks the SR architecture. I am quoting a snippet from
>> abstract of SR Architecture document https://tools.ietf.org/html/dr
>> aft-ietf-spring-segment-routing-13, which states:
>>
>> “SR allows to enforce a flow through any topological path while
>> maintaining per-flow state only at the ingress nodes to the SR domain.”
>>
>>
>>
>> In addition to creating states at transit and egress nodes, the procedure
>> also affects the data plane and makes it unscalable. It also makes
>> controller job much harder and error prune. In summary, I find the
>> procedure very complex and unscalable.
>>
>>
>>
>> Thanks
>>
>>
>>
>> Regards … Zafar
>>
>>
>>
>>
>>
>> *From: *spring <spring-boun...@ietf.org> on behalf of Greg Mirsky <
>> gregimir...@gmail.com>
>> *Date: *Wednesday, November 15, 2017 at 11:10 AM
>> *To: *"draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org" <
>> draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>, "
>> m...@ietf.org" <m...@ietf.org>, "spring@ietf.org" <spring@ietf.org>
>> *Subject: *[spring] Special purpose labels in
>> draft-hegde-spring-traffic-accounting-for-sr-paths
>>
>>
>>
>> Hi Shraddha,
>>
>> thank you for very well written and thought through draft. I have these
>> questions I'd like to discuss:
>>
>>- Have you thought of using not one special purpose label for both SR
>>Path Identifier and SR Path Identifier+Source SID cases but request two
>>special purpose labels, one for each case. Then the SR Path Identifier
>>would not have to lose the bit for C flag.
>>- And how you envision to collect the counters along the path? Of
>>course, a Controller may query LSR for all counters or counters for the
>>particular flow (SR Path Identifier+Source SID). But in addition I'd
>>propose to use in-band mechanism, perhaps another special purpose label, 
>> to
>>trigger the LSR to send counters of the same flow with the timestamp
>>out-band to the predefined Collector.
>>- And the last, have you considered ability to flush counters per
>>flow. In Scalability Considerations you've stated that counters are
>>maintained as long as collection of statistics is enabled. If that is on
>>the node scope, you may have to turn off/on the collection to flush off
>>some old counters. I think that finer granularity, per flow granularity
>>would be useful for operators. Again, perhaps the flow itself may be used
>>to signal the end of the measurement and trigger release of counters.
>>
>> Regards,
>>
>> Greg
>>
>
>
> ___
> mpls mailing list
> m...@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>
>
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

2017-11-15 Thread ShaoWen Ma

Hi Robert and all,

  SPRING try to get rid of per flow forwarding status. that's the design
principal for whole network.
  and Shraddha just want to add back per flow Traffic statistics as
request, which will only applied to interested flow.

  if you check the label stack for traffic statistics, that might be get
some processing trouble to handle:
{300|200|100} with another label stack such as {400|300|200|100} on the
same nodes.

  so path id do have it's value if customer want to check specific flow, by
not impact all packet process on the transit router.

Best Regards
Shaowen Ma


On Thu, Nov 16, 2017 at 10:26 AM, Robert Raszuk <rob...@raszuk.net> wrote:

> The architecture is fine. This is accounting state not forwarding state.
>
> But no new labels are needed.
>
> See on ingress you apply sr label stack based on some match of the fields
> of actual packet. So all you need is to do accounting on the very same
> fields of the packets on egress and you have path accounting required for
> you.
>
> Besides this method also seamlessly works over non sr capable SFs as long
> as such SFs do not mess with the packet content of those tuples.
>
> cheers,
> r.
>
> On Nov 16, 2017 10:05, "Xuxiaohu" <xuxia...@huawei.com> wrote:
>
>> Concur. Although it has some values, it's not cost-efficient from my
>> point of view. Network simplicity should be the first priority object.
>> Hence we would have to make some compromise.
>>
>> Best regards,
>> Xiaohu
>>
>>
>>
>>
>> --
>> 徐小虎 Xuxiaohu
>> M：+86-13910161692
>> E：xuxia...@huawei.com
>> 产品与解决方案-网络战略与业务发展部
>> Products & Solutions-Network Strategy & Business Development Dept
>>
>> *发件人： *Zafar Ali (zali)
>> *收件人： *Greg Mirsky<gregimir...@gmail.com>;draft-hegde-spring-traffic-acc
>> ounting-for-sr-paths> for-sr-pa...@ietf.org>;mpls<m...@ietf.org>;spring<spring@ietf.org>
>> *主题： *Re: [mpls] [spring] Special purpose labels in
>> draft-hegde-spring-traffic-accounting-for-sr-paths
>> *时间： *2017-11-16 02:24:10
>>
>> Hi,
>>
>>
>>
>> This draft breaks the SR architecture. I am quoting a snippet from
>> abstract of SR Architecture document https://tools.ietf.org/html/dr
>> aft-ietf-spring-segment-routing-13, which states:
>>
>> “SR allows to enforce a flow through any topological path while
>> maintaining per-flow state only at the ingress nodes to the SR domain.”
>>
>>
>>
>> In addition to creating states at transit and egress nodes, the procedure
>> also affects the data plane and makes it unscalable. It also makes
>> controller job much harder and error prune. In summary, I find the
>> procedure very complex and unscalable.
>>
>>
>>
>> Thanks
>>
>>
>>
>> Regards … Zafar
>>
>>
>>
>>
>>
>> *From: *spring <spring-boun...@ietf.org> on behalf of Greg Mirsky <
>> gregimir...@gmail.com>
>> *Date: *Wednesday, November 15, 2017 at 11:10 AM
>> *To: *"draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org" <
>> draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>, "
>> m...@ietf.org" <m...@ietf.org>, "spring@ietf.org" <spring@ietf.org>
>> *Subject: *[spring] Special purpose labels in
>> draft-hegde-spring-traffic-accounting-for-sr-paths
>>
>>
>>
>> Hi Shraddha,
>>
>> thank you for very well written and thought through draft. I have these
>> questions I'd like to discuss:
>>
>>- Have you thought of using not one special purpose label for both SR
>>Path Identifier and SR Path Identifier+Source SID cases but request two
>>special purpose labels, one for each case. Then the SR Path Identifier
>>would not have to lose the bit for C flag.
>>- And how you envision to collect the counters along the path? Of
>>course, a Controller may query LSR for all counters or counters for the
>>particular flow (SR Path Identifier+Source SID). But in addition I'd
>>propose to use in-band mechanism, perhaps another special purpose label, 
>> to
>>trigger the LSR to send counters of the same flow with the timestamp
>>out-band to the predefined Collector.
>>- And the last, have you considered ability to flush counters per
>>flow. In Scalability Considerations you've stated that counters are
>>maintained as long as collection of statistics is enabled. If that is on
>>the node scope, you may have to turn off/on the collection to flush off
>>some old counters. I think that finer granularity, per flow granularity
>>would be useful for operators. Again, perhaps the flow itself may be used
>>to signal the end of the measurement and trigger release of counters.
>>
>> Regards,
>>
>> Greg
>>
>> ___
>> mpls mailing list
>> m...@ietf.org
>> https://www.ietf.org/mailman/listinfo/mpls
>>
>>
> ___
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>
>
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

2017-11-15 Thread Greg Mirsky

Dear All,
I cannot imagine that operators will agree to deploy network that lacks
critical OAM tools to monitor performance and troubleshoot the network.
True, some will brave the challenge and be the early adopters but even they
will likely request that the OAM toolbox be sufficient to support their
operational needs. I see that this work clearly describes the problem and
why ability to quantify the flow behavior at internal nodes is important
for efficient network operation. First let's discuss whether the case and
requirement towards OAM is real and valid. Then we can continue to
discussion of what measurement method to use.

Regards,
Greg

On Thu, Nov 16, 2017 at 10:05 AM, Xuxiaohu <xuxia...@huawei.com> wrote:

> Concur. Although it has some values, it's not cost-efficient from my point
> of view. Network simplicity should be the first priority object. Hence we
> would have to make some compromise.
>
> Best regards,
> Xiaohu
>
>
>
>
> --
> 徐小虎 Xuxiaohu
> M：+86-13910161692
> E：xuxia...@huawei.com
> 产品与解决方案-网络战略与业务发展部
> Products & Solutions-Network Strategy & Business Development Dept
>
> *发件人： *Zafar Ali (zali)
> *收件人： *Greg Mirsky<gregimir...@gmail.com>;draft-hegde-spring-traffic-
> accounting-for-sr-paths accounting-for-sr-pa...@ietf.org>;mpls<m...@ietf.org>;spring<
> spring@ietf.org>
> *主题： *Re: [mpls] [spring] Special purpose labels in
> draft-hegde-spring-traffic-accounting-for-sr-paths
> *时间： *2017-11-16 02:24:10
>
> Hi,
>
>
>
> This draft breaks the SR architecture. I am quoting a snippet from
> abstract of SR Architecture document https://tools.ietf.org/html/
> draft-ietf-spring-segment-routing-13, which states:
>
> “SR allows to enforce a flow through any topological path while
> maintaining per-flow state only at the ingress nodes to the SR domain.”
>
>
>
> In addition to creating states at transit and egress nodes, the procedure
> also affects the data plane and makes it unscalable. It also makes
> controller job much harder and error prune. In summary, I find the
> procedure very complex and unscalable.
>
>
>
> Thanks
>
>
>
> Regards … Zafar
>
>
>
>
>
> *From: *spring <spring-boun...@ietf.org> on behalf of Greg Mirsky <
> gregimir...@gmail.com>
> *Date: *Wednesday, November 15, 2017 at 11:10 AM
> *To: *"draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org" <
> draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>, "
> m...@ietf.org" <m...@ietf.org>, "spring@ietf.org" <spring@ietf.org>
> *Subject: *[spring] Special purpose labels in draft-hegde-spring-traffic-
> accounting-for-sr-paths
>
>
>
> Hi Shraddha,
>
> thank you for very well written and thought through draft. I have these
> questions I'd like to discuss:
>
>- Have you thought of using not one special purpose label for both SR
>Path Identifier and SR Path Identifier+Source SID cases but request two
>special purpose labels, one for each case. Then the SR Path Identifier
>would not have to lose the bit for C flag.
>- And how you envision to collect the counters along the path? Of
>course, a Controller may query LSR for all counters or counters for the
>particular flow (SR Path Identifier+Source SID). But in addition I'd
>propose to use in-band mechanism, perhaps another special purpose label, to
>trigger the LSR to send counters of the same flow with the timestamp
>out-band to the predefined Collector.
>- And the last, have you considered ability to flush counters per
>flow. In Scalability Considerations you've stated that counters are
>maintained as long as collection of statistics is enabled. If that is on
>the node scope, you may have to turn off/on the collection to flush off
>some old counters. I think that finer granularity, per flow granularity
>would be useful for operators. Again, perhaps the flow itself may be used
>to signal the end of the measurement and trigger release of counters.
>
> Regards,
>
> Greg
>
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

2017-11-15 Thread Greg Mirsky

Hi Robert,
consider number of ACL filters one has to configure just in case the
particular SR flow comes along. Yes, that works but there are other costs
to pay. The proposed approach has some very attractive, IMHO, qualities.

Regards,
Greg

On Thu, Nov 16, 2017 at 10:34 AM, Robert Raszuk <rob...@raszuk.net> wrote:

> Greg,
>
> There is zero labels of any sort in my proposal needed. Just basic netflow.
>
> best
> r.
>
> On Nov 16, 2017 10:31, "Greg Mirsky" <gregimir...@gmail.com> wrote:
>
>> Hi Robert,
>> you proposal is similar to idea of Synonymous Labels
>> <https://tools.ietf.org/html/draft-ietf-mpls-sfl-framework-00>but I'm
>> afraid it will not scale for SR-MPLS as it require that the whole SR MPLS
>> stack must consist of such synonymous labels. And that will create state in
>> the transient nodes in the data plane, IMHO of course.
>>
>> Regards,
>> Greg
>>
>> On Thu, Nov 16, 2017 at 10:26 AM, Robert Raszuk <rob...@raszuk.net>
>> wrote:
>>
>>> The architecture is fine. This is accounting state not forwarding state.
>>>
>>> But no new labels are needed.
>>>
>>> See on ingress you apply sr label stack based on some match of the
>>> fields of actual packet. So all you need is to do accounting on the very
>>> same fields of the packets on egress and you have path accounting required
>>> for you.
>>>
>>> Besides this method also seamlessly works over non sr capable SFs as
>>> long as such SFs do not mess with the packet content of those tuples.
>>>
>>> cheers,
>>> r.
>>>
>>> On Nov 16, 2017 10:05, "Xuxiaohu" <xuxia...@huawei.com> wrote:
>>>
>>>> Concur. Although it has some values, it's not cost-efficient from my
>>>> point of view. Network simplicity should be the first priority object.
>>>> Hence we would have to make some compromise.
>>>>
>>>> Best regards,
>>>> Xiaohu
>>>>
>>>>
>>>>
>>>>
>>>> --------------
>>>> 徐小虎 Xuxiaohu
>>>> M：+86-13910161692
>>>> E：xuxia...@huawei.com
>>>> 产品与解决方案-网络战略与业务发展部
>>>> Products & Solutions-Network Strategy & Business Development Dept
>>>>
>>>> *发件人： *Zafar Ali (zali)
>>>> *收件人： *Greg Mirsky<gregimir...@gmail.com>;
>>>> draft-hegde-spring-traffic-accounting-for-sr-paths>>> de-spring-traffic-accounting-for-sr-pa...@ietf.org>;mpls<m...@ietf.org
>>>> >;spring<spring@ietf.org>
>>>> *主题： *Re: [mpls] [spring] Special purpose labels in
>>>> draft-hegde-spring-traffic-accounting-for-sr-paths
>>>> *时间： *2017-11-16 02:24:10
>>>>
>>>> Hi,
>>>>
>>>>
>>>>
>>>> This draft breaks the SR architecture. I am quoting a snippet from
>>>> abstract of SR Architecture document https://tools.ietf.org/html/dr
>>>> aft-ietf-spring-segment-routing-13, which states:
>>>>
>>>> “SR allows to enforce a flow through any topological path while
>>>> maintaining per-flow state only at the ingress nodes to the SR domain.”
>>>>
>>>>
>>>>
>>>> In addition to creating states at transit and egress nodes, the
>>>> procedure also affects the data plane and makes it unscalable. It also
>>>> makes controller job much harder and error prune. In summary, I find the
>>>> procedure very complex and unscalable.
>>>>
>>>>
>>>>
>>>> Thanks
>>>>
>>>>
>>>>
>>>> Regards … Zafar
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> *From: *spring <spring-boun...@ietf.org> on behalf of Greg Mirsky <
>>>> gregimir...@gmail.com>
>>>> *Date: *Wednesday, November 15, 2017 at 11:10 AM
>>>> *To: *"draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org" <
>>>> draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>, "
>>>> m...@ietf.org" <m...@ietf.org>, "spring@ietf.org" <spring@ietf.org>
>>>> *Subject: *[spring] Special purpose labels in
>>>> draft-hegde-spring-traffic-accounting-for-sr-paths
>>>>
>>>>
>>>>
>>>> Hi Shraddha,
>>>>
>>>> thank you for very well written and thought through draft. I have these
>&

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

2017-11-15 Thread Robert Raszuk

Greg,

There is zero labels of any sort in my proposal needed. Just basic netflow.

best
r.

On Nov 16, 2017 10:31, "Greg Mirsky" <gregimir...@gmail.com> wrote:

> Hi Robert,
> you proposal is similar to idea of Synonymous Labels
> <https://tools.ietf.org/html/draft-ietf-mpls-sfl-framework-00>but I'm
> afraid it will not scale for SR-MPLS as it require that the whole SR MPLS
> stack must consist of such synonymous labels. And that will create state in
> the transient nodes in the data plane, IMHO of course.
>
> Regards,
> Greg
>
> On Thu, Nov 16, 2017 at 10:26 AM, Robert Raszuk <rob...@raszuk.net> wrote:
>
>> The architecture is fine. This is accounting state not forwarding state.
>>
>> But no new labels are needed.
>>
>> See on ingress you apply sr label stack based on some match of the fields
>> of actual packet. So all you need is to do accounting on the very same
>> fields of the packets on egress and you have path accounting required for
>> you.
>>
>> Besides this method also seamlessly works over non sr capable SFs as long
>> as such SFs do not mess with the packet content of those tuples.
>>
>> cheers,
>> r.
>>
>> On Nov 16, 2017 10:05, "Xuxiaohu" <xuxia...@huawei.com> wrote:
>>
>>> Concur. Although it has some values, it's not cost-efficient from my
>>> point of view. Network simplicity should be the first priority object.
>>> Hence we would have to make some compromise.
>>>
>>> Best regards,
>>> Xiaohu
>>>
>>>
>>>
>>>
>>> --
>>> 徐小虎 Xuxiaohu
>>> M：+86-13910161692
>>> E：xuxia...@huawei.com
>>> 产品与解决方案-网络战略与业务发展部
>>> Products & Solutions-Network Strategy & Business Development Dept
>>>
>>> *发件人： *Zafar Ali (zali)
>>> *收件人： *Greg Mirsky<gregimir...@gmail.com>;draft-hegde-spring-traffic-acc
>>> ounting-for-sr-paths>> or-sr-pa...@ietf.org>;mpls<m...@ietf.org>;spring<spring@ietf.org>
>>> *主题： *Re: [mpls] [spring] Special purpose labels in
>>> draft-hegde-spring-traffic-accounting-for-sr-paths
>>> *时间： *2017-11-16 02:24:10
>>>
>>> Hi,
>>>
>>>
>>>
>>> This draft breaks the SR architecture. I am quoting a snippet from
>>> abstract of SR Architecture document https://tools.ietf.org/html/dr
>>> aft-ietf-spring-segment-routing-13, which states:
>>>
>>> “SR allows to enforce a flow through any topological path while
>>> maintaining per-flow state only at the ingress nodes to the SR domain.”
>>>
>>>
>>>
>>> In addition to creating states at transit and egress nodes, the
>>> procedure also affects the data plane and makes it unscalable. It also
>>> makes controller job much harder and error prune. In summary, I find the
>>> procedure very complex and unscalable.
>>>
>>>
>>>
>>> Thanks
>>>
>>>
>>>
>>> Regards … Zafar
>>>
>>>
>>>
>>>
>>>
>>> *From: *spring <spring-boun...@ietf.org> on behalf of Greg Mirsky <
>>> gregimir...@gmail.com>
>>> *Date: *Wednesday, November 15, 2017 at 11:10 AM
>>> *To: *"draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org" <
>>> draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>, "
>>> m...@ietf.org" <m...@ietf.org>, "spring@ietf.org" <spring@ietf.org>
>>> *Subject: *[spring] Special purpose labels in
>>> draft-hegde-spring-traffic-accounting-for-sr-paths
>>>
>>>
>>>
>>> Hi Shraddha,
>>>
>>> thank you for very well written and thought through draft. I have these
>>> questions I'd like to discuss:
>>>
>>>- Have you thought of using not one special purpose label for both
>>>SR Path Identifier and SR Path Identifier+Source SID cases but request 
>>> two
>>>special purpose labels, one for each case. Then the SR Path Identifier
>>>would not have to lose the bit for C flag.
>>>- And how you envision to collect the counters along the path? Of
>>>course, a Controller may query LSR for all counters or counters for the
>>>particular flow (SR Path Identifier+Source SID). But in addition I'd
>>>propose to use in-band mechanism, perhaps another special purpose label, 
>>> to
>>>trigger the LSR to send counters of the same flow with the timestamp
>>>out-band to the predefined Collector.
>>>- And the last, have you considered ability to flush counters per
>>>flow. In Scalability Considerations you've stated that counters are
>>>maintained as long as collection of statistics is enabled. If that is on
>>>the node scope, you may have to turn off/on the collection to flush off
>>>some old counters. I think that finer granularity, per flow granularity
>>>would be useful for operators. Again, perhaps the flow itself may be used
>>>to signal the end of the measurement and trigger release of counters.
>>>
>>> Regards,
>>>
>>> Greg
>>>
>>> ___
>>> mpls mailing list
>>> m...@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mpls
>>>
>>>
>
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

2017-11-15 Thread Greg Mirsky

Hi Robert,
you proposal is similar to idea of Synonymous Labels
<https://tools.ietf.org/html/draft-ietf-mpls-sfl-framework-00>but I'm
afraid it will not scale for SR-MPLS as it require that the whole SR MPLS
stack must consist of such synonymous labels. And that will create state in
the transient nodes in the data plane, IMHO of course.

Regards,
Greg

On Thu, Nov 16, 2017 at 10:26 AM, Robert Raszuk <rob...@raszuk.net> wrote:

> The architecture is fine. This is accounting state not forwarding state.
>
> But no new labels are needed.
>
> See on ingress you apply sr label stack based on some match of the fields
> of actual packet. So all you need is to do accounting on the very same
> fields of the packets on egress and you have path accounting required for
> you.
>
> Besides this method also seamlessly works over non sr capable SFs as long
> as such SFs do not mess with the packet content of those tuples.
>
> cheers,
> r.
>
> On Nov 16, 2017 10:05, "Xuxiaohu" <xuxia...@huawei.com> wrote:
>
>> Concur. Although it has some values, it's not cost-efficient from my
>> point of view. Network simplicity should be the first priority object.
>> Hence we would have to make some compromise.
>>
>> Best regards,
>> Xiaohu
>>
>>
>>
>>
>> --
>> 徐小虎 Xuxiaohu
>> M：+86-13910161692
>> E：xuxia...@huawei.com
>> 产品与解决方案-网络战略与业务发展部
>> Products & Solutions-Network Strategy & Business Development Dept
>>
>> *发件人： *Zafar Ali (zali)
>> *收件人： *Greg Mirsky<gregimir...@gmail.com>;draft-hegde-spring-traffic-acc
>> ounting-for-sr-paths> for-sr-pa...@ietf.org>;mpls<m...@ietf.org>;spring<spring@ietf.org>
>> *主题： *Re: [mpls] [spring] Special purpose labels in
>> draft-hegde-spring-traffic-accounting-for-sr-paths
>> *时间： *2017-11-16 02:24:10
>>
>> Hi,
>>
>>
>>
>> This draft breaks the SR architecture. I am quoting a snippet from
>> abstract of SR Architecture document https://tools.ietf.org/html/dr
>> aft-ietf-spring-segment-routing-13, which states:
>>
>> “SR allows to enforce a flow through any topological path while
>> maintaining per-flow state only at the ingress nodes to the SR domain.”
>>
>>
>>
>> In addition to creating states at transit and egress nodes, the procedure
>> also affects the data plane and makes it unscalable. It also makes
>> controller job much harder and error prune. In summary, I find the
>> procedure very complex and unscalable.
>>
>>
>>
>> Thanks
>>
>>
>>
>> Regards … Zafar
>>
>>
>>
>>
>>
>> *From: *spring <spring-boun...@ietf.org> on behalf of Greg Mirsky <
>> gregimir...@gmail.com>
>> *Date: *Wednesday, November 15, 2017 at 11:10 AM
>> *To: *"draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org" <
>> draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>, "
>> m...@ietf.org" <m...@ietf.org>, "spring@ietf.org" <spring@ietf.org>
>> *Subject: *[spring] Special purpose labels in
>> draft-hegde-spring-traffic-accounting-for-sr-paths
>>
>>
>>
>> Hi Shraddha,
>>
>> thank you for very well written and thought through draft. I have these
>> questions I'd like to discuss:
>>
>>- Have you thought of using not one special purpose label for both SR
>>Path Identifier and SR Path Identifier+Source SID cases but request two
>>special purpose labels, one for each case. Then the SR Path Identifier
>>would not have to lose the bit for C flag.
>>- And how you envision to collect the counters along the path? Of
>>course, a Controller may query LSR for all counters or counters for the
>>particular flow (SR Path Identifier+Source SID). But in addition I'd
>>propose to use in-band mechanism, perhaps another special purpose label, 
>> to
>>trigger the LSR to send counters of the same flow with the timestamp
>>out-band to the predefined Collector.
>>- And the last, have you considered ability to flush counters per
>>flow. In Scalability Considerations you've stated that counters are
>>maintained as long as collection of statistics is enabled. If that is on
>>the node scope, you may have to turn off/on the collection to flush off
>>some old counters. I think that finer granularity, per flow granularity
>>would be useful for operators. Again, perhaps the flow itself may be used
>>to signal the end of the measurement and trigger release of counters.
>>
>> Regards,
>>
>> Greg
>>
>> ___
>> mpls mailing list
>> m...@ietf.org
>> https://www.ietf.org/mailman/listinfo/mpls
>>
>>
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

2017-11-15 Thread Robert Raszuk

The architecture is fine. This is accounting state not forwarding state.

But no new labels are needed.

See on ingress you apply sr label stack based on some match of the fields
of actual packet. So all you need is to do accounting on the very same
fields of the packets on egress and you have path accounting required for
you.

Besides this method also seamlessly works over non sr capable SFs as long
as such SFs do not mess with the packet content of those tuples.

cheers,
r.

On Nov 16, 2017 10:05, "Xuxiaohu" <xuxia...@huawei.com> wrote:

> Concur. Although it has some values, it's not cost-efficient from my point
> of view. Network simplicity should be the first priority object. Hence we
> would have to make some compromise.
>
> Best regards,
> Xiaohu
>
>
>
>
> --
> 徐小虎 Xuxiaohu
> M：+86-13910161692
> E：xuxia...@huawei.com
> 产品与解决方案-网络战略与业务发展部
> Products & Solutions-Network Strategy & Business Development Dept
>
> *发件人： *Zafar Ali (zali)
> *收件人： *Greg Mirsky<gregimir...@gmail.com>;draft-hegde-spring-traffic-
> accounting-for-sr-paths accounting-for-sr-pa...@ietf.org>;mpls<m...@ietf.org>;spring<
> spring@ietf.org>
> *主题： *Re: [mpls] [spring] Special purpose labels in
> draft-hegde-spring-traffic-accounting-for-sr-paths
> *时间： *2017-11-16 02:24:10
>
> Hi,
>
>
>
> This draft breaks the SR architecture. I am quoting a snippet from
> abstract of SR Architecture document https://tools.ietf.org/html/
> draft-ietf-spring-segment-routing-13, which states:
>
> “SR allows to enforce a flow through any topological path while
> maintaining per-flow state only at the ingress nodes to the SR domain.”
>
>
>
> In addition to creating states at transit and egress nodes, the procedure
> also affects the data plane and makes it unscalable. It also makes
> controller job much harder and error prune. In summary, I find the
> procedure very complex and unscalable.
>
>
>
> Thanks
>
>
>
> Regards … Zafar
>
>
>
>
>
> *From: *spring <spring-boun...@ietf.org> on behalf of Greg Mirsky <
> gregimir...@gmail.com>
> *Date: *Wednesday, November 15, 2017 at 11:10 AM
> *To: *"draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org" <
> draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>, "
> m...@ietf.org" <m...@ietf.org>, "spring@ietf.org" <spring@ietf.org>
> *Subject: *[spring] Special purpose labels in draft-hegde-spring-traffic-
> accounting-for-sr-paths
>
>
>
> Hi Shraddha,
>
> thank you for very well written and thought through draft. I have these
> questions I'd like to discuss:
>
>- Have you thought of using not one special purpose label for both SR
>Path Identifier and SR Path Identifier+Source SID cases but request two
>special purpose labels, one for each case. Then the SR Path Identifier
>would not have to lose the bit for C flag.
>- And how you envision to collect the counters along the path? Of
>course, a Controller may query LSR for all counters or counters for the
>particular flow (SR Path Identifier+Source SID). But in addition I'd
>propose to use in-band mechanism, perhaps another special purpose label, to
>trigger the LSR to send counters of the same flow with the timestamp
>out-band to the predefined Collector.
>- And the last, have you considered ability to flush counters per
>flow. In Scalability Considerations you've stated that counters are
>maintained as long as collection of statistics is enabled. If that is on
>the node scope, you may have to turn off/on the collection to flush off
>some old counters. I think that finer granularity, per flow granularity
>would be useful for operators. Again, perhaps the flow itself may be used
>to signal the end of the measurement and trigger release of counters.
>
> Regards,
>
> Greg
>
> ___
> mpls mailing list
> m...@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>
>
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

2017-11-15 Thread Xuxiaohu

Concur. Although it has some values, it's not cost-efficient from my point of 
view. Network simplicity should be the first priority object. Hence we would 
have to make some compromise.

Best regards,
Xiaohu





徐小虎 Xuxiaohu
M：+86-13910161692<tel:+86-13910161692>
E：xuxia...@huawei.com<mailto:xuxia...@huawei.com>
产品与解决方案-网络战略与业务发展部
Products & Solutions-Network Strategy & Business Development Dept

发件人： Zafar Ali (zali)
收件人： Greg 
Mirsky<gregimir...@gmail.com<mailto:gregimir...@gmail.com>>;draft-hegde-spring-traffic-accounting-for-sr-paths<draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org<mailto:draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>>;mpls<m...@ietf.org<mailto:m...@ietf.org>>;spring<spring@ietf.org<mailto:spring@ietf.org>>
主题： Re: [mpls] [spring] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths
时间： 2017-11-16 02:24:10

Hi,

This draft breaks the SR architecture. I am quoting a snippet from abstract of 
SR Architecture document 
https://tools.ietf.org/html/draft-ietf-spring-segment-routing-13, which states:
“SR allows to enforce a flow through any topological path while maintaining 
per-flow state only at the ingress nodes to the SR domain.”

In addition to creating states at transit and egress nodes, the procedure also 
affects the data plane and makes it unscalable. It also makes controller job 
much harder and error prune. In summary, I find the procedure very complex and 
unscalable.

Thanks

Regards … Zafar


From: spring <spring-boun...@ietf.org> on behalf of Greg Mirsky 
<gregimir...@gmail.com>
Date: Wednesday, November 15, 2017 at 11:10 AM
To: "draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org" 
<draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>, "m...@ietf.org" 
<m...@ietf.org>, "spring@ietf.org" <spring@ietf.org>
Subject: [spring] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

Hi Shraddha,
thank you for very well written and thought through draft. I have these 
questions I'd like to discuss:

  *   Have you thought of using not one special purpose label for both SR Path 
Identifier and SR Path Identifier+Source SID cases but request two special 
purpose labels, one for each case. Then the SR Path Identifier would not have 
to lose the bit for C flag.
  *   And how you envision to collect the counters along the path? Of course, a 
Controller may query LSR for all counters or counters for the particular flow 
(SR Path Identifier+Source SID). But in addition I'd propose to use in-band 
mechanism, perhaps another special purpose label, to trigger the LSR to send 
counters of the same flow with the timestamp out-band to the predefined 
Collector.
  *   And the last, have you considered ability to flush counters per flow. In 
Scalability Considerations you've stated that counters are maintained as long 
as collection of statistics is enabled. If that is on the node scope, you may 
have to turn off/on the collection to flush off some old counters. I think that 
finer granularity, per flow granularity would be useful for operators. Again, 
perhaps the flow itself may be used to signal the end of the measurement and 
trigger release of counters.
Regards,
Greg
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

2017-11-15 Thread Stewart Bryant

Zafar

I don’t think you can assert that fails to comply with the SR arch. There is 
nothing they are doing that cannot be captured in Netflix/IPFIX and SR needs to 
work with IPFIX.

Stewart



> On 16 Nov 2017, at 2:23 am, Zafar Ali (zali)  wrote:
> 
> Hi,
>  
> This draft breaks the SR architecture. I am quoting a snippet from abstract 
> of SR Architecture document 
> https://tools.ietf.org/html/draft-ietf-spring-segment-routing-13, which 
> states:
> “SR allows to enforce a flow through any topological path while maintaining 
> per-flow state only at the ingress nodes to the SR domain.”
>  
> In addition to creating states at transit and egress nodes, the procedure 
> also affects the data plane and makes it unscalable. It also makes controller 
> job much harder and error prune. In summary, I find the procedure very 
> complex and unscalable.
>  
> Thanks
>  
> Regards … Zafar
>  
>  
> From: spring  on behalf of Greg Mirsky 
> 
> Date: Wednesday, November 15, 2017 at 11:10 AM
> To: "draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org" 
> , 
> "m...@ietf.org" , "spring@ietf.org" 
> Subject: [spring] Special purpose labels in 
> draft-hegde-spring-traffic-accounting-for-sr-paths
>  
> Hi Shraddha,
> thank you for very well written and thought through draft. I have these 
> questions I'd like to discuss:
> Have you thought of using not one special purpose label for both SR Path 
> Identifier and SR Path Identifier+Source SID cases but request two special 
> purpose labels, one for each case. Then the SR Path Identifier would not have 
> to lose the bit for C flag.
> And how you envision to collect the counters along the path? Of course, a 
> Controller may query LSR for all counters or counters for the particular flow 
> (SR Path Identifier+Source SID). But in addition I'd propose to use in-band 
> mechanism, perhaps another special purpose label, to trigger the LSR to send 
> counters of the same flow with the timestamp out-band to the predefined 
> Collector.
> And the last, have you considered ability to flush counters per flow. In 
> Scalability Considerations you've stated that counters are maintained as long 
> as collection of statistics is enabled. If that is on the node scope, you may 
> have to turn off/on the collection to flush off some old counters. I think 
> that finer granularity, per flow granularity would be useful for operators. 
> Again, perhaps the flow itself may be used to signal the end of the 
> measurement and trigger release of counters.
> Regards,
> Greg
> ___
> mpls mailing list
> m...@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

72 matches

Mail list logo