Re: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

[stefano previdi]

Hi,

I support the WG adoption of this draft.

Thanks.

s.


> On Jan 27, 2021, at 12:46 PM, James Guichard  
> wrote:
> 
> Dear WG:
>  
> This message starts a 2 week WG adoption call for 
> https://datatracker.ietf.org/doc/draft-dong-spring-sr-for-enhanced-vpn/ 
> ending February 10th2021.
>  
> After review of the document please indicate support (or not) for WG adoption 
> to the mailing list and if you are willing to work on the document, please 
> state this explicitly. This gives the chairs an indication of the energy 
> level of people in the working group willing to work on this document. Please 
> also provide comments/reasons for your support (or lack thereof) as this is a 
> stronger way to indicate your (non) support as this is not a vote.
>  
> Thanks!
>  
> Jim, Bruno & Joel
>  
>  
>  
> ___
> 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] WG Adoption Call for draft-li-spring-srv6-path-segment

[stefano previdi]

Hi,

I support the adoption of draft-li-spring-srv6-path-segment as it describes a 
useful feature (identifying an SR path through a segment identifier) which is 
already available in implementations.

Thanks.
s.


> On Nov 3, 2020, at 6:39 PM, James Guichard  
> wrote:
> 
> Dear WG:
>  
> This message starts a 3 week WG adoption call for 
> https://tools.ietf.org/html/draft-li-spring-srv6-path-segment-07, ending 
> November 24th 2020. Please note that this document has several changes from 
> v-06 that were requested by the SPRING chairs. For this reason, the chairs 
> have extended the adoption call for an additional week to allow the WG enough 
> time to review these changes before deciding on WG adoption.
>  
> After review of the document please indicate support (or not) for WG adoption 
> to the mailing list. Please also provide comments/reasons for that support 
> (or lack thereof) as silence will not be considered as consent.
>  
> Thanks!
>  
> Jim, Bruno & Joel
>  
>  
>  
>  
>  
> ___
> 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] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

[stefano previdi]

I support the adoption of this document.

Thanks.
s.


> On Jul 15, 2020, at 1:16 PM, James Guichard  
> wrote:
> 
> Dear WG:
>  
> This email begins a 2 week WG adoption call for 
> https://datatracker.ietf.org/doc/draft-dong-spring-sr-for-enhanced-vpn/ 
> ending Wednesday 29th July 2020.
>  
> Please speak up if you support or oppose adopting this document into the WG. 
> Please also provide comments/reasons for that support (or lack thereof). 
> Silence will not be considered consent.
>  
> Thanks!
>  
> Jim, Joel & Bruno
>  
>  
>  
> ___
> 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] draft-ietf-spring-srv6-network-programming - 2 week Early Allocation Call

[stefano previdi]

support.

s.


> On Dec 19, 2019, at 5:53 PM, bruno.decra...@orange.com wrote:
> 
> Hi SPRING WG,
>  
> This begins a 2 week Early Allocation call for a “Ethernet” value from the 
> "Protocol Numbers" registry.
> https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-07#section-9.1
> https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-07#section-5.3
> https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml
>  
> In parallel of the Working Group Last Call which is currently running, the 
> authors are requesting for early code point allocation from IANA as 
> implementations are under way.
>  
> The criteria for early allocation are:
>a.  The code points must be from a space designated as "RFC
>Required", "IETF Review", or "Standards Action".  Additionally,
>requests for early assignment of code points from a
>"Specification Required" registry are allowed if the
>specification will be published as an RFC.
>  
>b.  The format, semantics, processing, and other rules related to
>handling the protocol entities defined by the code points
>(henceforth called "specifications") must be adequately described
>in an Internet-Draft.
>  
>c.  The specifications of these code points must be stable; i.e., if
>there is a change, implementations based on the earlier and later
>specifications must be seamlessly interoperable.
>  
>d.  The Working Group chairs and Area Directors (ADs) judge that
>there is sufficient interest in the community for early (pre-RFC)
>implementation and deployment, or that failure to make an early
>allocation might lead to contention for the code point in the
>field.
> https://tools.ietf.org/html/rfc7120#section-2
>  
> I believe the above conditions are met. (minus the AD judgement which is 
> further down in the process)
>  
> As a reminder, this topic has mainly been discussed following IETF 105 
> (Montréal) both during the meeting and on the mailing list.
> During IETF 106 it has been discussed in the IntArea WG. 
> https://datatracker.ietf.org/meeting/106/proceedings#intarea
>  
> Note that this code point is not to be specific to SRv6. Depending on AD 
> guidance, this specific code point even be moved from 
> draft-ietf-spring-srv6-network-programming into a specific 1 page draft.
>  
> If you support early adoption,  please include “support” along with any 
> comments about the draft’s technical solution.
>  
> If you do not support early allocation, please include “no support” in your 
> email and indicate why.
>  
> Thank you,
> --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] WG Adoption Call: draft-xuclad-spring-sr-service-programming

[stefano previdi]

support.

Thanks.
s.


> On Jun 27, 2019, at 8:13 AM, Rob Shakir  
> wrote:
> 
> Hi SPRING WG,
> 
> This email initiates a two week working group adoption call for 
> draft-xuclad-spring-sr-service-programming. This follows the discussion that 
> we had in the last few IETF meetings, and particularly the focused discussion 
> we had at IETF 104 regarding service chaining and SPRING.
> 
> Please indicate your support, comments, or objections for adopting this draft 
> by Wednesday July 10th, 2019. We are particularly interested in hearing from 
> WG members who are not authors of this draft, and those folks that are 
> willing to spend time working on this draft after adoption.
> 
> We are also looking for volunteers who can provide a technical review of the 
> content of the draft at a later stage of its progress through the working 
> group (e.g., before WGLC).
> 
> In parallel - we'll send an IPR poll to the working group and authors. The 
> currently disclosed IPR can be found in the datatracker.
> 
> Thanks!
> Rob & Bruno.
> ___
> 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] WG Adoption Call: draft-guichard-spring-nsh-sr

[stefano previdi]

support.


Thanks.
s.


> On Jun 27, 2019, at 8:13 AM, Rob Shakir  
> wrote:
> 
> Hi SPRING WG,
> 
> This email initiates a two week working group adoption call for 
> draft-guichard-spring-nsh-sr. This follows the discussion that we had in the 
> last few IETF meetings, and particularly the focused discussion we had at 
> IETF 104 regarding service chaining and SPRING.
> 
> Please indicate your support, comments, or objections for adopting this draft 
> by Wednesday July 10th, 2019.. We are particularly interested in hearing from 
> WG members who are not authors of this draft, and those folks that are 
> willing to spend time working on this draft after adoption.
> 
> We are also looking for volunteers who can provide a technical review of the 
> content of the draft at a later stage of its progress through the working 
> group (e.g., before WGLC).
> 
> In parallel - we'll send an IPR poll to the working group and authors. The 
> currently disclosed IPR can be found in the datatracker.
> 
> Thanks!
> Rob & Bruno.
> 
> 
> ___
> 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] Working Group Adoption Call for draft-filsfils-spring-srv6-network-programming

[stefano previdi]

Hi,

I support the working group adoption of this document.

Thanks.
s.


> On Mar 13, 2019, at 7:49 PM, bruno.decra...@orange.com wrote:
> 
> Hi SPRING WG,
>  
> This email initiates a three week call for working group adoption for 
> draft-filsfils-spring-srv6-network-programming. (Three weeks to account for 
> the IETF week)
>  
> Please indicate your support, comments, or objection, for adopting this draft 
> as a working group item by April, 3rd, 2019 (aka 2019-04-03)
> We are particularly interested in hearing from working group members that are 
> not co-authors of this draft.
>  
> We are also looking for volunteers who would be ready to perform a technical 
> review of this work at some later stage, such as before or during WG the last 
> call.
>  
> In parallel to this adoption call, I will send an IPR call for this document. 
> We will need all authors and contributors to confirm their IPR position on 
> this document.
> There is currently 1 IPR filled (2)
>  
> (1)  
> https://tools.ietf.org/html/draft-filsfils-spring-srv6-network-programming-07
> (2)  
> https://datatracker.ietf.org/ipr/search/?id=draft-filsfils-spring-srv6-network-programming&submit=draft
>  
>  
> Thank you,
> --Bruno & Rob.
>  
> _
> 
> 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] Last Call: (Segment Routing with MPLS data plane) to Proposed Standard

[Stefano Previdi]

Fully agree.

Thanks.
s.




On Tue, Feb 26, 2019, 22:20 Adrian Farrel  wrote:

> This draft has been around the block a bit, but certainly needs to progress
> because a lot of other things are dependent on it.
>
> Fortunately after plenty of review and updates (thanks to the authors), I
> think it is now ready to become an RFC.
>
> Adrian
>
> -Original Message-
> From: spring  On Behalf Of The IESG
> Sent: 21 February 2019 18:42
> To: IETF-Announce 
> Cc: martin.vigour...@nokia.com;
> draft-ietf-spring-segment-routing-m...@ietf.org; spring@ietf.org;
> spring-cha...@ietf.org; shrad...@juniper.net
> Subject: [spring] Last Call:
> 
> (Segment Routing with MPLS data plane) to Proposed Standard
>
>
> The IESG has received a request from the Source Packet Routing in
> Networking
> WG (spring) to consider the following document: - 'Segment Routing with
> MPLS
> data plane'
>as Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> i...@ietf.org mailing lists by 2019-03-07. Exceptionally, comments may be
> sent to i...@ietf.org instead. In either case, please retain the beginning
> of
> the Subject line to allow automated sorting.
>
> Abstract
>
>
>Segment Routing (SR) leverages the source routing paradigm.  A node
>steers a packet through a controlled set of instructions, called
>segments, by prepending the packet with an SR header.  In the MPLS
>dataplane, the SR header is instantiated through a label stack. This
>document specifies the forwarding behavior to allow instantiating SR
>over the MPLS dataplane.
>
>
>
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-mpls/
>
> IESG discussion can be tracked via
>
> https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-mpls/ball
> ot/
> 
>
> The following IPR Declarations may be related to this I-D:
>
>https://datatracker.ietf.org/ipr/2880/
>https://datatracker.ietf.org/ipr/2453/
>https://datatracker.ietf.org/ipr/2454/
>
>
>
>
>
> ___
> 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] Working Group Adoption Call for draft-cheng-spring-mpls-path-segment

[stefano previdi]

I support the adoption of this draft as WG item.

Thanks.
s.


> On Feb 20, 2019, at 10:03 AM, bruno.decra...@orange.com wrote:
> 
> Hi SPRING WG,
> 
> This email initiates a two week call for working group adoption for 
> draft-cheng-spring-mpls-path-segment.
> 
> Please indicate your support, comments, or objection, for adopting this draft 
> as a working group item by March 6th 2019.
> We are particularly interested in hearing from working group members that are 
> not co-authors of this draft.
> We are also looking for volunteers who would be ready to perform a technical 
> review of this work at some later stage, such as before or during WG the last 
> call.
> 
> Additionally, there are currently 7 authors listed on this document. Please 
> trim this to <= 5 front-page authors, utilising a "Contributors" section if 
> required for the others. An approach to achieving this would be to list ~2 
> editors as the front-page authors.
> 
> In parallel to this adoption call, I will send an IPR call for this document. 
> We will need all authors and contributors to confirm their IPR position on 
> this document.
> 
> (1) https://tools.ietf.org/html/draft-cheng-spring-mpls-path-segment
> 
> Thanks,
> --Bruno & Rob.
> 
> 
> _
> 
> 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] Question: Inconsistency of SR policy structure

[stefano previdi]

> On Oct 19, 2018, at 9:00 AM, Chengli (IP Technology Research) 
>  wrote:
> 
> Hi Stefano, 
> 
> Please see line.
> 
> Cheng
> 
> 
> -----Original Message-
> From: stefano previdi [mailto:stef...@previdi.net] 
> Sent: Friday, October 19, 2018 2:49 PM
> To: Chengli (IP Technology Research) 
> Cc: draft-ietf-spring-segment-routing-pol...@ietf.org; 
> draft-ietf-idr-segment-routing-te-pol...@ietf.org; SPRING WG List 
> ; Lizhenbin 
> Subject: Re: Question: Inconsistency of SR policy structure 
> 
> Hi Cheng,
> 
> to my understanding the definition of an SR Policy 
> (draft-ietf-spring-segment-routing-policy) is correct.
> [Cheng]  Agree.
> An SR Policy may include different paths and each of these paths may be 
> advertised in a different way (BGP, PCEP, static, ...).
> 
> BGP extensions described in draft-ietf-idr-segment-routing-te-policy is one 
> of the ways paths of a policy may be advertised. 
> 
> In other words, to my understanding at the time we wrote the BGP extensions, 
> the SR Policy defined in draft-ietf-spring-segment-routing-policy is the set 
> of all paths individually advertised in BGP, PCEP, etc.
> [Cheng] Agree.
> 
> It may looks like a terminology issue but in fact, I don’t think so. Even if 
> BGP (or PCEP) advertises a policy with a single path, it is still a valid SR 
> Policy from the perspective of the advertiser. So the term “SR Policy” is 
> valid no matter how many paths ended up in the policy after the receiver 
> consolidated all of them.
> 
> 
> [Cheng] Agree. But the problem is. 
> In BGP extensions, I am not sure the where is the candidate path. It seems 
> like SR includes multiple SR path specified by SID lists. 
> But in SR policy architecture document, the upper level of SID list is the 
> candidate path. That makes me confused.


[Stefano]
see section 1 of draft-ietf-spring-segment-routing-policy as pointed out by 
Ketan.
In BGP we do advertise a single path (that may have of course, multiple 
weighted segment lists).

The receiver will add the paths received through BGP (for a given policy) and 
put them in the candidate path list for that policy with any other path that it 
could have received through other protocols.

thanks.
s.



> 
> 
> And btw, just a detail, your description is a bit misleading: in BGP also the 
> segment list is weighted.
> [Cheng] You are right. It is weighted.
> 
> 
> Hope this helps.
> s.
> 
> 
>> On Oct 19, 2018, at 8:23 AM, Chengli (IP Technology Research) 
>>  wrote:
>> 
>> Hi authors,
>> 
>> I am working on updating drafts of path segment extensions in BGP/BGP-LS:
>> · 
>> https://tools.ietf.org/html/draft-li-idr-sr-policy-path-segment-distribution-00
>> · 
>> https://tools.ietf.org/html/draft-li-idr-bgp-ls-sr-policy-path-segment-00
>> 
>> But I found the inconsistency of SR policy structure.
>>  • In 
>> https://tools.ietf.org/html//draft-ietf-spring-segment-routing-policy-01, 
>> the SR policy’s structure looks like:
>> 
>>SR policy POL1 
>>  Candidate-path CP1 >   100:1.1.1.1, discriminator = 1>
>>Preference 200
>>Weight W1, SID-List1 
>>Weight W2, SID-List2 
>>  Candidate-path CP2 >   100:2.2.2.2, discriminator = 2>
>>Preference 100
>>Weight W3, SID-List3 
>>Weight W4, SID-List4 
>> 
>> So the structure is : 
>> SR Policy
>>Candidate-path p1
>>Weighted SID-list1
>>Weighted SID-list2
>>Candidate-path p2
>>Weighted SID-list3
>>Weighted SID-list4
>> 
>> But in 
>> https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-04, SR 
>> policy is described by following structure,
>> 
>>   SR Policy SAFI NLRI: 
>>   Attributes:
>>  Tunnel Encaps Attribute (23)
>> Tunnel Type: SR Policy
>> Binding SID
>> Preference
>> Priority
>> Policy Name
>> Explicit NULL Label Policy (ENLP)
>> Segment List
>> Weight
>> Segment
>> Segment
>> ...
>> ...
>> 
>> The structure is,
>>SR Policy
>>Weighted SID list1
>>Weighted SID list2
>> 
>> Where is the candidate-path?  it seems like they are not aligned.
>> 
>> Thanks,
>> Cheng
> 

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

Re: [spring] Question: Inconsistency of SR policy structure

[stefano previdi]

Hi Cheng,

to my understanding the definition of an SR Policy 
(draft-ietf-spring-segment-routing-policy) is correct.

An SR Policy may include different paths and each of these paths may be 
advertised in a different way (BGP, PCEP, static, ...).

BGP extensions described in draft-ietf-idr-segment-routing-te-policy is one of 
the ways paths of a policy may be advertised. 

In other words, to my understanding at the time we wrote the BGP extensions, 
the SR Policy defined in draft-ietf-spring-segment-routing-policy is the set of 
all paths individually advertised in BGP, PCEP, etc.

It may looks like a terminology issue but in fact, I don’t think so. Even if 
BGP (or PCEP) advertises a policy with a single path, it is still a valid SR 
Policy from the perspective of the advertiser. So the term “SR Policy” is valid 
no matter how many paths ended up in the policy after the receiver consolidated 
all of them.

And btw, just a detail, your description is a bit misleading: in BGP also the 
segment list is weighted.

Hope this helps.
s.


> On Oct 19, 2018, at 8:23 AM, Chengli (IP Technology Research) 
>  wrote:
> 
> Hi authors,
>  
> I am working on updating drafts of path segment extensions in BGP/BGP-LS:
> · 
> https://tools.ietf.org/html/draft-li-idr-sr-policy-path-segment-distribution-00
> · 
> https://tools.ietf.org/html/draft-li-idr-bgp-ls-sr-policy-path-segment-00
>  
> But I found the inconsistency of SR policy structure.
>   • In 
> https://tools.ietf.org/html//draft-ietf-spring-segment-routing-policy-01, the 
> SR policy’s structure looks like:
>  
> SR policy POL1 
>   Candidate-path CP1 100:1.1.1.1, discriminator = 1>
> Preference 200
> Weight W1, SID-List1 
> Weight W2, SID-List2 
>   Candidate-path CP2 100:2.2.2.2, discriminator = 2>
> Preference 100
> Weight W3, SID-List3 
> Weight W4, SID-List4 
>  
> So the structure is : 
> SR Policy
> Candidate-path p1
> Weighted SID-list1
> Weighted SID-list2
> Candidate-path p2
> Weighted SID-list3
> Weighted SID-list4
>  
> But in 
> https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-04, SR 
> policy is described by following structure,
>  
>SR Policy SAFI NLRI: 
>Attributes:
>   Tunnel Encaps Attribute (23)
>  Tunnel Type: SR Policy
>  Binding SID
>  Preference
>  Priority
>  Policy Name
>  Explicit NULL Label Policy (ENLP)
>  Segment List
>  Weight
>  Segment
>  Segment
>  ...
>  ...
>  
> The structure is,
> SR Policy
> SID list1
> SID list2
>  
> Where is the candidate-path?  it seems like they are not aligned.
>  
> Thanks,
> Cheng

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

Re: [spring] IPR Poll for draft-ietf-spring-segment-routing-mpls

[Stefano Previdi]

I'm not aware of any undisclosed IPR.

Thanks.
s.


On Thu, May 24, 2018, 7:28 PM  wrote:

> Hi SPRING WG,
>
>
>
> In parallel to the WGLC for draft-ietf-spring-segment-routing-mpls, we
> would like to poll for IPR.
>
>
>
> If you are aware of IPR that applies to
> draft-ietf-spring-segment-routing-mpls please respond to this email. If you
> are aware of IPR, please indicate whether it has been
>
> disclosed in accordance with IETF IPR rules (RFCs 3979, 4879, 3669 and
> 5378 provide more details).
>
>
>
> If you are an *author or contributor* please respond to this email
> regardless of whether or not you're aware of any IPR. If you are not an
> author or contributor, please explicitly respond only if you are aware of
> IPR that has not yet been disclosed.
>
>
>
> This document will not advance until IPR confirmations have been received
> from all authors and contributors.
>
>
>
> Thanks,
>
> Bruno & Rob.
>
>
>
> _
>
> 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] Working Group Adoption Call for draft-filsfils-spring-segment-routing-policy

[stefano previdi]

as a non-co-author, I support the adoption of this draft.

s.


> On May 16, 2018, at 5:20 PM, Rob Shakir  wrote:
> 
> Hi SPRING WG,
> 
> This email initiates a two week call for working group adoption for 
> draft-filsfils-spring-segment-routing-policy. Please indicate your support, 
> or otherwise, for adopting this draft as a working group item by 30th May 
> 2018. We are particularly interested in hearing from working group members 
> that are not co-authors of this draft.
> 
> As part of the discussions of adopting this draft into SPRING with the ADs 
> and chairs of other WGs, there are a number of requests to the authors.
> 
> 1. Please clarify in the text traffic steering with "SR policy" and its 
> relationship to other traffic engineering functions. It seems to me that this 
> work is generally describing how one selects and steers traffic into 
> policies, rather than path calculation. Additional clarification of whether 
> this is the case (or not), would be welcome to ensure that the relationship 
> with other work is clear. We would ask the authors to consider whether 
> sections 14.1-14.4 are required scope of this document.
> 
> 2.. Consider what the core content of this document is, and how it can be 
> make as concise and clear as possible. There are some specific suggestions 
> that can be made here, but we would like to see this discussed with the 
> working group.
> 
> Additionally, there are currently 17 authors listed on this document. Please 
> trim this to <= 5 front-page authors, utilising a "Contributors" section if 
> required for the others.. An approach to achieving this would be to list ~2 
> editors as the front-page authors.
> 
> In parallel to this adoption call, I will send an IPR call for this document. 
> We will need all 17 authors to confirm their IPR position on this document.
> 
> Thanks,
> Bruno & Rob.
> ___
> 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] [**EXTERNAL**] Re: SPRING - rechartering discussion

[stefano previdi]

SPRINGers,


> On Mar 19, 2018, at 3:23 PM, Dongjie (Jimmy)  wrote:
> 
> Hi all,
>  
> I totally agree with Mach, Jeff and others that there is work to be done in 
> OAM as there are more requirements to use SR for both existing and emerging 
> applications.
>  
> SR-TE is another important area. The current SR-TE mainly focuses on steering 
> traffic to particular SR paths, while TE can have a broader scope than that, 
> for example, how to do resource partitioning (reservation) with SR needs to 
> be discussed.  


I agree with the above. This is yet another aspect of TE that needs to be 
addressed.

Also, the v6 side of SR will also require more work, e.g., in the definition of 
use cases that clearly benefit from extension header insertion so that (minor) 
changes can be proposed to the v6 specification allowing these use cases to be 
implemented and operated safely.

s.


> Actually this is already mentioned in the current charter:
>  
> o Some types of network virtualization, including multi-
> topology networks and the partitioning of network 
> resources for VPNs
>  
> I’d agree with Dan that SR-TE is different from RSVP-TE, while as Himanshu 
> said, it could be beneficial to leverage the TE expertise from TEAS.
>  
> Best regards,
> Jie
>  
> From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Voyer, Daniel
> Sent: Monday, March 19, 2018 11:42 AM
> To: Shah, Himanshu; Jeff Tantsura; Bernier, Daniel; 
> bruno.decra...@orange.com; spring@ietf.org
> Cc: Alvaro Retana (aretana); spring-cha...@ietf.org
> Subject: Re: [spring] [**EXTERNAL**] Re: SPRING - rechartering discussion
>  
> [DV] see inlines
>  
> From: spring  on behalf of "Shah, Himanshu" 
> 
> Date: Sunday, March 18, 2018 at 9:23 PM
> To: Jeff Tantsura , Daniel Bernier 
> , Bruno Decraene , 
> "spring@ietf.org" 
> Cc: "Alvaro Retana (aretana)" , "spring-cha...@ietf.org" 
> 
> Subject: Re: [spring] [**EXTERNAL**] Re: SPRING - rechartering discussion
>  
> Agree with Jeff, without harping on all the good reasons already stated for 
> SPRING WG charter extensions,
> I would think that it would be beneficial to leverage TE expertise from TEAS 
> WG to
> progress SR-TE there for a cohesive, uniform solution for all tunneling 
> schemes.
>  
> [DV] 1- SRTE is NOT a tunnel. Labels are signals straight in the IGP, as 
> known. This is why the word “policy” was introduce with SRTE – “SRTE Policy”.
> [DV] 2- According to TEAS WG charter - 
> https://datatracker.ietf.org/wg/teas/about/:
> 1. Definition of additional abstract service, link, and path 
> properties such as jitter, delay, and diversity. Extensions 
> to IGPs to advertise these properties, and extensions to 
> RSVP-TE to request and to accumulate these properties.
>  
> [DV] 3- also notice in the SPRING Charter - 
> https://datatracker.ietf.org/wg/spring/about/:
> o Some types of network virtualization, including multi-
> topology networks and the partitioning of network 
> resources for VPNs
> o Network path and node protection such as fast re-route
> o Network programmability
> o New OAM techniques
> o Simplification and reduction of network signalling 
> components
> o Load balancing and traffic engineering
> [DV] Hence I believe “SRTE policy” is a key component of the SR Architecture 
> and should pursued as part as the Architecture definition milestone of the 
> SPRING WG.
>  
> Dan 
>  
> IMHO..
>  
> Thanks,
> Himanshu
> From: spring  on behalf of Jeff Tantsura 
> 
> Date: Sunday, March 18, 2018 at 3:26 PM
> To: "Bernier, Daniel" , "bruno.decra...@orange.com" 
> , "spring@ietf.org" 
> Cc: Alvaro Retana , "spring-cha...@ietf.org" 
> 
> Subject: [**EXTERNAL**] Re: [spring] SPRING - rechartering discussion
>  
> Hi,
>  
> I'm not going to repeat all the valid reasons to continue mentioned 
> beforehand.
> There's definitely work to be done in architecture and O&M areas as well as 
> co-ordination of various activities across IETF.
>  
> Cheers,
> Jeff
> On 3/18/18, 13:23, "spring on behalf of Bernier, Daniel" 
>  wrote:
>  
> Hi,
> 
> I echo the need to continue the SPRING work on service-chaining. There is 
> a growing interest to have a mechanism that operates at the forwarding plane 
> level using source routing as an alternative to a dedicated service overlay. 
> This will surely generate other related work such as automated service 
> discovery, inter-domain chaining policies, parallelism versus sequential 
> chaining, various control-plane implementations, etc.
> 
> Secondly, since there is a tight relation to SR chaining and TE policies, 
> I believe there will is a lot of opportunities related to Path Awareness 
> which is currently running in IRTF. Opportunities like, intent translation to 
> SR policies, Policy requests or announcements between domains and host 
> (probably app) level TE policy requests (e.g. how can an app receive a proper 
> policy based on its requirements) ?
> 
> My humble operator 0.02 cents.
> 
> Daniel Bernier

Re: [spring] [mpls] The MPLS WG has placed draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued"

[Stefano Previdi (IETF)]

Francois, Xiaohu, 

I fully agree with you.

s.


> On Mar 8, 2018, at 11:20 AM, Francois Clad (fclad)  wrote:
> 
> Hi Xiaohu, all,
> 
> I agree with the point raised by Xiaohu. The draft-farrel-mpls-sfc is copying 
> ideas described in draft-xu-mpls-service-chaining. Please note that the work 
> in draft-xu-mpls-service-chaining started one year before 
> draft-farrel-mpls-sfc.
> 
> At IETF100, three drafts in this area were discussed / presented:
> - draft-xu-mpls-service-chaining
> - draft-farrel-mpls-sfc
> - draft-clad-spring-segment-routing-service-chaining
> 
> There was discussion over the mic on the right home for these drafts among 
> SFC, SPRING and MPLS, but no consensus was reached.
> 
> As Xiaohu mentioned, draft-xu-mpls-service-chaining and 
> draft-clad-spring-segment-routing-service-chaining have later merged as 
> draft-xuclad-spring-sr-service-chaining. We have also requested a slot for 
> presenting this draft during the upcoming IETF meeting.
> 
> In this context, we believe that asking for WG adoption for one of these 
> drafts is premature.
> 
> Thanks,
> Francois
> 
>> On 7 Mar 2018, at 01:13, 徐小虎(义先)  wrote:
>> 
>> Hi all, 
>> 
>> As I had pointed out at the last IETF meeting, section 6 of this draft has 
>> an serious overlap with 
>> https://tools.ietf.org/html/draft-xu-mpls-service-chaining-03 that has now 
>> been updated by 
>> https://tools.ietf.org/html/draft-xuclad-spring-sr-service-chaining-01 with 
>> a merge with draft-clad-spring-segment-routing-service-chaining.
>> 
>> Hence, I'm very interesting to know the intention of such rewritting of a 
>> given mechanism that has been described in another draft. Is there any 
>> special nutrition?
>> 
>> Best regards,
>> Xiaohu
>> --
>> 发件人：IETF Secretariat 
>> 发送时间：2018年3月6日(星期二) 22:09
>> 收件人：draft-farrel-mpls-sfc ; mpls 
>> ; mpls-chairs 
>> 主　题：[mpls] The MPLS WG has placed draft-farrel-mpls-sfc in state "Call For 
>> Adoption By WG Issued"
>> 
>> 
>> The MPLS WG has placed draft-farrel-mpls-sfc in state
>> Call For Adoption By WG Issued (entered by Loa Andersson)
>> 
>> The document is available at
>> https://datatracker.ietf.org/doc/draft-farrel-mpls-sfc/
>> 
>> ___
>> 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

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

Re: [spring] Genart telechat review of draft-ietf-spring-resiliency-use-cases-11

[stefano previdi]

Hi Brian,

thanks for the comments. See answers below.


> On Nov 11, 2017, at 12:25 AM, Brian Carpenter  
> wrote:
> 
> Reviewer: Brian Carpenter
> Review result: Ready
> 
> Gen-ART telechat review of draft-ietf-spring-resiliency-use-cases-11
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair. Please wait for direction from your
> document shepherd or AD before posting a new version of the draft.
> 
> For more information, please see the FAQ at
> .
> 
> Document:  draft-ietf-spring-resiliency-use-cases-11.txt
> Reviewer: Brian Carpenter
> Review Date: 2017-11-11
> IETF LC End Date: 2017-05-04
> IESG Telechat date: 2017-12-14
> 
> Summary: Ready
> 
> 
> Comment:
> 
> 
> When I reviewed this for Last Call, I had two general concerns:
> 1) Is it useful to publish use cases now, at the end of
> protocol development?


