Re: [spring] meaning of "Strict Shortest Path" algorithm in draft-ietf-spring-segment-routing-09

[Jeff Tantsura]

Hi Stefano,

While a bit unorthodox view on SPF, I’d expect any deviations from default SPF 
to be in the context of the IGP – I’m OK with the definition as is.
Thanks for your response.
 
Cheers,
Jeff
 

On 9/23/16, 00:57, "Stefano Previdi (sprevidi)"  wrote:

Hi Jeff,


> On Sep 22, 2016, at 4:47 PM, Jeff Tantsura  
wrote:
> 
> Hi Stefano,
> 
> Thanks for the explanation, I have got a bit of different view on the use 
of algorithm logic. 
> PBR is orthogonal to what an IGP does and IMO its presence should not be 
signaled.


please look at the example and you will see that there’s no signaling 
requirement.

the requirement is to have the ability to instruct the node on a specific 
routing paradigm.


> More logical would be to use 0 when only metric is taking into 
consideration when computing a path and other value otherwise, which is indeed 
deviation from the strict-SPF.
> 


are you suggesting that algorithm-0 (the default) must be strict-spf ? 


Thanks.
s.


> Please let me know what you think.
> 
> Cheers,
> Jeff
> 
> 
> 
> On 9/22/16, 06:57, "Stefano Previdi (sprevidi)"  
wrote:
> 
> 
>> On Sep 19, 2016, at 3:28 PM, Alexander Vainshtein 
 wrote:
>> 
>> Stefano,
>> I think life would be simpler if you could provide a meaningful example 
of behavior that is "SPF" (defined as the default algorithm)  but not "Strict 
SPF”.
> 
> 
>algorithm 0 is what you use by default. You compute your 
>segment list with SIDs representing segments which are 
>portion of shortest paths. However, you don’t know if in 
>each node along the path you computed the behavior is 
>exactly the one you intended.
> 
>Strict-SPF allows you to be sure that the path you 
>computed (and instantiated into a segment list) is 
>exactly what each node will honor.
> 
>Here’s an example: 
> 
>Assume following topology:
>. AG and GF links have metric of 20
>. All other links have metric of 10
> 
> _G_
>|   |
>A---B---C---D---E---F---Z
>|   |
>H---I---J
> 
>. Shortest path from A to Z is AGFZ.
>. There’s a policy in router A in order to send traffic to Z
>  through the desired path: ABCDEFZ. The reason could be a
>  better delay
>. Router A computes the path using its LSDB. We assume
>  that TE metric is available in the LSDB and representing
>  the delay of each link so to allow router A to compute a
>  delay-based shortest path.
>. Router A figures out that it needs segment list EZ in order
>  to steer traffic along ABCDEFZ path.
>. Router A sends traffic with segment list (label stack): EZ
>. Now, assume router E has also a local policy in order to
>  send traffic to Z through the desired path: EHIJZ. This
>  may be due to some BW constraint that instructs router E
>  to split part of the traffic towards a different path.
>. Therefore, router E imposes segment list (label stack) IZ
>  to traffic for Z.
>. When a packet sent by A (with label stack EZ) arrives in E,
>  the label stack is now Z and router E swaps it with IZ
>. Now the packet travels through path EHIJZ while router A
>  _thinks_ the packet would travel through path ABCDEFZ.
> 
>Therefore, there’s a need for router A to instruct any router
>in the path NOT to alter the shape of the path that router A
>initially computed for that packet.
> 
>Strict-SPF SID will do the job. A compliant implementation
>will install the Strict-SPF SID and nexthop regardless any
>local policy for that prefix.
> 
>Now, regarding the ECMP use case, given that ECMP limitations 
>still result in the use of paths all of which are IGP 
>shortest-paths such limitations do not violate the definition 
>of strict-spf behavior.
> 
>Hope this helps.
> 
>s.
> 
> 
> 
>> 
>> IMHO and FWIW Chris has tried to make such an example, but it does not 
look as valid to some people (me included). 
>> 
>> Without any such examples it is not clear why the "Strict SPF" algorithm 
is needed.
>> 
>> Regards,
>> Sasha
>> 
>> Office: +972-39266302
>> Cell:  +972-549266302
>> Email:   alexander.vainsht...@ecitele.com
>> 
>> 
>> -Original Message-
>> From: Stefano Previdi (sprevidi) [mailto:sprev...@cisco.com] 
>> Sent: Monday, September 19, 2016 4:17 PM
>> To: Alexander 

