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

[David Allan I]

You’re right, my issue was the semantics of the GAL being that of a termination 
and not a shim…. Would be strange to change that such that the stack could 
continue after it.

Dave


From: John E Drake [mailto:jdr...@juniper.net]
Sent: Friday, November 17, 2017 12:02 PM
To: David Allan I <david.i.al...@ericsson.com>; Ext - ruediger.g...@telekom.de 
<ruediger.g...@telekom.de>; adr...@olddog.co.uk
Cc: draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org; 
spring@ietf.org; z...@cisco.com; rob...@raszuk.net; m...@ietf.org
Subject: RE: [spring] [mpls] redux: Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

Dave,

I think the EoS bit is set in the GAL.  I.e., there would be a small fixed size 
identifier between the stack and the payload.  As I indicated it’s just a 
suggestion.

Yours Irrespectively,

John

From: David Allan I [mailto:david.i.al...@ericsson.com]
Sent: Thursday, November 16, 2017 10:26 PM
To: John E Drake <jdr...@juniper.net<mailto:jdr...@juniper.net>>; Ext - 
ruediger.g...@telekom.de<mailto:ruediger.g...@telekom.de> 
<ruediger.g...@telekom.de<mailto:ruediger.g...@telekom.de>>; 
adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>
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>; 
z...@cisco.com<mailto:z...@cisco.com>; 
rob...@raszuk.net<mailto:rob...@raszuk.net>; m...@ietf.org<mailto:m...@ietf.org>
Subject: RE: [spring] [mpls] redux: Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

Would not the concept of

(EOS set)

Get a bit strange?  We are simply swapping one reserved label for another…

Dave

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of John E Drake
Sent: Thursday, November 16, 2017 8:00 PM
To: Ext - ruediger.g...@telekom.de<mailto:ruediger.g...@telekom.de> 
<ruediger.g...@telekom.de<mailto:ruediger.g...@telekom.de>>; 
adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>
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>; 
z...@cisco.com<mailto:z...@cisco.com>; 
rob...@raszuk.net<mailto:rob...@raszuk.net>; m...@ietf.org<mailto:m...@ietf.org>
Subject: Re: [spring] [mpls] redux: Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

Ruediger,

There is also the possibility of using a GAL w/ a new fixed size GACH 
containing the SR Segment List Id.  This is similar to Robert’s suggestion of 
using a VXLAN header.

Yours Irrespectively,

John

From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of 
ruediger.g...@telekom.de<mailto:ruediger.g...@telekom.de>
Sent: Thursday, November 16, 2017 4:44 AM
To: adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>
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>; 
rob...@raszuk.net<mailto:rob...@raszuk.net>; 
m...@ietf.org<mailto:m...@ietf.org>; z...@cisco.com<mailto:z...@cisco.com>
Subject: Re: [mpls] [spring] redux: Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

Adrian,

to me, there’s no ideal solution. But an analysis may help to find a useful 
solution. There’s a need to collect traffic statistics also for packets which 
don’t follow the shortest end to end path. There’s no simple howto, I think.

For the time being, I’d prefer not to add special labels to the stack. What 
other options are there?

  *   Accounting at the router pushing a relevant label stack only.
  *   Accounting of an n-label stack.
  *   Acoounting of a subset of labels only (e.g. Node-SID Labels and 
Anycast-SID, but not ADJ-SID). The idea is a compromise to limit the number of 
counters be maintained. Consider accounting of the top 2 labels carrying global 
routing information.
  *   A special label. Shradda proposes to put such a label into the stack. The 
labels present there prior to the addition are maintained. One might think 
about a single top label which identifies and replaces the label stack carrying 
routing information relevant for the path. That would simplify accounting, but 
it requires suitable IGP functionality.

None of the options sounds simple. Are there more (and simpler) ones I didn’t 
come upon?

Regards, Ruediger

Von: spring [mailto:spring-boun...@ietf.org] Im Auftrag von Adrian Farrel
Gesendet: Donnerstag, 16. November 2017 06:35
An: 'Mach Chen' <mach.c...@huawei.com<mailto:mach.c...@huawei.com>>; 'Jeff 
Tantsura' <jefftant.i...@gmail.com<mailto:jefftant.i...@gmail.com>>; 'Robert 
Raszuk' <rob...@raszuk.net<mailto:rob...@raszuk.net>>
Cc: 'draft-hegde-sp

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