this is an old story and you should probably read the archives of the spring 
mailing list ;-) 

To give you a summarized version of it, I’d say that yes, it makes sense to 
have the use-case properly documented. Resiliency is one of the major network 
operator use-case in segment routing networks and vendors are required to 
provide solutions for it. Having a document which can be pointed to and that 
describes the typical use case and requirements helps the reader in 
understanding how the component of the SR architecture address these 
requirements.


> 2) The AD review dated 2017-04-20 pointed out that the
> document should be historically consistent.
> 
> I'm going to assume that since the AD is bringing the draft
> to the IESG, he's now happy on these two points.

> 
> Minor issue:
> 
> 
> I originally commented that Section 3 doesn't actually mention
> any specific requirements for Spring. In conversation with
> Stefano:
> 
>>> Right, but you don't state any *requirements* for SPRING that result from 
>>> this case,
>>> except the very general statement before section 3.1. Maybe that does 
>>> translate
>>> into specific requirements, but I don't see how.
> 
>> the generic requirement is the ability to instantiate source routed paths.
>> These source routed paths, in the framework of this draft, are for LFAs.
> 
> I still think that Section 3 doesn't identify this requirement.
> Maybe it's obvious to one skilled in the art, however. So
> I'm going to say "Ready”.


Thanks.
s.


> 
> 

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

Re: [spring] AD Review of draft-ietf-spring-segment-routing-12

[stefano previdi]

> On Nov 1, 2017, at 8:55 PM, Alvaro Retana  wrote:
> 
> On October 28, 2017 at 10:51:52 AM, Les Ginsberg (ginsberg) 
> (ginsb...@cisco.com ) wrote:
> Les:
> 
> Hi!
> 
>> Apologies for the long delay in responding. The transference of the pen from 
>> Stefano resulted in a longer delay than it should have.
>> 
> Thanks for taking this on!  
> 
> As a new author: are you aware of any undeclared IPR for this document?
> 
>> A new version has been published which addresses your comments. Specific 
>> replies inline.
>> 
> My replies (to what I think still needs work or answers to questions) are 
> below.
> 
> In general, I think that the definition of “SR Domain” still needs work.  I 
> would also strongly recommend that you include a Deployment/Operations 
> Section.


what exactly would you expect to find in such section ? We have the 
Manageability section which illustrates how SR can be managed. An 
operation/deployment section will have to be exhaustive and illustrative on the 
different use-cases that SR addresses and hence can become pretty large. 

To my view, the draft focuses on architecture, not on deployment or operation. 
These are mostly described in the different use-cases drafts.


> The update looks like a lot of changes: more than 400 lines (according to 
> rfcdiff) — but I think they are mostly clarifying.  


indeed, not a single change in the architecture has been introduced or changed.


> Instead of returning the document to the WG, I am going to start an IETF Last 
> Call for this document — it will be extended (4 weeks) to account for the 
> upcoming meeting in Singapore, US Holidays and to give the WG an opportunity 
> to re-review.


many thanks!

s.


> 
> Thanks!
> 
> Alvaro.
> 
> 
> 
> ...
> 
>> Major:
>> 
>>  
>> M1. The Introduction mentions several types of segments, and it says that 
>> the LDP LSP, RSVP-TE LSP, and BGP LSP segments are “illustrated in 
>> [I-D.ietf-spring-segment-routing-mpls]”.  But that is only true for the 
>> first two, for which examples are shown.  Where are these segment types 
>> defined?  The definition, and not the examples, is the Major issue here.  
>> This document being the main architecture document should include the 
>> complete description.  BTW, the list is only about the “MPLS instantiation”, 
>> are there similar types of segments for IP?
>> 
>>  
>> [Les:] The list has been modified – but some definitions will still be found 
>> in [I-D.ietf-spring-segment-routing-mpls] where it makes sense to do so. We 
>> prefer that so that we do not duplicate definitions.
>> 
> Ok — I would have preferred the definitions to show up here, but it’s ok, as 
> long at they are defined somewhere.
> 
> I went to look at the most recent version of 
> I-D.ietf-spring-segment-routing-mpls (-11), but there’s no definition of 
> those segments.   :-(I’ll take a look at that document and see if 
> they’re needed.
> 
> 
> 
> 
> 
>> M2. From Section 2. (Terminology): “Using the same SRGB on all nodes within 
>> the SR domain ease operations and troubleshooting and is expected to be a 
>> deployment guideline.”  It is “expected to be a deployment guideline” 
>> where/when??  Given that this document is the general architecture, I 
>> figured that maybe draft-ietf-spring-segment-routing-mpls contained that 
>> deployment recommendation, but all that document says is: “As described in 
>> [I-D.ietf-spring-segment-routing], using the same SRGB on all nodes within 
>> the SR domain eases operations and troubleshooting and is expected to be a 
>> deployment guideline.”  So…where are the Deployment/Operational 
>> considerations related to the SRGB?  I note that neither document 
>> (draft-ietf-spring-segment-routing or 
>> draft-ietf-spring-segment-routing-mpls) include them.  I would expect some 
>> information to be in this (general) document and other more specific 
>> information (like the considerations about using the same SRGB) to be in the 
>> more specific document (draft-ietf-spring-segment-routing-mpls, in this 
>> case).
>> 
>>  
>> [Les:] Definition of the SRGB has been enhanced and the definition of an SR 
>> Domain has been introduced and discussed. We hope this clarifies deployment 
>> considerations as regards SRGB/SRLB.
>> 
> SR Domain was already defined — the difference seems to be the somewhat 
> nebulous new text:
> 
>
> Segment Routing Domain (SR Domain)...If multiple protocol instances are
>deployed, the SR domain most commonly includes all of the protocol
>instances in a single SR domain.  However, some deployments may wish
>to sub-divide the network into multiple SR domains, each of which
>includes one or more protocol instances.  It is expected that all
>nodes in an SR Domain are managed by the same administrative entity. 
> 
> …which makes the definition depend on itself: "SR domain most commonly 
> includes all of the protocol instances in a single SR domain” (the domain 
> includes all the instances in the doma

Re: [spring] AD Review of draft-ietf-spring-segment-routing-12

[Stefano Previdi]

Hi Alvaro, Martin, Bruno,

Sorry for the long delay. 

The authors are working on the different reviews and will address all comments 
before next meeting. 

Thanks.

s.

On October 10, 2017 11:35:24 PM GMT+02:00, Alvaro Retana 
 wrote:
>Dear authors:
>
> 
>
>Hi!
>
> 
>
>It’s been 2 months since I sent out this review and I still haven’t
>heard anything back (not even an ACK!) from you.  What is the plan to
>address the comments and move this work forward?
>
> 
>
>Thanks!
>
> 
>
>Alvaro.
>
> 
>
>From: spring  on behalf of Alvaro Retana
>
>Date: Thursday, August 10, 2017 at 3:00 PM
>To: "draft-ietf-spring-segment-rout...@ietf.org"
>
>Cc: "spring-cha...@ietf.org" ,
>"spring@ietf.org" , Martin Vigoureux
>
>Subject: [spring] AD Review of draft-ietf-spring-segment-routing-12
>
> 
>
>Dear authors:
>
> 
>
>I just finished reviewing this document – sorry for the delay in
>processing.  Thanks for all the work you’ve but into this document!
>
> 
>
>I have some significant concerns (see below for details).  In general,
>the document presents an incomplete view of the architecture: details
>about important pieces are barely mentioned or not fully described, as
>is the case of the role of a central controller (PCE), and the BGP and
>Binding Segments.  
>
> 
>
>Also, some of the architectural details are predicated on specific bits
>defined in the extensions, where this document should describe the
>general operation and leave the details (like bit names) to the
>extensions.  Note that I’m not asking that you don’t mention the
>extensions – pointing to them is fine --, I’m asking you to define the
>functionality in general and not as a function of the extensions.  For
>an example, see point M5.1. below.
>
> 
>
>I will wait for at least the Major comments to be addressed before
>starting the IETF Last Call.
>
> 
>
>Thanks!
>
> 
>
>Alvaro.
>
> 
>
> 
>
> 
>
>Major:
>
> 
>
>M1. The Introduction mentions several types of segments, and it says
>that the LDP LSP, RSVP-TE LSP, and BGP LSP segments are “illustrated in
>[I-D.ietf-spring-segment-routing-mpls]”.  But that is only true for the
>first two, for which examples are shown.  Where are these segment types
>defined?  The definition, and not the examples, is the Major issue
>here.  This document being the main architecture document should
>include the complete description.  BTW, the list is only about the
>“MPLS instantiation”, are there similar types of segments for IP?
>
> 
>
> 
>
>M2. From Section 2. (Terminology): “Using the same SRGB on all nodes
>within the SR domain ease operations and troubleshooting and is
>expected to be a deployment guideline.”  It is “expected to be a
>deployment guideline” where/when??  Given that this document is the
>general architecture, I figured that maybe
>draft-ietf-spring-segment-routing-mpls contained that deployment
>recommendation, but all that document says is: “As described in
>[I-D.ietf-spring-segment-routing], using the same SRGB on all nodes
>within the SR domain eases operations and troubleshooting and is
>expected to be a deployment guideline.”  So…where are the
>Deployment/Operational considerations related to the SRGB?  I note that
>neither document (draft-ietf-spring-segment-routing or
>draft-ietf-spring-segment-routing-mpls) include them.  I would expect
>some information to be in this (general) document and other more
>specific information (like the considerations about using the same
>SRGB) to be in the more specific document
>(draft-ietf-spring-segment-routing-mpls, in this case).
>
> 
>
>M2.1.  The example illustrated in Figure 2 would be a great place to
>demonstrate the value of having the same SRGB.  In fact, the text now
>shows things not working and it even warns by saying that “using
>anycast segment without configuring the same SRGB on nodes belonging to
>the same device group may lead to misrouting”, but no explanation of
>how it should be done the right way.
>
> 
>
> 
>
>M3. From Section 2. (Terminology): “…a global segment is represented by
>a globally-unique index.”  
>
> 
>
>M3.1.  I couldn’t find anywhere a discussion about the use of the
>index.  When it is discussed in 3.1.2, it seems to be an understood
>concept: “A Prefix-SID is allocated in the form of an index in the
>SRGB…”  Even if straightforward, I think the concept of the index
>should be explained (maybe with an example) and not assumed.  I again
>went to look at draft-ietf-spring-segment-routing-mpls, but that
>document just points back to this one: “The notion of indexed global
>segment, defined in [I-D.ietf-spring-segment-routing]…” 
>
> 
>
>M3.2. I assume that “globally-unique index” is really unique to the SR
>Domain, right?  I ask this question because “globally-unique IPv6
>address” has a different connotation (as in unique world-wide, not just
>inside a domain).  Please clarify.
>
> 
>
>M3.3.  Note that the latest version (-10) of
>draft-ietf-spring-segment-routing-mpls introduced the SR Local Block
>(SRLB) which is not defined in this d

Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolution

[stefano previdi]

I strongly support the publication of this draft.

I’m  not aware of any IPR related to the mechanisms described in the draft.

s.


> On Jun 29, 2017, at 3:28 PM, Martin Vigoureux  
> wrote:
> 
> Hello Working Group,
> 
> This email starts a Working Group Last Call on 
> draft-ietf-spring-conflict-resolution-04 [1] which is considered mature and 
> ready for a final working group review.
> 
> ¤ Please read this document if you haven't read the most recent
> version yet, and send your comments to the list, no later than
> *21st of July*.
> Note that this is *not only* a call for comments on the document; it is also 
> a call for support (or not) to publish this document as a Proposed Standard 
> RFC.
> 
> ¤ *Coincidentally*, we are also polling for knowledge of any IPR that applies 
> to draft-ietf-spring-conflict-resolution, to ensure that IPR has been 
> disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 
> 5378 for more details).
> 
> If you are listed as an Author or Contributor of
> draft-ietf-spring-conflict-resolution-04 please respond to this email and 
> indicate whether or not you are aware of any relevant IPR.
> 
> Note that, as of today, no IPR has been disclosed against this document or 
> its earlier versions.
> 
> Thank you,
> Martin
> 
> [1] https://datatracker.ietf.org/doc/draft-ietf-spring-conflict-resolution/
> 
> ___
> 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] I-D Action: draft-ietf-spring-segment-routing-ldp-interop-08.txt

[Stefano Previdi (sprevidi)]

in this version we have better introduced the concept of the SRMS that is then 
referenced by routing protocol extensions drafts.

thanks.
s.


> On Jun 16, 2017, at 12:19 AM, internet-dra...@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Source Packet Routing in Networking of the 
> IETF.
> 
>Title   : Segment Routing interworking with LDP
>Authors : Clarence Filsfils
>      Stefano Previdi
>  Ahmed Bashandy
>  Bruno Decraene
>  Stephane Litkowski
>   Filename: draft-ietf-spring-segment-routing-ldp-interop-08.txt
>   Pages   : 20
>   Date: 2017-06-15
> 
> Abstract:
>   A Segment Routing (SR) node steers a packet through a controlled set
>   of instructions, called segments, by prepending the packet with an SR
>   header.  A segment can represent any instruction, topological or
>   service-based.  SR allows to enforce a flow through any topological
>   path and service chain while maintaining per-flow state only at the
>   ingress node to the SR domain.
> 
>   The Segment Routing architecture can be directly applied to the MPLS
>   data plane with no change in the forwarding plane.  This drafts
>   describes how Segment Routing operates in a network where LDP is
>   deployed and in the case where SR-capable and non-SR-capable nodes
>   coexist.
> 
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-ldp-interop/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-spring-segment-routing-ldp-interop-08
> https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-ldp-interop-08
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-segment-routing-ldp-interop-08
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> I-D-Announce mailing list
> i-d-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

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

Re: [spring] [OSPF] OSPFv2 Segment Routing Extensions ERO Extensions (would also effect OSPFv3 and IS-IS) - REPLY TO THIS ONE

[Stefano Previdi (sprevidi)]

> On Jun 12, 2017, at 4:05 PM, bruno.decra...@orange.com wrote:
> 
> Hi Stefano,
> 
>> From: Stefano Previdi (sprevidi) [mailto:sprev...@cisco.com]  > Sent: 
>> Monday, June 12, 2017 3:52 PM
>> 
>> Hi Rob,
>> 
>> sorry for the mess. I’m afraid, the problem has been poorly described.
>> 
>> We’re obviously NOT questioning the use of the Binding SID and we’re NOT 
>> proposing the
>> removal of it.
>> 
>> What we’re talking about is the set of RSVP-like/ERO-like subTLVs that have 
>> been defined in
>> both isis and ospf protocols and for which, apparently, nobody has found yet 
>> any use.
> 
> In order to clarify, could you provide the precise list/set of those subTLVs 
> which are proposed to be removed? for both IS-IS and OSPF.


I’d expect anyone to make the effort to go read the isis and ospf specs. 
Nevertheless, here are the set of subTLVs in ISIS in the form of 

2.4.7.  ERO Metric sub-TLV
2.4.8.  IPv4 ERO subTLV
2.4.9.  IPv6 ERO subTLV
2.4.10. Unnumbered Interface ID ERO subTLV
2.4.11. IPv4 Backup ERO subTLV
2.4.12. IPv6 Backup ERO subTLV
2.4.13. Unnumbered Interface ID Backup ERO subTLV

You’ll find the same subTLVs in ospf and ospfv3 drafts.

Note also that you have the equivalent TLVs defined in bgp-ls by 
draft-ietf-idr-bgp-ls-segment-routing-ext.

s.


> 
> Thanks
> --Bruno
> 
>> Can we try to shutdown the unnecessary noise and confusion ?
>> 
>> Thanks.
>> s.
>> 
>> 
>>> On Jun 12, 2017, at 3:08 PM, Rob Shakir  wrote:
>>> 
>>> Bruno, SPRING,
>>> 
>>> I am aware of at least one implementation that makes heavy use of Binding 
>>> SIDs, so I do
>> not think that this is something that we can remove from the protocol 
>> specification.
>>> It seems to me that we have a number of cases that continue to exist that 
>>> make it useful to
>> have them specified, particularly:
>>> • Binding of a SID to a deeper label stack to prevent there being large 
>>> label stacks
>> required on ingress. This is required due to limited push depth, and limited 
>> readable label
>> depths for hashing.
>>> • Re-use of some other protocol's or network's forwarding path by a 
>>> device that is
>> imposing an SR label stack.
>>> There is not an alternative construct that can be used for this purpose, so 
>>> we should not
>> remove it.
>>> 
>>> In both of these cases there seems, to me, to be a use case for having the 
>>> information in
>> the IGP in the case that an implementation computes TE paths using cSPF, 
>> having binding SID
>> information available to it (along with the ERO) enables it to reduce the 
>> label stack depth by
>> finding binding SIDs that follow the same path as the computed ERO. Without 
>> the ERO
>> (which might not be an RSVP-TE ERO, but I believe that it how it was first 
>> envisaged) how can
>> the head-end of an TE path know what path the advertised Binding SID takes? 
>> It's fine to
>> punt this and say "the PCE in the sky will know" - however, I believe 
>> SPRING's charter
>> doesn't limit the technology to only centralised computation of paths.
>>> 
>>> I don't believe current demand for this is a good reason to remove it from 
>>> the protocol
>> specification - it is still somewhat early days for folks deploying TE based 
>> on SR - where I
>> think the Binding SID concept is most important.
>>> 
>>> r.
>>> 
>>> On Mon, 12 Jun 2017 at 05:50  wrote:
>>> Hello SPRING WG,
>>> 
>>> I'd like to encourage discussion on this thread.
>>> 
>>> The related questions seem to be:
>>> - Binding SIDs:
>>>-  Is there any implementation?
>>>- Is it useful?
>>>- Does it need to be specified?
>>> 
>>> - Binding SIDs advertised in IGP:
>>>-  Is there any implementation?
>>> - Is it useful?
>>>- Does it need to be specified?
>>> 
>>> As of today, there seem to be multiple SPRING (related) document that make 
>>> reference
>> (define/use) to the Binding SIDs. e.g.
>>> - architecture 
>>> https://tools.ietf.org/html/draft-ietf-spring-segment-routing-11#section-
>> 3.5.2
>>> - MPLS instantiation 
>>> https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-
>> 08#section-2
>>> - non-protected paths 
>>> https://tools.ietf.org/html/draft-litkowski-sprin

Re: [spring] [OSPF] OSPFv2 Segment Routing Extensions ERO Extensions (would also effect OSPFv3 and IS-IS) - REPLY TO THIS ONE

[Stefano Previdi (sprevidi)]

Hi Rob,

sorry for the mess. I’m afraid, the problem has been poorly described.

We’re obviously NOT questioning the use of the Binding SID and we’re NOT 
proposing the removal of it.

What we’re talking about is the set of RSVP-like/ERO-like subTLVs that have 
been defined in both isis and ospf protocols and for which, apparently, nobody 
has found yet any use.

Can we try to shutdown the unnecessary noise and confusion ?

Thanks.
s.


> On Jun 12, 2017, at 3:08 PM, Rob Shakir  wrote:
> 
> Bruno, SPRING,
> 
> I am aware of at least one implementation that makes heavy use of Binding 
> SIDs, so I do not think that this is something that we can remove from the 
> protocol specification.
> It seems to me that we have a number of cases that continue to exist that 
> make it useful to have them specified, particularly:
>   • Binding of a SID to a deeper label stack to prevent there being large 
> label stacks required on ingress. This is required due to limited push depth, 
> and limited readable label depths for hashing.
>   • Re-use of some other protocol's or network's forwarding path by a 
> device that is imposing an SR label stack.
> There is not an alternative construct that can be used for this purpose, so 
> we should not remove it.
> 
> In both of these cases there seems, to me, to be a use case for having the 
> information in the IGP in the case that an implementation computes TE paths 
> using cSPF, having binding SID information available to it (along with the 
> ERO) enables it to reduce the label stack depth by finding binding SIDs that 
> follow the same path as the computed ERO. Without the ERO (which might not be 
> an RSVP-TE ERO, but I believe that it how it was first envisaged) how can the 
> head-end of an TE path know what path the advertised Binding SID takes? It's 
> fine to punt this and say "the PCE in the sky will know" - however, I believe 
> SPRING's charter doesn't limit the technology to only centralised computation 
> of paths.
> 
> I don't believe current demand for this is a good reason to remove it from 
> the protocol specification - it is still somewhat early days for folks 
> deploying TE based on SR - where I think the Binding SID concept is most 
> important.
> 
> r.
> 
> On Mon, 12 Jun 2017 at 05:50  wrote:
> Hello SPRING WG,
> 
> I'd like to encourage discussion on this thread.
> 
> The related questions seem to be:
> - Binding SIDs:
> -  Is there any implementation?
> - Is it useful?
> - Does it need to be specified?
> 
> - Binding SIDs advertised in IGP:
> -  Is there any implementation?
>  - Is it useful?
> - Does it need to be specified?
> 
> As of today, there seem to be multiple SPRING (related) document that make 
> reference (define/use) to the Binding SIDs. e.g.
> - architecture 
> https://tools.ietf.org/html/draft-ietf-spring-segment-routing-11#section-3.5.2
> - MPLS instantiation 
> https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-08#section-2
> - non-protected paths 
> https://tools.ietf.org/html/draft-litkowski-spring-non-protected-paths-01#section-3.3
> - SR policies: 
> https://tools.ietf.org/html/draft-filsfils-spring-segment-routing-policy-00#section-7
> 
> 
> However, it also seems a priori possible to define Binding SIDs and not 
> advertised them in the IGP. (e.g. by keeping them local to the PCE)
> 
> On a side note, if the Binding SIDs are removed from the IGP, do they need to 
> be removed from the BGP-LS extensions? [+IDR chairs]
> 
> Thanks,
> Regards,
> --Bruno
> 
> > From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Peter Psenak
> > Sent: Monday, June 12, 2017 10:18 AM
>  > To: OSPF WG List; spring@ietf.org; isis...@ietf.org
>  > Cc: draft-ietf-ospf-segment-routing-extensi...@ietf.org
>  > Subject: Re: [OSPF] OSPFv2 Segment Routing Extensions ERO Extensions 
> (would also effect
>  > OSPFv3 and IS-IS) - REPLY TO THIS ONE
>  >
>  > Hi,
>  >
>  > I would like to get some feedback on the usage of the SID/Label Binding 
> TLV.
>  >
>  > Is there any implementation that uses SID/Label Binding TLV for
>  > advertising the SID/Label binding to a FEC as specified in section 6 of
>  > the draft-ietf-ospf-segment-routing-extensions-16 or section 2.4 of
>  > draft-ietf-isis-segment-routing-extensions-12?
>  >
>  > If not, do we see this as something we want to preserve in the IGP SR
>  > drafts?
>  >
>  > ISIS uses The SID/Label Binding TLV to advertise
>  > prefixes to SID/Label mappings, which is known to be supported by
>  > several implementations and that piece needs to be preserved.
>  >
>  > thanks,
>  > Peter
>  >
>  > On 09/06/17 19:04 , Peter Psenak wrote:
>  > > Acee,
>  > >
>  > > my question is whether we need the whole section 6 and the SID/Label
>  > > Binding Sub-TLV that it specifies. In OSPF Binding SID is not used for
>  > > SRMS advertisement like in ISIS.
>  > >
>  > > thanks,
>  > > Peter
>  > >
>  > >
>  > >
>  > > On 09/06/17 16:45 , Acee Lindem (ace

Re: [spring] I-D Action: draft-ietf-spring-resiliency-use-cases-11.txt

[Stefano Previdi (sprevidi)]

latest addressed comments.

Thanks.
s.


> On May 23, 2017, at 9:12 AM, internet-dra...@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Source Packet Routing in Networking of the 
> IETF.
> 
>Title   : Resiliency use cases in SPRING networks
>Authors : Clarence Filsfils
>      Stefano Previdi
>  Bruno Decraene
>  Rob Shakir
>   Filename: draft-ietf-spring-resiliency-use-cases-11.txt
>   Pages   : 11
>   Date: 2017-05-23
> 
> Abstract:
>   This document identifies and describes the requirements for a set of
>   use cases related to network resiliency on Segment Routing (SPRING)
>   networks.
> 
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-spring-resiliency-use-cases/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-spring-resiliency-use-cases-11
> https://datatracker.ietf.org/doc/html/draft-ietf-spring-resiliency-use-cases-11
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-resiliency-use-cases-11
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> 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] A belated comment on end-to-end path protection in draft-ietf-spring-resiliency-use-cases

[Stefano Previdi (sprevidi)]

> On May 16, 2017, at 4:24 PM, Alexander Vainshtein 
>  wrote:
> 
> Stefano, 
> Lots of thanks for a prompt response.
> 
> 
> I will borrow the quantum mechanics terminology that differentiates between 
> pure and mixed (a.k.a. superposition) states of a quantum system.


I have nothing against quantum mechanics. Even more, I’d really encourage 
anyone to study this wonderful aspects of our universe.

Having said that, I’d remind you that ietf is about engineering, not science 
and we’re not here to list any possible combination of components that we 
describe in a drafts.

We’re here to address REAL problems and REAL requirements expressed by the 
industry that, at the end of the day, deploy and operate what we define and 
implement.

According to all the comments I’ve seen on this read, it looks to me the WG is 
inline with this and it doesn’t appear to me (please correct if I’m wrong) that 
there’s any consensus in extending the list of requirements of the resiliency 
use-cases draft.

Thanks.

s.

PS: nothing prevents you to cook a pizza with ham and chocolate... but that’s 
not a valid reason to do it...




> 
> As long as "mixed" use cases are not strictly prohibited in the draft (and 
> this was at least one possible interpretation of the text), I do not have any 
> issues with restricting it to just two "pure" use cases:
> - End-to-end path protection with disabled local protection
> - Local protection (of some kind) without end-to-end path protection.
> 
> This would leave the question about operational value and complexity of 
> "superposition" use cases open for further discussion.
> 
> Does this correctly reflect your intentions?
> 
> Regards,
> Sasha
> 
> Office: +972-39266302
> Cell:  +972-549266302
> Email:   alexander.vainsht...@ecitele.com
> 
> 
> -Original Message-
> From: Stefano Previdi (sprevidi) [mailto:sprev...@cisco.com] 
> Sent: Tuesday, May 16, 2017 5:01 PM
> To: Stephane Litkowski 
> Cc: Alexander Vainshtein ; spring@ietf.org; 
> Shell Nakash ; Michael Gorokhovsky 
> ; 
> draft-ietf-spring-resiliency-use-ca...@ietf.org; Sidd Aanand 
> ; Ron Sdayoor ; Rotem Cohen 
> 
> Subject: Re: [spring] A belated comment on end-to-end path protection in 
> draft-ietf-spring-resiliency-use-cases
> 
> Hi Stephane,
> 
> 
>> On May 16, 2017, at 11:29 AM, stephane.litkow...@orange.com wrote:
>> 
>> Hi,
>> 
>> I think there is a misunderstanding on what the text says:
>> “  A first protection strategy consists in excluding any local repair
>> 
>>   but instead use end-to-end path protection where each SPRING path 
>> is
>> 
>>   protected by a second disjoint SPRING path.  In this case local
>> 
>>   protection MUST NOT be used.
>> 
>> “
>> 
>> The text presents a design option which is to use end-to-end path protection 
>> and prevent any local-repair. In this option (the text mention: “In this 
>> case”), for sure, we need to prohibit local protection as this is the 
>> requirement of this design option.
> 
> 
> I agree.
> 
> 
>> Now if you want to combine end-to-end protection + local protection, that’s 
>> up to you and that’s another design option. IMO, I would not push for this 
>> combined design as it brings more complexity rather than solving problems, 
>> but it’s a personal design opinion.
> 
> 
> I agree.
> 
> I would add the precision that such option is NOT what the authors of the 
> draft had in mind so I’d suggest to anyone promoting such option to come with 
> some realistic operational requirements.
> 
> Thanks.
> s.
> 
> 
>> 
>> Brgds,
>> 
>> 
>> From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Alexander 
>> Vainshtein
>> Sent: Tuesday, May 16, 2017 10:29
>> To: Stefano Previdi (sprevidi)
>> Cc: spring@ietf.org; Shell Nakash; Michael Gorokhovsky; 
>> draft-ietf-spring-resiliency-use-ca...@ietf.org; Sidd Aanand; Ron 
>> Sdayoor; Rotem Cohen
>> Subject: Re: [spring] A belated comment on end-to-end path protection 
>> in draft-ietf-spring-resiliency-use-cases
>> 
>> 
>> 
>> Regards,
>> Sasha
>> 
>> Office: +972-39266302
>> Cell:  +972-549266302
>> Email:   alexander.vainsht...@ecitele.com
>> 
>> From: Alexander Vainshtein
>> Sent: Tuesday, May 16, 2017 11:28 AM
>> To: 'Stefano Previdi (sprevidi)' 
>> Cc: draft-ietf-spring-resliency-use-ca...@ietf.org; spring@ietf.org; 
>> Shell Nakash ; Michael Gorokhovsky 
>> ; Sidd Aanand 
>> ; Ron Sdayoor ; 
>> Rotem Cohen 
>> Subject: RE: [spring] A belated comm

Re: [spring] A belated comment on end-to-end path protection in draft-ietf-spring-resiliency-use-cases

[Stefano Previdi (sprevidi)]

Hi Stephane,


> On May 16, 2017, at 11:29 AM, stephane.litkow...@orange.com wrote:
> 
> Hi,
>  
> I think there is a misunderstanding on what the text says:
> “  A first protection strategy consists in excluding any local repair
> 
>but instead use end-to-end path protection where each SPRING path is
> 
>protected by a second disjoint SPRING path.  In this case local
> 
>protection MUST NOT be used.
> 
> “
>  
> The text presents a design option which is to use end-to-end path protection 
> and prevent any local-repair. In this option (the text mention: “In this 
> case”), for sure, we need to prohibit local protection as this is the 
> requirement of this design option.