Re: [spring] draft-ietf-spring-conflict-resolution - Preference Rule

[Marc Binderberger]

Hello Bruno,

thanks for the detailed reply and apology for my late response.


First, let me re-phrase what I propose. Realized that I never explained 
exactly what I had in mind and using the "ignore" keyword was just a bad idea 
too. Will avoid "ignore" as this keyword has been used in different ways 
already.

So what I propose is: if a prefix has conflicting mapping information - 
prefix or SID conflict - then keep this prefix unlabeled. [1]

I don't see that draft-ietf-spring-conflict-resolution is exactly covering 
this idea.



Then:

> But I'm not sure that you are really calling for the network operator to 
> have this flexibility.

I actually do expect requests from network operators to implement their 
specific view on how to operate the network into the conflict algorithm. The 
protocol design should allow for it.

But there are also network operators who prefer to keep the network 
relatively "dumb" and implement their operational logic into their OSS 
systems. I don't see why vendors would want to impose the more complex logic 
on customers not asking or not wanting it. Which is why I argue against the 
idea to make the preference algorithm "the" standard.

(yes, "simple" or "dumb" allows for interpretation. I'm sure you get the 
point though)


Saying all this, of course we should support the request from Orange and 
others for the preference algorithm. We do have the "algorithm" field, e.g. 
draft-ietf-isis-segment-routing-extensions, that could carry the 
SPF+conflict+... algorithm required.



There was also a misunderstanding about my "solving a problem that should be 
rare" statement. I said it with a qualifier "with the quoted rule above" and 
the rule was

   "Local configuration conflicts can be prevented before they are advertised"

If implementations check for a conflict between what they want to advertise 
and what is already advertised by others in the network then we filter out 
conflicts from config change that is happening after a time window of e.g. 
several seconds since the last SR config change in the network. Not saying 
this is a fool-proof algorithm but it puts a perspective on the problem.


> Basically, what I propose is to keep it safe, and not introduce new risks

sorry but I disagree. I cannot name customers but there are network operators 
who consider code complexity that they don't need a risk.



To summarize: I see your point for the preference algorithm but I disagree 
that this should be "the" standard behaviour of Segment Routing 
implementations. Rather we should allow for different algorithm. To have 
basic interoperability I propose the algorithm [1] above as a starting point. 
Other algorithm can be defined within IETF if network operators are 
interested in - we obviously have one algorithm with interest already :-)


Best regards,
Marc




On Tue, 30 Aug 2016 17:08:24 +, bruno.decra...@orange.com wrote:
> Hello Marc,
> 
> Speaking as an individual contributor, and network operator.
> 
> Please see inline.
> 
>> From: Marc Binderberger [mailto:m...@sniff.de] > Sent: Tuesday, August 09, 
>> 2016 9:56 AM
>> 
>> Hello Bruno and spring list experts,
>> 
>> jumping late into the discussion (sorry).
> 
> Thanks for the feedback.
>  
>> 
>> I would see any kind of preference list to handle a conflict to be an
>> somewhat arbitrary decision.
> 
> Agreed.
> Stéphane has proposed the addition of a "preference" field attached to 
> mapping server (advertisements) to allow a network operator to control this 
> preference decision, depending on SP rules or current network status (e.g. 
> migrations)
> To increase this capacity for customization, I guess that an option would 
> be to extend this preference to other SID advertisements.
> But I'm not sure that you are really calling for the network operator to 
> have this flexibility. So I don't think that this comment is really the 
> point that you want to make.
> 
>> That is okay for a particular network (assuming
>> the network operator had a word or two about the rules) but I don't 
>> consider
>> this a good idea for a standard to reflect specific designs or
>> operational/troubleshooting procedures.
>> 
>> E.g. who is saying that IPv6 should be preferred over IPv4?
> 
> The working group.
> You are welcome to contribute. IIRC, this specific point has already been 
> changed based on WG feedback.
> 
>> What when the
>> operator's workhorse is still IPv4 traffic and s/he would prefer to 
>> sacrifice
>> IPv6 to keep IPv4 running?
>> 
>> 
>> In reality, don't we expect the rule ...
>> 
>>"Local configuration conflicts can be prevented before they are 
>> advertised"
>> 
>> ... to cover the large amount of mistakes? 
> 
> I'm not sure to see why.
> A priori, I would expect that the more pre-existing configuration/states, 
> the more chance to conflict. Given that the network wide 
> states/configurations is greater (by at least 1 or 2 order of magnitude) 
> compared to the state/configuration of one 