[John E Drake]

Dave,

I think the EoS bit is set in the GAL.  I.e., there would be a small fixed size 
identifier between the stack and the payload.  As I indicated it’s just a 
suggestion.

Yours Irrespectively,

John

From: David Allan I [mailto:david.i.al...@ericsson.com]
Sent: Thursday, November 16, 2017 10:26 PM
To: John E Drake <jdr...@juniper.net>; Ext - ruediger.g...@telekom.de 
<ruediger.g...@telekom.de>; adr...@olddog.co.uk
Cc: draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org; 
spring@ietf.org; z...@cisco.com; rob...@raszuk.net; m...@ietf.org
Subject: RE: [spring] [mpls] redux: Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

Would not the concept of

(EOS set)

Get a bit strange?  We are simply swapping one reserved label for another…

Dave

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of John E Drake
Sent: Thursday, November 16, 2017 8:00 PM
To: Ext - ruediger.g...@telekom.de<mailto:ruediger.g...@telekom.de> 
<ruediger.g...@telekom.de<mailto:ruediger.g...@telekom.de>>; 
adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>
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>; 
z...@cisco.com<mailto:z...@cisco.com>; 
rob...@raszuk.net<mailto:rob...@raszuk.net>; m...@ietf.org<mailto:m...@ietf.org>
Subject: Re: [spring] [mpls] redux: Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

Ruediger,

There is also the possibility of using a GAL w/ a new fixed size GACH 
containing the SR Segment List Id.  This is similar to Robert’s suggestion of 
using a VXLAN header.

Yours Irrespectively,

John

From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of 
ruediger.g...@telekom.de<mailto:ruediger.g...@telekom.de>
Sent: Thursday, November 16, 2017 4:44 AM
To: adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>
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>; 
rob...@raszuk.net<mailto:rob...@raszuk.net>; 
m...@ietf.org<mailto:m...@ietf.org>; z...@cisco.com<mailto:z...@cisco.com>
Subject: Re: [mpls] [spring] redux: Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

Adrian,

to me, there’s no ideal solution. But an analysis may help to find a useful 
solution. There’s a need to collect traffic statistics also for packets which 
don’t follow the shortest end to end path. There’s no simple howto, I think.

For the time being, I’d prefer not to add special labels to the stack. What 
other options are there?
-Accounting at the router pushing a relevant label stack only.
-Accounting of an n-label stack.
-Acoounting of a subset of labels only (e.g. Node-SID Labels and 
Anycast-SID, but not ADJ-SID). The idea is a compromise to limit the number of 
counters be maintained. Consider accounting of the top 2 labels carrying global 
routing information.
-A special label. Shradda proposes to put such a label into the stack. 
The labels present there prior to the addition are maintained. One might think 
about a single top label which identifies and replaces the label stack carrying 
routing information relevant for the path. That would simplify accounting, but 
it requires suitable IGP functionality.

None of the options sounds simple. Are there more (and simpler) ones I didn’t 
come upon?

Regards, Ruediger

Von: spring [mailto:spring-boun...@ietf.org] Im Auftrag von Adrian Farrel
Gesendet: Donnerstag, 16. November 2017 06:35
An: 'Mach Chen' <mach.c...@huawei.com<mailto:mach.c...@huawei.com>>; 'Jeff 
Tantsura' <jefftant.i...@gmail.com<mailto:jefftant.i...@gmail.com>>; 'Robert 
Raszuk' <rob...@raszuk.net<mailto:rob...@raszuk.net>>
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>>
Betreff: Re: [spring] [mpls] redux: Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

Let's unpick a couple of things...

1. This work is not talking about per-flow accounting, it is talking about peer 
SR-path accounting
2. ipfix on its own does not cut it because you still have to put a marker in 
the packets
3. Yes, SR assumes there is no (i.e. zero) state per SR-path in the network
But this third point causes a tension: we want to use SR because it is good, 
but we want to do transit node diagnostics because (frankly) they are necessary.
To get the full picture of why they ar

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

[David Allan I]

Would not the concept of

(EOS set)

Get a bit strange?  We are simply swapping one reserved label for another…