I agree.

 
> Now if you want to combine end-to-end protection + local protection, that’s 
> up to you and that’s another design option. IMO, I would not push for this 
> combined design as it brings more complexity rather than solving problems, 
> but it’s a personal design opinion.


I agree.

I would add the precision that such option is NOT what the authors of the draft 
had in mind so I’d suggest to anyone promoting such option to come with some 
realistic operational requirements.

Thanks.
s.


>  
> Brgds,
>  
>  
> From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Alexander 
> Vainshtein
> Sent: Tuesday, May 16, 2017 10:29
> To: Stefano Previdi (sprevidi)
> Cc: spring@ietf.org; Shell Nakash; Michael Gorokhovsky; 
> draft-ietf-spring-resiliency-use-ca...@ietf.org; Sidd Aanand; Ron Sdayoor; 
> Rotem Cohen
> Subject: Re: [spring] A belated comment on end-to-end path protection in 
> draft-ietf-spring-resiliency-use-cases
>  
>  
>  
> Regards,
> Sasha
>  
> Office: +972-39266302
> Cell:  +972-549266302
> Email:   alexander.vainsht...@ecitele.com
>  
> From: Alexander Vainshtein 
> Sent: Tuesday, May 16, 2017 11:28 AM
> To: 'Stefano Previdi (sprevidi)' 
> Cc: draft-ietf-spring-resliency-use-ca...@ietf.org; spring@ietf.org; Shell 
> Nakash ; Michael Gorokhovsky 
> ; Sidd Aanand ; Ron 
> Sdayoor ; Rotem Cohen 
> Subject: RE: [spring] A belated comment on end-to-end path protection in 
> draft-ietf-spring-resiliency-use-cases
>  
> Stefano,
> Lots of thanks for a prompt response.
>  
> A couple of short comments if you do not mind:
>  
> Using 2119 language in a "use cases" document:
> 1.   Going back to the source I see that “MUST NOT… mean that the 
> definition is an absolute prohibition of the specification”
> 2.   I agree that the use case document defines which scenarios should be 
> addressed, but I do not see how it can impose an absolute prohibition on a 
> certain scenario.
>  
> Little sense link protection has in the case of path protection:
> 1.   This was definitely correct for traditional traffic engineering 
> because the “shortest traffic paths” (e.g., LDL PSPs) could be easily 
> differentiated from the “engineered traffic paths”.
> 2.   In addition, traditional local protection (e.g., MPLS FRR using 
> RSVP-TE) could deal with link and node failures regardless of whether the 
> failed link or node appeared in the ERO of the protected path.
> 3.   IMHO and FWIW, with SR  the situation is quite different:
> o   The shortest traffic paths not only coexist with engineered traffic 
> paths: the latter are in many cases “tunneled” within the former.
> o   Path protection cannot be applied to shortest traffic paths so they must 
> rely on local protection
> o   Local protection in the case of failure of a node or link that appears in 
> the ERO of an engineered SR path is highly non-trivial at best, so path 
> protection for the engineered LSPs looks like a preferred solution to me.
> I fully agree with you that the operators deploying SR should provide 
> feedback on this point based on actual operational experience.
> Meanwhile I doubt that a priori declaring some use cases as absolutely 
> prohibited is the right thing to do.
>  
> My 2c,
> Sasha
>  
> Office: +972-39266302
> Cell:  +972-549266302
> Email:   alexander.vainsht...@ecitele.com
>  
>  
> -Original Message-
> From: Stefano Previdi (sprevidi) [mailto:sprev...@cisco.com] 
> Sent: Monday, May 15, 2017 11:12 AM
> To: Alexander Vainshtein 
> Cc: draft-ietf-spring-resliency-use-ca...@ietf.org; spring@ietf.org; Shell 
> Nakash ; Michael Gorokhovsky 
> ; Sidd Aanand ; Ron 
> Sdayoor ; Rotem Cohen 
> Subject: Re: [spring] A belated comment on end-to-end path protection in 
> draft-ietf-spring-resiliency-use-cases
>  
>  
> > On May 11, 2017, at 12:04 PM, Alexander Vainshtein 
> >  wrote:
> > 
> > Hi all,
> > I have a belated (but hopefully l

Re: [spring] A belated comment on end-to-end path protection in draft-ietf-spring-resiliency-use-cases

[Stefano Previdi (sprevidi)]

> On May 11, 2017, at 12:04 PM, Alexander Vainshtein 
>  wrote:
> 
> Hi all,
> I have a belated (but hopefully late is still better than never) comment on 
> path protection as defined in Section 2 of the draft.
>  
> This second para in this section says:
>A first protection strategy consists in excluding any local repair
> 
>but instead use end-to-end path protection where each SPRING path is
> 
>protected by a second disjoint SPRING path.  In this case local
> 
>protection MUST NOT be used.
> 
> First of all, I do not think that RFC 2119 language should be used in 
> Informational documents, especially in the documents that describe use cases.


this document is also a requirements document for the resiliency use-case. 
RFC2119 terminology is perfectly usable and even more, it adds clarity on what 
the solution is expected to provide.


> In addition, I specifically disagree with the quoted statement above, 
> because, from my POV:
> · Local repair and end-to-end path protection can be combined for the 
> same path
> · Such a combination may be beneficial for the operators.


are you talking by experience or is it just something that came into your mind 
? I’d like to hear from operators using a combination of path and link 
protection.

This document has been deeply reviewed also by operators and it has been always 
obvious the little sense link protection has in case of path protection.


> One possible way to combine the two is described below:
>  
> 1.   A pair of SR paths is set up between the given two nodes – later 
> referred to as source and destination -  in the network. These paths are 
> “SR-disjoint” in the sense that their “explicit routes”  do not have any 
> common elements, be they nodes or adjacencies, with exclusion of the final 
> destination
> 2.   Local repair for these paths is enabled in the network. It is 
> triggered by locally observed events (link failures etc.), applied by the 
> nodes adjacent to the failure and guarantees that, in the case of a link or 
> node failure that is not specified in the explicit route, traffic along the 
> affected path would be restored within  milliseconds
> 3.   End-to-end liveness monitoring is enabled for the two SR paths, and 
> detects end-to-end failures of these paths within  milliseconds where Y >> 
> X. In other words, end-to-end liveness monitoring for these paths will ignore 
> any failures that local repair can fix, but will detect failures that cannot 
> be locally repaired (e.g., failures of nodes or links that have been 
> specified in the explicit route of one of the paths
> 4.   End-to-end liveness monitoring triggers end-to-end path protection 
> to be applied by the source node in the following way:
> a.   If it recognizes both paths as alive, one of them will carry the 
> customer traffic, while the other one will be idle. The rules for selecting 
> the active path in this scenario may vary
> b.  If end-to-end failure of one of these paths is detected while the 
> other one remains alive, traffic will be carried across the live path
> c.   If end-to-end failure of both paths is detected (e.g., if the final 
> destination node fails, or if the network is partitioned), this is recognized 
> as an unrecoverable failure.
>  
> From my POV the combination of local repair and end-to-end protection for SR 
> paths is one of a few possibilities to protect such paths against failures of 
> nodes and/or links that have been specified in their explicit routes. 
> (Another option has been described in Node Protection for SR-TE Paths, but 
> this draft has expired).
>  
> Do I miss something substantial?


to my view you created a use-case that doesn’t bring much to the picture but 
I’d let operators to comment.

s.


>  
> Regards,
> Sasha
>  
> Office: +972-39266302
> Cell:  +972-549266302
> Email:   alexander.vainsht...@ecitele.com
>  
> 
> ___
> 
> 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

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

Re: [spring] I-D Action: draft-ietf-spring-resiliency-use-cases-10.txt

[Stefano Previdi (sprevidi)]

Now, hopefully, this version addresses all comments (one was missing).

s.


> On May 8, 2017, at 7:40 PM, internet-dra...@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Source Packet Routing in Networking of the 
> IETF.
> 
>Title   : Resiliency use cases in SPRING networks
>Authors : Clarence Filsfils
>      Stefano Previdi
>  Bruno Decraene
>  Rob Shakir
>   Filename: draft-ietf-spring-resiliency-use-cases-10.txt
>   Pages   : 11
>   Date: 2017-05-08
> 
> Abstract:
>   This document identifies and describes the requirements for a set of
>   use cases related to network resiliency on Segment Routing (SPRING)
>   networks.
> 
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-spring-resiliency-use-cases/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-spring-resiliency-use-cases-10
> https://datatracker.ietf.org/doc/html/draft-ietf-spring-resiliency-use-cases-10
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-resiliency-use-cases-10
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> 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] Genart last call review of draft-ietf-spring-ipv6-use-cases-10

[Stefano Previdi (sprevidi)]

> On May 5, 2017, at 11:52 AM, Stewart Bryant  wrote:
> 
> Alternatively maybe it would be better to have a single use case: Operators 
> that wish to deploy SR without an MPLS control plane,


I’d agree with the above. Let’s simplify the document with, at the end, what is 
the simplest and most evident use case.

s.

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

Re: [spring] RtgDir review: draft-ietf-spring-resiliency-use-cases-08

[Stefano Previdi (sprevidi)]

Hi Stephane, Lou,

sorry, I missed that comment (in fact I did get it but forgot to address it).

I will add the necessary text and will submit a new version asap.

s.


> On May 4, 2017, at 9:50 AM, stephane.litkow...@orange.com wrote:
> 
> Hi Stefano,
> 
> Speaking as doc Shepherd, I do not see in the V09, how you are addressing 
> Lou's point about 1:1 and 1+1 protection in the Section 2.
> I think it make sense to add a simple explicit statement that  SPRING should 
> support both approach. It is partially addressed by " The two paths may be 
> used concurrently or as a primary and backup
>   path where the secondary path is used when the primary failed." 
> But the "concurrently" word is IMO ambiguous as it could mean 1+1 scheme or 
> ECMP like behavior.
> 
> Brgds,
> 
> 
> -Original Message-
> From: Stefano Previdi (sprevidi) [mailto:sprev...@cisco.com] 
> Sent: Friday, April 28, 2017 12:54
> To: Lou Berger
> Cc: rtg-...@ietf.org; rtg-...@ietf.org; 
> draft-ietf-spring-resiliency-use-cases@ietf.org; spring@ietf.org
> Subject: Re: RtgDir review: draft-ietf-spring-resiliency-use-cases-08
> 
> Hi Lou,
> 
> thanks for the comment. I integrated them in the new version I’ll submit asap.
> 
> Thanks.
> s.
> 
> 
>> On Apr 24, 2017, at 6:15 PM, Lou Berger  wrote:
>> 
>> Hello,
>> 
>> I have been selected as the Routing Directorate reviewer for this draft.
>> The Routing Directorate seeks to review all routing or routing-related 
>> drafts as they pass through IETF last call and IESG review, and 
>> sometimes on special request. The purpose of the review is to provide 
>> assistance to the Routing ADs. For more information about the Routing 
>> Directorate, please see 
>> ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
>> 
>> Although these comments are primarily for the use of the Routing ADs, 
>> it would be helpful if you could consider them along with any other 
>> IETF Last Call comments that you receive, and strive to resolve them 
>> through discussion or by updating the draft.
>> 
>> Document: draft-ietf-spring-resiliency-use-cases-08
>> Reviewer: Lou Berger
>> Review Date: April 24
>> Intended Status: Informational
>> 
>> Summary:
>> 
>>   I have some minor comments about this document that I think would 
>> be good, but not necessary, to be resolved before publication.
>> 
>> Comments:
>> 
>> This document is concise and clear.  I only have minor/nit level 
>> issues that could be addressed before publication, but I don't think 
>> it critical as the document is being published as Informational.
>> 
>> Major Issues:
>> 
>>  No major issues found.
>> 
>> Minor Issues:
>> 
>> - Section 2 mentions reversion, while sections 3 and 4 do not.
>> This leaves reversion requirements open to interpretation.
>> I suggest explicitly stating if reversion is a required  option or 
>> not in sections 3 and 4 as well.
>> 
>> - Section 2 mentions 1:1 style path protection.  Past/other work  on 
>> protection also allowed for / uses 1+1 style protection.  Is
>> 1+1 intentionally omitted? If not, I suggest allowing for it.
>> 
>> Nits:
>> 
>>> referred to as local protection techniques or Fast Reroute  
>>> techniques.
>> 
>> References should be provided for each technique.
>> 
>>>  It is essential that the primary and backup path benefit from an end-
>>>  to-end liveness monitoring/verification.  The method and mechanisms
>>>  that provide such liveness check are outside the scope of this
>>>  document.
>> 
>> Given the importance of liveness monitoring, I think it would be worth 
>> mentioned an example of such.
>> 
>> That's it!
>> Lou
>> 
> 
> 
> _
> 
> 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] I-D Action: draft-ietf-spring-segment-routing-ldp-interop-07.txt

[Stefano Previdi (sprevidi)]

this version integrates shepherd review comments.

Thanks.
s.


> On May 2, 2017, at 4:48 PM, internet-dra...@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Source Packet Routing in Networking of the 
> IETF.
> 
>Title   : Segment Routing interworking with LDP
>Authors : Clarence Filsfils
>      Stefano Previdi
>  Ahmed Bashandy
>  Bruno Decraene
>  Stephane Litkowski
>   Filename: draft-ietf-spring-segment-routing-ldp-interop-07.txt
>   Pages   : 20
>   Date: 2017-05-02
> 
> Abstract:
>   A Segment Routing (SR) node steers a packet through a controlled set
>   of instructions, called segments, by prepending the packet with an SR
>   header.  A segment can represent any instruction, topological or
>   service-based.  SR allows to enforce a flow through any topological
>   path and service chain while maintaining per-flow state only at the
>   ingress node to the SR domain.
> 
>   The Segment Routing architecture can be directly applied to the MPLS
>   data plane with no change in the forwarding plane.  This drafts
>   describes how Segment Routing operates in a network where LDP is
>   deployed and in the case where SR-capable and non-SR-capable nodes
>   coexist.
> 
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-ldp-interop/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-spring-segment-routing-ldp-interop-07
> https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-ldp-interop-07
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-segment-routing-ldp-interop-07
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> I-D-Announce mailing list
> i-d-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

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

Re: [spring] I-D Action: draft-ietf-spring-resiliency-use-cases-09.txt

[Stefano Previdi (sprevidi)]

this version integrates the latest comments from GENART, OPSDIR and RTGDIR 
reviews.

s.


> On May 2, 2017, at 4:43 PM, internet-dra...@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Source Packet Routing in Networking of the 
> IETF.
> 
>Title   : Resiliency use cases in SPRING networks
>Authors : Clarence Filsfils
>      Stefano Previdi
>  Bruno Decraene
>  Rob Shakir
>   Filename: draft-ietf-spring-resiliency-use-cases-09.txt
>   Pages   : 11
>   Date: 2017-05-02
> 
> Abstract:
>   This document identifies and describes the requirements for a set of
>   use cases related to network resiliency on Segment Routing (SPRING)
>   networks.
> 
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-spring-resiliency-use-cases/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-spring-resiliency-use-cases-09
> https://datatracker.ietf.org/doc/html/draft-ietf-spring-resiliency-use-cases-09
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-resiliency-use-cases-09
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> I-D-Announce mailing list
> i-d-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

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

Re: [spring] Genart last call review of draft-ietf-spring-resiliency-use-cases-08

[Stefano Previdi (sprevidi)]

> On May 1, 2017, at 10:02 PM, Brian E Carpenter  
> wrote:
> 
> Stefano,
> 
> I won't argue further about the general issues, they are really
> between you and the ADs. About this:
> 
> ...
>>> Minor issue:
>>> 
>>> 
>>> The text of section 3 doesn't explain what requirements for SPRING it
>>> generates. Really it just describes what any IGP will do anyway.
>> 
>> 
>> not really. Igp’s compute Dijkstra-based shortest paths. Igp’s do not 
>> compute repair paths (whatever flavor: dual, parallel, disjoint, etc).
> 
> Yes, but that is a comment on DV or SPF algorithms: in principle an IGP could 
> use other algorithms, should they be invented. Indeed, you refer to 
> "Automated computation by the IGP.”


well, the whole FRR and LFA story is based on LS protocols so DV is out of the 
picture here.


> 
>>> How does that impact SPRING? If there is no impact, please say so!
>> 
>> 
>> spring is about source routing and resiliency makes use of source routing. 
>> Resiliency makes use of source routing through SR.
> 
> Right, but you don't state any *requirements* for SPRING that result from 
> this case,
> except the very general statement before section 3.1. Maybe that does 
> translate
> into specific requirements, but I don't see how.


the generic requirement is the ability to instantiate source routed paths. 
These source routed paths, in the framework of this draft, are for LFAs.

Thanks.
s.



> 
>   Brian
> 

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

Re: [spring] Genart last call review of draft-ietf-spring-resiliency-use-cases-08

[Stefano Previdi (sprevidi)]

> On May 1, 2017, at 4:03 AM, Brian Carpenter  
> wrote:
> 
> Reviewer: Brian Carpenter
> Review result: Ready with Issues
> 
> Gen-ART Last Call review of draft-ietf-spring-resiliency-use-cases-08
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> .
> 
> Document: draft-ietf-spring-resiliency-use-cases-08.txt
> Reviewer: Brian Carpenter
> Review Date: 2017-05-01
> IETF LC End Date: 2017-05-04
> IESG Telechat date:  
> 
> Summary: Ready with issues
> 
> 
> Comment:
> 
> 
> I wonder about the value to the community of publishing use cases and
> requirements late in the standards process. They clearly have value
> while designing solutions, but do they really have archival value,
> since
> RFC7855 was published a year ago? (An alternative approach to use
> case
> documents is to structure them as example applications to validate
> the
> protocol design, but that would be a major rewrite.)


when spring was formed, it has been required from the AD (in charge at that 
time) to provide a problem-statement and use-case documents, hence this and the 
other use cases documents.

The resiliency use cases draft describes one of the major requirements for SR. 
LFAs, and their intrinsic characteristic of being topology-dependent, have been 
worked out for many years without reaching the complete (any topology) 
coverage. SR closed the loop and we have now the ability to not only have a 
complete topology-independent LFA coverage, but also an efficient 
microloop-avoidance mechanisms. Therefore, it is important to have an ietf 
document describing the use-case that illustrates/drives the architectural 
choices of SR (and the related extensions of igp/bgp protocols).

Now, one can argue that we are late in the process but so far no architectural 
document or even protocol extension have been standardized yet (even if for 
some of them we’re pretty well advanced). This is easily explained by the 
amount of SR drafts and the number of people involved in the. We had a lot of 
interactions (most of them have been extremely useful and constructive) and 
this, of course, consumes some time.

Also, I’ve been told (but I may be wrong) that some ietf documents are still 
not sorted out after more than 18 years... so we have some room here ;-)


> Major issue: 
> 
> 
> I agree with the AD review dated 2017-04-20; if we publish a use case
> document of this kind, it should be historically consistent.


which it seems they are knowing that no architectural document is published 
yet. 


> Minor issue:
> 
> 
> The text of section 3 doesn't explain what requirements for SPRING it
> generates. Really it just describes what any IGP will do anyway.


not really. Igp’s compute Dijkstra-based shortest paths. Igp’s do not compute 
repair paths (whatever flavor: dual, parallel, disjoint, etc).


> How does that impact SPRING? If there is no impact, please say so!


spring is about source routing and resiliency makes use of source routing. 
Resiliency makes use of source routing through SR.


> The other sections are quite clear on this aspect.


Thanks for your review.

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

Re: [spring] RtgDir review: draft-ietf-spring-resiliency-use-cases-08

[Stefano Previdi (sprevidi)]

Hi Lou,

thanks for the comment. I integrated them in the new version I’ll submit asap.

Thanks.
s.


> On Apr 24, 2017, at 6:15 PM, Lou Berger  wrote:
> 
> Hello,
> 
> I have been selected as the Routing Directorate reviewer for this draft.
> The Routing Directorate seeks to review all routing or routing-related
> drafts as they pass through IETF last call and IESG review, and
> sometimes on special request. The purpose of the review is to provide
> assistance to the Routing ADs. For more information about the Routing
> Directorate, please see
> ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
> 
> Although these comments are primarily for the use of the Routing ADs, it
> would be helpful if you could consider them along with any other IETF
> Last Call comments that you receive, and strive to resolve them through
> discussion or by updating the draft.
> 
> Document: draft-ietf-spring-resiliency-use-cases-08
> Reviewer: Lou Berger
> Review Date: April 24
> Intended Status: Informational
> 
> Summary:
> 
>I have some minor comments about this document that I think would be
> good, but not necessary, to be resolved before publication.
> 
> Comments:
> 
> This document is concise and clear.  I only have minor/nit level issues
> that could be addressed before publication, but I don't think it
> critical as the document is being published as Informational.
> 
> Major Issues:
> 
>   No major issues found.
> 
> Minor Issues:
> 
> - Section 2 mentions reversion, while sections 3 and 4 do not.
>  This leaves reversion requirements open to interpretation.
>  I suggest explicitly stating if reversion is a required
>  option or not in sections 3 and 4 as well.
> 
> - Section 2 mentions 1:1 style path protection.  Past/other work
>  on protection also allowed for / uses 1+1 style protection.  Is
>  1+1 intentionally omitted? If not, I suggest allowing for it.
> 
> Nits:
> 
>>  referred to as local protection techniques or Fast Reroute
>>  techniques.
> 
> References should be provided for each technique.
> 
>>   It is essential that the primary and backup path benefit from an end-
>>   to-end liveness monitoring/verification.  The method and mechanisms
>>   that provide such liveness check are outside the scope of this
>>   document.
> 
> Given the importance of liveness monitoring, I think it would be worth
> mentioned an example of such.
> 
> That's it!
> Lou
> 

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

Re: [spring] New Version Notification for draft-gulkohegde-routing-planes-using-sr-00.txt

[Stefano Previdi (sprevidi)]

Hi Pushpasis,

I agree. The problem/use-case is already described in RFC7855, the required 
protocol extensions are already documented in ospf, isis and bgp drafts, we 
already have multiple implementations, and deployments have been done.

s.


> On Mar 14, 2017, at 8:20 AM, Pushpasis Sarkar  
> wrote:
> 
> Hi Authors,
> 
> First I must admit that I have not read the entire draft in details... 
> 
> But from the abstract it seems that for the problem that this draft is trying 
> to address, a similar problem is already addressed in the Segment Routing 
> Problem Statement and Use-Case document (RFC 7855, section 3.3.1.1.1. 
> Disjointness in Dual-Plane Networks). And the same has been solved using any 
> cast segments as specified in draft-ietf-spring-mpls-anycast-segment. 
> 
> Request you to clarify why we need the solution proposed in this draft over 
> the one proposed in draft-ietf-mpls-anycast-segments.. 
> 
> Thanks and Best regards,
> -Pushpasis
> 
> 
> On Mon, Mar 13, 2017 at 8:25 PM, Shraddha Hegde  wrote:
> Hi All,
> 
> New draft submitted for "separating routing planes using segment routing".
> Looking for inputs and comments.
> 
> PS: The draft erroneously got submitted as individual and not affiliated to 
> any WG but the intention was to submit it to SPRING WG.
> We will correct it once the submission window opens. Apologies for the 
> inconvenience.
> 
> Rgds
> Shraddha
> 
> 
> -Original Message-
> From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
> Sent: Monday, March 13, 2017 11:57 PM
> To: arkadiy.gu...@thomsonreuters.com ; 
> Shraddha Hegde ; Arkadiy Gulko 
> 
> Subject: New Version Notification for 
> draft-gulkohegde-routing-planes-using-sr-00.txt
> 
> 
> A new version of I-D, draft-gulkohegde-routing-planes-using-sr-00.txt
> has been successfully submitted by Shraddha Hegde and posted to the IETF 
> repository.
> 
> Name:   draft-gulkohegde-routing-planes-using-sr
> Revision:   00
> Title:  Separating Routing Planes using Segment Routing
> Document date:  2017-03-13
> Group:  Individual Submission
> Pages:  7
> URL:
> https://www.ietf.org/internet-drafts/draft-gulkohegde-routing-planes-using-sr-00.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-gulkohegde-routing-planes-using-sr/
> Htmlized:   
> https://tools.ietf.org/html/draft-gulkohegde-routing-planes-using-sr-00
> 
> 
> Abstract:
>Many network deployments arrange the network topologies in two or
>more planes.  The traffic generally uses one of the planes and fails
>over to the other plane when there are link or node failure.  Certain
>applications require the traffic to be strictly restricted to a
>particular plane and should not failover to the other plane.  This
>document proposes a solution for the strict planar routing using
>Segment Routing.
> 
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission 
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
> ___
> 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

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

Re: [spring] [Idr] IDR WG 2 week WG LC on draft-ietf-idr-bgpls-segment-routing-epe - (2/15/2017 to 3/1/2017)

[Stefano Previdi (sprevidi)]

John, Bruno,

sorry for having missed that. I’ll resubmit right now. I integrated all 
comments. Regarding the missing "section 3.1" (referring to the isis draft), I 
replaced text with the reference to draft-ietf-idr-bgp-ls-segment-routing-ext 
which defines the bgp-ls tlv for advertising the SRGB. I gave this as an 
example. I also moved draft-ietf-spring-segment-routing into the normative 
references section.

Thanks.

s.


> On Mar 10, 2017, at 8:52 PM, John G.Scudder  wrote:
> 
> Hi Authors,
> 
> I see that yesterday's -10 revision doesn't address Bruno's comments, below. 
> Can you please either update the document if you accept Bruno's suggestions, 
> or otherwise discuss them on the list? We can't declare the WGLC to be 
> satisfactorily finished until this is resolved.
> 
> Thanks,
> 
> --John
> 
>> On Feb 16, 2017, at 11:50 AM, bruno.decra...@orange.com wrote:
>> 
>> Hi,
>>  
>> I’ve read the draft, please find below some minor comments:
>>  
>> ---
>> §4.3
>> "  *  A 4 octet index defining the offset in the SID/Label space 
>> advertised by this router using the encodings defined in  Section 3.1."
>>  
>> - Following the recent addition of the SRLB Label Space, I'd rather have the 
>> text explicitly refers to name of that Label space. e.g.
>> OLD: SID/Label space
>> NEW: SRGB
>>  
>> - Which (SRGB) advertisement? I'm assuming the IGP one, but I guess someone 
>> may imagine using the BGP "Originator SRGB TLV". Then what if the node runs 
>> multiple IGP with different SRGB configured?
>>  
>> - Note that this document has no "Section 3.1". The text seems borrowed from 
>> the IS-IS SR draft, hence may be adding the name of this draft would just 
>> solve the point. (with a normative reference to this IS-IS draft)
>>  
>> ---
>> OLD: The Link NLRI uses the new Protocol-ID value (to be assigned by IANA)
>> proposed NEW: The Link NLRI uses the BGP Protocol-ID (TBD1)
>>  
>> (“new” may become unspecific 2 years from now)
>>  
>> ---
>> One could probably argue that [I-D.ietf-spring-segment-routing] should be a 
>> normative reference.
>>  
>> Thanks,
>> Regards,
>> --Bruno
>>  
>>  
>> From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Susan Hares
>> Sent: Thursday, February 16, 2017 12:35 AM
>> To: i...@ietf.org
>> Cc: 'Alvaro Retana (aretana)'; spring@ietf.org
>> Subject: [spring] IDR WG 2 week WG LC on 
>> draft-ietf-idr-bgpls-segment-routing-epe - (2/15/2017 to 3/1/2017)
>>  
>> This begins a 2 week IDR WG last call on 
>> draft-ietf-idr-bgpls-segment-routing-epe from (2/15 to 3/1/2017)There 
>> are two implementations describe on the wiki at:
>> https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgpls-segment-routing-epe%20
>>  
>> The two implementation are from  Cisco IOS-XR release 6.0.2 and Cisco Nexus 
>> Switch N9000/N3000 platforms running NX-OS 7.0(3)I1(1) or greater.   The 
>> authors will indicate on the list and in the wiki the following information :
>>  
>> 1)  Were these implementations separate implementations?
>> 2)  What were the results of the interoperability tests?
>>  
>> This work is linked to the draft-ietf-spring-segment-routing-central-epe 
>> work in the SPRING WG. Based on the two drafts, the WG should might 
>> consider:  
>> 1)  Is there need for this work in deployments in networks/
>> 2)  Is this technically ready for publication?
>> 3)  Does it fit with the spring informational draft?
>>  
>> For the ease of reference the web references are below:
>> https://datatracker.ietf.org/doc/draft-ietf-idr-bgpls-segment-routing-epe/
>> https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-central-epe/
>>  
>> Sue Hares 
>> _
>> 
>> 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.
>> 
>> ___
>> Idr mailing list
>> i...@ietf.org
>> https://www.ietf.org/mailman/listinfo/idr
> 

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

Re: [spring] I-D Action: draft-ietf-spring-segment-routing-mpls-08.txt

[Stefano Previdi (sprevidi)]

updated version after reviews.

s.


> On Mar 10, 2017, at 9:21 AM, internet-dra...@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Source Packet Routing in Networking of the 
> IETF.
> 
>Title   : Segment Routing with MPLS data plane
>Authors : Clarence Filsfils
>      Stefano Previdi
>  Ahmed Bashandy
>  Bruno Decraene
>  Stephane Litkowski
>  Rob Shakir
>   Filename: draft-ietf-spring-segment-routing-mpls-08.txt
>   Pages   : 11
>   Date: 2017-03-10
> 
> Abstract:
>   Segment Routing (SR) leverages the source routing paradigm.  A node
>   steers a packet through a controlled set of instructions, called
>   segments, by prepending the packet with an SR header.  In the MPLS
>   dataplane, the SR header is instantiated through a label stack.  A
>   segment can represent any instruction, topological or service-based.
>   Additional segments can be defined in the future.  SR allows to
>   enforce a flow through any topological path and/or service chain
>   while maintaining per-flow state only at the ingress node to the SR
>   domain.
> 
>   Segment Routing can be directly applied to the MPLS architecture with
>   no change in the forwarding plane.  This drafts describes how Segment
>   Routing operates on top of the MPLS data plane.
> 
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-mpls/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-08
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-segment-routing-mpls-08
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> I-D-Announce mailing list
> i-d-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

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