Re: [spring] SPRING WGLC for draft-ietf-spring-resiliency-use-cases

[Rob Shakir]

On Mon, Sep 26, 2016 at 1:25 AM,  wrote:
>
>
>  > Authors: In parallel with the WGLC, please respond to this message
> (making sure you cc
>  > spring@ietf.org) and indicate if you are aware of any relevant IPR.
> Please do this even if it
>  > has been previously disclosed. Thanks.
>
> IINM, we are missing the IPR answers from Clarence, Stefano, Pierre and
> Rob.
>

 I'm not aware of any IPR on this draft.

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

Re: [spring] WGLC for draft-ietf-spring-oam-usecase

[Martin Horneffer]

Hello everyone,

speaking as co-worker of one of the editors: From my own viewpoint I 
think this document makes a lot of sense and is in a good state. I'm not 
aware of any problemwith the current state of the document. And there 
already is an implementation report. The document should be sent to the 
IESG.


The only reason not to do so might be to abandon SPRING usecase 
documents at all. But since we have bee asked to produce usecase 
documents and went along that track so far, we should IMHO proceed by 
promoting this document as well.


Best regards, Martin


Am 12.09.16 um 18:30 schrieb bruno.decra...@orange.com:

Dear SPRING WG,

The authors have indicated that draft-ietf-spring-oam-usecase is ready for WGLC.

Please send your comments to spring@ietf.org on whether this use case is ready 
to be sent to the IESG as an informational draft. We will plan to end the WGLC 
on September 26.

* Please comment as silence counts as a lack of interest. In the absence of WG 
support and review, this document will not be sent to the IESG. *

You may also be interested in an implementation report: 
https://tools.ietf.org/html/draft-leipnitz-spring-pms-implementation-report-00

This document has 2 disclosed IPR: 
https://datatracker.ietf.org/ipr/search/?submit=draft=draft-ietf-spring-oam-usecase

We are also polling for knowledge of implementations of part or all of what 
this document describe. Please inform the mailing list, the chairs, or only one 
of the chairs.

Finally, if you want to volunteer to be Document Shepherd for this document, 
please let us know.

Regards,

--Bruno

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

___
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] SPRING WGLC for draft-ietf-spring-resiliency-use-cases

[Stefano Previdi (sprevidi)]

> On Sep 26, 2016, at 10:25 AM, bruno.decra...@orange.com wrote:
> 
> Hi Authors,
> 
>> From: John G. Scudder [mailto:j...@juniper.net]  > Sent: Tuesday, July 12, 
>> 2016 4:44 PM
>> 
>> Dear SPRING WG (and I've taken the liberty of cc'ing RTGWG),
>> 
>> The authors have indicated that draft-ietf-spring-resiliency-use-cases is 
>> ready for WGLC.
>> Please send your comments to spring@ietf.org. We will plan to end the WGLC 
>> on July 31.
>> I notice that there is an outstanding question from Alexander Vainshtein
>> , sent to the list on July 10 -- authors, 
>> please
>> consider his note to be part of the WGLC and respond accordingly.
> 
> Please consider answering Alexander's comment.
> 
>> Authors: In parallel with the WGLC, please respond to this message (making 
>> sure you cc
>> spring@ietf.org) and indicate if you are aware of any relevant IPR. Please 
>> do this even if it
>> has been previously disclosed. Thanks.
> 
> IINM, we are missing the IPR answers from Clarence, Stefano, Pierre and Rob.


I’m not aware of any IPR related to this document.

s.


> 
> Thanks,
> Regards,
> --Bruno
> 
>> Thanks to Stéphane Litkowski for agreeing to be document shepherd.
>> 
>> Regards,
>> 
>> --John
> 
> _
> 
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
> falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged 
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete 
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been 
> modified, changed or falsified.
> Thank you.
> 

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