Dave

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of John E Drake
Sent: Thursday, November 16, 2017 8:00 PM
To: Ext - ruediger.g...@telekom.de <ruediger.g...@telekom.de>; 
adr...@olddog.co.uk
Cc: draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org; 
spring@ietf.org; z...@cisco.com; rob...@raszuk.net; m...@ietf.org
Subject: Re: [spring] [mpls] redux: Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

Ruediger,

There is also the possibility of using a GAL w/ a new fixed size GACH 
containing the SR Segment List Id.  This is similar to Robert’s suggestion of 
using a VXLAN header.

Yours Irrespectively,

John

From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of 
ruediger.g...@telekom.de<mailto:ruediger.g...@telekom.de>
Sent: Thursday, November 16, 2017 4:44 AM
To: adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>
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>; 
rob...@raszuk.net<mailto:rob...@raszuk.net>; 
m...@ietf.org<mailto:m...@ietf.org>; z...@cisco.com<mailto:z...@cisco.com>
Subject: Re: [mpls] [spring] redux: Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

Adrian,

to me, there’s no ideal solution. But an analysis may help to find a useful 
solution. There’s a need to collect traffic statistics also for packets which 
don’t follow the shortest end to end path. There’s no simple howto, I think.

For the time being, I’d prefer not to add special labels to the stack. What 
other options are there?

  *   Accounting at the router pushing a relevant label stack only.
  *   Accounting of an n-label stack.
  *   Acoounting of a subset of labels only (e.g. Node-SID Labels and 
Anycast-SID, but not ADJ-SID). The idea is a compromise to limit the number of 
counters be maintained. Consider accounting of the top 2 labels carrying global 
routing information.
  *   A special label. Shradda proposes to put such a label into the stack. The 
labels present there prior to the addition are maintained. One might think 
about a single top label which identifies and replaces the label stack carrying 
routing information relevant for the path. That would simplify accounting, but 
it requires suitable IGP functionality.

None of the options sounds simple. Are there more (and simpler) ones I didn’t 
come upon?

Regards, Ruediger

Von: spring [mailto:spring-boun...@ietf.org] Im Auftrag von Adrian Farrel
Gesendet: Donnerstag, 16. November 2017 06:35
An: 'Mach Chen' <mach.c...@huawei.com<mailto:mach.c...@huawei.com>>; 'Jeff 
Tantsura' <jefftant.i...@gmail.com<mailto:jefftant.i...@gmail.com>>; 'Robert 
Raszuk' <rob...@raszuk.net<mailto:rob...@raszuk.net>>
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>>
Betreff: Re: [spring] [mpls] redux: Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

Let's unpick a couple of things...

1. This work is not talking about per-flow accounting, it is talking about peer 
SR-path accounting
2. ipfix on its own does not cut it because you still have to put a marker in 
the packets
3. Yes, SR assumes there is no (i.e. zero) state per SR-path in the network
But this third point causes a tension: we want to use SR because it is good, 
but we want to do transit node diagnostics because (frankly) they are necessary.
To get the full picture of why they are necessary read the draft, or consider 
ECMP.

This discussion will not be unfamiliar to those who tried to debug LDP networks.

Adrian

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

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

[Dongjie (Jimmy)]

Hi Robert,

When you say “no marker of any sort is needed”,  I think actually you mean to 
use the markers in another layer, e.g. the IP layer.

In a layered network, IMO each layer (Ethernet, MPLS, IP, etc.) needs its own 
OAM mechanisms. For example, we cannot use Ethernet OAM to replace IP OAM☺

Best regards,
Jie

From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of Robert Raszuk
Sent: Thursday, November 16, 2017 3:08 PM
To: Adrian Farrel
Cc: draft-hegde-spring-traffic-accounting-for-sr-paths; spring; mpls; Zafar Ali 
(zali)
Subject: Re: [mpls] [spring] redux: Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

Adrian

I do not agree with with #2 .. no marker of any sort is needed.

And debugging LDP networks is no different then debugging IP networks so sure 
some who are used to ATM/Frame Relay find it very hard to troubleshoot.

Best
r.


On Nov 16, 2017 13:35, "Adrian Farrel" 
<adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>> wrote:
Let's unpick a couple of things...

1. This work is not talking about per-flow accounting, it is talking about peer 
SR-path accounting
2. ipfix on its own does not cut it because you still have to put a marker in 
the packets
3. Yes, SR assumes there is no (i.e. zero) state per SR-path in the network
But this third point causes a tension: we want to use SR because it is good, 
but we want to do transit node diagnostics because (frankly) they are necessary.
To get the full picture of why they are necessary read the draft, or consider 
ECMP.