Re: [spring] I-D Action: draft-ietf-spring-segment-routing-central-epe-05.txt

[Stefano Previdi (sprevidi)]

this is the updated version after the various reviews.

Thanks.
s.


> On Mar 10, 2017, at 9:15 AM, internet-dra...@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Source Packet Routing in Networking of the 
> IETF.
> 
>Title   : Segment Routing Centralized BGP Egress Peer 
> Engineering
>Authors : Clarence Filsfils
>  Stefano Previdi
>  Ebben Aries
>  Dmitry Afanasiev
>   Filename: draft-ietf-spring-segment-routing-central-epe-05.txt
>   Pages   : 19
>   Date: 2017-03-10
> 
> Abstract:
>   Segment Routing (SR) leverages source routing.  A node steers a
>   packet through a controlled set of instructions, called segments, by
>   prepending the packet with an SR header.  A segment can represent any
>   instruction topological or service-based.  SR allows to enforce a
>   flow through any topological path and service chain while maintaining
>   per-flow state only at the ingress node of the SR domain.
> 
>   The Segment Routing architecture can be directly applied to the MPLS
>   dataplane with no change on the forwarding plane.  It requires a
>   minor extension to the existing link-state routing protocols.
> 
>   This document illustrates the application of Segment Routing to solve
>   the BGP Egress Peer Engineering (BGP-EPE) requirement.  The SR-based
>   BGP-EPE solution allows a centralized (Software Defined Network, SDN)
>   controller to program any egress peer policy at ingress border
>   routers or at hosts within the domain.
> 
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-central-epe/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-spring-segment-routing-central-epe-05
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-segment-routing-central-epe-05
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> I-D-Announce mailing list
> i-d-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

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

Re: [spring] I-D Action: draft-ietf-spring-segment-routing-msdc-04.txt

[Stefano Previdi (sprevidi)]

new version with, hopefully, all comments, questions and issues being addressed.

Thanks.
s.

> On Mar 9, 2017, at 1:05 PM, internet-dra...@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Source Packet Routing in Networking of the 
> IETF.
> 
>Title   : BGP-Prefix Segment in large-scale data centers
>Authors : Clarence Filsfils
>      Stefano Previdi
>  Jon Mitchell
>  Ebben Aries
>  Petr Lapukhov
>   Filename: draft-ietf-spring-segment-routing-msdc-04.txt
>   Pages   : 25
>   Date: 2017-03-09
> 
> Abstract:
>   This document describes the motivation and benefits for applying
>   segment routing in BGP-based large-scale data-centers.  It describes
>   the design to deploy segment routing in those data-centers, for both
>   the MPLS and IPv6 dataplanes.
> 
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-msdc/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-spring-segment-routing-msdc-04
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-segment-routing-msdc-04
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> I-D-Announce mailing list
> i-d-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

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

Re: [spring] Routing directorate review of draft-ietf-spring-segment-routing-central-epe-04

[Stefano Previdi (sprevidi)]

Hi Jon,

many thanks for your review. Some comments inline.

where you don’t see any answer to your comments is because I applied them to 
the draft.


> On Mar 7, 2017, at 7:35 PM, Jonathan Hardwick 
>  wrote:
> 
> Hello
> 
> I have been selected to do a routing directorate “early” review of this draft.
> https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-central-epe/
> 
> The routing directorate will, on request from the working group chair, 
> perform an “early” review of a draft before it is submitted for publication 
> to the IESG.  The early review can be performed at any time during the 
> draft’s lifetime as a working group document.  The purpose of the early 
> review depends on the stage that the document has reached.  As this document 
> is in working group last call, my focus for the review was to determine 
> whether the document is ready to be published.  Please consider my comments 
> along with the other working group last call comments.
> 
> For more information about the Routing Directorate, please see 
> ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
> 
> Best regards
> Jon
> 
> 
> Document: draft-ietf-spring-segment-routing-central-epe-04.txt
> Reviewer: Jonathan Hardwick
> Review Date: 7 March 2017
> Intended Status: Informational
> 
> Summary
> Congratulations on a very clear and well-written document.  I have a few 
> minor comments below but otherwise the document looks ready to advance.
> 
> Abstract
> s/It requires minor/It requires a minor/
> Expand acronym SDN on 1st use
> 
> Section 1
> s/SID's/SIDs/
> 3rd bullet - why is the reference here?


I believe you refer to this paragraph:

   [I-D.ietf-spring-segment-routing] defines three types of BGP peering
   segments/SID's: PeerNode SID, PeerAdj SID and PeerSet SID.

the peerNode/Adj/Set segment are indeed defined in 
draft-ietf-spring-segment-routing. In this draft we illustrate the use case and 
the SR solution to it.


> "The solution is described for IPv4..." - I am obliged to discourage the use 
> of exclusively IPv4 examples in this document.  See 
> https://www.iab.org/2016/11/07/iab-statement-on-ipv6/.


I’ll work out that... there’s a substantial amount of addresses so I’ll be sure 
not to mess up everything ;-)


> Section 1.1 can be removed - section 13 lists the references.
> Section 1.2 bullet 6: s/ingress EPE/ingress PE/
> Section 1.2 bullet 6: s/at an source/at a source/
> 
> Section 3
> I found it a bit strange that you did not list the PeerNode segments 
> contiguously in this section (they are 1012, 1022 and 1052).  But it's not a 
> big deal - I can live with it.
> Section 3.6 s/An BGP-EPE enabled/A BGP-EPE enabled/
> 
> It's not clear if the FRR behaviour you are specifying in 3.6 is mandatory or 
> just an example. 


in fact it’s just an illustrative example. I changed the “SHOULD” into a “MAY” 
and added more text.


>  However, the PeerNode SID and PeerAdj SID have the following backup rule.
> "2. Else backup via another PeerNode SID to the same AS."
> 
> That's reasonable under some circumstances but it might not agree with the 
> policy of the adjacent AS.  For whatever reason that AS might want to steer 
> traffic to certain IP destinations away from certain links, by not 
> advertising BGP routes over those links, or advertising them with different 
> MEDs.  Is there scope for the EPE controller taking these preferences into 
> account?


yes, that’s a good point and I added text on that.


> Section 4
> s/an BGP-EPE controller/a BGP-EPE controller/
> Section 4.1: When you say "engineered peers" do you mean "BGP-EPE enabled 
> border routers"?
> Section 4.1: "add-path all" sounds like a vendor specific CLI command.  Could 
> you rephrase as "with the router configured to advertise all paths using BGP 
> add-path [RFC7911]"?
> 
> Section 4.3: s/described in the section 2 (BGP-LS advertisements)/described 
> in section 2/
> Section 4.4 s/an BGP-EPE/a BGP-EPE/
> 
> Section 4.6 This section leaves me with a few questions.  What are "business 
> policies"?  How should they be collected, and why?  Do you mean "collected" 
> or "configured”?s


it could be both but of course these mechanisms are out of scope of this draft.


> Section 4.7: What is SID 64?  I infer it's the SID for PE C.  It should 
> probably be given in section 3.


it is defined in 1.2

  “C’s loopback is 203.0.113.3/32 with SID 64”

I added a reference.


> Section 5
> Section 5.2 "The tunnel and the steering policy could be configured via..." - 
> Do we need a list?  It could also be configured by CLI - does it matter?
> Section 5.3 s/them BGP upstream peers/their BGP upstream peers/
> Section 5.4 This example confused me as it appears to contradict section 1.2 
> bullet 1 when applied to Internet traffic.  Or is this example just talking 
> about an inter-AS L3VPN service?


It’s doesn’t need to be “inter-AS”=. It’s a way to build a vpn route in the 
controller with a vpn label representing an EPE resource (pee

Re: [spring] [RTG-DIR] Review of draft-ietf-spring-segment-routing-msdc-03

[Stefano Previdi (sprevidi)]

> On Mar 7, 2017, at 3:30 PM, Susan Hares  wrote:
> 
> Stefano: 
> 
> Summary:  As I have often said, I believe in helping BGP meet the needs of 
> operators (DC or BGP), and this includes BGP-LS.  If your transition from 
> OSPF/IS-IS LSPs to BGP in BGP to MPLS is to meet operator needs - great.   
> Just document the security concern issues (new types of information, privacy 
> issues on sending link info). 
> 
> My "concern" comments on BGP-LS only focus on 3 things: 
> 1) Upgrade your security section to deal with issues regarding new types of 
> information and privacy issues on sending link-information (inside DC or DCI) 


agreed and will do so. Note also that EPE is just one piece of the picture 
described in the draft.


> 1 to 3 paragraphs should be sufficient.  I will suggest text. 
> 2) Be precise in your RFC3107 terminology - 


agreed. I added some text explaining what we intend by 3107 ebgp and ibgp.


> 3)  Encourage the use of 4-byte Private AS, and treat 2-byte Private ASes as 
> a legacy issues. 


ok, will do so.


> All response below boil down to this summary.   Editorial Nits are your 
> choice to adopt/not-adopt.  IETF LC and IESG review will provide you lots of 
> feedback on editorial nits.


yup, I applied all of them.

Thanks.
s.


>  
> 
> Sue 
> 
> -Original Message-
> From: rtg-dir [mailto:rtg-dir-boun...@ietf.org] On Behalf Of Stefano Previdi 
> (sprevidi)
> Sent: Tuesday, March 7, 2017 6:21 AM
> To: Susan Hares
> Cc: rtg-...@ietf.org; spring@ietf.org; i...@ietf.org; 
> draft-ietf-spring-segment-routing-msdc@ietf.org
> Subject: Re: [RTG-DIR] [spring] Review of 
> draft-ietf-spring-segment-routing-msdc-03
> 
> Hi Sue,
> 
> thanks for the review. Some comments below.
> 
> 
>> On Mar 6, 2017, at 5:25 PM, Susan Hares  wrote:
>> 
>> Reviewer: Susan Hares
>> Review result: Has Issues
>> 
>> The RTG-DIR has the categories:  minor concerns or major concerns 
>> regarding "issues", I wil differentiate my issues by this quality.
>> I also have editorial nits regardign under specified text. 
>> 
>> Major concerns: 
>> 1) The security section is not sufficient for any review by the 
>> Security area
>> 
>> This draft depends on IDR WG draft (ietf-idr-bgp-prefix-sid) that 
>> defines the BGP Segment attribute.  If this attribute is used with 
>> IPv6, this simply gives more infromation about a link to a next.
>> However, the combination of this information with the information 
>> passed using draft-ietf-idr-bgpls-segment-routing-epe-09 that utilizes 
>> BGP to pass BGP topologies in BGP - requires a better security 
>> section.  BGP-LS was described to be an "information gathering"
>> function handled by a few routers on the edge of the network to obtain 
>> link-state topology information.  The BGP peers would carry this 
>> information in a separate informational stream.  With this constraint,
>> it was approved by the IESG.   
> 
> Stefano: well, we have now different models that have been deployed and 
> assuming that bgp-ls uses a separate stream is not accurate if we look what’s 
> in the industry.  However, I take your point and I agree that more text in 
> the security section is required in order to emphasize that the model the 
> draft addresses is internal (DC and interconnected DC over a 
> same-administration network).
> 
> Sue:  Good.  I look forward to your security section.  Please note to clearly 
> state (or reference) whether the interconnected DC is over physically 
> isolated or logically isolated on shared infrastructure.   Please indicated 
> any privacy issues. 
> 
>> draft-ietf-idr-bgpls-segment-routing-epe  expands the initial concept 
>> of BGP-LS from "information gathering" to a full-routing scheme of BGP 
>> within BGP for data centers and for data center interconnection to the 
>> network.
> 
> Stefano: EPE defines a model where the topology of the peering point (not the 
> network, just the peering point) is advertised to an internal server.
> Yes, but the topology of peering point may be considered information that 
> falls under the "privacy" issues in security.   The security considerations 
> should indicate whether you assume the peering point is physically isolated 
> or shared infrastructure.  If shared infrastructure, are you requiring TCP-AO 
> to e securie. 
> 
>>  This extension takes it out of the approved range of the BGP-LS.
> Stefano:  I don’t know what is the “approved range”. To me, bgp-ls carries 
> topology information. We started with lsdb, then extended to mpls-lsp's, ip 
> tunnels, peering points, and more

Re: [spring] Review of draft-ietf-spring-segment-routing-msdc-03

[Stefano Previdi (sprevidi)]

Hi Sue,

thanks for the review. Some comments below.


> On Mar 6, 2017, at 5:25 PM, Susan Hares  wrote:
> 
> Reviewer: Susan Hares
> Review result: Has Issues
> 
> The RTG-DIR has the categories:  minor concerns or major concerns
> regarding "issues", I wil differentiate my issues by this quality. 
> I also have editorial nits regardign under specified text. 
> 
> Major concerns: 
> 1) The security section is not sufficient for any review by the
> Security area 
> 
> This draft depends on IDR WG draft (ietf-idr-bgp-prefix-sid) that
> defines the BGP Segment attribute.  If this attribute is used with
> IPv6, this simply gives more infromation about a link to a next. 
> However, the combination of this information with the information
> passed using draft-ietf-idr-bgpls-segment-routing-epe-09 that utilizes
> BGP to pass BGP topologies in BGP - requires a better security
> section.  BGP-LS was described to be an "information gathering"
> function handled by a few routers on the edge of the network to obtain
> link-state topology information.  The BGP peers would carry this
> information in a separate informational stream.  With this constraint,
> it was approved by the IESG.   


well, we have now different models that have been deployed and assuming that 
bgp-ls uses a separate stream is not accurate if we look what’s in the industry.

However, I take your point and I agree that more text in the security section 
is required in order to emphasize that the model the draft addresses is 
internal (DC and interconnected DC over a same-administration network).


> draft-ietf-idr-bgpls-segment-routing-epe  expands the initial concept
> of BGP-LS from "information gathering" to a full-routing scheme of BGP
> within BGP for data centers and for data center interconnection to the
> network.


EPE defines a model where the topology of the peering point (not the network, 
just the peering point) is advertised to an internal server.


>   This extension takes it out of the approved range of the
> BGP-LS.


I don’t know what is the “approved range”. To me, bgp-ls carries topology 
information. We started with lsdb, then extended to mpls-lsp's, ip tunnels, 
peering points, and more will come.

The security of bgp-ls doesn’t change. It’s the boundary of the network where 
bgp-ls is applied that matters.


>  Therefore, the security sections in both the IDR WG drafts
> and this draft need to describe the new threat scenarios and describe
> threat mitigation strategies for deployments.  


I will add more text about the information originated by bgp-ls (or the bgp 
prefix sid) and how it is intended to be consumed internally to a domain.


> In addition, the information by BGP-LS
> (draft-ietf-idr-bgpls-segment-routing-epe) or in draft-ietf-bgp-sid
> may have privacy issues - so these need to be described the security
> section. 


same here. I will emphasize the deployment model and the security boundaries.


> 2) through-out the text you use words such as "ebgp3107" or BGP 3107
> updates"
> 
> This phrase is inaccurate.  The base RFC3107 support will not provide
> BGP-Prefix support (as supported in bgp-idr-bgp-prefix.   Some texts
> goes on to clarify the addition of the BGP SID Prefix attribute.  It
> would be better to invent a new phrase or term.


I’ll check this out.


> In section 8.1, the authors state:
> "The Prefix Segement is a lightweight extension to the BGP Labelled
> Unicast".  As noted in my #1 major concern, this "hand-waving"
> description either needs to be refined to be accurate.  If the MPLS
> usage only uses the BGP-Prefix label and does not extend to the
> Egress, it is simplier.


the BGP Prefix SID Attribute is just an extension to a 3107 update.


>  However, it is not clear that is what section
> 8.1 is about.   If 8.1 includes the
> draft-ietf-idr-bgpls-segment-routing-epe, then BGP-LS addition does
> have a number of prefixes and rules.   The trade-off between BGP-LS +
> BGP-LS SID (draft-ietf-idr-bgp-sid) handling + BGP LS egress peer
> engineering draft (draft-ietf-idr-bgp-segment-routing-epe) and a
> signalling protocol is more complex than the hand-wave.


Not sure I understand your point but to me the statement: 
“The Prefix Segement is a lightweight extension to the BGP Labelled Unicast”
is correct because the prefix-sid is really just a new attribute. Here we’re 
just talking protocol extension.

The interaction and combination between prefix-sid and epe is a deployment and 
operational model that (we agreed above) requires more explanation in terms of 
security.


>  It may be the
> right choice based on current implementations and management issues,
> but these need to be laid specifically. 
> 
> 3) Why are you defining 2-byte Private Use AS when there are plenty of
> 4-Byte Private Use AS (p. 5). 


well, we just want to be sure we address the worse case where you only have 2 
octets.


> 
> This usage increases the confusion regarding 2-byte/4-byte ASN.  IDR
> specifically worked on

Re: [spring] I-D Action: draft-ietf-spring-segment-routing-msdc-03.txt

[Stefano Previdi (sprevidi)]

this drafts integrates comments received during WG last and shepherd reviews.

Thanks.
s.

> On Mar 3, 2017, at 3:53 PM, internet-dra...@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Source Packet Routing in Networking of the 
> IETF.
> 
>Title   : BGP-Prefix Segment in large-scale data centers
>Authors : Clarence Filsfils
>      Stefano Previdi
>  Jon Mitchell
>  Ebben Aries
>  Petr Lapukhov
>   Filename: draft-ietf-spring-segment-routing-msdc-03.txt
>   Pages   : 23
>   Date: 2017-03-03
> 
> Abstract:
>   This document describes the motivation and benefits for applying
>   segment routing in BGP-based large-scale data-centers.  It describes
>   the design to deploy segment routing in those data-centers, for both
>   the MPLS and IPv6 dataplanes.
> 
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-msdc/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-spring-segment-routing-msdc-03
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-segment-routing-msdc-03
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> 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] WG Last Call for draft-ietf-spring-segment-routing-msdc-02

[Stefano Previdi (sprevidi)]

> On Mar 1, 2017, at 7:27 PM, Anoop Ghanwani  wrote:
> 
> On Wed, Mar 1, 2017 at 9:21 AM, Stefano Previdi (sprevidi) 
>  wrote:
> 
> > On Mar 1, 2017, at 5:48 PM, Anoop Ghanwani  wrote:
> >
> > Thanks for the responses.
> >
> > On Wed, Mar 1, 2017 at 7:44 AM, Stefano Previdi (sprevidi) 
> >  wrote:
> >
> > > On Feb 28, 2017, at 8:29 PM, Anoop Ghanwani  wrote:
> > >
> > >
> > > - pg 5, line 1
> > >   What is the criteria that allow sharing the AS number?  Is there a 
> > > reference?
> >
> >
> > we changed this to “use the same AS”. As explained in 4.3, using the same 
> > AS brings the update loop prevention mechanism so facilitate filtering and 
> > propagation.
> >
> >
> > I think your response is about the spine/leaf nodes.  My comment is about 
> > the ToR nodes.
> 
> 
> the same applies. The rules and guidelines related to bgp deployment and AS 
> numbering are the same.
> 
> 
> In this draft, we have:
> >>>
>  For efficient usage of the scarce 2-byte Private Use AS pool,
>  different Tier-3 nodes might share the same AS.
> 
> >>>
> 
> In RFC 7938, we have:
> >>>
>  A unique ASN is allocated to every Tier 3 device (e.g., ToR) in
>   this topology.
> 
> >>>
> 
> What I am asking for is clarification on how different Tier-3 nodes might 
> share the same AS number.


“share” is the wrong term and we agreed to change it.

Btw, RFC7938 section 5.2.2. "Private Use ASNs” says:


   The original range of Private Use ASNs [RFC6996] limited operators to
   1023 unique ASNs.  Since it is quite likely that the number of
   network devices may exceed this number, a workaround is required.
   One approach is to re-use the ASNs assigned to the Tier 3 devices
   across different clusters.  For example, Private Use ASNs 65001,
   65002 ... 65032 could be used within every individual cluster and
   assigned to Tier 3 devices.

By “share” we intended to “use” the same number in different clusters.

s.


> 
> Your comment above (referencing 4.3) is talking about a different scheme 
> (iBGP) in which case I am assuming all nodes (spine, leaf, tor) share the 
> same AS number.
> 
> Thanks,
> Anoop 

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

Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-msdc-02

[Stefano Previdi (sprevidi)]

> On Mar 1, 2017, at 5:48 PM, Anoop Ghanwani  wrote:
> 
> Thanks for the responses.
> 
> On Wed, Mar 1, 2017 at 7:44 AM, Stefano Previdi (sprevidi) 
>  wrote:
> 
> > On Feb 28, 2017, at 8:29 PM, Anoop Ghanwani  wrote:
> >
> >
> > - pg 5, line 1
> >   What is the criteria that allow sharing the AS number?  Is there a 
> > reference?
> 
> 
> we changed this to “use the same AS”. As explained in 4.3, using the same AS 
> brings the update loop prevention mechanism so facilitate filtering and 
> propagation.
> 
> 
> I think your response is about the spine/leaf nodes.  My comment is about the 
> ToR nodes.


the same applies. The rules and guidelines related to bgp deployment and AS 
numbering are the same.


> > - pg 7
> >   "local label 1600x" -> "local label (16000 + x).
> >   Also because of the way loopbacks are assigned, does this mean that the 
> > number nodes that this scheme can handle is 512?  May be good to mention 
> > why this is considered a good number.
> 
> 
> the example assumes loopbacks assigned from 192.0.2/24. It gives you 255 host 
> addresses. This is of course just illustrative.
> 
> It may be good to mention explicitly that the numbers used are illustrative.  
> I did not get that impression when reading the draft. 
> 
> 
> > - pg 11
> >   "BGP Prefix Segment 16011 then directs the packet down to Node11 along 
> > the path (Node5, Node9, Node11)."
> >   I think it would be worth mentioning that node 9 need not appear in this 
> > path.  In general, because of the nature of clos topologies, there is no 
> > need to have intermediate nodes between the spine and the ToR on the way 
> > down.  (If there is, it would be good to know why.)
> 
> 
> maybe I’m missing your point but the example is baed on the illustrative 
> topology where 9 in the shortest path but you don’t need to specify 9 in the 
> segment list. This is base of SR explained in the architecture draft.
> 
> 
> Yes, that is indeed my point. I think it would be better to remove it and 
> have a statement that says why it doesn't appear pointing to the arch doc.


I will add a reference but remember that this is a use case draft. For the 
mechanics of SR you always have to reference to the architecture draft (in 
fact, it is referenced in many places in the draft).

Thanks.
s.


> 
> Thanks,
> Anoop 

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

Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-msdc-02

[Stefano Previdi (sprevidi)]

> On Feb 28, 2017, at 8:29 PM, Anoop Ghanwani  wrote:
> 
> I support publication of the document as an informational RFC.
> 
> Below are my comments.
> 
> Thanks,
> Anoop
> 
> ==
> 
> - pg 5, line 1
>   What is the criteria that allow sharing the AS number?  Is there a 
> reference?


we changed this to “use the same AS”. As explained in 4.3, using the same AS 
brings the update loop prevention mechanism so facilitate filtering and 
propagation.


> - pg 6
>   "This means that every new connection will be established 
>obliviously (memory- less) with regards to the paths chosen 
> before, or chosen by other nodes."
>   I am not sure what "chosen by other nodes" adds.  I think it 
>   can be removed. 


It refers to the “obliviousness” extended also to the choices that other nodes 
of the network could have made.


> - pg 7
>   "local label 1600x" -> "local label (16000 + x).
>   Also because of the way loopbacks are assigned, does this mean that the 
> number nodes that this scheme can handle is 512?  May be good to mention why 
> this is considered a good number.


the example assumes loopbacks assigned from 192.0.2/24. It gives you 255 host 
addresses. This is of course just illustrative.


> - pg 11
>   "BGP Prefix Segment 16011 then directs the packet down to Node11 along the 
> path (Node5, Node9, Node11)."
>   I think it would be worth mentioning that node 9 need not appear in this 
> path.  In general, because of the nature of clos topologies, there is no need 
> to have intermediate nodes between the spine and the ToR on the way down.  
> (If there is, it would be good to know why.)


maybe I’m missing your point but the example is baed on the illustrative 
topology where 9 in the shortest path but you don’t need to specify 9 in the 
segment list. This is base of SR explained in the architecture draft. 


> 
> Editorial


I fixed the remaining editorial nits.

Thanks.

s.


> 
> - some inconsistencies throughout.  would be good to make them consistent.
>   Node1 and Node2 vs Nodes 1 and 2 vs "Node1" and "Node2"
>   data center, data-center, DC
> 
> - Spell out SRGB and AIGP at first use.
> 
> - pg 1
>   "use-case use-cases" -> use-cases
> 
> - pg 5
>   "via BGP session" -> "via a BGP session."  (missing 'a' and period.)
>   "address of it's loopback" -> "address of its loopback"
>   "per-flow ECMP that does not" -> "per-flow ECMP does not"
>   "placed on one path over others" ->  "placed on one path over others."  
> (missing period)
>   " implements oblivious" -> "implements an oblivious"
> 
> - pg 6
>   "Absence of path visibility" -> "The absence of path visibility"
>   
> - pg 7
>   "Figure 2 zooms on" -> "Figure 2 zooms in on"
> 
> - pg 8 
>   "an nondeterministic label" -> "a non-deterministic label"
> 
> - pg 9
>   "Referring to Figure 1Referring to Figure 1" -> "Referring to Figure 1"
> 
> - pg 11
>   "if Node7 does not support" -> "even though Node7 does not support"
> 
> - p12
>   Missing a period at the end of the first and second items in Sec 4.3.
>   "Attribute adverting" -> "Attribute advertising"
> 
> - pg 14
>   "let us illustrate this assuming" -> "let us illustrate this concept 
> assuming"
>   "flow to Z" -> "flow to HostZ"
>   "assuming A is made aware" -> "assuming HostA is made aware"
>   
> - pg 15
>   "the latter one" -> "the last one"
> 
> - pg 16
>   "monitoring network elements health" -> "monitoring network elements' 
> health"
>   "inSection 7.2" -> "in Section 7.2"
>   "BGP Labelled Unicast" -> "BGP Labeled Unicast"  (also on pg 17)
> 
> - pg 18
>   "thanks to PHP" -> "because of PHP"
>   "Internet- scale" -> "Internet-scale"  (extra space)
>   "go-to-the- Internet" -> "go-to-the-Internet"
>   " do not recommend to use" -> "do not recommend using"
>   "operation viewpoint" -> "operational viewpoint"
> 
> - pg 19
>   "allows to construct" -> "allows us to construct"
>   "Spine5 and Spine 8" -> Node5 and Node8
>   "(e.g. ToR1's SRGB is [1000, 1999], ToR2's SRGB is [2000, 2999]...)." ->
>   "(e.g. ToR1's SRGB is [1000, 1999], ToR2's SRGB is [2000, 2999], ...)." ->
> 

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

Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-msdc-02

[Stefano Previdi (sprevidi)]

> On Mar 1, 2017, at 3:39 PM, bruno.decra...@orange.com wrote:
> 
> Hi Stefano,
> 
>> From: Stefano Previdi (sprevidi) [mailto:sprev...@cisco.com]  > Sent: 
>> Tuesday, February 28, 2017 10:16 AM
>> 
>> Hi Bruno,
>> 
>> thanks for the review. I integrated all the comments in the new version I'm 
>> going to submit
>> very soon.
> 
> 
> Thanks.
> 
> 
>> One last comment here below:
>> 
>>> On Feb 22, 2017, at 2:00 PM, bruno.decra...@orange.com wrote:
>>> 
>>> 2)  For the document write up, are there any known deployment of 
>>> draft-ietf-spring-
>> segment-routing-msdc?
>>> 
>>> 
>>> 3)  § 2.1.  Reference design
>>> 
>>> "   o  Each node is its own AS (Node X has AS X)
>>> 
>>>  *  For simple and efficient route propagation filtering, Nodes 5,
>>> 6, 7 and 8 share the same AS, Nodes 3 and 4 share the same AS,
>>> Nodes 9 and 10 share the same AS.
>>> 
>>>  *  For efficient usage of the scarce 2-byte Private Use AS pool,
>>> different Tier-3 nodes might share the same AS.
>>> 
>>>  *  Without loss of generality, we will simplify these details in
>>> this document and assume that each node has its own AS."
>>> 
>>> 
>>> First 2 bullets are contradicting each other's.
>> 
>> 
>> why so ? First bullet refers to tier-1 and tier-2. second bullet refers to 
>> tier-3.
> 
> Bullet 1: "Each node is its own AS"
> Bullet 2: "Nodes 5, 6, 7 and 8 share the same AS”


ok sorry, the indent was such that I was confused.


> Looks a priori contradicting.
> Now thinking more about this, and given that on your 5-stage clos topology 
> nodes 5, 6, 7 and 8 are not connected to each other's and any flow has no 
> valid reason to cross two of them, I now see what you mean.
> 
> I would then propose the following change:
> OLD: share the same AS
> NEW: use the same AS number


I agree. I also think that “sharing” has other implications which are not 
intended here.


> It may look the same, but the two nodes are indeed in different ASes. But 
> they use the same AS number, just like private AS number.
> 
> Or may be it's just me ;-)  So up to you.


no, it’s me too ;-)

s.


> 
> Thanks,
> -- Bruno
>> 
>> thanks.
>> s.
>> 
> 
> 
> _
> 
> 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] WG Last Call for draft-ietf-spring-segment-routing-msdc-02

[Stefano Previdi (sprevidi)]

Hi Bruno,

thanks for the review. I integrated all the comments in the new version I’m 
going to submit very soon.

One last comment here below:

> On Feb 22, 2017, at 2:00 PM, bruno.decra...@orange.com wrote:
>  
> 2)  For the document write up, are there any known deployment of 
> draft-ietf-spring-segment-routing-msdc?
> 
> 
> 3)  § 2.1.  Reference design
> 
> “   o  Each node is its own AS (Node X has AS X)
>  
>   *  For simple and efficient route propagation filtering, Nodes 5,
>  6, 7 and 8 share the same AS, Nodes 3 and 4 share the same AS,
>  Nodes 9 and 10 share the same AS.
>  
>   *  For efficient usage of the scarce 2-byte Private Use AS pool,
>  different Tier-3 nodes might share the same AS.
>  
>   *  Without loss of generality, we will simplify these details in
>  this document and assume that each node has its own AS.”
>  
>  
> First 2 bullets are contradicting each other’s.


why so ? First bullet refers to tier-1 and tier-2. second bullet refers to 
tier-3.

thanks.
s.
 

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

Re: [spring] A question regarding mode of SR/LDP interop

[Stefano Previdi (sprevidi)]

Sasha,


> On Feb 23, 2017, at 3:42 PM, Alexander Vainshtein 
>  wrote:
> 
> Stefano,
> I respectfully disagree. 
> 
> From my POV YANG data models (same as MIBs before them) are supposed to 
> provide a comprehensive list of configurable parameters that impact operation 
> of a protocol within the limits defined by the corresponding protocol spec.


Far be it from me to question yang benefits... ;-)

it’s just that, from a protocol definition perspective, I won’t assume a given 
choice for management/configuration so that people can then chose snmp-mibs, 
yang or whatever comes next.

Where I agree with you is on the need for yang models to support the sr/ldp 
interop if the target is to be yang-capable on all aspects of protocol 
implementations.

s.


> 
> My 2c,
> Sasha
> 
> Office: +972-39266302
> Cell:  +972-549266302
> Email:   alexander.vainsht...@ecitele.com
> 
> 
> -Original Message-
> From: Stefano Previdi (sprevidi) [mailto:sprev...@cisco.com] 
> Sent: Thursday, February 23, 2017 4:17 PM
> To: Alexander Vainshtein 
> Cc: draft-ietf-spring-sr-y...@ietf.org; spring@ietf.org; Michael Gorokhovsky 
> 
> Subject: Re: [spring] A question regarding mode of SR/LDP interop
> 
> 
>> On Feb 23, 2017, at 2:45 PM, Alexander Vainshtein 
>>  wrote:
>> 
>> Hi all,
>> I would like to point to what looks to me as inconsistency between the 
>> current (-05) version of the SR YANG Data Model draft and the latest (-06) 
>> version of the Segment Routing Interop with LDP draft.
>> 
>> The following text has been added to the latter:
>> 
>>  Section 2 describes the co-existence of SR with other MPLS Control
>> 
>>   Plane.  Section 3 documents a method to migrate from LDP to 
>> SR-based
>> 
>>   MPLS tunneling.  Section 4 documents the interworking between SR 
>> and
>> 
>>   LDP in the case of non-homogeneous deployment.  Section 5 describes
>> 
>>   how a partial SR deployment can be used to provide SR benefits to
>> 
>>   LDP-based traffic including a possible application of SR in the
>> 
>>   context of inter-domain MPLS use-cases.
>> 
>> 
>> 
>>   Typically, an implementation will allow an operator to select
>> 
>>   (through configuration) which of the described modes of SR and LDP
>> 
>>   co-existence to use.
>> 
>> 
>> To the best of my understanding, there is no match for the highlighted 
>> configuration parameter in the former document.
> 
> 
> well, from an SR perspective, “through configuration” is not limited to 
> YANG...
> 
> s.
> 
> 
>> (This is expected since such a parameter has not been mentioned in the 
>> previous (-05) version of the former).
>> 
>> I hope the next version of the YANG Model draft will take care of that.
>> 
>> Regards, and lots of thanks in advance, Sasha
>> 
>> Office: +972-39266302
>> Cell:  +972-549266302
>> Email:   alexander.vainsht...@ecitele.com
>> 
>> ___
>> 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] A question regarding mode of SR/LDP interop

[Stefano Previdi (sprevidi)]

> On Feb 23, 2017, at 2:45 PM, Alexander Vainshtein 
>  wrote:
> 
> Hi all,
> I would like to point to what looks to me as inconsistency between the 
> current (-05) version of the SR YANG Data Model draft and the latest (-06) 
> version of the Segment Routing Interop with LDP draft.
>  
> The following text has been added to the latter:
>  
>   Section 2 describes the co-existence of SR with other MPLS Control
> 
>Plane.  Section 3 documents a method to migrate from LDP to SR-based
> 
>MPLS tunneling.  Section 4 documents the interworking between SR and
> 
>LDP in the case of non-homogeneous deployment.  Section 5 describes
> 
>how a partial SR deployment can be used to provide SR benefits to
> 
>LDP-based traffic including a possible application of SR in the
> 
>context of inter-domain MPLS use-cases.
> 
>  
> 
>Typically, an implementation will allow an operator to select
> 
>(through configuration) which of the described modes of SR and LDP
> 
>co-existence to use.
> 
>  
> To the best of my understanding, there is no match for the highlighted 
> configuration parameter in the former document.


well, from an SR perspective, “through configuration” is not limited to YANG...

s.


> (This is expected since such a parameter has not been mentioned in the 
> previous (-05) version of the former).
>  
> I hope the next version of the YANG Model draft will take care of that.
>  
> Regards, and lots of thanks in advance,
> Sasha
>  
> Office: +972-39266302
> Cell:  +972-549266302
> Email:   alexander.vainsht...@ecitele.com
>  
> ___
> 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] A question regarding IS-IS Segment Routing Extensions

[Stefano Previdi (sprevidi)]

> On Feb 23, 2017, at 1:08 PM, Alexander Vainshtein 
>  wrote:
> 
> Hi all,
> My colleagues and I have a couple of questions about some behavioral aspects 
> of IS-IS Segment Routing (SR) extensions.
>  
> Suppose that we have an IS-IS domain where some routers run IS-IS with SR 
> extensions, and some routers run “vanilla” IS-IS for IPv4.
> 1.   What is supposed to happen when router A that runs IS-ISD without SR 
> extensions establishes an adjacency with router B that runs IS-IS with SR 
> extensions. Our expectations are that:
> a.   An adjacency between A and B would be allowed to progress to its 
> FULL state. Is that correct?


yes.


> b.  B will distribute all SR-related TLVs and sub-TLVs to A. Is that 
> correct?


yes.


> c.   A will silently discard all SR-related TLVs and sub-TLVs it has 
> received from B. Is that correct?


yes. However “discard” is not the right term. “ignore” is the right one.


> 2.   What is supposed to happen if IS-IS adjacency between A and B 
> reaches its FULL state, and then SR extensions are enabled in A. We expect 
> that:
> a.   It is possible to enable SR extensions in A without resetting its 
> adjacency with B (or any other adjacent router). Is that correct?


yes.


> b.  Once B learns that SR capabilities of A have changed, it floods its 
> LSP database with all SR-related TLVs and sub-TLVs to A. Is that correct?


LSDBs are not flooded again if there’s no change in adjacency state.

Link state protocols work such that each router (SR capable or not) is supposed 
to keep the entire LSDB (even the TLVs it doesn’t understand). When suddenly SR 
is enabled, the router re-read its LSDB and process the SR TLVs/Sub-TLVs 
accordingly.


> A brief scan of the draft did not yield answers to any of the questions above.


because this is not related to SR but to the normal behavior of link-state 
routing.


> Timely feedback would be very highly appreciated.


hope this helps.
s.


>  
> Regards, and lots of thanks in advance,
> Sasha
>  
> Office: +972-39266302
> Cell:  +972-549266302
> Email:   alexander.vainsht...@ecitele.com

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

Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-msdc-02

[Stefano Previdi (sprevidi)]

as co-author, I support the publication of this draft.

Thanks.
s.


> On Feb 21, 2017, at 10:50 AM, bruno.decra...@orange.com wrote:
> 
> Hello Working Group,
>  
> This email starts a 2-week Working Group Last Call on 
> draft-ietf-spring-segment-routing-msdc-02 [1].
>  
> Please read the document if you haven't read the most recent version yet, and 
> send your comments to the list, no later than the *7th of March*.
> Note that this is *not only* a call for comments on the document; it is also 
> a call for support (or not) to publish this document as an Informational RFC.
>  
> We have already polled for IPR knowledge on this document and all Authors 
> have replied.
> No IPR has been disclosed [2].
>  
> Thank you
>  
> M&B
>  
> [1] https://tools.ietf.org/html/draft-ietf-spring-segment-routing-msdc-02
> [2] 
> https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-spring-segment-routing-msdc
>  
>  
>  
>  
> _
> 
> 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] I-D Action: draft-ietf-spring-segment-routing-central-epe-04.txt

[Stefano Previdi (sprevidi)]

Hi,

this version integrates comments received during shepherd review. 

Thanks.
s.


> On Feb 16, 2017, at 11:34 PM, internet-dra...@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Source Packet Routing in Networking of the 
> IETF.
> 
>Title   : Segment Routing Centralized BGP Egress Peer 
> Engineering
>Authors : Clarence Filsfils
>  Stefano Previdi
>  Ebben Aries
>  Dmitry Afanasiev
>   Filename: draft-ietf-spring-segment-routing-central-epe-04.txt
>   Pages   : 19
>   Date: 2017-02-16
> 
> Abstract:
>   Segment Routing (SR) leverages source routing.  A node steers a
>   packet through a controlled set of instructions, called segments, by
>   prepending the packet with an SR header.  A segment can represent any
>   instruction topological or service-based.  SR allows to enforce a
>   flow through any topological path and service chain while maintaining
>   per-flow state only at the ingress node of the SR domain.
> 
>   The Segment Routing architecture can be directly applied to the MPLS
>   dataplane with no change on the forwarding plane.  It requires minor
>   extension to the existing link-state routing protocols.
> 
>   This document illustrates the application of Segment Routing to solve
>   the BGP Egress Peer Engineering (BGP-EPE) requirement.  The SR-based
>   BGP-EPE solution allows a centralized (SDN) controller to program any
>   egress peer policy at ingress border routers or at hosts within the
>   domain.
> 
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-central-epe/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-spring-segment-routing-central-epe-04
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-segment-routing-central-epe-04
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> I-D-Announce mailing list
> i-d-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

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

Re: [spring] I-D Action: draft-ietf-spring-segment-routing-11.txt

[Stefano Previdi (sprevidi)]

Hi,

this version integrates various comments received during the WG last call and 
by the shepherd review.

Thanks.
s.


> On Feb 16, 2017, at 11:30 PM, internet-dra...@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Source Packet Routing in Networking of the 
> IETF.
> 
>Title   : Segment Routing Architecture
>Authors : Clarence Filsfils
>      Stefano Previdi
>  Bruno Decraene
>  Stephane Litkowski
>  Rob Shakir
>   Filename: draft-ietf-spring-segment-routing-11.txt
>   Pages   : 28
>   Date: 2017-02-16
> 
> Abstract:
>   Segment Routing (SR) leverages the source routing paradigm.  A node
>   steers a packet through an ordered list of instructions, called
>   segments.  A segment can represent any instruction, topological or
>   service-based.  A segment can have a semantic local to an SR node or
>   global within an SR domain.  SR allows to enforce a flow through any
>   topological path and service chain while maintaining per-flow state
>   only at the ingress nodes to the SR domain.
> 
>   Segment Routing can be directly applied to the MPLS architecture with
>   no change on the forwarding plane.  A segment is encoded as an MPLS
>   label.  An ordered list of segments is encoded as a stack of labels.
>   The segment to process is on the top of the stack.  Upon completion
>   of a segment, the related label is popped from the stack.
> 
>   Segment Routing can be applied to the IPv6 architecture, with a new
>   type of routing header.  A segment is encoded as an IPv6 address.  An
>   ordered list of segments is encoded as an ordered list of IPv6
>   addresses in the routing header.  The active segment is indicated by
>   the Destination Address of the packet.  The next active segment is
>   indicated by a pointer in the new routing header.
> 
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-spring-segment-routing-11
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-segment-routing-11
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> I-D-Announce mailing list
> i-d-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

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

Re: [spring] IDR WG 2 week WG LC on draft-ietf-idr-bgpls-segment-routing-epe - (2/15/2017 to 3/1/2017)

[Stefano Previdi (sprevidi)]

> On Feb 16, 2017, at 12:34 AM, Susan Hares  wrote:
> 
> This begins a 2 week IDR WG last call on 
> draft-ietf-idr-bgpls-segment-routing-epe from (2/15 to 3/1/2017)There are 
> two implementations describe on the wiki at: 
> https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgpls-segment-routing-epe%20
>  
> The two implementation are from  Cisco IOS-XR release 6.0.2 and Cisco Nexus 
> Switch N9000/N3000 platforms running NX-OS 7.0(3)I1(1) or greater.   The 
> authors will indicate on the list and in the wiki the following information :
>  
> 1)  Were these implementations separate implementations? 


yes.


> 2)  What were the results of the interoperability tests? 


the two implementations are interoperable on the set of features they support. 
See 
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgpls-segment-routing-epe%20 
for details.


> This work is linked to the draft-ietf-spring-segment-routing-central-epe work 
> in the SPRING WG. Based on the two drafts, the WG should might consider:  
> 1)  Is there need for this work in deployments in networks/ 


yes. This work has been triggered after several operators requirements for 
egress traffic engineering.


> 2)  Is this technically ready for publication? 


the authors believe so.


> 3)  Does it fit with the spring informational draft? 


yes. The use-case draft describing EPE 
(draft-ietf-spring-segment-routing-central-epe) has been adopted as WG doc in 
SPRING and it started the shepherd review.

Thanks.
s.


> For the ease of reference the web references are below: 
> https://datatracker.ietf.org/doc/draft-ietf-idr-bgpls-segment-routing-epe/
> https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-central-epe/
>  
> Sue Hares 
> ___
> 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] WG Last Call for draft-ietf-spring-segment-routing-central-epe

[Stefano Previdi (sprevidi)]

support as co-author.

s.


> On Feb 13, 2017, at 11:08 AM, bruno.decra...@orange.com wrote:
> 
> Hello Working Group,
>  
> This email starts a 2-week Working Group Last Call on 
> draft-ietf-spring-segment-routing-central-epe-03 [1].
>  
> Please read the document if you haven't read the most recent version yet, and 
> send your comments to the list, no later than the *27th of February*.
> Note that this is *not only* a call for comments on the document; it is also 
> a call for support (or not) to publish this document as an Informational RFC.
>  
> We have already polled for IPR knowledge on this document and all Authors 
> have replied.
> Two IPR have been disclosed [2].
>  
> Thank you
>  
> M&B
> [1] 
> https://tools.ietf.org/html/draft-ietf-spring-segment-routing-central-epe-03
> [2] 
> https://datatracker.ietf.org/ipr/search/?id=draft-ietf-spring-segment-routing-central-epe&submit=draft
>  
> _
> 
> 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] I-D Action: draft-ietf-spring-segment-routing-ldp-interop-06.txt

[Stefano Previdi (sprevidi)]

integrated various comments from various contributors.

Thanks.
s.

> On Feb 8, 2017, at 3:30 PM, internet-dra...@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Source Packet Routing in Networking of the 
> IETF.
> 
>Title   : Segment Routing interworking with LDP
>Authors : Clarence Filsfils
>      Stefano Previdi
>  Ahmed Bashandy
>  Bruno Decraene
>  Stephane Litkowski
>   Filename: draft-ietf-spring-segment-routing-ldp-interop-06.txt
>   Pages   : 20
>   Date: 2017-02-08
> 
> Abstract:
>   A Segment Routing (SR) node steers a packet through a controlled set
>   of instructions, called segments, by prepending the packet with an SR
>   header.  A segment can represent any instruction, topological or
>   service-based.  SR allows to enforce a flow through any topological
>   path and service chain while maintaining per-flow state only at the
>   ingress node to the SR domain.
> 
>   The Segment Routing architecture can be directly applied to the MPLS
>   data plane with no change in the forwarding plane.  This drafts
>   describes how Segment Routing operates in a network where LDP is
>   deployed and in the case where SR-capable and non-SR-capable nodes
>   coexist.
> 
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-ldp-interop/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-spring-segment-routing-ldp-interop-06
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-segment-routing-ldp-interop-06
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> 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] I-D Action: draft-ietf-spring-segment-routing-mpls-07.txt

[Stefano Previdi (sprevidi)]

this is the updated version after all received comments.

Thanks.
s.


> On Feb 7, 2017, at 2:50 PM, internet-dra...@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Source Packet Routing in Networking of the 
> IETF.
> 
>Title   : Segment Routing with MPLS data plane
>Authors : Clarence Filsfils
>      Stefano Previdi
>  Ahmed Bashandy
>  Bruno Decraene
>  Stephane Litkowski
>  Martin Horneffer
>  Rob Shakir
>  Jeff Tantsura
>  Edward Crabbe
>   Filename: draft-ietf-spring-segment-routing-mpls-07.txt
>   Pages   : 16
>   Date: 2017-02-07
> 
> Abstract:
>   Segment Routing (SR) leverages the source routing paradigm.  A node
>   steers a packet through a controlled set of instructions, called
>   segments, by prepending the packet with an SR header.  In the MPLS
>   dataplane, the SR header is instantiated through a label stack.  A
>   segment can represent any instruction, topological or service-based.
>   Additional segments can be defined in the future.  SR allows to
>   enforce a flow through any topological path and/or service chain
>   while maintaining per-flow state only at the ingress node to the SR
>   domain.
> 
>   Segment Routing can be directly applied to the MPLS architecture with
>   no change in the forwarding plane.  This drafts describes how Segment
>   Routing operates on top of the MPLS data plane.
> 
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-mpls/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-07
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-segment-routing-mpls-07
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> 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] WG Last Call for draft-ietf-spring-segment-routing-mpls-06

[Stefano Previdi (sprevidi)]

Stewart,

I applied some of your comments in the new submitted version of the draft. Some 
other comments below.


> On Feb 2, 2017, at 1:15 PM, Stewart Bryant  wrote:
> 
> Here are a number of WGLC comments on this document.
> 
> - Stewart
> 
>  Segment Routing with MPLS data plane
>   draft-ietf-spring-segment-routing-mpls-06
> 
> Abstract
> 
>   Segment Routing (SR) leverages the source routing paradigm.  A node
>   steers a packet through a controlled set of instructions, called
>   segments, by prepending the packet with an SR header.
> 
> SB> This is SR MPLS. The above text implies a special header. Surely
> SB> it appends a stack of MPLS label stack entries that encode the 
> instructions
> SB> as label values.


the first statement is the generic description of SR as an architecture. Then, 
I will add a statement regarding the incarnation of the SR header in the mpls 
dataplane (i.e.: a label stack).


> 
>   A segment can
>   represent any instruction, topological or service-based.
> SB> and more!
>   SR allows
>   to enforce a flow through any topological path and service chain
>   while maintaining per-flow state only at the ingress node to the SR
>   domain.
> 
> SB> The above does not read well.
> SB> Surely something like:
> SB> SR allows an ingress node to steer a packet through a
> SB> topological path specifying which service actions or other
> SB> operations need to executed on arrival as a each specified node.


the above is confusing because it implies the two are merged.

paths can be topological, service-based or both.


>   Segment Routing can be directly applied to the MPLS architecture with
>   no change in the forwarding plane.  This drafts describes how Segment
>   Routing operates on top of the MPLS data plane.
> 
> ===
> 
> 
> 2.  Illustration
> 
>   Segment Routing, applied to the MPLS data plane, offers the ability
>   to tunnel services (VPN, VPLS, VPWS) from an ingress PE to an egress
>   PE, without any other protocol than ISIS or OSPF
>   ([I-D.ietf-isis-segment-routing-extensions] and
>   [I-D.ietf-ospf-segment-routing-extensions]).  LDP and RSVP-TE
>   signaling protocols are not required.
> 
> SB> Strictly no protocol is required as we did in MPLS-TP.
> SB> What you are saying is that by embedding additional
> SB> information in the the link state igp in use, you remove the
> SB> dependence on LDP, and RSVP-TE, although of course RSVP-TE
> SB> does run-time bandwidth accounting which you have to move to
> SB> a central place.


the text has been already reviewed and commented multiple time and reflects the 
agreement of the WG. We specify that SR doesn’t need rsvp-te or ldp. 

In the context of SR, we just don’t need them. On other context they certainly 
have their value.


> 
> SB> I suspect that the reader would be better served by putting the
> SB> rest of this after explaining how the protocol mapping works.
> 
> ==
> 
> 
>   Supporting MPLS services (VPN, VPLS, VPWS) with SR has the following
>   benefits:
> 
>  Simple operation: one single intra-domain protocol to operate: the
>  IGP.  No need to support IGP synchronization extensions as
>  described in [RFC5443] and [RFC6138].
> 
>  Excellent scaling: one Node-SID per PE.
> 
> SB> Is this all it seems. If you are going to steer the packet
> SB> I think you need more than one node-SID to get the packet there.


not really. Please have a look at the architecture and illustrations.


> SB> I presume the point is (and it should be brought out) that with
> SB> liberal label retention you have a label per adjacency that maps
> SB> to the remote PE (in the RP), although only one is in the FIB. If you have
> SB> an RSVP-TE path you have more than one label per PE, you have
> SB> one per constructed path, but in the FIB you only need to specify
> SB> a single label imposition, whilst in SR, you need to specify a
> SB> multi-label imposition.


this would trigger the neverending debate on whether we should start comparing 
all aspects pros/cons of control planes (SR vs. ldp/rsvp). 

We’re just interested into how SR works: one sid per pe.


> SB> As I understand it different vendors have different approaches
> SB> to label aggregation which may further complicate the issue, but
> SB> this text needs to be neutral on that point.
> 
> 
> 3.  MPLS Instantiation of Segment Routing
> 
>   MPLS instantiation of Segment Routing fits in the MPLS architecture
>   as defined in [RFC3031] both from a control plane and forwarding
>   plane perspective:
> 
>   o  From a control plane perspective [RFC3031] does not mandate a
>  single signaling protocol.  Segment Routing proposes to use the
>  Link State IGP as its use of information flooding fits very well
>  with label stacking on ingress.
> 
> SB> Surely you propose to be protocol agnostic? For example SR will work just 
> as
> SB> well with for example a pub-sub approach.
> 
>   o  Fro

Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-ldp-interop-05

[Stefano Previdi (sprevidi)]

I support as co-author.

s.


> On Feb 6, 2017, at 2:20 PM, Martin Vigoureux  
> wrote:
> 
> Hello Working Group,
> 
> This email starts a 2-week Working Group Last Call on 
> draft-ietf-spring-segment-routing-ldp-interop-05 [1].
> 
> ¤ Please read the document if you haven't read the most recent
> version yet, and send your comments to the list, no later than the
> *19th of February*.
> Note that this is *not only* a call for comments on the document; it is also 
> a call for support (or not) to publish this document as a Proposed Standard 
> RFC.
> 
> ¤ We have already polled for IPR knowledge on this document and all Authors 
> have replied.
> IPR exists against this document and has been disclosed [2].
> 
> Thank you
> 
> M&B
> 
> ---
> [1] 
> https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-ldp-interop/
> [2] 
> https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-spring-segment-routing-ldp-interop

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

Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-06

[Stefano Previdi (sprevidi)]

Hi Uma,

We'll add a couple of statements on that matter.

Thanks.

s.

-Original Message-
From: Uma Chunduri [uma.chund...@huawei.com]
Received: Monday, 30 Jan 2017, 6:40PM
To: Stewart Bryant [stewart.bry...@gmail.com]; Stefano Previdi (sprevidi) 
[sprev...@cisco.com]; Martin Horneffer [m...@nic.dtag.de]
CC: draft-ietf-spring-segment-routing-m...@ietf.org 
[draft-ietf-spring-segment-routing-m...@ietf.org]; spring@ietf.org 
[spring@ietf.org]; Martin Vigoureux [martin.vigour...@nokia.com]; m...@ietf.org 
[m...@ietf.org]
Subject: RE: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-06


Hi Martin, Stefano,

>It seems to me this could easily become an endless discussion again. People 
>seem to have very different views on it. Thus I'm not sure whether it would be 
>suitable for this document.

Sorry, that was not at all my intention to get into an endless discussion.
Being an SR MPLS data plane document, I felt discussion or reference to SID 
depth related aspects would be important. This is one of the aspects we 
contended with, when SR is being discussed in MBH deployments in my previous 
organization.

> The manageability section of the architecture draft mention that a node may 
> want to signal its stack capabilities and we have igp extensions for that.

I am fine with referencing both or a summary as pointed by Stewart below at 
some appropriate place in the document.

--
Uma C.


-Original Message-
From: Stewart Bryant [mailto:stewart.bry...@gmail.com]
Sent: Monday, January 30, 2017 3:51 AM
To: Stefano Previdi (sprevidi) ; Martin Horneffer 

Cc: draft-ietf-spring-segment-routing-m...@ietf.org; spring@ietf.org; Martin 
Vigoureux ; Uma Chunduri ; 
m...@ietf.org
Subject: Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-06

Stefano,

This is the document that someone interested in SR from and an MPLS perspective 
may well start with. A discussion on the issue of label stack depth and the 
practical constrains is thus very much in scope. The fact that you had a debate 
in the past immediately points to the need for a summary of the key issues and 
conclusions in this document.

Stewart


On 30/01/2017 11:27, Stefano Previdi (sprevidi) wrote:
> I agree with Martin,
>
> I think we have discussed this at length and I wouldn't re-spin the debate 
> (and come to the same conclusion again and again). The manageability section 
> of the architecture draft mention that a node may want to signal its stack 
> capabilities and we have igp extensions for that.
>
> s.
>
>
>> On Jan 30, 2017, at 10:13 AM, Martin Horneffer  wrote:
>>
>> Hello Uma,
>>
>> what kind of label depth discussion are you thinking of?
>>
>> It seems to me this could easily become an endless discussion again. People 
>> seem to have very different views on it. Thus I'm not sure whether it would 
>> be suitable for this document.
>>
>> BTW:
>>
>> For my needs, bandwidth optimization is one of the major use cases for all 
>> traffic engineering technologies such as SR or RSVP.
>>
>> We are currently supporting scientific university research about this, and 
>> first results give strong confirmation that for bandwidth optimization in 
>> real world networks you rarely need more than 1 additional segment. Or 
>> rather, the additional efficiency gained by using mor than 1 additional 
>> segment is very small. We compare a global real backbone network with 
>> current routing, theoretical MCF optimization and realistic optimization 
>> with 1 (or 2 or 3) additional traffic engineering segments (aka 2-SR, 3-SR, 
>> 4-SR).
>> Thus, from my point of view, an SR optimized network would typically have 
>> the same label stack depth as a similarily RSVP optimized network in some 
>> places, and a smaller label stack for the overall average .
>>
>> All other use-cases I found of serious interest so far all work with 1 
>> additional segment (i.e. label) at most.
>>
>> Best regards, Martin
>>
>>
>> Am 27.01.17 um 20:59 schrieb Uma Chunduri:
>>> Support.
>>>
>>> One quick comment:
>>>
>>> While section 3 correctly documents MPLS instantiation of SR -  given the 
>>> constructs SR has (ADJ SID for example) it's good to document SID/Label 
>>> depth implications in the deployments.
>>>
>>> --
>>> Uma C.
>>>
>>> -Original Message-
>>> From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Martin
>>> Vigoureux
>>> Sent: Friday, January 27, 2017 3:05 AM
>>> To: spring@ietf.org
>>> Cc: draft-ietf-spring-segment-routing-m...@ietf.org
>>> Subject: [spring] WG Last Call for
&g

Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-06

[Stefano Previdi (sprevidi)]

I agree with Martin,

I think we have discussed this at length and I wouldn't re-spin the debate (and 
come to the same conclusion again and again). The manageability section of the 
architecture draft mention that a node may want to signal its stack 
capabilities and we have igp extensions for that.

s.


> On Jan 30, 2017, at 10:13 AM, Martin Horneffer  wrote:
> 
> Hello Uma,
> 
> what kind of label depth discussion are you thinking of?
> 
> It seems to me this could easily become an endless discussion again. People 
> seem to have very different views on it. Thus I'm not sure whether it would 
> be suitable for this document.
> 
> BTW:
> 
> For my needs, bandwidth optimization is one of the major use cases for all 
> traffic engineering technologies such as SR or RSVP.
> 
> We are currently supporting scientific university research about this, and 
> first results give strong confirmation that for bandwidth optimization in 
> real world networks you rarely need more than 1 additional segment. Or 
> rather, the additional efficiency gained by using mor than 1 additional 
> segment is very small. We compare a global real backbone network with current 
> routing, theoretical MCF optimization and realistic optimization with 1 (or 2 
> or 3) additional traffic engineering segments (aka 2-SR, 3-SR, 4-SR).
> Thus, from my point of view, an SR optimized network would typically have the 
> same label stack depth as a similarily RSVP optimized network in some places, 
> and a smaller label stack for the overall average .
> 
> All other use-cases I found of serious interest so far all work with 1 
> additional segment (i.e. label) at most.
> 
> Best regards, Martin
> 
> 
> Am 27.01.17 um 20:59 schrieb Uma Chunduri:
>> Support.
>> 
>> One quick comment:
>> 
>> While section 3 correctly documents MPLS instantiation of SR -  given the 
>> constructs SR has (ADJ SID for example) it's good to document SID/Label 
>> depth implications in the deployments.
>> 
>> --
>> Uma C.
>> 
>> -Original Message-
>> From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Martin Vigoureux
>> Sent: Friday, January 27, 2017 3:05 AM
>> To: spring@ietf.org
>> Cc: draft-ietf-spring-segment-routing-m...@ietf.org
>> Subject: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-06
>> 
>> Hello Working Group,
>> 
>> This email starts a 2-week Working Group Last Call on
>> draft-ietf-spring-segment-routing-mpls-06 [1].
>> 
>> ¤ Please read the document if you haven't read the most recent version yet, 
>> and send your comments to the list, no later than the *12th of February*.
>> Note that this is *not only* a call for comments on the document; it is also 
>> a call for support (or not) to publish this document as a Proposed Standard 
>> RFC.
>> 
>> ¤ We have already polled for IPR knowledge on this document and all Authors 
>> have replied.
>> IPR exists against this document and has been disclosed [2].
>> 
>> Thank you
>> 
>> M&B
>> 
>> ---
>> [1] https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-mpls/
>> [2]
>> https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-spring-segment-routing-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
>> 
> 

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