Re: [spring] IPR for draft-ietf-spring-segment-routing-msdc prior to WGLC

[bruno.decraene]

Jon, Ebben, Petr,
 
IINM we are missing your reply.
 
Could you please reply to this IPR call on the SPRING mailing list?
 
Thanks,
Regards,
--Bruno

 > -Original Message-
 > From: DECRAENE Bruno IMT/OLN
 > Sent: Friday, September 09, 2016 11:29 AM
 > To: draft-ietf-spring-segment-routing-m...@ietf.org
 > Cc: martin.vigour...@nokia.com
 > Subject: RE: [spring] IPR for draft-ietf-spring-segment-routing-msdc prior 
 > to WGLC
 > 
 > Jon, Ebben, Petr,
 > 
 > IINM we are missing your reply.
 > 
 > Could you please reply to this IPR call on the SPRING mailing list?
 > 
 > Thanks,
 > Regards,
 > --Bruno
 > 
 > > -Original Message-
 > > From: spring [mailto:spring-boun...@ietf.org] On Behalf Of John G.Scudder
 > > Sent: Sunday, July 24, 2016 2:50 PM
 > > To: draft-ietf-spring-segment-routing-m...@ietf.org
 > > Cc: spring@ietf.org
 > > Subject: [spring] IPR for draft-ietf-spring-segment-routing-msdc prior to 
 > > WGLC
 > >
 > > Dear Authors:
 > >
 > > As we discussed at the SPRING meeting, working group last call has been 
 > > requested for
 > > draft-ietf-spring-segment-routing-msdc. Before we begin the WGLC, please 
 > > indicate
 > > whether you are aware of any relevant IPR and if so, whether it has been 
 > > disclosed.
 > (Please
 > > do this even if you've done it before, thanks for your help.) Please cc 
 > > the WG in your
 > reply.
 > >
 > > As soon as this has been collected from all authors, we'll start the WGLC.
 > >
 > > Thanks,
 > >
 > > --Bruno and John
 > >
 > > ___
 > > spring mailing list
 > > spring@ietf.org
 > > https://www.ietf.org/mailman/listinfo/spring

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

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

Re: [spring] IPR for draft-ietf-spring-ipv6-use-cases prior to WGLC

[bruno.decraene]

Mark, Clarence,
 
IINM, we are missing IPR statement from you.
 
Could you please reply to the IPR call, on the spring mailing list?
 
Thanks,
Regards,
 --Bruno

> From: DECRAENE Bruno IMT/OLN
> Sent: Friday, September 09, 2016 11:09 AM
 > To: draft-ietf-spring-ipv6-use-ca...@ietf.org
 > Cc: martin.vigour...@nokia.com
 > Subject: RE: [spring] IPR for draft-ietf-spring-ipv6-use-cases prior to WGLC
 > 
 > Mark, Clarence,
 > 
 > IINM, we are missing IPR statement from you.
 > 
 > Could you please reply to the IPR call, on the spring mailing list?
 > 
 > Thanks,
 > Regards,
 > --Bruno
 > 
 > 
 > 
 > 
 > > -Original Message-
 > > From: spring [mailto:spring-boun...@ietf.org] On Behalf Of John G.Scudder
 > > Sent: Sunday, July 24, 2016 2:48 PM
 > > To: draft-ietf-spring-ipv6-use-ca...@ietf.org
 > > Cc: spring@ietf.org
 > > Subject: [spring] IPR for draft-ietf-spring-ipv6-use-cases prior to WGLC
 > >
 > > Dear Authors:
 > >
 > > As we discussed at the SPRING meeting, working group last call has been 
 > > requested for
 > > draft-ietf-spring-ipv6-use-cases. Before we begin the WGLC, please 
 > > indicate whether
 > you
 > > are aware of any relevant IPR and if so, whether it has been disclosed. 
 > > (Please do this
 > even
 > > if you've done it before, thanks for your help.) Please cc the WG in your 
 > > reply.
 > >
 > > As soon as this has been collected from all authors, we'll start the WGLC.
 > >
 > > Thanks,
 > >
 > > --Bruno and John
 > >
 > > ___
 > > spring mailing list
 > > spring@ietf.org
 > > https://www.ietf.org/mailman/listinfo/spring

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

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