This discussion will not be unfamiliar to those who tried to debug LDP networks.

Adrian


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

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

[Greg Mirsky]

Hi John,
if network doesn't use payload information to handle ECMP then performance
measurement using RFC 8169-style or pure active OAM based on RFC 6374 will
certainly work. But if it is DPI-based hashing for ECMP, then there cannot
be guarantee that packets with GAL/G-ACh follow the same path as regular
packets. Of course, one can use GAL/G-ACh encapsulation as a tunnel, as
normal case and then do any sort of measurements.

Regards,
Greg

On Thu, Nov 16, 2017 at 7:59 PM, John E Drake <jdr...@juniper.net> wrote:

> Ruediger,
>
>
>
> There is also the possibility of using a GAL w/ a new fixed size GACH
> containing the SR Segment List Id.  This is similar to Robert’s suggestion
> of using a VXLAN header.
>
>
>
> Yours Irrespectively,
>
>
>
> John
>
>
>
> *From:* mpls [mailto:mpls-boun...@ietf.org] *On Behalf Of *
> ruediger.g...@telekom.de
> *Sent:* Thursday, November 16, 2017 4:44 AM
> *To:* adr...@olddog.co.uk
> *Cc:* draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org;
> spring@ietf.org; rob...@raszuk.net; m...@ietf.org; z...@cisco.com
> *Subject:* Re: [mpls] [spring] redux: Special purpose labels in
> draft-hegde-spring-traffic-accounting-for-sr-paths
>
>
>
> Adrian,
>
>
>
> to me, there’s no ideal solution. But an analysis may help to find a
> useful solution. There’s a need to collect traffic statistics also for
> packets which don’t follow the shortest end to end path. There’s no simple
> howto, I think.
>
>
>
> For the time being, I’d prefer not to add special labels to the stack.
> What other options are there?
>
> -Accounting at the router pushing a relevant label stack only.
>
> -Accounting of an n-label stack.
>
> -Acoounting of a subset of labels only (e.g. Node-SID Labels and
> Anycast-SID, but not ADJ-SID). The idea is a compromise to limit the number
> of counters be maintained. Consider accounting of the top 2 labels carrying
> global routing information.
>
> -A special label. Shradda proposes to put such a label into the
> stack. The labels present there prior to the addition are maintained. One
> might think about a single top label which identifies and replaces the
> label stack carrying routing information relevant for the path. That would
> simplify accounting, but it requires suitable IGP functionality.
>
>
>
> None of the options sounds simple. Are there more (and simpler) ones I
> didn’t come upon?
>
>
>
> Regards, Ruediger
>
>
>
> *Von:* spring [mailto:spring-boun...@ietf.org <spring-boun...@ietf.org>] *Im
> Auftrag von *Adrian Farrel
> *Gesendet:* Donnerstag, 16. November 2017 06:35
> *An:* 'Mach Chen' <mach.c...@huawei.com>; '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>
> *Betreff:* Re: [spring] [mpls] redux: Special purpose labels in
> draft-hegde-spring-traffic-accounting-for-sr-paths
>
>
>
> Let's unpick a couple of things...
>
>
>
> 1. This work is not talking about per-flow accounting, it is talking about
> peer SR-path accounting
>
> 2. ipfix on its own does not cut it because you still have to put a marker
> in the packets
>
> 3. Yes, SR assumes there is no (i.e. zero) state per SR-path in the network
>
> But this third point causes a tension: we want to use SR because it is
> good, but we want to do transit node diagnostics because (frankly) they are
> necessary.
>
> To get the full picture of why they are necessary read the draft, or
> consider ECMP.
>
>
>
> This discussion will not be unfamiliar to those who tried to debug LDP
> networks.
>
>
>
> Adrian
>
>
>
> ___
> 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] redux: Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

[John E Drake]

Sasha,

That’s a very good point.  Including the SR Segment List Ids could have the 
effect of disturbing the traffic flows away from the link in question.

Yours Irrespectively,

John