Re: [spring] WG LC for draft-ietf-spring-ipv6-use-cases

[Stefano Previdi (sprevidi)]

I support this draft.

s.


> On Dec 6, 2016, at 2:39 PM, Martin Vigoureux  
> wrote:
> 
> Hello WG,
> 
> this e-mail initiates a two-week WG LC for draft-ietf-spring-ipv6-use-cases 
> [1].
> 
> All the authors have already replied to the IPR poll.
> There is no known IPR.
> 
> Please read the latest version of the document and state whether or not you 
> support the submission of this document to the IESG with the objective to 
> become an Informational RFC.
> 
> Please also express the comments you would have on this latest version.
> 
> Your involvement in this step is very important so please take the time to 
> read and express your opinions on the list.
> 
> Thank you
> 
> M&B
> 
> [1] https://datatracker.ietf.org/doc/draft-ietf-spring-ipv6-use-cases/
> 
> ___
> 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] WG LC for draft-ietf-spring-segment-routing

[Stefano Previdi (sprevidi)]

as an author, I support this draft.

s.


> On Dec 6, 2016, at 2:34 PM, Martin Vigoureux  
> wrote:
> 
> WG,
> 
> this is a reminder, please express your opinion regarding this WG LC.
> 
> Thank you
> 
> -m
> 
> Le 28/11/2016 à 10:37, Martin Vigoureux a écrit :
>> Hello WG,
>> 
>> this e-mail initiates a two-week WG LC for
>> draft-ietf-spring-segment-routing [1].
>> 
>> All authors have already replied to the IPR poll.
>> There is known IPR [2] on this document.
>> 
>> Please read the latest version of the document and state whether or not
>> you support the submission of this document to the IESG as a Proposed
>> Standard.
>> 
>> Please also express the comments you would have on this latest version.
>> 
>> Your involvement in this step is very important so please take the time
>> to read and express your opinions on the list.
>> 
>> Thank you
>> 
>> M&B
>> 
>> [1] https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing/
>> [2]
>> https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-spring-segment-routing
>> 
>> 
>> ___
>> 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

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

Re: [spring] Conflict resolution - a plea for simplicity

[Stefano Previdi (sprevidi)]

> On Dec 5, 2016, at 12:19 AM, Stewart Bryant  wrote:
> 
> 
> 
> On 04/12/2016 15:53, Stefano Previdi (sprevidi) wrote:
>> Stewart,
>> 
>> thanks for the feedback.
>> 
>> Just to give you an update, the work currently done in the context of the 
>> conflict-resolution draft aimed to, indeed, limit/reduce the impact of a 
>> misconfiguration in presence of conflicting prefix/sid mappings.
>> 
>> It is based on the concept that there’s no such “bad” or “wrong” prefix/sid 
>> mapping as long as all nodes use the same.
> This philosophy always seems incorrect to me.
> 
> If the operator planed for some traffic to go via an SR route, then must have 
> done it for a reason. That reason may have been to protect a property of the 
> service, or to protect other traffic from that service. Either way, if it is 
> intended to go via an SR path, it really should go via that path and not via 
> some other path that the network is guessing at.


an “SR route” is nothing else than a route for which you have a label.

the value this label (or index) has is mostly irrelevant as long as all nodes 
consistently use the same.

This is how SR works. Please refer to the long email thread on this matter.

s.



> 
> 
>> 
>> However, while we came up with a very efficient scheme, complexity is also 
>> part of the picture from an implementation, deployment, troubleshooting 
>> perspective. Not to mention the fun we’re going to have in doing 
>> interoperability tests.
> Right, so why not just do something really simple.
> 
>> 
>> So, the authors have raised this concern a few times but apparently the only 
>> feedback we got (so far) from the WG was more oriented on the efficiency of 
>> the conflict-resolution algorithm, regardless the simplicity (which is fine 
>> by me as long as it is well understood).
>> 
>> Les Ginsberg is about to propose a simplification of the algorithm in order 
>> to (re)introduce the simplicity of the original proposal (or at least try to 
>> improve simplicity in the current scheme).
> OK, look forward to seeing it.
> 
> - S
> 
> 
>> Thanks.
>> s.
>> 
>> 
>>> On Dec 2, 2016, at 6:54 PM, Stewart Bryant  wrote:
>>> 
>>> There was some discussion on the conflict resolution draft at IETF97
>>> that got cut off with a request to discuss on the list.
>>> 
>>> As I understand the situation, we have a misconfiguration in the network,
>>> and we are being encouraged to take an essentially aggressive strategy
>>> of picking one of the configurations and assuming that must be right
>>> in order to continue forwarding traffic. It seems to me that we are
>>> tossing a coin here and whilst we could be sending traffic the
>>> right way we could also be sending it the wrong way with bad
>>> consequences in terms of misdelivery or inducing congestion.
>>> 
>>> The alternative strategy is to note the conflict and not believe either
>>> router. This more conservative strategy seems the better approach for
>>> a number of reasons:
>>> 
>>> 1) Traffic will not be misdelivered, or use unintended parts of the network.
>>> 
>>> 2) Traffic,  was being routed via SR rather than simple shortest path
>>> for a reason and so you should not try to guess the operators decision,
>>> you should rigidly execute it.
>>> 
>>> 3) It seems to me that the aggressive approach fails 7 of Ross Callons
>>> Twelve truths (RFC1925). These were published on 1/April, but the real
>>> joke is that they ARE useful truths, so forget about the date. 3,
>>> 4, *5*, *6*, 8, probably 10, certainly 12.
>>> 
>>> 4) Finally there is the protocol 101 rule stating that the exception
>>> path MUST be simple, because it is rarely executed and thus often
>>> hosts most of the bugs.
>>> 
>>> Point 4 is particularly important. What we have in the draft is
>>> complex and difficult to test on a live network, and yet it is
>>> only there to take action when someone makes a mistake.
>>> Exception code like this is usually the Cinderella in the
>>> system, rushed in at the end of development and hardly tested.
>>> 
>>> It is usually by far the best approach to assert that the
>>> misconfiguration should never happen, have a very simple test
>>> do detect it and do something very simple by effective when
>>> it is detected. Given that routing only works because
>>> routers tell the truth, and clearly one or both of the routers
>>> has breached that trust, the best approach is to trust neither.
>>> 
>>> What is unclear to me is what to do with the traffic, i.e. do
>>> you degrade it to the base path, or do you drop it. I would think
>>> that the latter is the more conservative, because presumably it
>>> was put in the SR path for a reason, and so SHOULD be carried on
>>> an SR path.
>>> 
>>> - Stewart
>>> 
> 

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

Re: [spring] Conflict resolution - a plea for simplicity

[Stefano Previdi (sprevidi)]

Stewart,

thanks for the feedback.

Just to give you an update, the work currently done in the context of the 
conflict-resolution draft aimed to, indeed, limit/reduce the impact of a 
misconfiguration in presence of conflicting prefix/sid mappings.

It is based on the concept that there’s no such “bad” or “wrong” prefix/sid 
mapping as long as all nodes use the same.

However, while we came up with a very efficient scheme, complexity is also part 
of the picture from an implementation, deployment, troubleshooting perspective. 
Not to mention the fun we’re going to have in doing interoperability tests.

So, the authors have raised this concern a few times but apparently the only 
feedback we got (so far) from the WG was more oriented on the efficiency of the 
conflict-resolution algorithm, regardless the simplicity (which is fine by me 
as long as it is well understood).

Les Ginsberg is about to propose a simplification of the algorithm in order to 
(re)introduce the simplicity of the original proposal (or at least try to 
improve simplicity in the current scheme).

Thanks.
s.


> On Dec 2, 2016, at 6:54 PM, Stewart Bryant  wrote:
> 
> There was some discussion on the conflict resolution draft at IETF97
> that got cut off with a request to discuss on the list.
> 
> As I understand the situation, we have a misconfiguration in the network,
> and we are being encouraged to take an essentially aggressive strategy
> of picking one of the configurations and assuming that must be right
> in order to continue forwarding traffic. It seems to me that we are
> tossing a coin here and whilst we could be sending traffic the
> right way we could also be sending it the wrong way with bad
> consequences in terms of misdelivery or inducing congestion.
> 
> The alternative strategy is to note the conflict and not believe either
> router. This more conservative strategy seems the better approach for
> a number of reasons:
> 
> 1) Traffic will not be misdelivered, or use unintended parts of the network.
> 
> 2) Traffic,  was being routed via SR rather than simple shortest path
> for a reason and so you should not try to guess the operators decision,
> you should rigidly execute it.
> 
> 3) It seems to me that the aggressive approach fails 7 of Ross Callons
> Twelve truths (RFC1925). These were published on 1/April, but the real
> joke is that they ARE useful truths, so forget about the date. 3,
> 4, *5*, *6*, 8, probably 10, certainly 12.
> 
> 4) Finally there is the protocol 101 rule stating that the exception
> path MUST be simple, because it is rarely executed and thus often
> hosts most of the bugs.
> 
> Point 4 is particularly important. What we have in the draft is
> complex and difficult to test on a live network, and yet it is
> only there to take action when someone makes a mistake.
> Exception code like this is usually the Cinderella in the
> system, rushed in at the end of development and hardly tested.
> 
> It is usually by far the best approach to assert that the
> misconfiguration should never happen, have a very simple test
> do detect it and do something very simple by effective when
> it is detected. Given that routing only works because
> routers tell the truth, and clearly one or both of the routers
> has breached that trust, the best approach is to trust neither.
> 
> What is unclear to me is what to do with the traffic, i.e. do
> you degrade it to the base path, or do you drop it. I would think
> that the latter is the more conservative, because presumably it
> was put in the SR path for a reason, and so SHOULD be carried on
> an SR path.
> 
> - Stewart
> 

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

Re: [spring] WG LC for draft-ietf-spring-segment-routing

[Stefano Previdi (sprevidi)]

On Nov 30, 2016, at 2:27 PM, Stewart Bryant  wrote:
> On 30/11/2016 10:38, Stefano Previdi (sprevidi) wrote:
>>> On Nov 29, 2016, at 8:21 PM, Stewart Bryant  
>>> wrote:
>>> 
>>> The following are my comments on this text in response to the WGLC.
>>> A lot of comments are embedded in the draft text below.
>>> 
>>> However I have some major overarching comments. Although this is called
>>> an architecture it seems to be rather more of a description of how
>>> a large number of other documents combine to produce an overall
>>> specification for SR.
>> 
>> the references points to protocol extensions that would allow to implement 
>> the architecture. Then, you have other documents describing the use cases.
>> 
>> We’ve been debating quite a bit at the time of the spring wg forming and we 
>> agreed to separate these topics (i.e.: architecture, protocol extensions and 
>> use cases).
> 
> Separating them is fine, and having a use case dependency i.e. requirements 
> is OK, so long as the IESG agree to publish them (there is a policy decision 
> that makes this less automatic than it used to be).


indeed, things have slightly changed since the time the WG has been 
authoritatively formed...


> However I think the architecture really needs to stand alone and above the 
> implementations.
> 
>> 
>> Now, of course, having these references may impact the publication process 
>> of the architecture draft and maybe we should revisit many of the references.
> 
> That would be wise. Also because you are changing the IPv6 dataplane, I don't 
> think you can assume it is done until it is done and yet you have a lot of 
> detail in the architecture. I don't see why the architecture needs any of 
> that detail. At the arch level you really just have a list of instructions 
> yet to be executed and everything else is implementation of that architecture.
> 
>> 
>> Having said that, having a document with all the pointers to use cases and 
>> protocols helps the reader.
>> 
>> 
>>> Certainly for an architecture the number
>>> of forward references to detailed solutions for a description of the
>>> concept is quite extraordinary.
>>> 
>>> So embedded is the contents of some of these referenced documents
>>> that I do not think that it safe to publish this text other than
>>> synchronously with some of those documents. This is absolutely the case
>>> for the dataplane definitions, especially for IPv6, but seems
>>> likely to apply to other references. The further implication of
>>> the constant dependence on other documents is that many of them
>>> are really normative rather  than informative references, making
>>> this document a hostage to their fate.
>>> 
>>> It is far more conventional in an architecture to set out the general
>>> description and state the invariants, and put the detail into
>>> specific protocol documents, but to have the architecture as a
>>> standalone text. In other words to set things out so that
>>> the reader understands how components fit together, what the subtleties
>>> are and what the constraints on the components are, but leave the
>>> component design decisions to the component designers.
>> 
>> we can easily re-phrase most of the sections and remove some of the 
>> references so to free (or relax) most of the dependencies.
> That would be a good idea.


we’re in sync then.


>>> Clearly I think this draft needs significant work before it is
>>> ready for submission to the IESG for publication.
>> 
>> Well, I think it may require some editorial changes but I think the 
>> architecture structure and component is pretty solid... otherwise we 
>> wouldn’t have multi-vendor implementations and deployments...
> 
> I agree that the MPLS side is likely to be safe.


well, even for SR IPv6 we do have multivendor implementations.

s.


> I don't think IP is as safe and will not do so until I actually see it in the 
> RFC editor's queue. I do worry that the stack/(list+pointer) + address scope 
> differences may lead to design stress going forward.
> 
> I have not looked at the detail of the sub-components yet.
> 
>> 
>> I’ll go through your other comments in a separate email.
>> 
>> Thanks.
>> s.
>> 
> 
> - Stewart
> 
>> 
>>> - Stewart
>>> 
>>> 
>>> 
>>> 
>>> Network Working Group   C. Filsfils, Ed.
>>> Internet-Draft  

Re: [spring] WG LC for draft-ietf-spring-segment-routing

[Stefano Previdi (sprevidi)]

> On Nov 29, 2016, at 8:21 PM, Stewart Bryant  wrote:
> 
> The following are my comments on this text in response to the WGLC.
> A lot of comments are embedded in the draft text below.
> 
> However I have some major overarching comments. Although this is called
> an architecture it seems to be rather more of a description of how
> a large number of other documents combine to produce an overall
> specification for SR.


the references points to protocol extensions that would allow to implement the 
architecture. Then, you have other documents describing the use cases.

We’ve been debating quite a bit at the time of the spring wg forming and we 
agreed to separate these topics (i.e.: architecture, protocol extensions and 
use cases).

Now, of course, having these references may impact the publication process of 
the architecture draft and maybe we should revisit many of the references.

Having said that, having a document with all the pointers to use cases and 
protocols helps the reader.


> Certainly for an architecture the number
> of forward references to detailed solutions for a description of the
> concept is quite extraordinary.
> 
> So embedded is the contents of some of these referenced documents
> that I do not think that it safe to publish this text other than
> synchronously with some of those documents. This is absolutely the case
> for the dataplane definitions, especially for IPv6, but seems
> likely to apply to other references. The further implication of
> the constant dependence on other documents is that many of them
> are really normative rather  than informative references, making
> this document a hostage to their fate.
> 
> It is far more conventional in an architecture to set out the general
> description and state the invariants, and put the detail into
> specific protocol documents, but to have the architecture as a
> standalone text. In other words to set things out so that
> the reader understands how components fit together, what the subtleties
> are and what the constraints on the components are, but leave the
> component design decisions to the component designers.


we can easily re-phrase most of the sections and remove some of the references 
so to free (or relax) most of the dependencies.


> Clearly I think this draft needs significant work before it is
> ready for submission to the IESG for publication.


Well, I think it may require some editorial changes but I think the 
architecture structure and component is pretty solid... otherwise we wouldn’t 
have multi-vendor implementations and deployments... 

I’ll go through your other comments in a separate email.

Thanks.
s.



> 
> - Stewart
> 
> 
> 
> 
> Network Working Group   C. Filsfils, Ed.
> Internet-Draft   S. Previdi, Ed.
> Intended status: Standards Track Cisco Systems, Inc.
> Expires: May 23, 2017B. Decraene
>S. Litkowski
>  Orange
>   R. Shakir
>  Google
>   November 19, 2016
> 
> 
>  Segment Routing Architecture
>  draft-ietf-spring-segment-routing-10
> 
> Abstract
> 
>   Segment Routing (SR) leverages the source routing paradigm.  A node
>   steers a packet through an ordered list of instructions, called
>   segments.  A segment can represent any instruction, topological or
>   service-based.  A segment can have a local semantic to an SR node or
>   global within an SR domain.  SR allows to enforce a flow through any
>   topological path and service chain while maintaining per-flow state
>   only at the ingress node to the SR domain.
> 
> SB> Since you mention service chains here, we really should be having
> SB> a wider discussion about whether SR and SFC are really the same
> SB> technology.
> 
>   Segment Routing can be directly applied to the MPLS architecture with
>   no change on the forwarding plane.
> 
> SB> Applied to or implemented using MPLS?
> 
>   A segment is encoded as an MPLS
>   label.  An ordered list of segments is encoded as a stack of labels.
>   The segment to process is on the top of the stack.  Upon completion
>   of a segment, the related label is popped from the stack.
> 
>   Segment Routing can be applied to the IPv6 architecture, with a new
>   type of routing header.  A segment is encoded as an IPv6 address.  An
>   ordered list of segments is encoded as an ordered list of IPv6
>   addresses in the routing header.  The active segment is indicated by
>   the Destination Address of the packet.  The next active segment is
>   indicated by a pointer in the new routing header.
> 
> SB> You really cannot say this until the v6 de

[spring] authors, please read

[Stefano Previdi (sprevidi)]

As mentioned by Martin during our meeting in Seoul, there are drafts for which 
we still miss IPR statement from some of the authors.

The algorithm is the following:
. if you’re co-author of any segment-routing related draft
.   do check if your IPR declaration is done AND
.   do check that your email address and affiliation is 
 correctly reflected in your drafts 

At this stage we took too much time on this IPR issue and we’re updating the 
author’s list of all drafts so to keep the process compliant with well known 
IETF IPR policy.


Thanks.
s.


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

Re: [spring] clarification of text in draft-ietf-spring-segment-routing-09

[Stefano Previdi (sprevidi)]

the current draft reflects the changes discussed during “the last several 
months”

the only missing update is about strict-spf and your proposed change is going 
to be included very soon (hopefully this week).

s.


> On Nov 15, 2016, at 12:29 AM, Chris Bowers  wrote:
> 
> Stefano,
> 
> Has the change suggested in this email been incorporated in the text of 
> draft-ietf-spring-segment-routing?  
> Can you publish the current working version of the draft with the WG so that 
> we can make sure that proposed textual changes and additions from the last 
> several months have been incorporated?
> 
> Chris
> 
> -----Original Message-
> From: Stefano Previdi (sprevidi) [mailto:sprev...@cisco.com] 
> Sent: Thursday, September 15, 2016 1:42 AM
> To: Chris Bowers 
> Cc: spring@ietf.org
> Subject: Re: [spring] clarification of text in 
> draft-ietf-spring-segment-routing-09
> 
> Hi Chris,
> 
> 
>> On Sep 12, 2016, at 4:04 PM, Chris Bowers  wrote:
>> 
>> As far as I can tell, this request for clarification of the text in 
>> draft-ietf-spring-segment-routing-09 has not been addressed.
>> 
>> Thanks,
>> Chris
>> 
>> -Original Message-
>> From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Chris Bowers
>> Sent: Wednesday, August 3, 2016 9:24 AM
>> To: spring@ietf.org
>> Subject: [spring] clarification of text in 
>> draft-ietf-spring-segment-routing-09
>> 
>> SPRING WG,
>> 
>> The following paragraph in section 3.2.1 of 
>> draft-ietf-spring-segment-routing-09 is confusing.
>> 
>>  The ingress node of an SR domain validates that the path to a prefix,
>>  advertised with a given algorithm, includes nodes all supporting the
>>  advertised algorithm.  In other words, when computing paths for a
>>  given algorithm, the transit nodes MUST compute the algorithm X on
>>  the IGP topology, regardless of the support of the algorithm X by the
>>  nodes in that topology.  As a consequence, if a node on the path does
>>  not support algorithm X, the IGP-Prefix segment will be interrupted
>>  and will drop packet on that node.  It's the responsibility of the
>>  ingress node using a segment to check that all downstream nodes
>>  support the algorithm of the segment.
>> 
>> I interpret the first, third, and fourth sentences in this paragraph as 
>> saying that an ingress node should make sure that transit nodes on a path 
>> install transit forwarding entries for prefix-SIDs for a given algorithm by 
>> looking that 
>> the SR-Algorithm (sub)-TLV advertised by the transit nodes before sending 
>> traffic on that path.   
>> 
>> However, the second sentence in the paragraph confuses this interpretation.  
>> 
>> "In other words, when computing 
>> paths for a
>>  given algorithm, the transit nodes MUST compute the algorithm X on
>>  the IGP topology, regardless of the support of the algorithm X by the
>>  nodes in that topology."
>> 
>> This sentence could be interpreted as saying that transit nodes must compute 
>> all algorithms advertised by any node in the topology, even if the transit 
>> node doesn't support the algorithm.  This sentence doesn't make sense to me. 
>> 
>> A simple solution would be to delete this second sentence.
> 
> I’d go for it.
> 
> Thanks.
> s.
> 
> 
>> However, other clarifying text would be another solution.
>> 
>> Thanks,
>> Chris
>> 
>> ___
>> 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
> 

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

Re: [spring] I-D Action: draft-filsfils-spring-large-scale-interconnect-04.txt

[Stefano Previdi (sprevidi)]

All,

added more text explaining the various figures and examples.


Thanks.
s.


> On Oct 30, 2016, at 7:58 PM, internet-dra...@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Source Packet Routing in Networking of the 
> IETF.
> 
>Title   : Interconnecting Millions Of Endpoints With Segment 
> Routing
>Authors : Clarence Filsfils
>  Dennis Cai
>  Stefano Previdi
>  Wim Henderickx
>  Dave Cooper
>  Francis Ferguson
>  Tim Laberge
>  Steven Lin
>  Bruno Decraene
>  Luay Jalil
>  Jeff Tantsura
>  Rob Shakir
>   Filename: draft-filsfils-spring-large-scale-interconnect-04.txt
>   Pages   : 11
>   Date: 2016-10-30
> 
> Abstract:
>   This document describes an application of Segment Routing to scale
>   the network to support hundreds of thousands of network nodes, and
>   tens of millions of physical underlay endpoints.  This use-case can
>   be applied to the interconnection of massive-scale DC's and/or large
>   aggregation networks.  Forwarding tables of midpoint and leaf nodes
>   only require a few tens of thousands of entries.
> 
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-filsfils-spring-large-scale-interconnect/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-filsfils-spring-large-scale-interconnect-04
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-filsfils-spring-large-scale-interconnect-04
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> I-D-Announce mailing list
> i-d-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

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

Re: [spring] I-D Action: draft-filsfils-spring-sr-recursing-info-03.txt

[Stefano Previdi (sprevidi)]

this is just a refresh. 

Note that this draft is in "Call For Adoption By WG” state.

Thanks.
s.


> On Oct 17, 2016, at 1:50 PM, internet-dra...@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Source Packet Routing in Networking of the 
> IETF.
> 
>Title   : Segment Routing Recursive Information
>Authors : Clarence Filsfils
>      Stefano Previdi
>  Peter Psenak
>  Les Ginsberg
>   Filename: draft-filsfils-spring-sr-recursing-info-03.txt
>   Pages   : 8
>   Date: 2016-10-17
> 
> Abstract:
>   Segment Routing (SR) allows for a flexible definition of end-to-end
>   paths within IGP topologies by encoding paths as sequences of
>   topological sub-paths, called "segments".  These segments are
>   advertised by the link-state routing protocols (IS-IS and OSPF).
> 
>   There are use cases where it is desirable to utilize a SID associated
>   with a given node in order to transport traffic destined to different
>   local services supported by such node.  This document defines the
>   mechanism to do so and illustrates it.
> 
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-filsfils-spring-sr-recursing-info/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-filsfils-spring-sr-recursing-info-03
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-filsfils-spring-sr-recursing-info-03
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> 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] I-D Action: draft-ietf-spring-resiliency-use-cases-07.txt

[Stefano Previdi (sprevidi)]

SPRINGers,

this is the updated version after Stephane and Sasha comments about path 
disjointness.

Let me know if it captures correctly the outcome of our discussion.

Thanks.
s.


> On Oct 11, 2016, at 11:57 AM, internet-dra...@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Source Packet Routing in Networking of the 
> IETF.
> 
>Title   : Resiliency use cases in SPRING networks
>Authors : Clarence Filsfils
>      Stefano Previdi
>  Pierre Francois
>  Bruno Decraene
>  Rob Shakir
>   Filename: draft-ietf-spring-resiliency-use-cases-07.txt
>   Pages   : 11
>   Date: 2016-10-11
> 
> Abstract:
>   This document identifies and describes the requirements for a set of
>   use cases related to network resiliency on Segment Routing (SPRING)
>   networks.
> 
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-spring-resiliency-use-cases/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-spring-resiliency-use-cases-07
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-resiliency-use-cases-07
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> 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] Issue with path protection for SR-TE LSPs

[Stefano Previdi (sprevidi)]

Stephane, Sasha, All,

just to be sure w’ere in sync.

It is obvious to me that it won’t make much sense to have a requirements 
stating that disjointness must be guaranteed in all cases and even when “any” 
failure occurs. 

In real networks, multiple (correlated or not) events may happen simultaneously 
and despite the theoretical possibility to always find disjointness, in 
practice the requirements is different.

Disjointness is computed on a specific topology and for a specific service 
(i.e.: no resource sharing between paths).

What’s important is that the spring architecture must be capable of ensuring 
disjointness in a given topology, monitor it and, in case of any network event, 
validate it (or re-validate it).

If something has changed in the network that brakes the disjointness, then the 
pdisjoint paths must be recomputed.

Thanks.
s.


> On Sep 30, 2016, at 2:21 PM, Stefano Previdi (sprevidi)  
> wrote:
> 
> Sasha, Stephane,
> 
> 
>> On Sep 30, 2016, at 1:29 PM, stephane.litkow...@orange.com wrote:
>> 
>> Hi,
>> 
>> Expressed this way I agree that this is an interesting additional 
>> requirement for the draft.
> 
> 
> I agree. I’ll update the draft.
> 
> s.
> 
> 
>> 
>> Best Regards,
>> 
>> Stephane
>> 
>> 
>> -Original Message-
>> From: Alexander Vainshtein [mailto:alexander.vainsht...@ecitele.com] 
>> Sent: Tuesday, September 27, 2016 14:41
>> To: LITKOWSKI Stephane OBS/OINIS
>> Cc: spring@ietf.org; Shell Nakash; Michael Gorokhovsky; 
>> draft-ietf-spring-resiliency-use-ca...@ietf.org; Marina Fizgeer; Rotem 
>> Cohen; DECRAENE Bruno IMT/OLN; Stefano Previdi (sprevidi)
>> Subject: RE: [spring] Issue with path protection for SR-TE LSPs
>> 
>> Stephane,
>> Lots of thanks for an important clarification.
>> 
>> But don’t you think that in addition to your statement "SPRING architecture 
>> MUST provide a way to compute paths that MUST NOT be protected by local 
>> repair techniques" the draft should also say that " SPRING architecture MUST 
>> provide a way to instantiate pairs of paths that will would remain disjoint 
>> in spite of any topology changes in the network"?
>> 
>> Regards,
>> Sasha
>> 
>> Office: +972-39266302
>> Cell:  +972-549266302
>> Email:   alexander.vainsht...@ecitele.com
>> 
>> 
>> -Original Message-
>> From: stephane.litkow...@orange.com [mailto:stephane.litkow...@orange.com] 
>> Sent: Tuesday, September 27, 2016 2:41 PM
>> To: Alexander Vainshtein ; DECRAENE Bruno 
>> IMT/OLN ; Stefano Previdi (sprevidi) 
>> 
>> Cc: spring@ietf.org; Shell Nakash ; Michael 
>> Gorokhovsky ; 
>> draft-ietf-spring-resiliency-use-ca...@ietf.org; Marina Fizgeer 
>> ; Rotem Cohen 
>> Subject: RE: [spring] Issue with path protection for SR-TE LSPs
>> 
>> Hi,
>> 
>> As Stefano mentioned, as it's a use case and requirement draft, we do not 
>> have to talk about solutions, and about issues in using one or other 
>> mechanism.
>> Such considerations about using or not some particular SIDs to fill the 
>> "path must not be protected by any local repair" constraint are up to a 
>> solution draft and not this document. Regarding this document, the 
>> requirement is clear : " SPRING architecture MUST provide a way to compute 
>> paths that MUST
>> NOT be protected by local repair techniques", that's all we can expect 
>> from this document.
>> 
>> Best Regards,
>> 
>> Stephane
>> 
>> 
>> -Original Message-
>> From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Alexander 
>> Vainshtein
>> Sent: Tuesday, September 27, 2016 12:22
>> To: DECRAENE Bruno IMT/OLN; Stefano Previdi (sprevidi)
>> Cc: spring@ietf.org; Shell Nakash; Michael Gorokhovsky; 
>> draft-ietf-spring-resiliency-use-ca...@ietf.org; Marina Fizgeer; Rotem Cohen
>> Subject: Re: [spring] Issue with path protection for SR-TE LSPs
>> 
>> Stefano, Bruno and all,
>> Lots of thanks for detailed responses that, frankly, now go much deeper than 
>> my original question.
>> 
>> My concern was about combining "regular" prefix SIDs advertised with the 
>> default algorithm and path protection for SR LSPs.
>> To the best of my understanding, within his, admittedly limited, scope:
>> - there is no way to guarantee that Main and Protection paths will remain 
>> disjoint following some topology changes in the network
>> - if some local protection for these SIDs is enabled in the network, there 
>&

[spring] IPR on draft-filsfils-spring-large-scale-interconnect-02.txt

[Stefano Previdi (sprevidi)]

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

s.


> On Oct 3, 2016, at 2:16 PM, bruno.decra...@orange.com wrote:
> 
> Authors,
> 
> As a reminder, we are missing the IPR statement from: Clarence Filsfils, 
> Stefano Previdi, Dave Cooper, Francis Ferguson, Tim LaBerge, Steven Lin, Luay 
> Jalil.
> 
> Regards,
> -- Bruno
> 
>> -Original Message-
>> From: IETF Secretariat [mailto:ietf-secretariat-re...@ietf.org]
>> Sent: Monday, October 03, 2016 1:42 PM
>> To: draft-filsfils-spring-large-scale-interconn...@ietf.org
>> Cc: aret...@cisco.com; martin.vigour...@nokia.com; spring-cha...@ietf.org; 
>> Martin
>> Vigoureux
>> Subject: Expiration impending: 
>> 
>> 
>> The following draft will expire soon:
>> 
>> Name: draft-filsfils-spring-large-scale-interconnect
>> Title:Interconnecting Millions Of Endpoints With Segment Routing
>> State:I-D Exists
>> Expires:  2016-10-06 (in 2 days, 19 hours)
> 
> 
> _
> 
> 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] Issue with path protection for SR-TE LSPs

[Stefano Previdi (sprevidi)]

Sasha, Stephane,


> On Sep 30, 2016, at 1:29 PM, stephane.litkow...@orange.com wrote:
> 
> Hi,
> 
> Expressed this way I agree that this is an interesting additional requirement 
> for the draft.


I agree. I’ll update the draft.

s.


> 
> Best Regards,
> 
> Stephane
> 
> 
> -Original Message-
> From: Alexander Vainshtein [mailto:alexander.vainsht...@ecitele.com] 
> Sent: Tuesday, September 27, 2016 14:41
> To: LITKOWSKI Stephane OBS/OINIS
> Cc: spring@ietf.org; Shell Nakash; Michael Gorokhovsky; 
> draft-ietf-spring-resiliency-use-ca...@ietf.org; Marina Fizgeer; Rotem Cohen; 
> DECRAENE Bruno IMT/OLN; Stefano Previdi (sprevidi)
> Subject: RE: [spring] Issue with path protection for SR-TE LSPs
> 
> Stephane,
> Lots of thanks for an important clarification.
> 
> But don’t you think that in addition to your statement "SPRING architecture 
> MUST provide a way to compute paths that MUST NOT be protected by local 
> repair techniques" the draft should also say that " SPRING architecture MUST 
> provide a way to instantiate pairs of paths that will would remain disjoint 
> in spite of any topology changes in the network"?
> 
> Regards,
> Sasha
> 
> Office: +972-39266302
> Cell:  +972-549266302
> Email:   alexander.vainsht...@ecitele.com
> 
> 
> -Original Message-
> From: stephane.litkow...@orange.com [mailto:stephane.litkow...@orange.com] 
> Sent: Tuesday, September 27, 2016 2:41 PM
> To: Alexander Vainshtein ; DECRAENE Bruno 
> IMT/OLN ; Stefano Previdi (sprevidi) 
> 
> Cc: spring@ietf.org; Shell Nakash ; Michael 
> Gorokhovsky ; 
> draft-ietf-spring-resiliency-use-ca...@ietf.org; Marina Fizgeer 
> ; Rotem Cohen 
> Subject: RE: [spring] Issue with path protection for SR-TE LSPs
> 
> Hi,
> 
> As Stefano mentioned, as it's a use case and requirement draft, we do not 
> have to talk about solutions, and about issues in using one or other 
> mechanism.
> Such considerations about using or not some particular SIDs to fill the "path 
> must not be protected by any local repair" constraint are up to a solution 
> draft and not this document. Regarding this document, the requirement is 
> clear : " SPRING architecture MUST provide a way to compute paths that MUST
>  NOT be protected by local repair techniques", that's all we can expect 
> from this document.
> 
> Best Regards,
> 
> Stephane
> 
> 
> -Original Message-
> From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Alexander 
> Vainshtein
> Sent: Tuesday, September 27, 2016 12:22
> To: DECRAENE Bruno IMT/OLN; Stefano Previdi (sprevidi)
> Cc: spring@ietf.org; Shell Nakash; Michael Gorokhovsky; 
> draft-ietf-spring-resiliency-use-ca...@ietf.org; Marina Fizgeer; Rotem Cohen
> Subject: Re: [spring] Issue with path protection for SR-TE LSPs
> 
> Stefano, Bruno and all,
> Lots of thanks for detailed responses that, frankly, now go much deeper than 
> my original question.
> 
> My concern was about combining "regular" prefix SIDs advertised with the 
> default algorithm and path protection for SR LSPs.
> To the best of my understanding, within his, admittedly limited, scope:
> - there is no way to guarantee that Main and Protection paths will remain 
> disjoint following some topology changes in the network
> - if some local protection for these SIDs is enabled in the network, there is 
> no way to guarantee that it will not affect some segments of such LSPs.
> 
> To the best of my understanding, Stefano's answers says that you can use some 
> "special" prefix-SIDs (e.g., marking them as not protecting, advertising tem 
> with some non-default algorithm etc.). I have no problem with these answers - 
> but from my POV they are out of the narrow scope of my original questions. 
> I do not think that this draft should list any specific solutions. But maybe 
> it should say that "the default prefix-SIDs" (i.e. prefix-SIDs advertised 
> with the default algorithm etc.) should not be used in specification of 
> SR-LSPs employing the path protection scheme?
> 
> Regards,
> Sasha
> 
> Office: +972-39266302
> Cell:  +972-549266302
> Email:   alexander.vainsht...@ecitele.com
> 
> -Original Message-
> From: spring [mailto:spring-boun...@ietf.org] On Behalf Of 
> bruno.decra...@orange.com
> Sent: Tuesday, September 27, 2016 12:08 PM
> To: Stefano Previdi (sprevidi) 
> Cc: spring@ietf.org; Alexander Vainshtein ; 
> Shell Nakash ; Michael Gorokhovsky 
> ; 
> draft-ietf-spring-resiliency-use-ca...@ietf.org; Marina Fizgeer 
> ; Rotem Cohen 
> Subject: Re: [spring] Issue with path protection for SR-

Re: [spring] Issue with path protection for SR-TE LSPs

[Stefano Previdi (sprevidi)]

> On Sep 27, 2016, at 9:50 AM, bruno.decra...@orange.com wrote:
> 
> Hi Stefano,
> 
> As an individual contributor, please find a comment inline
> 
>> From: Stefano Previdi (sprevidi) [mailto:sprev...@cisco.com]  > Sent: 
>> Monday, September 26, 2016 11:22 AM
>> 
>> 
>> 
>> 
>>> On Sep 26, 2016, at 11:14 AM, Stefano Previdi (sprevidi) 
>>>  wrote:
>>> 
>>> Hi Sasha,
>>> 
>>> sorry for being late. See below.
>>> 
>>> 
>>>> On Jul 10, 2016, at 11:07 AM, Alexander Vainshtein
>>  wrote:
>>>> 
>>>> Hi all,
>>>> I have read the SR Resiliency Use Cases draft and I have an issue with the 
>>>> path
>> protection use case.
>>>> 
>>>> The draft defines this use case with the following constrains/qualifiers 
>>>> (quoting from
>> Section 2):
>>>> · The operator configures two SPRING paths T1 and T2 from A to Z
>>>> · Initially, the customer traffic (e.g., PW traffic) is sent from 
>>>> A to Z via T1. When
>> T1 fails, the traffic is sent via T2.
>>>> · The two paths are made disjoint using the SPRING architecture
>>>> · The two configured paths T1 and T2 MUST NOT benefit from local 
>>>> protection
>>>> 
>>>> The draft does not go into any detail regarding the type of segments that 
>>>> the operator
>> uses when specifying T1 and T2, and the example given in the draft can be 
>> interpreted in
>> two ways:
>>>> · T1 and T2 are specified using only adjacency SID
>>>> · T1 and T2 are specified using node SIDs (or a mix of node SIDs 
>>>> and adjacency
>> SIDs).
>>> 
>>> 
>>> this is intentional.
>>> 
>>> It’s a use case draft where we describe the various protection requirements 
>>> and
>> strategies for protection.
>>> 
>>> It has never been intended to describe a specific solution.
>>> 
>>> 
>>>> If T1 and T2 are specified using node SIDs, there is no guarantee that 
>>>> these paths, even
>> if initially disjoint, will remain disjoint when the underlying network 
>> topology changes.
>>> 
>>> 
>>> It all depends on various factors among which the topology and how these 
>>> paths have
>> been computed (i.e.: for which failure: link/node/srlg). IOW, you _can_ 
>> compute disjoint
>> paths taking into account a given srlg failure.
>>> 
>>> For sure, a path expressed through an exhaustive (list of adj-sid will give 
>>> you the best
>> guarantee on the path the packet will take in all cases but it is not the 
>> point of the draft.
>>> 
>>> 
>>>> Further, if TI FRR is enabled in the network for protection of non-TE SR 
>>>> LSPs, the
>> fragments of T1 and T2 that are specified using node SIDs will not be 
>> excluded from local
>> protection.
>> 
>> 
>> sorry, I realized something is missing in my answer.
>> 
>> In fact, even using node-sids and even for non TE SR traffic, you can still 
>> ensure the path
>> you computed uses non protected sid’s.
>> 
>> Think about the use of strict-spf sid’s where the rule is clear: just 
>> fowllow spt and do not
>> diverge from it.
> 
> IMO, it would be useful to indicate in draft-ietf-spring-segment-routing that 
> strict-spf SID MUST NOT be protected by a local protection (aka Fast ReRoute).
> It may be obvious to you, but it was not for me. In particular in the case of 
> TI-LFA where the protection _do_ follow the SPF (indeed in the new topology, 
> but just like strict-spf after the IGP convergence)


Well, I’m not recommending this. I just took an example on how you could 
enforce a specific forwarding rule through a given segment identifier. There 
are multiple choices for that:
. add a flag to prefix-sid (i.e.: do not protect)
. define new “unprotected” SIDs
. define new algorithm
. use strict-spf algorithm
. probably more...

Here, in the context of this draft, I don’t think we have to list the possible 
solutions, right ?

My answer was given to Sasha when he claimed that there are now ways to prevent 
protection for a given traffic. That statement was wrong (IMO) and I 
illustrated one way to achieve it.

Thanks.
s.


> 
> Thanks
> --Bruno
> 
> 
>> s.
>> 
>> 
>>>> So it seems that path protection for SR LSPs as specified in the draft is 
>>>> only

Re: [spring] Issue with path protection for SR-TE LSPs

[Stefano Previdi (sprevidi)]

> On Sep 26, 2016, at 11:14 AM, Stefano Previdi (sprevidi)  
> wrote:
> 
> Hi Sasha,
> 
> sorry for being late. See below.
> 
> 
>> On Jul 10, 2016, at 11:07 AM, Alexander Vainshtein 
>>  wrote:
>> 
>> Hi all,
>> I have read the SR Resiliency Use Cases draft and I have an issue with the 
>> path protection use case.
>> 
>> The draft defines this use case with the following constrains/qualifiers 
>> (quoting from Section 2):
>> · The operator configures two SPRING paths T1 and T2 from A to Z
>> · Initially, the customer traffic (e.g., PW traffic) is sent from A 
>> to Z via T1. When T1 fails, the traffic is sent via T2.
>> · The two paths are made disjoint using the SPRING architecture
>> · The two configured paths T1 and T2 MUST NOT benefit from local 
>> protection
>> 
>> The draft does not go into any detail regarding the type of segments that 
>> the operator uses when specifying T1 and T2, and the example given in the 
>> draft can be interpreted in two ways:
>> · T1 and T2 are specified using only adjacency SID
>> · T1 and T2 are specified using node SIDs (or a mix of node SIDs and 
>> adjacency SIDs).
> 
> 
> this is intentional.
> 
> It’s a use case draft where we describe the various protection requirements 
> and  strategies for protection.
> 
> It has never been intended to describe a specific solution.
> 
> 
>> If T1 and T2 are specified using node SIDs, there is no guarantee that these 
>> paths, even if initially disjoint, will remain disjoint when the underlying 
>> network topology changes.
> 
> 
> It all depends on various factors among which the topology and how these 
> paths have been computed (i.e.: for which failure: link/node/srlg). IOW, you 
> _can_ compute disjoint paths taking into account a given srlg failure.
> 
> For sure, a path expressed through an exhaustive (list of adj-sid will give 
> you the best guarantee on the path the packet will take in all cases but it 
> is not the point of the draft.
> 
> 
>> Further, if TI FRR is enabled in the network for protection of non-TE SR 
>> LSPs, the fragments of T1 and T2 that are specified using node SIDs will not 
>> be excluded from local protection.


sorry, I realized something is missing in my answer.

In fact, even using node-sids and even for non TE SR traffic, you can still 
ensure the path you computed uses non protected sid’s. 

Think about the use of strict-spf sid’s where the rule is clear: just fowllow 
spt and do not diverge from it.

s.


>> So it seems that path protection for SR LSPs as specified in the draft is 
>> only applicable to paths that are specified using only adjacency SIDs.

> I don’t disagree while I believe it mostly depends on the topology. 
> 
> More important is the fact that the document should not focus on one specific 
> way of computing protection paths.
> 
> s.
> 
> 
>> 
>> Did I miss something substantial?
>> 
>> Regards, and lots fo thanks in advance,
>> Sasha
>> 
>> Office: +972-39266302
>> Cell:  +972-549266302
>> Email:   alexander.vainsht...@ecitele.com
>> 
>> ___
>> 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] Issue with path protection for SR-TE LSPs

[Stefano Previdi (sprevidi)]

Hi Sasha,

sorry for being late. See below.


> On Jul 10, 2016, at 11:07 AM, Alexander Vainshtein 
>  wrote:
> 
> Hi all,
> I have read the SR Resiliency Use Cases draft and I have an issue with the 
> path protection use case.
>  
> The draft defines this use case with the following constrains/qualifiers 
> (quoting from Section 2):
> · The operator configures two SPRING paths T1 and T2 from A to Z
> · Initially, the customer traffic (e.g., PW traffic) is sent from A 
> to Z via T1. When T1 fails, the traffic is sent via T2.
> · The two paths are made disjoint using the SPRING architecture
> · The two configured paths T1 and T2 MUST NOT benefit from local 
> protection
>  
> The draft does not go into any detail regarding the type of segments that the 
> operator uses when specifying T1 and T2, and the example given in the draft 
> can be interpreted in two ways:
> · T1 and T2 are specified using only adjacency SID
> · T1 and T2 are specified using node SIDs (or a mix of node SIDs and 
> adjacency SIDs).


this is intentional.

It’s a use case draft where we describe the various protection requirements and 
 strategies for protection.

It has never been intended to describe a specific solution.

 
> If T1 and T2 are specified using node SIDs, there is no guarantee that these 
> paths, even if initially disjoint, will remain disjoint when the underlying 
> network topology changes.


It all depends on various factors among which the topology and how these paths 
have been computed (i.e.: for which failure: link/node/srlg). IOW, you _can_ 
compute disjoint paths taking into account a given srlg failure.

For sure, a path expressed through an exhaustive (list of adj-sid will give you 
the best guarantee on the path the packet will take in all cases but it is not 
the point of the draft.


> Further, if TI FRR is enabled in the network for protection of non-TE SR 
> LSPs, the fragments of T1 and T2 that are specified using node SIDs will not 
> be excluded from local protection.
>  

> So it seems that path protection for SR LSPs as specified in the draft is 
> only applicable to paths that are specified using only adjacency SIDs.


I don’t disagree while I believe it mostly depends on the topology. 

More important is the fact that the document should not focus on one specific 
way of computing protection paths.

s.


>  
> Did I miss something substantial?
>  
> Regards, and lots fo thanks in advance,
> Sasha
>  
> Office: +972-39266302
> Cell:  +972-549266302
> Email:   alexander.vainsht...@ecitele.com
>  
> ___
> 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-mpls prior to WGLC

[Stefano Previdi (sprevidi)]

> On Sep 23, 2016, at 11:25 AM, Stewart Bryant  wrote:
> 
> https://www.google.com/patents/US9049233


sorry, we missed that one in the disclosure. I just updated the list and a new 
IPR disclosure has been issued.

s.


> 
> may be applicable, as may some of the cited patents.
> 
> Stewart
> 
> 
> On 09/09/2016 12:57, Martin Vigoureux wrote:
>> Authors and Contributors,
>> 
>> it seems that we are missing answers to the IPR question from a good number 
>> of people:
>> 
>> Authors: Clarence, Ahmed, Martin, and Edward
>> Contributors: Igor and Saku
>> 
>> Please do respond. We need this to move forward.
>> 
>> Thanks
>> -m
>> 
>> Le 08/08/2016 13:10, stephane.litkow...@orange.com a écrit :
>>> Hi,
>>> 
>>> I'm not aware of any IPR for this doc.
>>> 
>>> Brgds,
>>> 
>>> Stephane
>>> 
>>> -Original Message-
>>> From: John G.Scudder [mailto:j...@juniper.net]
>>> Sent: Sunday, July 24, 2016 14:52
>>> To: draft-ietf-spring-segment-routing-m...@ietf.org
>>> Cc: spring@ietf.org
>>> Subject: IPR for draft‐ietf-spring-segment‐routing-mpls 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-mpls. 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
>>> 
>>> _
>>>  
>>> 
>>> 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
> 
> ___
> 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] I-D Action: draft-ietf-spring-resiliency-use-cases-05.txt

[Stefano Previdi (sprevidi)]

Hi Stephane,

I incorporated your last comments and submitted a new version of the draft. Let 
me know if it addresses your comments.

Thanks.
s.



> On Sep 23, 2016, at 12:10 PM, stephane.litkow...@orange.com wrote:
> 
> Hi Stefano
> 
> Answers inline
> 
> Best Regards,
> 
> 
> -Original Message-
> From: Stefano Previdi (sprevidi) [mailto:sprev...@cisco.com] 
> Sent: Thursday, September 22, 2016 18:18
> To: LITKOWSKI Stephane OBS/OINIS
> Cc: SPRING WG
> Subject: Re: I-D Action: draft-ietf-spring-resiliency-use-cases-05.txt
> 
> Hi Stephane,
> 
> 
>> On Sep 20, 2016, at 2:07 PM, stephane.litkow...@orange.com wrote:
>> 
>> Hi Stefano,
>> 
>> Thanks for the great improvments in the text.
>> 
>> Few more comments :
>> 
>> §2 :
>> I still have an issue with : "the two paths are installed in the forwarding 
>> plane of A."
>> This works for sure, and in this case it would be good to mention that paths 
>> are working in a FRR approach providing sub-50msec restoration.
>> 
>> But I think it's too restrictive as path protection can be achieved by 
>> pre-computing T2 but not installing it in FIB (just present at RIB level or 
>> tunnel table => control plane level), so when T1 fails, T2 is pushed to FIB 
>> immediately.
> 
> 
> I’m ok with that but note that the whole paragraph starts with “For 
> example...” which means that it is just to illustrate one possible way.
> 
> So, I will remove the “installation" part of the paragraph.
> 
> 
>> It would be good to let both options opened as primary/backup LSPs with path 
>> protection can be implemented in both ways depending the level of service 
>> that we want to achieve for the restoration.
> 
> 
> I agree but I wouldn’t even try to list all the options...
> 
> [SLI] The idea is not to list all options but not to close options. As it is 
> written now, it looks as the only supported use cases will be the FRR use 
> case that you are presenting. So here, I just want the text to be more open.
> 
> 
>> §3.1 :
>> What about SRLG protection ? you provided text for link and node protection, 
>> it would be good to provide some for SRLG as well.
> 
> something like:
>In case of SRLG protection, the bypass will avoid 
>members of the same SRLG of the protected link.
> 
> [SLI] Yes, you need to add also that the path will need to merge asap of the 
> primary path (bypass case).
> 
> 
>> §4 :
>> Again, not sure that SRLG is a good example as it can be achieved using 
>> management free local protection.
> 
> 
> I agree. Note that the example works the same in case of BW constraint too.
> 
> [SLI] Right
> 
>> Could you find a more relevant example that could not be achieved through 
>> management free local protection ? maybe a BW or latency case ?
> 
> 
> in the case the node doesn’t want to use two links to protect each other due 
> to the amount of BW available on each of these links and that can’t absorb 
> the other link traffic.
> 
> [SLI] Fine
> 
>> §4.2 :
>> It would be good to add that the repair path customization should be on a 
>> per destination basis. As told it's more a per destination protection. I'm 
>> wondering if it would be better to name it in such way rather than using 
>> shortest path protection.
>> What do you think ?
> 
> 
> ok for me.
> 
> 
>> §9 :
>> "Also, necessary mechanisms SHOULD be provided ... to control when a repair 
>> path ..."
>> "When" is important, but "how" is also important, especially for managed 
>> protection. Would be good to add this.
> 
> 
> agreed.
> 
> I’ll submit the new version with your comments asap.
> 
> Thanks.
> s.
> 
> 
>> 
>> 
>> Best Regards,
>> 
>> Stephane
>> 
>> 
>> -Original Message-
>> From: Stefano Previdi (sprevidi) [mailto:sprev...@cisco.com]
>> Sent: Monday, September 19, 2016 19:44
>> To: LITKOWSKI Stephane OBS/OINIS
>> Cc: SPRING WG
>> Subject: Re: I-D Action: draft-ietf-spring-resiliency-use-cases-05.txt
>> 
>> Hi Stephane,
>> 
>> this version hopefully addresses your comments. Let me know if there’s 
>> anything that still needs to be addressed. 
>> 
>> Thanks.
>> s.
>> 
>> 
>>> On Sep 19, 2016, at 7:39 PM, internet-dra...@ietf.org wrote:
>>> 
>>> 
>>> A New Internet-Draft is available from the on-line Internet-Drafts 
>>> directories.
>>> This draft is a work item o

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

[Stefano Previdi (sprevidi)]

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 Vainshtein ; Jeff Tantsura 
>> ; Chris Bowers 
>> Cc: spring@ietf.org
>> Subject: Re: [spring] meaning of "Strict Shortest Path" algorithm in 
>> draft-ietf-spring-segment-routing-09
>> 
>> Chris, Jeff, Alex,
>> 
>> strict-SPF behavior has been intended as the forwarding of the packet 
>> according to spf, without

Re: [spring] I-D Action: draft-ietf-spring-resiliency-use-cases-05.txt

[Stefano Previdi (sprevidi)]

Hi Stephane,


> On Sep 20, 2016, at 2:07 PM, stephane.litkow...@orange.com wrote:
> 
> Hi Stefano,
> 
> Thanks for the great improvments in the text.
> 
> Few more comments :
> 
> §2 :
> I still have an issue with : "the two paths are installed in the forwarding 
> plane of A."
> This works for sure, and in this case it would be good to mention that paths 
> are working in a FRR approach providing sub-50msec restoration.
> 
> But I think it's too restrictive as path protection can be achieved by 
> pre-computing T2 but not installing it in FIB (just present at RIB level or 
> tunnel table => control plane level), so when T1 fails, T2 is pushed to FIB 
> immediately.


I’m ok with that but note that the whole paragraph starts with “For example...” 
which means that it is just to illustrate one possible way.

So, I will remove the “installation" part of the paragraph.


> It would be good to let both options opened as primary/backup LSPs with path 
> protection can be implemented in both ways depending the level of service 
> that we want to achieve for the restoration.


I agree but I wouldn’t even try to list all the options...


> §3.1 :
> What about SRLG protection ? you provided text for link and node protection, 
> it would be good to provide some for SRLG as well.

something like:
In case of SRLG protection, the bypass will avoid 
members of the same SRLG of the protected link.

 
> §4 :
> Again, not sure that SRLG is a good example as it can be achieved using 
> management free local protection.


I agree. Note that the example works the same in case of BW constraint too.


> Could you find a more relevant example that could not be achieved through 
> management free local protection ? maybe a BW or latency case ?


in the case the node doesn’t want to use two links to protect each other due to 
the amount of BW available on each of these links and that can’t absorb the 
other link traffic.


> §4.2 :
> It would be good to add that the repair path customization should be on a per 
> destination basis. As told it's more a per destination protection. I'm 
> wondering if it would be better to name it in such way rather than using 
> shortest path protection.
> What do you think ?


ok for me.


> §9 :
> "Also, necessary mechanisms SHOULD be provided ... to control when a repair 
> path ..."
> "When" is important, but "how" is also important, especially for managed 
> protection. Would be good to add this.


agreed.

I’ll submit the new version with your comments asap.

Thanks.
s.


> 
> 
> Best Regards,
> 
> Stephane
> 
> 
> -Original Message-
> From: Stefano Previdi (sprevidi) [mailto:sprev...@cisco.com] 
> Sent: Monday, September 19, 2016 19:44
> To: LITKOWSKI Stephane OBS/OINIS
> Cc: SPRING WG
> Subject: Re: I-D Action: draft-ietf-spring-resiliency-use-cases-05.txt
> 
> Hi Stephane,
> 
> this version hopefully addresses your comments. Let me know if there’s 
> anything that still needs to be addressed. 
> 
> Thanks.
> s.
> 
> 
>> On Sep 19, 2016, at 7:39 PM, internet-dra...@ietf.org wrote:
>> 
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories.
>> This draft is a work item of the Source Packet Routing in Networking of the 
>> IETF.
>> 
>>   Title   : Use-cases for Resiliency in SPRING
>>   Authors : Clarence Filsfils
>> Stefano Previdi
>> Pierre Francois
>> Bruno Decraene
>> Rob Shakir
>>  Filename: draft-ietf-spring-resiliency-use-cases-05.txt
>>  Pages   : 11
>>  Date: 2016-09-19
>> 
>> Abstract:
>>  This document identifies and describe the requirements for a set of
>>  use cases related to network resiliency on Segment Routing (SPRING)
>>  networks.
>> 
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-spring-resiliency-use-case
>> s/
>> 
>> There's also a htmlized version available at:
>> https://tools.ietf.org/html/draft-ietf-spring-resiliency-use-cases-05
>> 
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-resiliency-use-cas
>> es-05
>> 
>> 
>> Please note that it may take a couple of minutes from the time of 
>> submission until the htmlized version and diff are available at 
>> tools.ietf.org.
>> 
>> Internet-Drafts are also available by anonymous FTP at:
>&g

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

[Stefano Previdi (sprevidi)]

> 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 Vainshtein ; Jeff Tantsura 
> ; Chris Bowers 
> Cc: spring@ietf.org
> Subject: Re: [spring] meaning of "Strict Shortest Path" algorithm in 
> draft-ietf-spring-segment-routing-09
> 
> Chris, Jeff, Alex,
> 
> strict-SPF behavior has been intended as the forwarding of the packet 
> according to spf, without any form of policy. 
> 
> It is true that ecmp is a matter of local implementation so we could extend 
> the behavior description to:
> 
> forwarding of the packet according to spf, 
> without any form of policy and according 
> to ecmp capability of the node.
> 
> Now, if you intentionally (through configuration) reduce the number of ecmp 
> members, isn’t this fit the definition of a policy ?
> 
> The strict-spf behavior has been defined for exactly that purpose: allow an 
> instruction to override any policy decision.
> 
> Note well, I’m not opposed to relax the constraint and allow ecmp differences 
> in the “strict-spf” behavior. It’s just that at this stage I’m not (yet) 
> convinced it’s a good thing.
> 
> s.
> 
> 
>> On Sep 19, 2016, at 2:27 PM, Alexander Vainshtein 
>>  wrote:
>> 
>> Jeff,
>> I fully agree with what you say: from my POV restrictions on the number of 
>> ECMP next hops do not make an SPF less strict.
>> 
>> Regards,
>> Sasha
>> 
>> Office: +972-39266302
>> Cell:  +972-549266302
>> Email:   alexander.vainsht...@ecitele.com
>> 
>> From: Jeff Tantsura [mailto:jefftant.i...@gmail.com]
>> Sent: Monday, September 19, 2016 3:09 PM
>> To: Stefano Previdi (sprevidi) 
>> Cc: Alexander Vainshtein ; 
>> spring@ietf.org; Chris Bowers 
>> Subject: Re: [spring] meaning of "Strict Shortest Path" algorith

Re: [spring] I-D Action: draft-ietf-spring-resiliency-use-cases-05.txt

[Stefano Previdi (sprevidi)]

Hi Stephane,

this version hopefully addresses your comments. Let me know if there’s anything 
that still needs to be addressed. 

Thanks.
s.

 
> On Sep 19, 2016, at 7:39 PM, internet-dra...@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Source Packet Routing in Networking of the 
> IETF.
> 
>Title   : Use-cases for Resiliency in SPRING
>Authors : Clarence Filsfils
>      Stefano Previdi
>  Pierre Francois
>  Bruno Decraene
>  Rob Shakir
>   Filename: draft-ietf-spring-resiliency-use-cases-05.txt
>   Pages   : 11
>   Date: 2016-09-19
> 
> Abstract:
>   This document identifies and describe the requirements for a set of
>   use cases related to network resiliency on Segment Routing (SPRING)
>   networks.
> 
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-spring-resiliency-use-cases/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-spring-resiliency-use-cases-05
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-resiliency-use-cases-05
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> I-D-Announce mailing list
> i-d-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

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

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

[Stefano Previdi (sprevidi)]

Chris, Jeff, Alex,

strict-SPF behavior has been intended as the forwarding of the packet according 
to spf, without any form of policy. 

It is true that ecmp is a matter of local implementation so we could extend the 
behavior description to:

 forwarding of the packet according to spf, 
 without any form of policy and according 
 to ecmp capability of the node.

Now, if you intentionally (through configuration) reduce the number of ecmp 
members, isn’t this fit the definition of a policy ?

The strict-spf behavior has been defined for exactly that purpose: allow an 
instruction to override any policy decision.

Note well, I’m not opposed to relax the constraint and allow ecmp differences 
in the “strict-spf” behavior. It’s just that at this stage I’m not (yet) 
convinced it’s a good thing.

s.


> On Sep 19, 2016, at 2:27 PM, Alexander Vainshtein 
>  wrote:
> 
> Jeff,
> I fully agree with what you say: from my POV restrictions on the number of 
> ECMP next hops do not make an SPF less strict.
>  
> Regards,
> Sasha
>  
> Office: +972-39266302
> Cell:  +972-549266302
> Email:   alexander.vainsht...@ecitele.com
>  
> From: Jeff Tantsura [mailto:jefftant.i...@gmail.com] 
> Sent: Monday, September 19, 2016 3:09 PM
> To: Stefano Previdi (sprevidi) 
> Cc: Alexander Vainshtein ; spring@ietf.org; 
> Chris Bowers 
> Subject: Re: [spring] meaning of "Strict Shortest Path" algorithm in 
> draft-ietf-spring-segment-routing-09
>  
> Number if ECMP paths is an implementation subject and would differ from 
> platform to platform. The way subset of ECMP paths is chosen is local to the 
> implementation.
> If you limit number of paths/size of ECMP bundle - it doesn't make it less 
> SPF-strict as long as SPF(Dijkstra) has been applied to compute.
> 
> Regards,
> Jeff
> 
> On Sep 19, 2016, at 12:21 PM, Stefano Previdi (sprevidi)  
> wrote:
> 
> sorry. What I meant is that if you restrict the number of ecmp path you have 
> computed, it is not what the definition of strict-spf is.
> 
> IOW, strict-spf means that you forward according to what SPF algorithm has 
> computed without applying any sort of constraint/policy/hack.
> 
> s.
> 
> 
> 
> On Sep 19, 2016, at 12:17 PM, Alexander Vainshtein 
>  wrote:
>  
> Stefano, Chris and all,
> I have to admit that I am completely confused:
>- to the best of my understanding, Chris has asked whether a policy that 
> puts a limit on max. number of ECMP next hops is not compatible with the 
> Strict SPF algorithm
>- Stefano says that "Yes, this policy is a good example when Strict SPF 
> algorithm can be advertised".
>  
>  
> What do I miss?
> Regards,
> Sasha
>  
> Office: +972-39266302
> Cell:  +972-549266302
> Email:   alexander.vainsht...@ecitele.com
>  
> -Original Message-
> From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Stefano Previdi 
> (sprevidi)
> Sent: Monday, September 19, 2016 12:43 PM
> To: Chris Bowers 
> Cc: spring@ietf.org
> Subject: Re: [spring] meaning of "Strict Shortest Path" algorithm in 
> draft-ietf-spring-segment-routing-09
>  
>  
> On Sep 14, 2016, at 7:06 PM, Chris Bowers  wrote:
>  
> SPRING WG,
>  
> The current text in draft-ietf-spring-segment-routing-09 regarding the
> "Strict Shortest Path" algorithm reads as follows.
>  
>  o  "Strict Shortest Path": This algorithm mandates that the packet is
> forwarded according to ECMP-aware SPF algorithm and instruct any
> router in the path to ignore any possible local policy overriding
> SPF decision.  The SID advertised with "Strict Shortest Path"
> algorithm ensures that the path the packet is going to take is the
> expected, and not altered, SPF path.
>  
> One example of a local policy that overrides the ECMP-aware SPF
> algorithm decision is a limit on the number of ECMP next-hops.  The
> text above implies that if a router places any limit on the number of
> ECMP forwarding next-hops then it would be wrong for it to advertise the 
> “Strict Shortest Path” algorithm capability.
>  
> Is this the intended interpretation?
>  
>  
> well, yes. Your example is a good one for the “strict-SPF” behavior.
>  
> s.
>  
>  
>  
> If not, what is the intended interpretation?
>  
> Thanks,
> Chris
>  
> ___
> 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
> 
> ___
> 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] meaning of "Strict Shortest Path" algorithm in draft-ietf-spring-segment-routing-09

[Stefano Previdi (sprevidi)]

sorry. What I meant is that if you restrict the number of ecmp path you have 
computed, it is not what the definition of strict-spf is.

IOW, strict-spf means that you forward according to what SPF algorithm has 
computed without applying any sort of constraint/policy/hack.

s.


> On Sep 19, 2016, at 12:17 PM, Alexander Vainshtein 
>  wrote:
> 
> Stefano, Chris and all,
> I have to admit that I am completely confused:
>   - to the best of my understanding, Chris has asked whether a policy 
> that puts a limit on max. number of ECMP next hops is not compatible with the 
> Strict SPF algorithm
>   - Stefano says that "Yes, this policy is a good example when Strict SPF 
> algorithm can be advertised".
> 
> 
> What do I miss?
> Regards,
> Sasha
> 
> Office: +972-39266302
> Cell:  +972-549266302
> Email:   alexander.vainsht...@ecitele.com
> 
> -Original Message-----
> From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Stefano Previdi 
> (sprevidi)
> Sent: Monday, September 19, 2016 12:43 PM
> To: Chris Bowers 
> Cc: spring@ietf.org
> Subject: Re: [spring] meaning of "Strict Shortest Path" algorithm in 
> draft-ietf-spring-segment-routing-09
> 
> 
>> On Sep 14, 2016, at 7:06 PM, Chris Bowers  wrote:
>> 
>> SPRING WG,
>> 
>> The current text in draft-ietf-spring-segment-routing-09 regarding the 
>> "Strict Shortest Path" algorithm reads as follows.
>> 
>>   o  "Strict Shortest Path": This algorithm mandates that the packet is
>>  forwarded according to ECMP-aware SPF algorithm and instruct any
>>  router in the path to ignore any possible local policy overriding
>>  SPF decision.  The SID advertised with "Strict Shortest Path"
>>  algorithm ensures that the path the packet is going to take is the
>>  expected, and not altered, SPF path.
>> 
>> One example of a local policy that overrides the ECMP-aware SPF 
>> algorithm decision is a limit on the number of ECMP next-hops.  The 
>> text above implies that if a router places any limit on the number of 
>> ECMP forwarding next-hops then it would be wrong for it to advertise the 
>> “Strict Shortest Path” algorithm capability.
>> 
>> Is this the intended interpretation?
> 
> 
> well, yes. Your example is a good one for the “strict-SPF” behavior.
> 
> s.
> 
> 
>> 
>> If not, what is the intended interpretation?
>> 
>> Thanks,
>> Chris
>> 
>> ___
>> 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

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

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

[Stefano Previdi (sprevidi)]

> On Sep 14, 2016, at 7:06 PM, Chris Bowers  wrote:
> 
> SPRING WG,
>  
> The current text in draft-ietf-spring-segment-routing-09 regarding the 
> "Strict Shortest Path" algorithm reads as follows.  
>  
>o  "Strict Shortest Path": This algorithm mandates that the packet is
>   forwarded according to ECMP-aware SPF algorithm and instruct any
>   router in the path to ignore any possible local policy overriding
>   SPF decision.  The SID advertised with "Strict Shortest Path"
>   algorithm ensures that the path the packet is going to take is the
>   expected, and not altered, SPF path.
>  
> One example of a local policy that overrides the ECMP-aware SPF algorithm 
> decision is a limit 
> on the number of ECMP next-hops.  The text above implies that if a router 
> places any 
> limit on the number of ECMP forwarding next-hops then it would be wrong for 
> it to advertise 
> the “Strict Shortest Path” algorithm capability.  
>  
> Is this the intended interpretation?


well, yes. Your example is a good one for the “strict-SPF” behavior.

s.


>  
> If not, what is the intended interpretation?
>  
> Thanks,
> Chris
>  
> ___
> 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] clarification of text in draft-ietf-spring-segment-routing-09

[Stefano Previdi (sprevidi)]

Hi Chris,


> On Sep 12, 2016, at 4:04 PM, Chris Bowers  wrote:
> 
> As far as I can tell, this request for clarification of the text in 
> draft-ietf-spring-segment-routing-09 has not been addressed.
> 
> Thanks,
> Chris
> 
> -Original Message-
> From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Chris Bowers
> Sent: Wednesday, August 3, 2016 9:24 AM
> To: spring@ietf.org
> Subject: [spring] clarification of text in 
> draft-ietf-spring-segment-routing-09
> 
> SPRING WG,
> 
> The following paragraph in section 3.2.1 of 
> draft-ietf-spring-segment-routing-09 is confusing.
> 
>   The ingress node of an SR domain validates that the path to a prefix,
>   advertised with a given algorithm, includes nodes all supporting the
>   advertised algorithm.  In other words, when computing paths for a
>   given algorithm, the transit nodes MUST compute the algorithm X on
>   the IGP topology, regardless of the support of the algorithm X by the
>   nodes in that topology.  As a consequence, if a node on the path does
>   not support algorithm X, the IGP-Prefix segment will be interrupted
>   and will drop packet on that node.  It's the responsibility of the
>   ingress node using a segment to check that all downstream nodes
>   support the algorithm of the segment.
> 
> I interpret the first, third, and fourth sentences in this paragraph as 
> saying that an ingress node should make sure that transit nodes on a path 
> install transit forwarding entries for prefix-SIDs for a given algorithm by 
> looking that 
> the SR-Algorithm (sub)-TLV advertised by the transit nodes before sending 
> traffic on that path.   
> 
> However, the second sentence in the paragraph confuses this interpretation.  
> 
>  "In other words, when computing 
> paths for a
>   given algorithm, the transit nodes MUST compute the algorithm X on
>   the IGP topology, regardless of the support of the algorithm X by the
>   nodes in that topology."
> 
> This sentence could be interpreted as saying that transit nodes must compute 
> all algorithms advertised by any node in the topology, even if the transit 
> node doesn't support the algorithm.  This sentence doesn't make sense to me. 
> 
> A simple solution would be to delete this second sentence.

I’d go for it.

Thanks.
s.


>  However, other clarifying text would be another solution.
> 
> Thanks,
> Chris
> 
> ___
> 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

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

Re: [spring] I-D Action: draft-ietf-spring-segment-routing-central-epe-02.txt

[Stefano Previdi (sprevidi)]

FYI,

just a refresh.

s.


> On Sep 13, 2016, at 10:24 AM, internet-dra...@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Source Packet Routing in Networking of the 
> IETF.
> 
>Title   : Segment Routing Centralized BGP Peer Engineering
>Authors : Clarence Filsfils
>      Stefano Previdi
>  Ebben Aries
>  Daniel Ginsburg
>  Dmitry Afanasiev
>   Filename: draft-ietf-spring-segment-routing-central-epe-02.txt
>   Pages   : 18
>   Date: 2016-09-13
> 
> Abstract:
>   Segment Routing (SR) leverages source routing.  A node steers a
>   packet through a controlled set of instructions, called segments, by
>   prepending the packet with an SR header.  A segment can represent any
>   instruction topological or service-based.  SR allows to enforce a
>   flow through any topological path and service chain while maintaining
>   per-flow state only at the ingress node of the SR domain.
> 
>   The Segment Routing architecture can be directly applied to the MPLS
>   dataplane with no change on the forwarding plane.  It requires minor
>   extension to the existing link-state routing protocols.
> 
>   This document illustrates the application of Segment Routing to solve
>   the BGP Peer Engineering (BGP-PE) requirement.  The SR-based BGP-PE
>   solution allows a centralized (SDN) controller to program any egress
>   peer policy at ingress border routers or at hosts within the domain.
>   This document is on the informational track.
> 
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-central-epe/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-spring-segment-routing-central-epe-02
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-segment-routing-central-epe-02
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> 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] REMINDER : Shepherd's review of draft-ietf-spring-resiliency-use-cases

[Stefano Previdi (sprevidi)]

Hi Stephane,

I’ll take care of this asap. Sorry for the delay.

s.


> On Sep 7, 2016, at 1:05 PM, stephane.litkow...@orange.com wrote:
> 
> Hi Authors,
>  
> Could you please check the comment’s below so we can continue to progress the 
> document ?
>  
> Thanks !
>  
> From: spring [mailto:spring-boun...@ietf.org] On Behalf Of 
> stephane.litkow...@orange.com
> Sent: Monday, August 22, 2016 15:14
> To: draft-ietf-spring-resiliency-use-ca...@ietf.org
> Cc: spring@ietf.org; rt...@ietf.org
> Subject: [spring] Shepherd review of draft-oetf-spring-resiliency-use-cases
>  
> Hi,
>  
> I have been selected as Shepherd for this document, and as part of my review 
> I have several comments that you will find below :
>  
> General :
> Is it a requirement document ? If yes, it would be good to mention it. The 
> document states requirements multiple times.
>  
>  
> Abstract :
> The abstract is really short, would be good to enhance it with what is 
> exactly described.
>  
> In Section 1, there should be an issue with the XML file as the hypertext 
> link is missing at : “We discuss two different approaches to provide …, in 
> Section 3”. Hyperlink missing for “Section 3”.
>  
> In Section 2, 
> It would be good to state in the example that the paths must not be protected 
> by any local repair techniques. Example : “The two paths are made disjoint 
> using the SPRING architecture and must not be protected by any local repair 
> techniques”.
>  
> As a requirement, the two paths must be disjoint (link or node, or srlg), 
> this has some impacts on the path expression : using a node-SID would be a 
> bad idea as there is no guarantee. It would be good to mention that the 
> solution must take care of this.
>  
> It would be easier to state that path T1 is primary and T2 is backup instead 
> of : “When T1 is  up, the packets of the PW are sent on T1”.
> Why not using the following text :
> “T1 is programmed as primary forwarding entry while T2 is a backup entry. In 
> nominal state, PW traffic is carried over T1. When T1 fails, the PW traffic 
> is switched on T2”.
> Before telling that the solution for end-to-end liveness is out of scope, it 
> would be good to state that it is mandatory to have such mechanism to make 
> the solution work. Is it a SPRING path liveness check or service liveness 
> check ?  It would be good to tell who is in charge of the detection and path 
> switchover ? is it LSP ingress, is it a node outside SPRING network ? If 
> there are multiple options, please tell it.
>  
> I would propose to change the last sentence to highlight the two requirements 
> in case we need SPRING path liveness check :
> “From a SPRING viewpoint, the SPRING architecture MUST provide end-to-end 
> liveness check of SPRING based LSPs. In addition, it MUST provide a way to 
> create LSPs that must not be protected by local repair techniques.”
>  
> Globally this section looks confusing to me. End to end protection could be 
> achieved in multiple ways, for example :
> - Having a dumb network that only provides disjoint non protected path and 
> having end-to-end probes at service level that would help an external 
> component to switchover traffic. Provider network is not aware of the 
> protection done. In your figure we can add A’ and Z’, and we establish two 
> disjoint LSPs (A->Z and A’->Z’). Customer is dual meshed to A/A’ and Z/Z’ and 
> is managing liveness check and switchover (network is not involved).
> - Having primary/backup like approach : two disjoint LSPs from A->Z , A 
> programs one in FIB. A provides OAM on the LSP. When primary LSP fails, the 
> second one is installed in FIB.
> - Having FRR like approach : two disjoint LSPs from A->Z , A programs both in 
> FIB in a FRR like fashion. A provides aggressive OAM on the LSPs to enable 
> traffic switchover in a very short time.
>  
> The current text is not really clear on the proposed approach. Maybe another 
> one ?
>  
>  
> Section 3
> s/the backup path computation should/the backup path computation SHOULD/
> s/in any topology/in any topology./
> s/by the IGP/by the IGP./
>  
> Section 3.1
> “ending at the protected nexthop”, that’s true only for link protection, but 
> not possible in case of node protection. This sentence is a generic one and 
> is not specific to link protection case.
> I cannot parse : “so as to bypass the failed component …”
> I would propose something like :
> “One way to provide local repair is to enforce a failover along the shortest 
> path around the protected component. In case of link protection,  the point 
> of local repair will create a bypass avoiding the protected link and merging 
> back to primary path at the nexthop. In case of node protection, the bypass 
> will avoid the protected node and merge back to primary path at the 
> next-nexthop.”
> What about SRLG case ?
>  
> “In our example, C protects Z”, protects for what ? link / node /srlg failure 
> ? proposed text : “In our example, C protects destinatio

Re: [spring] 答复: Re: WG adoption requested for draft-filsfils-spring-sr-recursing-info

[Stefano Previdi (sprevidi)]

> On Aug 25, 2016, at 4:41 AM, peng.sha...@zte.com.cn wrote:
> 
> Stefano, 
> 
> see inline with [Deccan] 
> 
> Thanks 
> Deccan 
> 
> 
> 
> "Stefano Previdi (sprevidi)" 
> 2016-08-23 23:22
> 
> 收件人
> "peng.sha...@zte.com.cn" ,
> 抄送
> SPRING WG 
> 主题
> Re: [spring] WG adoption requested for draft-filsfils-spring-sr-recursing-info
> 
> 
> 
> 
> 
> Hi Deccan,
> 
> 
> > On Aug 23, 2016, at 4:39 AM, peng.sha...@zte.com.cn wrote:
> > 
> > Hi Stefano 
> > 
> > Sure, SRRI provided in this document can explicitly indicate a recursive 
> > operation (or relationship). 
> > But it maybe a default behavior to do recursive operation when an SR-NODE 
> > received remote prefix-sid with L/V flag set according to the documents 
> > already existed. For example, 
> > prefix reachability advertisement received: 
> > prefix (1.0.0.99/32) 
> > prefix-sid (30004), L/V flag set,  //ISIS-SR 
> > "IPv4 Source Router ID" is 1.0.0.4 //rfc7794 
> > Then, prefix 1.0.0.9/32 can do recursion to prefix 1.0.0.4/32 by default.
> 
> 
> there are other cases where V/L are used so I wouldn’t 
> bind these flags to the recursive behavior.
> 
> [Deccan] Yes, it is entirely possible to generate a segment list only 
> including segments with local meaning, such as adjacency segment list, 
> service segment list, etc., without any node segment. So it is not 
> appropriate to do recursive operation for local meaning segments by default. 
> There maybe other cases that I don't know.
> 
> > If "default behavior" is not accepted, we can define a new RECURSIVE flag 
> > in Prefix-SID Sub-TLV. 
> 
> 
> if I understand your proposal, you could:
> . attach the SourceRouterID (RFC7794) to the prefix
> . attach a prefix-sid with:
>   . recursive flag set, which means the sid is to be 
>  taken from the sourceRouterID
>   . optionally set the V/L flag and also a local label
>   . if no V/L flag are set, the value of the sid/label 
>  field in the prefix-sid must be 0 on transmit and 
>  ignored on receive.
> 
> [Deccan] The above last point could be modified: 
> In despite V/L flag set or not, the value of the sid/label field in the 
> prefix-sid must always be a valid value. That is, for recursive use-case, it 
> is its own sid; for sharing use-case, it is the sharing sid. However, if the 
> received nodes don't know RECURSIVE flag, for sharing use-case, sid 
> conflicting will process; for recursive use-case, no recursion to be done. 


so, it’s broken.


> I see at least 2 problems with that:
> 1. the value of the prefix-sid you’re going to advertise 
>   will be misinterpreted by non-srri-capable nodes 
>   (i.e.: nodes know knowing the recursive flag). I.e: The 
>   value of the prefix sid would be either an explicit 
>   null label either a 0-value index.
> 2. RFC7794 states that: the Router ID advertised is 
>   always the Router ID of the IS-IS instance that 
>   originated the advertisement.
> 
>   This reduces the ability to use other addresses of the 
>   node for recursion.
> 
> Bottom line, having a separate repository for the recursing 
> information is the safest and cleanest option which allows 
> better flexibility (i.e.: allowing to recurse to a 
> non-router-ID address) and which ensure backward 
> compatibility (i.e.: non-srri-nodes will simply ignore the 
> whole srri info and consider the prefix as it had no sid at 
> all).
> 
> [Deccan] Yes, the alternate method only allows to recurse to a router-id 
> address. But, don't you think router-id address is enough for any segment 
> list?


absolutely not. Yu need to be able to recurse multiple prefixes to different 
addresses (all belonging to the same node).


> Especially for an SR-TE path dynamic computed by CSPF, I think a 
> non-router-id address will have no chance to represent a node-segment. 
> However, the alternate method seems to be not much clean than SRRI method, 
> for the possible sid conflicting introduced in sharing use-case, from this 
> point, the SRRI method is good. 


CSPF is not the main use case here.


> > BTW, all we discussed is SID recursive but not sharing,
> 
> 
> of course it is sharing. As defined in the draft, the 
> local label attached to the srri info it’s an optional 
> optimization. Without the local label, you will share the 
> same sid among multiple prefixes. 
> 
> 
> > even the first case in this draft is actually not SID sharing, otherwise it 
> > will be cared by draft-ietf-spring-conflict-resolution. 
> 
> 
> No, it is not a conflict. Having a dedicated srri

Re: [spring] WG adoption requested for draft-filsfils-spring-sr-recursing-info

[Stefano Previdi (sprevidi)]

Hi Deccan,


> On Aug 23, 2016, at 4:39 AM, peng.sha...@zte.com.cn wrote:
> 
> Hi Stefano 
> 
> Sure, SRRI provided in this document can explicitly indicate a recursive 
> operation (or relationship). 
> But it maybe a default behavior to do recursive operation when an SR-NODE 
> received remote prefix-sid with L/V flag set according to the documents 
> already existed. For example, 
> prefix reachability advertisement received: 
> prefix (1.0.0.99/32) 
> prefix-sid (30004), L/V flag set,  //ISIS-SR 
> "IPv4 Source Router ID" is 1.0.0.4 //rfc7794 
> Then, prefix 1.0.0.9/32 can do recursion to prefix 1.0.0.4/32 by default.


there are other cases where V/L are used so I wouldn’t 
bind these flags to the recursive behavior.


> If "default behavior" is not accepted, we can define a new RECURSIVE flag in 
> Prefix-SID Sub-TLV. 


if I understand your proposal, you could:
. attach the SourceRouterID (RFC7794) to the prefix
. attach a prefix-sid with:
   . recursive flag set, which means the sid is to be 
  taken from the sourceRouterID
   . optionally set the V/L flag and also a local label
   . if no V/L flag are set, the value of the sid/label 
  field in the prefix-sid must be 0 on transmit and 
  ignored on receive.

I see at least 2 problems with that:
1. the value of the prefix-sid you’re going to advertise 
   will be misinterpreted by non-srri-capable nodes 
   (i.e.: nodes know knowing the recursive flag). I.e: The 
   value of the prefix sid would be either an explicit 
   null label either a 0-value index.
2. RFC7794 states that: the Router ID advertised is 
   always the Router ID of the IS-IS instance that 
   originated the advertisement.
 
   This reduces the ability to use other addresses of the 
   node for recursion.

Bottom line, having a separate repository for the recursing 
information is the safest and cleanest option which allows 
better flexibility (i.e.: allowing to recurse to a 
non-router-ID address) and which ensure backward 
compatibility (i.e.: non-srri-nodes will simply ignore the 
whole srri info and consider the prefix as it had no sid at 
all).


> BTW, all we discussed is SID recursive but not sharing,


of course it is sharing. As defined in the draft, the 
local label attached to the srri info it’s an optional 
optimization. Without the local label, you will share the 
same sid among multiple prefixes. 


> even the first case in this draft is actually not SID sharing, otherwise it 
> will be cared by draft-ietf-spring-conflict-resolution. 


No, it is not a conflict. Having a dedicated srri 
repository makes it clear.

s.


> Thanks 
> Deccan 
> 
> 
> 
> 
> 
> "Stefano Previdi (sprevidi)" 
> 2016-08-22 21:38
> 
> 收件人
> "peng.sha...@zte.com.cn" ,
> 抄送
> SPRING WG 
> 主题
> Re: [spring] WG adoption requested for draft-filsfils-spring-sr-recursing-info
> 
> 
> 
> 
> 
> 
> > On Aug 9, 2016, at 5:55 AM, peng.sha...@zte.com.cn wrote:
> > 
> > Other documents have already addressed this issue,
> 
> 
> I don’t think so. Can you point to these documents ?
> 
> 
> > for example, set L-flag of Prefix-SID Sub-TLV in 
> > draft-ietf-isis-segment-routing-extensions-05 and contain IPv4 Source 
> > Router ID in rfc7794. 
> 
> 
> the L flag has the solely purpose of indicating the sid contains a local 
> value. Typically it goes with the V flag that indicates a value (i.e.: local 
> label).
> 
> Nothing is mentioned regarding sharing the same sid among different services.
> 
> s.
> 
> 
> 
> > 
> > 
> > Thanks, 
> > 
> > Deccan 
> > 
> > 
> > 
> > 
> > 
> > [spring] WG adoption requested for draft-filsfils-spring-sr-recursing-info 
> > "John G. Scudder"  Sun, 24 July 2016 12:54 UTCShow header
> > Dear WG,
> > 
> > As we discussed at our meeting, working group adoption has been requested 
> > for draft-filsfils-spring-sr-recursing-info. Please reply to the list with 
> > your comments, including although not limited to whether or not you support 
> > adoption. Non-authors are especially encouraged to comment.
> > 
> > We will end the call on August 31, 2015. 
> > 
> > Authors, please indicate whether you are aware of any relevant IPR and if 
> > so, whether it has been disclosed.
> > 
> > Thanks,
> > 
> > --Bruno and John
> > 
> > 
> > ___
> > 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] WG adoption requested for draft-filsfils-spring-sr-recursing-info

[Stefano Previdi (sprevidi)]

> On Aug 9, 2016, at 5:55 AM, peng.sha...@zte.com.cn wrote:
> 
> Other documents have already addressed this issue,


I don’t think so. Can you point to these documents ?


> for example, set L-flag of Prefix-SID Sub-TLV in 
> draft-ietf-isis-segment-routing-extensions-05 and contain IPv4 Source Router 
> ID in rfc7794. 


the L flag has the solely purpose of indicating the sid contains a local value. 
Typically it goes with the V flag that indicates a value (i.e.: local label).

Nothing is mentioned regarding sharing the same sid among different services.

s.



> 
> 
> Thanks, 
> 
> Deccan 
> 
> 
> 
> 
> 
> [spring] WG adoption requested for draft-filsfils-spring-sr-recursing-info 
> "John G. Scudder"  Sun, 24 July 2016 12:54 UTCShow header
> Dear WG,
> 
> As we discussed at our meeting, working group adoption has been requested for 
> draft-filsfils-spring-sr-recursing-info. Please reply to the list with your 
> comments, including although not limited to whether or not you support 
> adoption. Non-authors are especially encouraged to comment.
> 
> We will end the call on August 31, 2015. 
> 
> Authors, please indicate whether you are aware of any relevant IPR and if so, 
> whether it has been disclosed.
> 
> Thanks,
> 
> --Bruno and John
> 
> 
> ___
> 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] WG adoption requested for draft-filsfils-spring-sr-recursing-info

[Stefano Previdi (sprevidi)]

as co-author I support the adoption of this document as WG item.

I know about IPR related to this draft and it has been disclosed.

s.



> On Jul 24, 2016, at 2:54 PM, John G. Scudder  wrote:
> 
> Dear WG,
> 
> As we discussed at our meeting, working group adoption has been requested for 
> draft-filsfils-spring-sr-recursing-info. Please reply to the list with your 
> comments, including although not limited to whether or not you support 
> adoption. Non-authors are especially encouraged to comment.
> 
> We will end the call on August 31, 2015. 
> 
> Authors, please indicate whether you are aware of any relevant IPR and if so, 
> whether it has been disclosed.
> 
> Thanks,
> 
> --Bruno and John
> 
> ___
> 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] New spring WG Co-Chair

[Stefano Previdi (sprevidi)]

Many thanks to John for his excellent work on spring wg co-chair duty. 

Hi Martin and welcome to the party.

s.



> On Jul 26, 2016, at 5:57 PM, Alvaro Retana (aretana)  
> wrote:
> 
> Dear spring WG:
> 
> Due to the demands of his job John has decided to step down as spring 
> Co-Chair, a position he has held since the formation of the WG almost 3 years 
> ago.  John has been instrumental in driving the collaboration with other 
> groups working on spring-related extensions.  Thank you!!
> 
> In consultation with Bruno and the other RTG ADs, we have asked Martin 
> Vigoureux to take on the role of spring Co-Chair.  Martin is an experienced 
> Chair (he is also the Co-Chair of bess) and will work with Bruno on driving 
> the current work items to completion and publication.  We expect the 
> transition to be seamless as the WG moves through a period of adoption and 
> WGLCs.  Welcome Martin!
> 
> Martin can be reached at martin.vigour...@nokia.com.
> 
> Thanks!
> 
> Alvaro.
> ___
> 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] WG adoption requested for draft‐filsfils‐spring‐large-scale-interconnect

[Stefano Previdi (sprevidi)]

As co-author, I support the adoption of this document to WG item.

I’m not aware of any IPR that hasn’t been disclosed already.

s.


> On Jul 24, 2016, at 2:55 PM, John G. Scudder  wrote:
> 
> Dear WG,
> 
> As we discussed at our meeting, working group adoption has been requested for 
> draft‐filsfils‐spring‐large-scale-interconnect. Please reply to the list with 
> your comments, including although not limited to whether or not you support 
> adoption. Non-authors are especially encouraged to comment.
> 
> We will end the call on August 31, 2015. 
> 
> Authors, please indicate whether you are aware of any relevant IPR and if so, 
> whether it has been disclosed. Also, the length of the author list for this 
> document greatly exceeds the maximum recommended. Assuming the document is 
> adopted, the authors should be prepared to correct this when submitting as a 
> WG document, ideally by reducing the list to simply the active editor(s) and 
> making use of the "contributors" section for the full list.
> 
> Thanks,
> 
> --Bruno and John
> 
> ___
> 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] IPR for draft‐ietf-spring-segment‐routing-mpls prior to WGLC

[Stefano Previdi (sprevidi)]

I’m not aware of any IPR that hasn’t been disclosed already.

s.


> On Jul 24, 2016, at 2:52 PM, John G.Scudder  wrote:
> 
> Dear Authors:
> 
> As we discussed at the SPRING meeting, working group last call has been 
> requested for draft‐ietf-spring-segment‐routing-mpls. 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

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

[Stefano Previdi (sprevidi)]

I’m not aware of any IPR that hasn’t been disclosed already.

s.


> On Jul 24, 2016, at 2:50 PM, John G.Scudder  wrote:
> 
> 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