From: Alexander Vainshtein [mailto:alexander.vainsht...@ecitele.com]
Sent: Thursday, November 16, 2017 7:28 AM
To: John E Drake <jdr...@juniper.net>
Cc: draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org; 
spring@ietf.org; z...@cisco.com; rob...@raszuk.net; m...@ietf.org; Ext - 
ruediger.g...@telekom.de <ruediger.g...@telekom.de>; adr...@olddog.co.uk; 
Michael Gorokhovsky <michael.gorokhov...@ecitele.com>
Subject: RE: [spring] [mpls] redux: Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

John,
Looks like a very interesting proposal.
Please note that GAL and GACH would not (hopefully) affect ECMP (if it is used 
on the label stack hashing) while the proposal in draft-hegde by and of itself 
does not guarantee that: the reserved label would be skipped, but the ID 
“labels” could be taken for real labels by the hashing function...

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 John E Drake
Sent: Thursday, November 16, 2017 2:00 PM
To: Ext - ruediger.g...@telekom.de<mailto:ruediger.g...@telekom.de> 
<ruediger.g...@telekom.de<mailto:ruediger.g...@telekom.de>>; 
adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>
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>; 
z...@cisco.com<mailto:z...@cisco.com>; 
rob...@raszuk.net<mailto:rob...@raszuk.net>; m...@ietf.org<mailto:m...@ietf.org>
Subject: Re: [spring] [mpls] redux: Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

Ruediger,

There is also the possibility of using a GAL w/ a new fixed size GACH 
containing the SR Segment List Id.  This is similar to Robert’s suggestion of 
using a VXLAN header.

Yours Irrespectively,

John

From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of 
ruediger.g...@telekom.de<mailto:ruediger.g...@telekom.de>
Sent: Thursday, November 16, 2017 4:44 AM
To: adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>
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>; 
rob...@raszuk.net<mailto:rob...@raszuk.net>; 
m...@ietf.org<mailto:m...@ietf.org>; z...@cisco.com<mailto:z...@cisco.com>
Subject: Re: [mpls] [spring] redux: Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

Adrian,

to me, there’s no ideal solution. But an analysis may help to find a useful 
solution. There’s a need to collect traffic statistics also for packets which 
don’t follow the shortest end to end path. There’s no simple howto, I think.

For the time being, I’d prefer not to add special labels to the stack. What 
other options are there?
-Accounting at the router pushing a relevant label stack only.
-Accounting of an n-label stack.
-Acoounting of a subset of labels only (e.g. Node-SID Labels and 
Anycast-SID, but not ADJ-SID). The idea is a compromise to limit the number of 
counters be maintained. Consider accounting of the top 2 labels carrying global 
routing information.
-A special label. Shradda proposes to put such a label into the stack. 
The labels present there prior to the addition are maintained. One might think 
about a single top label which identifies and replaces the label stack carrying 
routing information relevant for the path. That would simplify accounting, but 
it requires suitable IGP functionality.

None of the options sounds simple. Are there more (and simpler) ones I didn’t 
come upon?

Regards, Ruediger

Von: spring [mailto:spring-boun...@ietf.org] Im Auftrag von Adrian Farrel
Gesendet: Donnerstag, 16. November 2017 06:35
An: 'Mach Chen' <mach.c...@huawei.com<mailto:mach.c...@huawei.com>>; 'Jeff 
Tantsura' <jefftant.i...@gmail.com<mailto:jefftant.i...@gmail.com>>; 'Robert 
Raszuk' <rob...@raszuk.net<mailto:rob...@raszuk.net>>
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>>
Betreff: Re: [spring] [mpls] redux: Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

Let's unpick a couple of things...

1. This work is not ta

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

[Ruediger.Geib]

John,

that’s not what I’m looking for. What I’m looking for is traffic statistics 
collected at transit nodes. These statistics should reveal the true end-to-end 
traffic demand within the MPLS domain. The collection of statistics shouldn’t 
add complexity. A low number of counters helps to simplify collection and 
post-processing.

If I’m not entirely wrong, this discussion at least partially discusses 
different ways how to define what kind of flow to account and where and how to 
capture related statistics. In that case I prefer a collection of a broader set 
of requirements and possible solutions. If our ongoing discussion doesn’t 
identify a set of useful options (I’m not sure whether all contributors to the 
discussion require the same here), a draft collecting different requirements 
and solutions may be helpful.

Regards,

Ruediger

Von: John E Drake [mailto:jdr...@juniper.net]
Gesendet: Donnerstag, 16. November 2017 13:00
An: Geib, Rüdiger <ruediger.g...@telekom.de>; adr...@olddog.co.uk
Cc: draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org; 
spring@ietf.org; rob...@raszuk.net; m...@ietf.org; z...@cisco.com
Betreff: RE: [mpls] [spring] redux: Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

Ruediger,

There is also the possibility of using a GAL w/ a new fixed size GACH 
containing the SR Segment List Id.  This is similar to Robert’s suggestion of 
using a VXLAN header.

Yours Irrespectively,

John

From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of 
ruediger.g...@telekom.de<mailto:ruediger.g...@telekom.de>
Sent: Thursday, November 16, 2017 4:44 AM
To: adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>
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>; 
rob...@raszuk.net<mailto:rob...@raszuk.net>; 
m...@ietf.org<mailto:m...@ietf.org>; z...@cisco.com<mailto:z...@cisco.com>
Subject: Re: [mpls] [spring] redux: Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

Adrian,

to me, there’s no ideal solution. But an analysis may help to find a useful 
solution. There’s a need to collect traffic statistics also for packets which 
don’t follow the shortest end to end path. There’s no simple howto, I think.

For the time being, I’d prefer not to add special labels to the stack. What 
other options are there?

  *   Accounting at the router pushing a relevant label stack only.
  *   Accounting of an n-label stack.
  *   Acoounting of a subset of labels only (e.g. Node-SID Labels and 
Anycast-SID, but not ADJ-SID). The idea is a compromise to limit the number of 
counters be maintained. Consider accounting of the top 2 labels carrying global 
routing information.
  *   A special label. Shradda proposes to put such a label into the stack. The 
labels present there prior to the addition are maintained. One might think 
about a single top label which identifies and replaces the label stack carrying 
routing information relevant for the path. That would simplify accounting, but 
it requires suitable IGP functionality.

None of the options sounds simple. Are there more (and simpler) ones I didn’t 
come upon?

Regards, Ruediger

Von: spring [mailto:spring-boun...@ietf.org] Im Auftrag von Adrian Farrel
Gesendet: Donnerstag, 16. November 2017 06:35
An: 'Mach Chen' <mach.c...@huawei.com<mailto:mach.c...@huawei.com>>; 'Jeff 
Tantsura' <jefftant.i...@gmail.com<mailto:jefftant.i...@gmail.com>>; 'Robert 
Raszuk' <rob...@raszuk.net<mailto:rob...@raszuk.net>>
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>>
Betreff: Re: [spring] [mpls] redux: Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

Let's unpick a couple of things...

1. This work is not talking about per-flow accounting, it is talking about peer 
SR-path accounting
2. ipfix on its own does not cut it because you still have to put a marker in 
the packets
3. Yes, SR assumes there is no (i.e. zero) state per SR-path in the network
But this third point causes a tension: we want to use SR because it is good, 
but we want to do transit node diagnostics because (frankly) they are necessary.
To get the full picture of why they are necessary read the draft, or consider 
ECMP.

This discussion will not be unfamiliar to those who tried to debug LDP networks.

Adrian

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

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

[Alexander Vainshtein]

John,
Looks like a very interesting proposal.
Please note that GAL and GACH would not (hopefully) affect ECMP (if it is used 
on the label stack hashing) while the proposal in draft-hegde by and of itself 
does not guarantee that: the reserved label would be skipped, but the ID 
“labels” could be taken for real labels by the hashing function...

Regards,
Sasha

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

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of John E Drake
Sent: Thursday, November 16, 2017 2:00 PM
To: Ext - ruediger.g...@telekom.de <ruediger.g...@telekom.de>; 
adr...@olddog.co.uk
Cc: draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org; 
spring@ietf.org; z...@cisco.com; rob...@raszuk.net; m...@ietf.org
Subject: Re: [spring] [mpls] redux: Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

Ruediger,

There is also the possibility of using a GAL w/ a new fixed size GACH 
containing the SR Segment List Id.  This is similar to Robert’s suggestion of 
using a VXLAN header.

Yours Irrespectively,

John

From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of 
ruediger.g...@telekom.de<mailto:ruediger.g...@telekom.de>
Sent: Thursday, November 16, 2017 4:44 AM
To: adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>
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>; 
rob...@raszuk.net<mailto:rob...@raszuk.net>; 
m...@ietf.org<mailto:m...@ietf.org>; z...@cisco.com<mailto:z...@cisco.com>
Subject: Re: [mpls] [spring] redux: Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

Adrian,

to me, there’s no ideal solution. But an analysis may help to find a useful 
solution. There’s a need to collect traffic statistics also for packets which 
don’t follow the shortest end to end path. There’s no simple howto, I think.

For the time being, I’d prefer not to add special labels to the stack. What 
other options are there?
-  Accounting at the router pushing a relevant label stack only.
-  Accounting of an n-label stack.
-  Acoounting of a subset of labels only (e.g. Node-SID Labels and 
Anycast-SID, but not ADJ-SID). The idea is a compromise to limit the number of 
counters be maintained. Consider accounting of the top 2 labels carrying global 
routing information.
-  A special label. Shradda proposes to put such a label into the 
stack. The labels present there prior to the addition are maintained. One might 
think about a single top label which identifies and replaces the label stack 
carrying routing information relevant for the path. That would simplify 
accounting, but it requires suitable IGP functionality.

None of the options sounds simple. Are there more (and simpler) ones I didn’t 
come upon?

Regards, Ruediger

Von: spring [mailto:spring-boun...@ietf.org] Im Auftrag von Adrian Farrel
Gesendet: Donnerstag, 16. November 2017 06:35
An: 'Mach Chen' <mach.c...@huawei.com<mailto:mach.c...@huawei.com>>; 'Jeff 
Tantsura' <jefftant.i...@gmail.com<mailto:jefftant.i...@gmail.com>>; 'Robert 
Raszuk' <rob...@raszuk.net<mailto:rob...@raszuk.net>>
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>>
Betreff: Re: [spring] [mpls] redux: Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

Let's unpick a couple of things...

1. This work is not talking about per-flow accounting, it is talking about peer 
SR-path accounting
2. ipfix on its own does not cut it because you still have to put a marker in 
the packets
3. Yes, SR assumes there is no (i.e. zero) state per SR-path in the network
But this third point causes a tension: we want to use SR because it is good, 
but we want to do transit node diagnostics because (frankly) they are necessary.
To get the full picture of why they are necessary read the draft, or consider 
ECMP.

This discussion will not be unfamiliar to those who tried to debug LDP networks.

Adrian


___

This e-mail message is intended for the recipient only and contains information 
which is 
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received 
this 
transmission in error, please inform us by e-mail, phone or fax, and then 
delete the original 
and all copies thereof.
___
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[John E Drake]

Ruediger,

There is also the possibility of using a GAL w/ a new fixed size GACH 
containing the SR Segment List Id.  This is similar to Robert’s suggestion of 
using a VXLAN header.

Yours Irrespectively,

John

From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of ruediger.g...@telekom.de
Sent: Thursday, November 16, 2017 4:44 AM
To: adr...@olddog.co.uk
Cc: draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org; 
spring@ietf.org; rob...@raszuk.net; m...@ietf.org; z...@cisco.com
Subject: Re: [mpls] [spring] redux: Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

Adrian,

to me, there’s no ideal solution. But an analysis may help to find a useful 
solution. There’s a need to collect traffic statistics also for packets which 
don’t follow the shortest end to end path. There’s no simple howto, I think.

For the time being, I’d prefer not to add special labels to the stack. What 
other options are there?
-Accounting at the router pushing a relevant label stack only.
-Accounting of an n-label stack.
-Acoounting of a subset of labels only (e.g. Node-SID Labels and 
Anycast-SID, but not ADJ-SID). The idea is a compromise to limit the number of 
counters be maintained. Consider accounting of the top 2 labels carrying global 
routing information.
-A special label. Shradda proposes to put such a label into the stack. 
The labels present there prior to the addition are maintained. One might think 
about a single top label which identifies and replaces the label stack carrying 
routing information relevant for the path. That would simplify accounting, but 
it requires suitable IGP functionality.

None of the options sounds simple. Are there more (and simpler) ones I didn’t 
come upon?

Regards, Ruediger

Von: spring [mailto:spring-boun...@ietf.org] Im Auftrag von Adrian Farrel
Gesendet: Donnerstag, 16. November 2017 06:35
An: 'Mach Chen' <mach.c...@huawei.com<mailto:mach.c...@huawei.com>>; 'Jeff 
Tantsura' <jefftant.i...@gmail.com<mailto:jefftant.i...@gmail.com>>; 'Robert 
Raszuk' <rob...@raszuk.net<mailto:rob...@raszuk.net>>
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>>
Betreff: Re: [spring] [mpls] redux: Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

Let's unpick a couple of things...

1. This work is not talking about per-flow accounting, it is talking about peer 
SR-path accounting
2. ipfix on its own does not cut it because you still have to put a marker in 
the packets
3. Yes, SR assumes there is no (i.e. zero) state per SR-path in the network
But this third point causes a tension: we want to use SR because it is good, 
but we want to do transit node diagnostics because (frankly) they are necessary.
To get the full picture of why they are necessary read the draft, or consider 
ECMP.

This discussion will not be unfamiliar to those who tried to debug LDP networks.

Adrian

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

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

[Ruediger.Geib]

Adrian,

to me, there’s no ideal solution. But an analysis may help to find a useful 
solution. There’s a need to collect traffic statistics also for packets which 
don’t follow the shortest end to end path. There’s no simple howto, I think.

For the time being, I’d prefer not to add special labels to the stack. What 
other options are there?

  *   Accounting at the router pushing a relevant label stack only.
  *   Accounting of an n-label stack.
  *   Acoounting of a subset of labels only (e.g. Node-SID Labels and 
Anycast-SID, but not ADJ-SID). The idea is a compromise to limit the number of 
counters be maintained. Consider accounting of the top 2 labels carrying global 
routing information.
  *   A special label. Shradda proposes to put such a label into the stack. The 
labels present there prior to the addition are maintained. One might think 
about a single top label which identifies and replaces the label stack carrying 
routing information relevant for the path. That would simplify accounting, but 
it requires suitable IGP functionality.

None of the options sounds simple. Are there more (and simpler) ones I didn’t 
come upon?

Regards, Ruediger

Von: spring [mailto:spring-boun...@ietf.org] Im Auftrag von Adrian Farrel
Gesendet: Donnerstag, 16. November 2017 06:35
An: 'Mach Chen' <mach.c...@huawei.com>; '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>
Betreff: Re: [spring] [mpls] redux: Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths

Let's unpick a couple of things...

1. This work is not talking about per-flow accounting, it is talking about peer 
SR-path accounting
2. ipfix on its own does not cut it because you still have to put a marker in 
the packets
3. Yes, SR assumes there is no (i.e. zero) state per SR-path in the network
But this third point causes a tension: we want to use SR because it is good, 
but we want to do transit node diagnostics because (frankly) they are necessary.
To get the full picture of why they are necessary read the draft, or consider 
ECMP.

This discussion will not be unfamiliar to those who tried to debug LDP networks.

Adrian

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

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

[Robert Raszuk]

Adrian

I do not agree with with #2 .. no marker of any sort is needed.

And debugging LDP networks is no different then debugging IP networks so
sure some who are used to ATM/Frame Relay find it very hard to troubleshoot.

Best
r.


On Nov 16, 2017 13:35, "Adrian Farrel"  wrote:

Let's unpick a couple of things...



1. This work is not talking about per-flow accounting, it is talking about
peer SR-path accounting

2. ipfix on its own does not cut it because you still have to put a marker
in the packets

3. Yes, SR assumes there is no (i.e. zero) state per SR-path in the network

But this third point causes a tension: we want to use SR because it is
good, but we want to do transit node diagnostics because (frankly) they are
necessary.

To get the full picture of why they are necessary read the draft, or
consider ECMP.



This discussion will not be unfamiliar to those who tried to debug LDP
networks.



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

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

[Adrian Farrel]

Let's unpick a couple of things...
 
1. This work is not talking about per-flow accounting, it is talking about peer 
SR-path accounting
2. ipfix on its own does not cut it because you still have to put a marker in 
the packets
3. Yes, SR assumes there is no (i.e. zero) state per SR-path in the network
But this third point causes a tension: we want to use SR because it is good, 
but we want to do transit node diagnostics because (frankly) they are necessary.
To get the full picture of why they are necessary read the draft, or consider 
ECMP.
 
This discussion will not be unfamiliar to those who tried to debug LDP networks.
 
Adrian
 
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring