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 <r...@rob.sh> 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 <bruno.decra...@orange.com> 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-lit

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
>  > >
>  > >
>  > >
>  

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 
> <alexander.vainsht...@ecitele.com> 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 <stephane.litkow...@orange.com>
> Cc: Alexander Vainshtein <alexander.vainsht...@ecitele.com>; spring@ietf.org; 
> Shell Nakash <shell.nak...@ecitele.com>; Michael Gorokhovsky 
> <michael.gorokhov...@ecitele.com>; 
> draft-ietf-spring-resiliency-use-ca...@ietf.org; Sidd Aanand 
> <sidd.aan...@ecitele.com>; Ron Sdayoor <ron.sday...@ecitele.com>; Rotem Cohen 
> <rotem.co...@ecitele.com>
> 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: 'Stef

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 <lber...@labn.net> 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

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-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 

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 <sha...@ndzh.com> 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 <sha...@ndzh.com> 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, 

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 <an...@alumni.duke.edu> wrote:
> 
> On Wed, Mar 1, 2017 at 9:21 AM, Stefano Previdi (sprevidi) 
> <sprev...@cisco.com> wrote:
> 
> > On Mar 1, 2017, at 5:48 PM, Anoop Ghanwani <an...@alumni.duke.edu> wrote:
> >
> > Thanks for the responses.
> >
> > On Wed, Mar 1, 2017 at 7:44 AM, Stefano Previdi (sprevidi) 
> > <sprev...@cisco.com> wrote:
> >
> > > On Feb 28, 2017, at 8:29 PM, Anoop Ghanwani <an...@alumni.duke.edu> 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 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)]

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 
> <alexander.vainsht...@ecitele.com> 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 <alexander.vainsht...@ecitele.com>
> Cc: draft-ietf-spring-sr-y...@ietf.org; spring@ietf.org; Michael Gorokhovsky 
> <michael.gorokhov...@ecitele.com>
> Subject: Re: [spring] A question regarding mode of SR/LDP interop
> 
> 
>> On Feb 23, 2017, at 2:45 PM, Alexander Vainshtein 
>> <alexander.vainsht...@ecitele.com> 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] 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
>  
> [1] https://tools.ietf.org/html/draft-ietf-spring-segment-routing-msdc-02
> [2] 
> https://datatracker.ietf.org/ipr/search/?submit=draft=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
> [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=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 

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
> 
> ---
> [1] 
> https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-ldp-interop/
> [2] 
> https://datatracker.ietf.org/ipr/search/?submit=draft=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) <sprev...@cisco.com>; Martin Horneffer 
<m...@nic.dtag.de>
Cc: draft-ietf-spring-segment-routing-m...@ietf.org; spring@ietf.org; Martin 
Vigoureux <martin.vigour...@nokia.com>; Uma Chunduri <uma.chund...@huawei.com>; 
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 <m...@nic.dtag.de> 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.or

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
>> 
>> ---
>> [1] https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-mpls/
>> [2]
>> https://datatracker.ietf.org/ipr/search/?submit=draft=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
> 
> [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
>> 
>> [1] https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing/
>> [2]
>> https://datatracker.ietf.org/ipr/search/?submit=draft=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 <stewart.bry...@gmail.com> 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 <stewart.bry...@gmail.com> 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 <stewart.bry...@gmail.com> wrote:
> On 30/11/2016 10:38, Stefano Previdi (sprevidi) wrote:
>>> On Nov 29, 2016, at 8:21 PM, Stewart Bryant <stewart.bry...@gmail.com> 
>>> 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.
&

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 

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] 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 <alexander.vainsht...@ecitele.com>; DECRAENE Bruno 
> IMT/OLN <bruno.decra...@orange.com>; Stefano Previdi (sprevidi) 
> <sprev...@cisco.com>
> Cc: spring@ietf.org; Shell Nakash <shell.nak...@ecitele.com>; Michael 
> Gorokhovsky <michael.gorokhov...@ecitele.com>; 
> draft-ietf-spring-resiliency-use-ca...@ietf.org; Marina Fizgeer 
> <marina.fizg...@ecitele.com>; Rotem Cohen <rotem.co...@ecitele.com>
> 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) <sprev...@cisco.com>
> Cc: s

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] 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:
>> ftp://ftp.ietf.or

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 
> <alexander.vainsht...@ecitele.com> 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) <sprev...@cisco.com>
> Cc: Alexander Vainshtein <alexander.vainsht...@ecitele.com>; spring@ietf.org; 
> Chris Bowers <cbow...@juniper.net>
> 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) <sprev...@cisco.com> 
> 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 
> <alexander.vainsht...@ecitele.com> 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 <cbow...@juniper.net>
> 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 <cbow...@juniper.net> 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 
> <alexander.vainsht...@ecitele.com> 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 <cbow...@juniper.net>
> 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 <cbow...@juniper.net> 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 

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)" <sprev...@cisco.com>
> 2016-08-23 23:22
> 
> 收件人
> "peng.sha...@zte.com.cn" <peng.sha...@zte.com.cn>,
> 抄送
> SPRING WG <spring@ietf.org>
> 主题
> 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. 
>

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)" <sprev...@cisco.com>
> 2016-08-22 21:38
> 
> 收件人
> "peng.sha...@zte.com.cn" <peng.sha...@zte.com.cn>,
> 抄送
> SPRING WG <spring@ietf.org>
> 主题
> 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" <j...@juniper.net> 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‐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

Re: [spring] IPR for draft-ietf-spring-segment-routing prior to (additional) WGLC

[Stefano Previdi (sprevidi)]

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

s.


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

[Stefano Previdi (sprevidi)]

Hi,

integrated comments on SRMS and sRGB and added reference on Manageability and 
Security sections.

Thanks.
s.


 
> On Jul 6, 2016, at 5:31 PM, internet-dra...@ietf.org wrote:
> 
> 
> A new version of I-D, draft-ietf-spring-segment-routing-mpls-05.txt
> has been successfully submitted by Stefano Previdi and posted to the
> IETF repository.
> 
> Name: draft-ietf-spring-segment-routing-mpls
> Revision: 05
> Title:Segment Routing with MPLS data plane
> Document date:2016-07-06
> Group:spring
> Pages:15
> URL:
> https://www.ietf.org/internet-drafts/draft-ietf-spring-segment-routing-mpls-05.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-mpls/
> Htmlized:   
> https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-05
> Diff:   
> https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-segment-routing-mpls-05
> 
> 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.  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.
> 
>   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.
> 
> 
> 
> 
> 
> 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

Re: [spring] New Version Notification for draft-ietf-spring-segment-routing-09.txt

[Stefano Previdi (sprevidi)]

Hi,

Security and Manageability sections have been added. 


Thanks.
s.


> On Jul 4, 2016, at 2:30 PM, internet-dra...@ietf.org wrote:
> 
> 
> A new version of I-D, draft-ietf-spring-segment-routing-09.txt
> has been successfully submitted by Stefano Previdi and posted to the
> IETF repository.
> 
> Name: draft-ietf-spring-segment-routing
> Revision: 09
> Title:Segment Routing Architecture
> Document date:2016-07-04
> Group:spring
> Pages:29
> URL:
> https://www.ietf.org/internet-drafts/draft-ietf-spring-segment-routing-09.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing/
> Htmlized:   
> https://tools.ietf.org/html/draft-ietf-spring-segment-routing-09
> Diff:   
> https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-segment-routing-09
> 
> 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.
> 
>   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.
> 
> 
> 
> 
> 
> 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

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

[Stefano Previdi (sprevidi)]

Added text on LDP when used in “independent vs. ordered” distribution mode.

thanks.
s.


> On Jul 4, 2016, at 9:51 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-04.txt
>   Pages   : 20
>   Date: 2016-07-04
> 
> 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-04
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-segment-routing-ldp-interop-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/
> 
> ___
> 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] [nvo3] L4 Checksum and draft-ietf-6man-segment-routing-header

[Stefano Previdi (sprevidi)]

> On May 31, 2016, at 5:54 PM, Tal Mizrahi <ta...@marvell.com> wrote:
> 
> Hi Stefano,
> 
> Going back to our original discussion, I believe we can conclude that the L4 
> Checksum may be interesting in two possible scenarios:
> 
> 
> 1.   The SRH is generated by the host. In this case the L4 Checksum is 
> computed by the host based on the IP address of the last hop.
> 
> 2.   The SRH is generated by the ingress node of the SR domain using an 
> IP tunnel. Specifically, if the tunnel encapsulation includes an L4 header 
> (e.g., VXLAN, VXLAN-GPE, Geneve, GUE), then (again) the ingress node computes 
> the L4 Checksum based on the IP address of the last hop.
> 
> In both cases intermediate routers in the SR domain do not need to update the 
> Checksum, even though they update the destination IP address.


it can be simplified by stating that any SRH that is inserted in transit MUST 
be removed prior to deliver the packet to the final destination.

All other cases implies that the source is inserting the SRH, in which case the 
checksum is consistent.


s.



> 
> It would be great if some text would be added to the draft to clarify these 
> observations.
> 
> Cheers,
> Tal.
> 
> 
> 
> From: Larry Kreeger (kreeger) [mailto:kree...@cisco.com]
> Sent: Monday, May 23, 2016 11:55 PM
> To: Tal Mizrahi
> Cc: draft-ietf-nvo3-gen...@tools.ietf.org; 
> draft-ietf-nvo3-vxlan-...@tools.ietf.org; spring@ietf.org; 6man WG; 
> n...@ietf.org; draft-ietf-6man-segment-routing-hea...@tools.ietf.org; Stefano 
> Previdi (sprevidi)
> Subject: Re: [nvo3] [spring] L4 Checksum and 
> draft-ietf-6man-segment-routing-header
> 
> I agree with Robert and Jesse. - Larry
> 
> From: Jesse Gross <jgr...@vmware.com<mailto:jgr...@vmware.com>>
> Date: Monday, May 23, 2016 at 1:19 PM
> To: Robert Raszuk <rob...@raszuk.net<mailto:rob...@raszuk.net>>, Tal Mizrahi 
> <ta...@marvell.com<mailto:ta...@marvell.com>>
> Cc: 
> "draft-ietf-nvo3-gen...@tools.ietf.org<mailto:draft-ietf-nvo3-gen...@tools.ietf.org>"
>  
> <draft-ietf-nvo3-gen...@tools.ietf.org<mailto:draft-ietf-nvo3-gen...@tools.ietf.org>>,
>  
> "draft-ietf-nvo3-vxlan-...@tools.ietf.org<mailto:draft-ietf-nvo3-vxlan-...@tools.ietf.org>"
>  
> <draft-ietf-nvo3-vxlan-...@tools.ietf.org<mailto:draft-ietf-nvo3-vxlan-...@tools.ietf.org>>,
>  "spring@ietf.org<mailto:spring@ietf.org>" 
> <spring@ietf.org<mailto:spring@ietf.org>>, 6man WG 
> <i...@ietf.org<mailto:i...@ietf.org>>, "n...@ietf.org<mailto:n...@ietf.org>" 
> <n...@ietf.org<mailto:n...@ietf.org>>, 
> "draft-ietf-6man-segment-routing-hea...@tools.ietf.org<mailto:draft-ietf-6man-segment-routing-hea...@tools.ietf.org>"
>  
> <draft-ietf-6man-segment-routing-hea...@tools.ietf.org<mailto:draft-ietf-6man-segment-routing-hea...@tools.ietf.org>>,
>  "Stefano Previdi (sprevidi)" <sprev...@cisco.com<mailto:sprev...@cisco.com>>
> Subject: Re: [nvo3] [spring] L4 Checksum and 
> draft-ietf-6man-segment-routing-header
> Resent-From: <alias-boun...@ietf.org<mailto:alias-boun...@ietf.org>>, 
> <jgr...@vmware.com<mailto:jgr...@vmware.com>>
> Resent-To: Larry Kreeger <kree...@cisco.com<mailto:kree...@cisco.com>>, 
> <uri.el...@intel.com<mailto:uri.el...@intel.com>>, 
> <draft-ietf-6man-segment-routing-hea...@ietf.org<mailto:draft-ietf-6man-segment-routing-hea...@ietf.org>>
> Resent-Date: Monday, May 23, 2016 at 1:20 PM
> 
> I agree that I don't believe that there is anything in these drafts that 
> precludes the use of extension headers or segment routing - IP is simply the 
> layer underneath that these protocols are building on. The figures are 
> definitely just examples - they also show outer Ethernet headers, which is 
> not a requirement.
> 
> I wouldn't want to add text specifically stating that extension headers are 
> permissible. It seems like that could lead to similar questions in the future 
> where one might wonder if other features of IP are allowed because one is 
> explicitly listed and others are not, etc. In my opinion, the drafts are 
> about as clear as they can be on this point.
> 
> Jesse
> 
> On 5/23/16, 1:09 AM, "rras...@gmail.com<mailto:rras...@gmail.com> on behalf 
> of Robert Raszuk" <rras...@gmail.com<mailto:rras...@gmail.com> on behalf of 
> rob...@raszuk.net<mailto:rob...@raszuk.net>> wrote:
> 
> Hi Tal,
> 
>> In order to avoid ambiguity, it would be great if the
>> authors could explicitly mention that IPv6 extension
>> headers a

Re: [spring] RFC 7855 on Source Packet Routing in Networking (SPRING) Problem Statement and Requirements

[Stefano Previdi (sprevidi)]

SPRING’ers,

This is our first rfc. 

Now that we have a problem statement and requirements documents, we know what 
we have to do ;-)

Thanks to everyone for the support.


Thanks.
s.


> On May 26, 2016, at 1:48 AM, rfc-edi...@rfc-editor.org wrote:
> 
> A new Request for Comments is now available in online RFC libraries.
> 
> 
>RFC 7855
> 
>Title:  Source Packet Routing in Networking 
>(SPRING) Problem Statement and Requirements 
>Author: S. Previdi, Ed.,
>C. Filsfils, Ed.,
>B. Decraene, S. Litkowski,
>M. Horneffer, R. Shakir
>Status: Informational
>Stream: IETF
>Date:   May 2016
>Mailbox:sprev...@cisco.com, 
>cfils...@cisco.com, 
>bruno.decra...@orange.com, 
>stephane.litkow...@orange.com, 
>martin.hornef...@telekom.de,
>r...@rob.sh
>Pages:  19
>Characters: 38006
>Updates/Obsoletes/SeeAlso:   None
> 
>I-D Tag:draft-ietf-spring-problem-statement-08.txt
> 
>URL:https://www.rfc-editor.org/info/rfc7855
> 
>DOI:http://dx.doi.org/10.17487/RFC7855
> 
> The ability for a node to specify a forwarding path, other than the
> normal shortest path, that a particular packet will traverse,
> benefits a number of network functions.  Source-based routing
> mechanisms have previously been specified for network protocols but
> have not seen widespread adoption.  In this context, the term
> "source" means "the point at which the explicit route is imposed";
> therefore, it is not limited to the originator of the packet (i.e.,
> the node imposing the explicit route may be the ingress node of an
> operator's network).
> 
> This document outlines various use cases, with their requirements,
> that need to be taken into account by the Source Packet Routing in
> Networking (SPRING) architecture for unicast traffic.  Multicast use
> cases and requirements are out of scope for this document.
> 
> This document is a product of the Source Packet Routing in Networking Working 
> Group of the IETF.
> 
> 
> INFORMATIONAL: This memo provides information for the Internet community.
> It does not specify an Internet standard of any kind. Distribution of
> this memo is unlimited.
> 
> This announcement is sent to the IETF-Announce and rfc-dist lists.
> To subscribe or unsubscribe, see
>  https://www.ietf.org/mailman/listinfo/ietf-announce
>  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist
> 
> For searching the RFC series, see https://www.rfc-editor.org/search
> For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk
> 
> Requests for special distribution should be addressed to either the
> author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
> specifically noted otherwise on the RFC itself, all RFCs are for
> unlimited distribution.
> 
> 
> The RFC Editor Team
> Association Management Solutions, LLC
> 
> 
> ___
> 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] L4 Checksum and draft-ietf-6man-segment-routing-header

[Stefano Previdi (sprevidi)]

> On May 16, 2016, at 7:10 PM, Tom Herbert <t...@herbertland.com> wrote:
> 
> On Mon, May 16, 2016 at 4:32 AM, Tal Mizrahi <ta...@marvell.com> wrote:
>>> it’s all about IP, not layer-2.
>>> 
>>> s.
>> 
>> Right. However, it appears that at least in some cases a VXLAN VTEP will use 
>> SR. It certainly may be the case in SFC use cases (see Section 2.3 in 
>> draft-ietf-spring-ipv6-use-cases).
>> 
> 
> draft-ietf-6man-segment-routing-header mentions that the packet is
> encapsulated


into an outer ipv6 header which makes it a layer-3 encap.


> , but I don't think it is explicit as to exact
> encapsulation format (I suppose simple ip6ip6 is implied).


see section 2.2


> But, it
> seems like any of several encapsulation techniques could work (VXLAN,


I have some problems to understand where to fit an extension header into a 
vxlan encap…


> GRE/IP, ESP/IP, GUE, foo over UDP, etc.) and if a device that wants to
> do SR is already doing tunneling it seems reasonable to me to only
> have one layer of encapsulation. Maybe this should be clarified in the
> draft?


the draft is about IPv6 extension header and more precisely a new type of the 
routing extension header defined in rfc2460. That’s the context.


s.




> 
> Tom
> 
>> 
>> 
>>> -Original Message-
>>> From: Stefano Previdi (sprevidi) [mailto:sprev...@cisco.com]
>>> Sent: Monday, May 16, 2016 2:24 PM
>>> To: Tal Mizrahi
>>> Cc: Ole Trøan; draft-ietf-6man-segment-routing-hea...@tools.ietf.org;
>>> spring@ietf.org; 6man WG
>>> Subject: Re: [spring] L4 Checksum and draft-ietf-6man-segment-routing-
>>> header
>>> 
>>> 
>>>> On May 16, 2016, at 1:19 PM, Tal Mizrahi <ta...@marvell.com> wrote:
>>>> 
>>>> Hi Stefano,
>>>> 
>>>> Thanks again for the prompt response.
>>>> 
>>>>> 2. the SRH is originated by the ingress node of the SR domain.
>>>>> This is done by encapsulating the packet into a outer
>>>>> (additional) ipv6 header followed by an SRH. This is L3
>>>>> encapsulation and no L4 checksum is involved. When the  packet leaves
>>>>> the SR tunnel the outer encapsulation  (including the SRH) is removed
>>>>> and the packet continues  its journey like nothing happened.
>>>> 
>>>> So VXLAN is off the table?
>>> 
>>> 
>>> it’s all about IP, not layer-2.
>>> 
>>> s.
>>> 
>>> 
>>>> It would be worthwhile to clarify this in the draft. If you have a specific
>>> encapsulation in mind, it would be great if the draft would specify it.
>>>> 
>>>> Thanks,
>>>> Tal.
>>>> 
>>>> 
>>>>> -Original Message-
>>>>> From: Stefano Previdi (sprevidi) [mailto:sprev...@cisco.com]
>>>>> Sent: Monday, May 16, 2016 2:13 PM
>>>>> To: Tal Mizrahi
>>>>> Cc: Ole Trøan; draft-ietf-6man-segment-routing-hea...@tools.ietf.org;
>>>>> spring@ietf.org; 6man WG
>>>>> Subject: Re: [spring] L4 Checksum and
>>>>> draft-ietf-6man-segment-routing- header
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> On May 16, 2016, at 11:04 AM, Tal Mizrahi <ta...@marvell.com> wrote:
>>>>>> 
>>>>>> Hi Stefano,
>>>>>> 
>>>>>> Thanks for the responses.
>>>>>> 
>>>>>>> exactly.
>>>>>>> 
>>>>>>> Moreover, draft-ietf-6man-segment-routing-header assumes
>>>>>>> encapsulation so clearly there’s no L4 involved here.
>>>>>>> 
>>>>>>> s.
>>>>>> 
>>>>>> Two questions:
>>>>>> 1. What if the encapsulation is VXLAN? L4 would still be involved, right?
>>>>> 
>>>>> 
>>>>> See below.
>>>>> 
>>>>> 
>>>>>> 2. When you say 'assumes encapsulation', does it mean that a host
>>>>>> cannot
>>>>> send an IPv6 packet with an SRH? The current draft says:
>>>>>> 
>>>>>> A Source SR Node can be any node originating an IPv6 packet with
>>>>>> its
>>>>>> IPv6 and Segment Routing Headers.  This include either:
>>>>>> 
>>>>>>A host originating an IPv6 packet.
>>>>>> 
>>>>>>An 

Re: [spring] L4 Checksum and draft-ietf-6man-segment-routing-header

[Stefano Previdi (sprevidi)]

> On May 16, 2016, at 1:19 PM, Tal Mizrahi <ta...@marvell.com> wrote:
> 
> Hi Stefano,
> 
> Thanks again for the prompt response.
> 
>> 2. the SRH is originated by the ingress node of the SR domain.
>>  This is done by encapsulating the packet into a outer
>>  (additional) ipv6 header followed by an SRH. This is L3
>>  encapsulation and no L4 checksum is involved. When the
>>  packet leaves the SR tunnel the outer encapsulation
>>  (including the SRH) is removed and the packet continues
>>  its journey like nothing happened.
> 
> So VXLAN is off the table?


it’s all about IP, not layer-2.

s.


> It would be worthwhile to clarify this in the draft. If you have a specific 
> encapsulation in mind, it would be great if the draft would specify it.
> 
> Thanks,
> Tal.
> 
> 
>> -Original Message-
>> From: Stefano Previdi (sprevidi) [mailto:sprev...@cisco.com]
>> Sent: Monday, May 16, 2016 2:13 PM
>> To: Tal Mizrahi
>> Cc: Ole Trøan; draft-ietf-6man-segment-routing-hea...@tools.ietf.org;
>> spring@ietf.org; 6man WG
>> Subject: Re: [spring] L4 Checksum and draft-ietf-6man-segment-routing-
>> header
>> 
>> Hi,
>> 
>> On May 16, 2016, at 11:04 AM, Tal Mizrahi <ta...@marvell.com> wrote:
>>> 
>>> Hi Stefano,
>>> 
>>> Thanks for the responses.
>>> 
>>>> exactly.
>>>> 
>>>> Moreover, draft-ietf-6man-segment-routing-header assumes
>>>> encapsulation so clearly there’s no L4 involved here.
>>>> 
>>>> s.
>>> 
>>> Two questions:
>>> 1. What if the encapsulation is VXLAN? L4 would still be involved, right?
>> 
>> 
>> See below.
>> 
>> 
>>> 2. When you say 'assumes encapsulation', does it mean that a host cannot
>> send an IPv6 packet with an SRH? The current draft says:
>>> 
>>>  A Source SR Node can be any node originating an IPv6 packet with its
>>>  IPv6 and Segment Routing Headers.  This include either:
>>> 
>>> A host originating an IPv6 packet.
>>> 
>>> An SR domain ingress router encapsulating a received IPv6 packet
>>> into an outer IPv6 header followed by an SRH.
>>> 
>>> 
>>> 
>>> Will appreciate if you can clarify that.
>> 
>> 
>> ok, two cases:
>> 
>> 1. the SRH is inserted at the source.
>>  the source originates the packet, the ipv6 header and
>>  the SRH. The source computes L4 checksum taking into
>>  account the whole IPv6+SRH. Here, theres’ nothing new
>>  compared to rfc2460.
>> 
>> 2. the SRH is originated by the ingress node of the SR domain.
>>  This is done by encapsulating the packet into a outer
>>  (additional) ipv6 header followed by an SRH. This is L3
>>  encapsulation and no L4 checksum is involved. When the
>>  packet leaves the SR tunnel the outer encapsulation
>>  (including the SRH) is removed and the packet continues
>>  its journey like nothing happened.
>> 
>> s.
>> 
>> 
>>> 
>>> Thanks,
>>> Tal.
>>> 
>>>> -Original Message-
>>>> From: Stefano Previdi (sprevidi) [mailto:sprev...@cisco.com]
>>>> Sent: Monday, May 16, 2016 11:59 AM
>>>> To: Ole Trøan; Tal Mizrahi
>>>> Cc: draft-ietf-6man-segment-routing-hea...@tools.ietf.org;
>>>> spring@ietf.org; 6man WG
>>>> Subject: Re: [spring] L4 Checksum and
>>>> draft-ietf-6man-segment-routing- header
>>>> 
>>>> 
>>>>> On May 15, 2016, at 8:06 PM, otr...@employees.org wrote:
>>>>> 
>>>>> Tal,
>>>>> 
>>>>>> [Apologies if this issue has been discussed before.]
>>>>>> 
>>>>>> According to draft-ietf-6man-segment-routing-header, an ‘SR Segment
>>>> Endpoint Node’ updates the Destination IP address.
>>>>>> Therefore, it must also update the Layer 4 Checksum, right?
>>>>>> 
>>>>>> I wonder if there is an upper bound on the size of the SRH.
>>>>>> Otherwise, the
>>>> L4 Checksum may be located in a pretty deep location.
>>>>>> Speaking from a chip vendor’s perspective this may be a problem.
>>>>> 
>>>>> From RFC2460, RH0:
>>>>> 
>>>>> 
>>>>>o  If the IPv6 packet contains a Routing header, the Destination
>>>>>   Address used in the pseudo-header is that of the final
>>>>>   destination.  At the originating node, that address will be in
>>>>>   the last element of the Routing header; at the recipient(s),
>>>>>   that address will be in the Destination Address field of the
>>>>>   IPv6 header.
>>>>> 
>>>>> I would expect SR would work the same.
>>>> 
>>>> 
>>>> exactly.
>>>> 
>>>> Moreover, draft-ietf-6man-segment-routing-header assumes
>>>> encapsulation so clearly there’s no L4 involved here.
>>>> 
>>>> s.
>>>> 
>>>> 
>>>>> 
>>>>> Cheers,
>>>>> Ole
>>>>> 
>>> 
> 

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

Re: [spring] L4 Checksum and draft-ietf-6man-segment-routing-header

[Stefano Previdi (sprevidi)]

Hi,

On May 16, 2016, at 11:04 AM, Tal Mizrahi <ta...@marvell.com> wrote:
> 
> Hi Stefano,
> 
> Thanks for the responses.
> 
>> exactly.
>> 
>> Moreover, draft-ietf-6man-segment-routing-header assumes encapsulation
>> so clearly there’s no L4 involved here.
>> 
>> s.
> 
> Two questions:
> 1. What if the encapsulation is VXLAN? L4 would still be involved, right?


See below.


> 2. When you say 'assumes encapsulation', does it mean that a host cannot send 
> an IPv6 packet with an SRH? The current draft says:
> 
>   A Source SR Node can be any node originating an IPv6 packet with its
>   IPv6 and Segment Routing Headers.  This include either:
> 
>  A host originating an IPv6 packet.
> 
>  An SR domain ingress router encapsulating a received IPv6 packet
>  into an outer IPv6 header followed by an SRH.
> 
> 
> 
> Will appreciate if you can clarify that.


ok, two cases:

1. the SRH is inserted at the source. 
   the source originates the packet, the ipv6 header and 
   the SRH. The source computes L4 checksum taking into 
   account the whole IPv6+SRH. Here, theres’ nothing new 
   compared to rfc2460.

2. the SRH is originated by the ingress node of the SR domain.
   This is done by encapsulating the packet into a outer 
   (additional) ipv6 header followed by an SRH. This is L3 
   encapsulation and no L4 checksum is involved. When the 
   packet leaves the SR tunnel the outer encapsulation 
   (including the SRH) is removed and the packet continues 
   its journey like nothing happened.

s.


> 
> Thanks,
> Tal.
> 
>> -Original Message-
>> From: Stefano Previdi (sprevidi) [mailto:sprev...@cisco.com]
>> Sent: Monday, May 16, 2016 11:59 AM
>> To: Ole Trøan; Tal Mizrahi
>> Cc: draft-ietf-6man-segment-routing-hea...@tools.ietf.org; spring@ietf.org;
>> 6man WG
>> Subject: Re: [spring] L4 Checksum and draft-ietf-6man-segment-routing-
>> header
>> 
>> 
>>> On May 15, 2016, at 8:06 PM, otr...@employees.org wrote:
>>> 
>>> Tal,
>>> 
>>>> [Apologies if this issue has been discussed before.]
>>>> 
>>>> According to draft-ietf-6man-segment-routing-header, an ‘SR Segment
>> Endpoint Node’ updates the Destination IP address.
>>>> Therefore, it must also update the Layer 4 Checksum, right?
>>>> 
>>>> I wonder if there is an upper bound on the size of the SRH. Otherwise, the
>> L4 Checksum may be located in a pretty deep location.
>>>> Speaking from a chip vendor’s perspective this may be a problem.
>>> 
>>> From RFC2460, RH0:
>>> 
>>> 
>>> o  If the IPv6 packet contains a Routing header, the Destination
>>>Address used in the pseudo-header is that of the final
>>>destination.  At the originating node, that address will be in
>>>the last element of the Routing header; at the recipient(s),
>>>that address will be in the Destination Address field of the
>>>IPv6 header.
>>> 
>>> I would expect SR would work the same.
>> 
>> 
>> exactly.
>> 
>> Moreover, draft-ietf-6man-segment-routing-header assumes encapsulation
>> so clearly there’s no L4 involved here.
>> 
>> s.
>> 
>> 
>>> 
>>> Cheers,
>>> Ole
>>> 
> 

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

Re: [spring] L4 Checksum and draft-ietf-6man-segment-routing-header

[Stefano Previdi (sprevidi)]

> On May 16, 2016, at 8:21 AM, Tal Mizrahi  wrote:
> 
> Hi Ole,
> 
> Thanks for the prompt response. 
> 
> It would be helpful if the authors added a comment about the L4 Checksum to 
> the current draft, even though this functionality was defined in RFC 2460.


please read carefully draft-ietf-6man-segment-routing-header.

The model described assumes encapsulation of the original packet into an outer 
ipv6 header followed by a SRH. When the packet leaves the SR tunnel there are 
no traces of segment routing whatsoever. L4 clearly does not apply here, it’s 
basic tunneling.

s.


> 
> Best regards,
> Tal.
> 
>> -Original Message-
>> From: otr...@employees.org [mailto:otr...@employees.org]
>> Sent: Sunday, May 15, 2016 9:07 PM
>> To: Tal Mizrahi
>> Cc: draft-ietf-6man-segment-routing-hea...@tools.ietf.org; spring@ietf.org;
>> 6man WG
>> Subject: Re: [spring] L4 Checksum and draft-ietf-6man-segment-routing-
>> header
>> 
>> Tal,
>> 
>>> [Apologies if this issue has been discussed before.]
>>> 
>>> According to draft-ietf-6man-segment-routing-header, an ‘SR Segment
>> Endpoint Node’ updates the Destination IP address.
>>> Therefore, it must also update the Layer 4 Checksum, right?
>>> 
>>> I wonder if there is an upper bound on the size of the SRH. Otherwise, the 
>>> L4
>> Checksum may be located in a pretty deep location.
>>> Speaking from a chip vendor’s perspective this may be a problem.
>> 
>> From RFC2460, RH0:
>> 
>> 
>> o  If the IPv6 packet contains a Routing header, the Destination
>>Address used in the pseudo-header is that of the final
>>destination.  At the originating node, that address will be in
>>the last element of the Routing header; at the recipient(s),
>>that address will be in the Destination Address field of the
>>IPv6 header.
>> 
>> I would expect SR would work the same.
>> 
>> Cheers,
>> Ole
> 

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

Re: [spring] L4 Checksum and draft-ietf-6man-segment-routing-header

[Stefano Previdi (sprevidi)]

> On May 15, 2016, at 8:06 PM, otr...@employees.org wrote:
> 
> Tal,
> 
>> [Apologies if this issue has been discussed before.]
>> 
>> According to draft-ietf-6man-segment-routing-header, an ‘SR Segment Endpoint 
>> Node’ updates the Destination IP address.
>> Therefore, it must also update the Layer 4 Checksum, right?
>> 
>> I wonder if there is an upper bound on the size of the SRH. Otherwise, the 
>> L4 Checksum may be located in a pretty deep location.
>> Speaking from a chip vendor’s perspective this may be a problem.
> 
> From RFC2460, RH0:
> 
> 
>  o  If the IPv6 packet contains a Routing header, the Destination
> Address used in the pseudo-header is that of the final
> destination.  At the originating node, that address will be in
> the last element of the Routing header; at the recipient(s),
> that address will be in the Destination Address field of the
> IPv6 header.
> 
> I would expect SR would work the same.


exactly.

Moreover, draft-ietf-6man-segment-routing-header assumes encapsulation so 
clearly there’s no L4 involved here.

s.


> 
> Cheers,
> Ole
> 

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

[spring] updated drafts

[Stefano Previdi (sprevidi)]

I just submitted:

draft-ietf-spring-segment-routing-ldp-interop-02 and
draft-ietf-spring-segment-routing-08

hopefully integrating the remaining comments from Sasha and Eric.

Thanks.
s.



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

Re: [spring] draft-ginsberg-spring-conflict-resolution - WG adoption call

[Stefano Previdi (sprevidi)]

> On May 6, 2016, at 10:16 PM, Uma Chunduri  wrote:
> 
> Les,
>  
> 2 quick things.
>  
> 1.
> >[Les:] There are two legitimate use cases for SRMS:
>>1)To advertise SIDs for non-SR 
> capable nodes
>>2)As a global provisioning tool
>  I am hearing #2 for the first time. I don’t see this 
> either  discussed earlier in the WG list  or captured in architecture 
> document 
>  
> https://tools.ietf.org/html/draft-ietf-spring-segment-routing-07. Even in the 
> protocol extensions document for example 
>  
> https://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions-06#section-2.4
>  we always discussed this from non-SR 
>  capable nodes PoV. So I request to add this in 
> architecture document before factoring this for solution in conflict 
> resolution. 


using a SRMS for advertising SID on behalf of SR capable nodes does not 
introduce any change in the SR architecture so not sure what we need to 
document here.


   
> 
> 2.   Also this is the first time ever we have a requirement for cross 
> protocols verification we ought to discuss the implications of this  
> and protocols involved (with in AS or otherwise) in the architecture document 
> (at least briefly).


the architecture draft is data-pane agnostic so I presume you refer to 
draft-ietf-spring-segment-routing-mpls.

with the ipv6 data-plane SR conflicts are in fact solved by ipv6 addressing 
techniques ;-)

s.


>  
> --
> Uma C.
>  
> From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Les Ginsberg 
> (ginsberg)
> Sent: Wednesday, May 04, 2016 9:38 AM
> To: Uma Chunduri; bruno.decra...@orange.com; spring@ietf.org
> Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution - WG adoption 
> call
>  
> Uma –
>  
> To restate, the problem being addressed here is to guarantee consistent use 
> of SIDs in the forwarding plane network-wide in the presence of conflicting 
> advertisements. The set of advertisements includes both SIDs advertised in 
> protocol prefix reachability advertisements and SRMS advertisements because 
> problems occur based upon inconsistencies in what is installed in the 
> forwarding plane of different routers. It matters not whether Router A used a 
> SID advertised by a protocol prefix reachability advertisement or by an SRMS 
> advertisement – what matter is whether the SID used is consistent with what 
> the neighbors of Router A use. So simply ensuring that OSPF (for example) 
> resolves SIDs in a consistent way does not fully address the problem space.
>  
> More inline.
>  
> From: Uma Chunduri [mailto:uma.chund...@ericsson.com] 
> Sent: Tuesday, May 03, 2016 3:59 PM
> To: Les Ginsberg (ginsberg); bruno.decra...@orange.com; spring@ietf.org
> Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution - WG adoption 
> call
>  
> Les,
>  
> With all due respects, cross protocol verification  of prefix and SID 
> conflicts as an “architectural change”  and it can severely impact the 
> existing implementations (at least the one I work on). 
>  
> [Les:] It is quite correct – and I can confirm based on personal experience – 
> that support for conflict resolution is a significant effort.
>  
> Also I have couple of cases where current version of the draft is not clear 
> about resolution.
>  
> IMO, first we need clarity with in a protocol instance resolution rules 
> before going to resolve the same across protocols (I mentioned few cases 
> below) .
> Separation of reachability advertisements and SRMS would help “cross 
> protocol” verification of the ranges and SRMS is not applicable to all 
> protocols.
>  
>  
> In-line [Uma]:
>  
> --
> Uma C.
>  
> From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] 
> Sent: Saturday, April 30, 2016 10:11 PM
> To: Uma Chunduri; bruno.decra...@orange.com; spring@ietf.org
> Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution - WG adoption 
> call
>  
> Uma –
>  
> We are indeed defining conflict resolution across all the SID advertisements 
> regardless of source (protocol or SRMS) –
>  
> [Uma]: While you can theoretically do anything for current implementation 
> this kind of cross protocol verification is a new architectural requirement.  
>Because it seems “a central entity” need to gather all 
> different protocol instances SRMS advertisements and should settle with 
> resolution. 
>  
> -  Also note SRMS is not applicable for BGP but it seems all prefix 
> SIDs need to be verified  with IGP instances SRMS advertisements. Is this 
> true? While the document mostly talks about these and compares with prefix 
> advertisement.
> [Les:] The issue is protocol agnostic.
>  
> -  Algorithm proposed needs more clarity: Take Section 3.2.4
>  
> o
> 

Re: [spring] Issue re PHP specification in SPRING drafts

[Stefano Previdi (sprevidi)]

Eric,


> On Feb 26, 2016, at 2:44 PM, Eric C Rosen  wrote:
> 
> There seems to be some inconsistency in the various documents about the way 
> that penultimate hop popping is handled.
> 
> When advertising a prefix-SID via OSPF, the OSPF Segment Routing extensions 
> associate an NP-Flag with the prefix-SID.  From section 5 of 
> draft-ietf-ospf-segment-routing-extensions:
> 
>  If the NP-Flag is not set then any upstream neighbor of the
>  Prefix-SID originator MUST pop the Prefix-SID.  This is equivalent
>  to the penultimate hop popping mechanism used in the MPLS
>  dataplane.
> 
> When advertising a prefix-SID via ISIS, the ISIS Segment Routing extensions 
> associate a P-flag with the prefix-SID.  From section 2.1.1.2 of 
> draft-ietf-isis-segment-routing-extensions:
> 
>  If the P-flag is not set then any upstream neighbor of the
>  Prefix-SID originator MUST pop the Prefix-SID.  This is
>  equivalent to the penultimate hop popping mechanism used in
>  the MPLS dataplane which improves performance of the
>  ultimate hop.
> 
> These specs allow a node to REQUIRE its "upstream neighbors" on a given 
> prefix segment to perform penultimate hop popping on any packet whose top 
> label corresponds to a prefix-SID that has been advertised via ISIS or OSPF.
> 
> The architecture document has a weaker requirement.  From section 3.2.2 of 
> draft-ietf-spring-segment-routing:
> 
>  The IGP signaling extension for IGP-Prefix segment includes
>  the P-Flag.  A Node N advertising a Prefix-SID SID-R for
>  its attached prefix R resets the P-Flag to allow its
>  connected neighbors to perform the NEXT operation while
>  processing SID-R.  This behavior is equivalent to
>  Penultimate Hop Popping in MPLS.  When set, the neighbors
>  of N must perform the CONTINUE operation while processing
>  SID-R.
> 
> This could be interpreted as allowing the upstream neighbor to perform the 
> CONTINUE operation even if the P-Flag is clear,


well, that’s not the intention. I’ll fix the text to make this clear.


> which would mean that the choice of whether to do PHP is left to the 
> neighbor.  This seems to contradict the statements quoted above from the IGP 
> documents.
> 
> Shouldn't the architecture document be modified so that it says the same 
> thing as the IGP documents?


Yes.


> A related issue in the architecture document stems from the following passage 
> from section 3.2.2 of the architecture document:
> 
>   o A node N attaching a Prefix-SID SID-R to its attached prefix
> R MUST maintain the following FIB entry:
> 
> Incoming Active Segment: SID-R
> Ingress Operation: NEXT
> Egress interface: NULL
> 
> If SID-R has been advertised in OSPF with the NP-flag clear, or if it has 
> been advertised in ISIS with the P-flag set, there is no need for this FIB 
> entry to be maintained.  Perhaps the passage should actually read:
> 
>   o If a node N advertises Prefix-SID SID-R for a prefix R that
> is attached to N, N MUST either clear the P-Flag in the
> advertisement of SID-R, or else maintain the following
> FIB entry:
> 
> Incoming Active Segment: SID-R
> Ingress Operation: NEXT
> Egress interface: NULL


ok. 

I will update the doc.

Thanks.
s.


> 
> 
> 
> 
> 
> 
> 
> 
> 
> ___
> 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 re PHP specification in SPRING drafts

[Stefano Previdi (sprevidi)]

Hi Eric,

sorry, I missed that one and will look into this asap.
s.


> On May 9, 2016, at 4:36 PM, Eric C Rosen  wrote:
> 
> A few months back I pointed out a couple of small issues that I think need to 
> be addressed in draft-ietf-spring-segment-routing. I still think they need to 
> be addressed.
> 
> 
> On 2/26/2016 8:44 AM, Eric C Rosen wrote:
>> There seems to be some inconsistency in the various documents about the way 
>> that penultimate hop popping is handled.
>> 
>> When advertising a prefix-SID via OSPF, the OSPF Segment Routing extensions 
>> associate an NP-Flag with the prefix-SID.  From section 5 of 
>> draft-ietf-ospf-segment-routing-extensions:
>> 
>>  If the NP-Flag is not set then any upstream neighbor of the
>>  Prefix-SID originator MUST pop the Prefix-SID.  This is equivalent
>>  to the penultimate hop popping mechanism used in the MPLS
>>  dataplane.
>> 
>> When advertising a prefix-SID via ISIS, the ISIS Segment Routing extensions 
>> associate a P-flag with the prefix-SID.  From section 2.1.1.2 of 
>> draft-ietf-isis-segment-routing-extensions:
>> 
>>  If the P-flag is not set then any upstream neighbor of the
>>  Prefix-SID originator MUST pop the Prefix-SID.  This is
>>  equivalent to the penultimate hop popping mechanism used in
>>  the MPLS dataplane which improves performance of the
>>  ultimate hop.
>> 
>> These specs allow a node to REQUIRE its "upstream neighbors" on a given 
>> prefix segment to perform penultimate hop popping on any packet whose top 
>> label corresponds to a prefix-SID that has been advertised via ISIS or OSPF.
>> 
>> The architecture document has a weaker requirement.  From section 3.2.2 of 
>> draft-ietf-spring-segment-routing:
>> 
>>  The IGP signaling extension for IGP-Prefix segment includes
>>  the P-Flag.  A Node N advertising a Prefix-SID SID-R for
>>  its attached prefix R resets the P-Flag to allow its
>>  connected neighbors to perform the NEXT operation while
>>  processing SID-R.  This behavior is equivalent to
>>  Penultimate Hop Popping in MPLS.  When set, the neighbors
>>  of N must perform the CONTINUE operation while processing
>>  SID-R.
>> 
>> This could be interpreted as allowing the upstream neighbor to perform the 
>> CONTINUE operation even if the P-Flag is clear, which would mean that the 
>> choice of whether to do PHP is left to the neighbor.  This seems to 
>> contradict the statements quoted above from the IGP documents.
>> 
>> Shouldn't the architecture document be modified so that it says the same 
>> thing as the IGP documents?
>> 
>> A related issue in the architecture document stems from the following 
>> passage from section 3.2.2 of the architecture document:
>> 
>>   o A node N attaching a Prefix-SID SID-R to its attached prefix
>> R MUST maintain the following FIB entry:
>> 
>> Incoming Active Segment: SID-R
>> Ingress Operation: NEXT
>> Egress interface: NULL
>> 
>> If SID-R has been advertised in OSPF with the NP-flag clear, or if it has 
>> been advertised in ISIS with the P-flag set, there is no need for this FIB 
>> entry to be maintained.  Perhaps the passage should actually read:
>> 
>>   o If a node N advertises Prefix-SID SID-R for a prefix R that
>> is attached to N, N MUST either clear the P-Flag in the
>> advertisement of SID-R, or else maintain the following
>> FIB entry:
>> 
>> Incoming Active Segment: SID-R
>> Ingress Operation: NEXT
>> Egress interface: NULL
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
> 
> ___
> 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-6man-segment-routing-header-01.txt

[Stefano Previdi (sprevidi)]

well, I think you missed how routing headers are handled in ipv6.

Please read rfc2460 section 4.4 and then draft-ietf-6man-segment-routing-header 
section 4 and especially section 4.3.

You’ll see that the routing header is not an mpls label stack.

s.


> On Apr 29, 2016, at 9:29 AM, rabah.gued...@orange.com wrote:
> 
> If we consider SRH insertion with IPv6 PHP, the original destination address 
> would be lost when removing the SRH,
> The packet reaches the egress with a DA that matches egress address, but no 
> other information how to forward the packet to its final destination
>  
>  
> 
>  
> Rabah Guedrez 
> Thésard 
> ORANGE/IMT/OLN/WTC/IEE/ITEQ
>  
> Phone: +33 2 96 07 18 56 
> rabah.gued...@orange.com
>  
>  
> De : Stefano Previdi (sprevidi) [mailto:sprev...@cisco.com] 
> Envoyé : jeudi 28 avril 2016 13:46
> À : GUEDREZ Rabah IMT/OLN
> Cc : spring@ietf.org; i...@ietf.org
> Objet : RE: I-D Action: draft-ietf-6man-segment-routing-header-01.txt
>  
> There are many operators and use cases where, instead of encapsulation, srh 
> insertion is a far better option.
> 
> In fact all current implementations are doing srh insertion.
> 
> Still, from a spec perspective, the srh processis the same. 
> 
> s.
> 
> -Original Message- 
> From: rabah.gued...@orange.com [rabah.gued...@orange.com]
> Received: Thursday, 28 Apr 2016, 12:58
> To: Stefano Previdi (sprevidi) [sprev...@cisco.com]
> CC: spring@ietf.org [spring@ietf.org]; i...@ietf.org [i...@ietf.org]
> Subject: RE: I-D Action: draft-ietf-6man-segment-routing-header-01.txt
> 
> You have said in a previous response to a question that the draft only 
> consider the encapsulation of client packet into a new IPV6 header with SRH, 
> and not adding only an SRH to an existing packet.
> Which make sense especially for service providers who would prefer to tunnel 
> client traffic  (not modify the header of the client packets for security 
> reasons).
> 
> If you only consider encapsulation, does keeping  c-flag relevant?
>  
> Rabah Guedrez 
> Thésard 
> ORANGE/IMT/OLN/WTC/IEE/ITEQ 
>  
> Phone: +33 2 96 07 18 56 
> rabah.gued...@orange.com 
>  
> 
> 
> -Message d'origine-
> De : Stefano Previdi (sprevidi) [mailto:sprev...@cisco.com] 
> Envoyé : jeudi 28 avril 2016 12:31
> À : GUEDREZ Rabah IMT/OLN
> Cc : spring@ietf.org; i...@ietf.org
> Objet : Re: I-D Action: draft-ietf-6man-segment-routing-header-01.txt
> 
> On Apr 28, 2016, at 11:13 AM, rabah.gued...@orange.com wrote:
> > 
> > Rabah Guedrez
> > Thésard
> > ORANGE/IMT/OLN/WTC/IEE/ITEQ
> >  
> > Phone: +33 2 96 07 18 56
> > rabah.gued...@orange.com
> >  
> > 
> > 
> > -Message d'origine-
> > De : Stefano Previdi (sprevidi) [mailto:sprev...@cisco.com] Envoyé : 
> > mercredi 27 avril 2016 15:50 À : GUEDREZ Rabah IMT/OLN Cc : 
> > spring@ietf.org; i...@ietf.org Objet : Re: I-D Action: 
> > draft-ietf-6man-segment-routing-header-01.txt
> > 
> > 
> >> On Apr 27, 2016, at 3:17 PM, rabah.gued...@orange.com wrote:
> >> 
> >> Hi,
> >> I would like some clarification about the treatment of the  SRH by an 
> >> end point (the node that its loopback matches the DA field),
> >> 
> >> In section 3 :
> >> You say that the
> >> C-flag: Clean-up flag.  Set when the SRH has to be removed from
> >> the packet when the packet reaches the last segment.
> > 
> > 
> > the text is confusing but the semantic is correct ;-)
> > 
> > the cleanup flag is processed so that the last segment receives a packet 
> > without any SRH.
> > 
> > However, as you figured out, the processing of the C flag is done on the 
> > segment before last (penultimate segment). So, probably a more accurate 
> > text would be:
> > 
> >  C-flag: Clean-up flag.  
> >  Set when the SRH has to be removed from
> >  the packet prior to forward the packet 
> >  towards the last segment.
> > 
> > 
> > 
> >> Which mean that the last node inspects the SRH flags if the c-flag is set, 
> >> the node has to remove the SRH before sending the packet to its final 
> >> destination.
> >> 
> >> But In section 4.3.
> >> 
> >> You say that the node that decrements the Segments left pointer has 
> >> to check if the c-flag is set when the new value of the segments left 
> >> point is equal to zero, If the c-flag is set and the segments left 
> >> pointer == 0 then remove the SRH,
> >> 
> >> What is confusing for me is

Re: [spring] I-D Action: draft-ietf-6man-segment-routing-header-01.txt

[Stefano Previdi (sprevidi)]

There are many operators and use cases where, instead of encapsulation, srh 
insertion is a far better option.

In fact all current implementations are doing srh insertion.

Still, from a spec perspective, the srh processis the same.

s.

-Original Message-
From: rabah.gued...@orange.com [rabah.gued...@orange.com]
Received: Thursday, 28 Apr 2016, 12:58
To: Stefano Previdi (sprevidi) [sprev...@cisco.com]
CC: spring@ietf.org [spring@ietf.org]; i...@ietf.org [i...@ietf.org]
Subject: RE: I-D Action: draft-ietf-6man-segment-routing-header-01.txt

You have said in a previous response to a question that the draft only consider 
the encapsulation of client packet into a new IPV6 header with SRH, and not 
adding only an SRH to an existing packet.
Which make sense especially for service providers who would prefer to tunnel 
client traffic  (not modify the header of the client packets for security 
reasons).

If you only consider encapsulation, does keeping  c-flag relevant?

Rabah Guedrez
Thésard
ORANGE/IMT/OLN/WTC/IEE/ITEQ

Phone: +33 2 96 07 18 56
rabah.gued...@orange.com



-Message d'origine-
De : Stefano Previdi (sprevidi) [mailto:sprev...@cisco.com]
Envoyé : jeudi 28 avril 2016 12:31
À : GUEDREZ Rabah IMT/OLN
Cc : spring@ietf.org; i...@ietf.org
Objet : Re: I-D Action: draft-ietf-6man-segment-routing-header-01.txt

On Apr 28, 2016, at 11:13 AM, rabah.gued...@orange.com wrote:
>
> Rabah Guedrez
> Thésard
> ORANGE/IMT/OLN/WTC/IEE/ITEQ
>
> Phone: +33 2 96 07 18 56
> rabah.gued...@orange.com
>
>
>
> -----Message d'origine-
> De : Stefano Previdi (sprevidi) [mailto:sprev...@cisco.com] Envoyé :
> mercredi 27 avril 2016 15:50 À : GUEDREZ Rabah IMT/OLN Cc :
> spring@ietf.org; i...@ietf.org Objet : Re: I-D Action:
> draft-ietf-6man-segment-routing-header-01.txt
>
>
>> On Apr 27, 2016, at 3:17 PM, rabah.gued...@orange.com wrote:
>>
>> Hi,
>> I would like some clarification about the treatment of the  SRH by an
>> end point (the node that its loopback matches the DA field),
>>
>> In section 3 :
>> You say that the
>> C-flag: Clean-up flag.  Set when the SRH has to be removed from
>> the packet when the packet reaches the last segment.
>
>
> the text is confusing but the semantic is correct ;-)
>
> the cleanup flag is processed so that the last segment receives a packet 
> without any SRH.
>
> However, as you figured out, the processing of the C flag is done on the 
> segment before last (penultimate segment). So, probably a more accurate text 
> would be:
>
>  C-flag: Clean-up flag.
>  Set when the SRH has to be removed from
>  the packet prior to forward the packet
>  towards the last segment.
>
>
>
>> Which mean that the last node inspects the SRH flags if the c-flag is set, 
>> the node has to remove the SRH before sending the packet to its final 
>> destination.
>>
>> But In section 4.3.
>>
>> You say that the node that decrements the Segments left pointer has
>> to check if the c-flag is set when the new value of the segments left
>> point is equal to zero, If the c-flag is set and the segments left
>> pointer == 0 then remove the SRH,
>>
>> What is confusing for me is that the node that decrements the pointer is not 
>> the last node in the SR path (behavior similar to  PHP for MPLS) , which I 
>> find in direct contradiction with section 3.
>
>
> you're right. The node that processes the cleanup flag is the penultimate 
> segment, not the last.
>
>
>> Another question if a node receives a packet with the already segment
>> left == 0, what should that node do with the packet(e.g., drops it?)
>
>
> a node receiving a packet where:
>1. DA == itself
>2. a routing header is present
>3. segments_left == 0
>
> MUST ignore the routing header and process the packet normally. This
> is described in RFC2460 section 4.4
>
> Rabah : >>>>>> do you consider that the c-flag must be set for all the 
> packets.


no.

The c-flag is to be set when you insert an SRH into an existing packet.

You set the c-flag so to be sure the SRH is removed before delivering the 
packet to its intended destination.


> if we consider that setting the c-flag is not obligatory, then the  egress 
> would receive an SRH with :
>   1. DA == itself
>2. a routing header is present
>3. segments_left == 0


when you use encapsulation and you don't set the c-flag, then the egress 
receives the packet as you described above.


>   The SRH has to be ignored based on RFC2460, is that corrects ?


yes, the above is normal behavior when the path is completed (i.e.: all 
segments have been pr

[spring] Fwd: New Version Notification for draft-filsfils-spring-sr-recursing-info-02.txt

[Stefano Previdi (sprevidi)]

just refreshed the draft.

Comments are appreciated.

Thanks.
s.



> Begin forwarded message:
> 
> From: 
> Subject: New Version Notification for 
> draft-filsfils-spring-sr-recursing-info-02.txt
> Date: April 26, 2016 at 6:18:35 AM GMT+2
> To: Clarence Filsfils , Peter Psenak , 
> Les Ginsberg , Stefano Previdi 
> 
> 
> A new version of I-D, draft-filsfils-spring-sr-recursing-info-02.txt
> has been successfully submitted by Stefano Previdi and posted to the
> IETF repository.
> 
> Name: draft-filsfils-spring-sr-recursing-info
> Revision: 02
> Title:Segment Routing Recursive Information
> Document date:2016-04-25
> Group:Individual Submission
> Pages:8
> URL:
> https://www.ietf.org/internet-drafts/draft-filsfils-spring-sr-recursing-info-02.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-filsfils-spring-sr-recursing-info/
> Htmlized:   
> https://tools.ietf.org/html/draft-filsfils-spring-sr-recursing-info-02
> Diff:   
> https://www.ietf.org/rfcdiff?url2=draft-filsfils-spring-sr-recursing-info-02
> 
> 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.
> 
> 
> 
> 
> 
> 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

Re: [spring] I-D Action: draft-ietf-spring-segment-routing-ldp-interop-01.txt

[Stefano Previdi (sprevidi)]

this is the latest update of the ldp-interop draft after various comments among 
which the ones from Alex (sorry from being so late).

I hope it address most of the comments, knowing that the authors are still 
working on the manageability section (I just didn’t want to let the draft 
expire).

Thanks.
s.


> On Apr 14, 2016, at 5:22 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-01.txt
>   Pages   : 16
>   Date: 2016-04-14
> 
> 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-01
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-segment-routing-ldp-interop-01
> 
> 
> 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] draft-ginsberg-spring-conflict-resolution - WG adoption call

[Stefano Previdi (sprevidi)]

as co-author, I support the WG adoption of this draft
s.


> On Apr 14, 2016, at 9:50 AM, bruno.decra...@orange.com wrote:
> 
> Dear WG,
> 
> As we discussed at our meeting last week, working group adoption has been 
> requested for draft-ginsberg-spring-conflict-resolution.
> Please reply to the list with your comments, including although not limited 
> to whether or not you support adoption.
> 
> Thanks,
> 
> --John and 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] New Version Notification for draft-ietf-spring-segment-routing-msdc-01.txt

[Stefano Previdi (sprevidi)]

just a refresh with updated references.

Any comments/feedbakc is welcome.

Thanks.
s.

> On Apr 13, 2016, at 4:50 PM, internet-dra...@ietf.org wrote:
> 
> 
> A new version of I-D, draft-ietf-spring-segment-routing-msdc-01.txt
> has been successfully submitted by Stefano Previdi and posted to the
> IETF repository.
> 
> Name: draft-ietf-spring-segment-routing-msdc
> Revision: 01
> Title:BGP-Prefix Segment in large-scale data centers
> Document date:2016-04-13
> Group:spring
> Pages:23
> URL:
> https://www.ietf.org/internet-drafts/draft-ietf-spring-segment-routing-msdc-01.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-msdc/
> Htmlized:   
> https://tools.ietf.org/html/draft-ietf-spring-segment-routing-msdc-01
> Diff:   
> https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-segment-routing-msdc-01
> 
> Abstract:
>   This document describes the motivation and benefits for applying
>   segment routing in the data-center.  It describes the design to
>   deploy segment routing in the data-center, for both the MPLS and IPv6
>   dataplanes.
> 
> 
> 
> 
> 
> 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

Re: [spring] Terry Manderson's Discuss on draft-ietf-spring-problem-statement-06: (with DISCUSS)

[Stefano Previdi (sprevidi)]

Hi Terry,

We just updated draft-ietf-spring-resiliency-use-cases with more introductory 
text on FR/Microloop-avoidance and updated the reference to the draft in 
draft-ietf-spring-problem-statement.

Thanks.
s.



> On Apr 5, 2016, at 1:22 PM, Terry Manderson <terry.mander...@icann.org> wrote:
> 
> Stefano, 
> 
> Thank you for addressing my DISCUSS, when I see a rev of this document
> that addresses these items I will review and likely clear the discuss.
> 
> Cheers
> Terry 
> 
> On 5/04/2016, 4:04 AM, "Stefano Previdi (sprevidi)" <sprev...@cisco.com>
> wrote:
> 
>> Hi Terry,
>> 
>> 
>> sorry for coming back late on this. See below:
>> 
>> 
>>> On Jan 19, 2016, at 4:11 AM, Terry Manderson
>>> <terry.mander...@icann.org> wrote:
>>> 
>>> Terry Manderson has entered the following ballot position for
>>> draft-ietf-spring-problem-statement-06: Discuss
>>> 
>>> When responding, please keep the subject line intact and reply to all
>>> email addresses included in the To and CC lines. (Feel free to cut this
>>> introductory paragraph, however.)
>>> 
>>> 
>>> Please refer to 
>>> https://www.ietf.org/iesg/statement/discuss-criteria.html
>>> for more information about IESG DISCUSS and COMMENT positions.
>>> 
>>> 
>>> The document, along with other ballot positions, can be found here:
>>> https://datatracker.ietf.org/doc/draft-ietf-spring-problem-statement/
>>> 
>>> 
>>> 
>>> --
>>> DISCUSS:
>>> --
>>> 
>>> Thanks for putting in the effort in writing this. Firstly, I concur with
>>> Benoit's observation about text taken from the charter and laid in to
>>> the
>>> document verbatim. That tends not to help the reader and a large
>>> assumption is made that the reader understands the concerns of source
>>> based routing for partitioning VPNs, fast re-route, TE, signalling, and
>>> so on.
>> 
>> 
>> yes, the co-authors assume that the reader is already familiar with
>> concepts such as source routing, TE, VPN, Š
>> 
>> Maybe we can add references/pointers to relevant documents.
>> 
>> 
>>> Please consider rewriting the intro and other parts to help with
>>> understanding (for example in 3.2 Fast Reroute; microploop avoidance is
>>> listed as a requirement, however a sensible coverage of microloop
>>> avoidance is not found in the draft, nor in the nearby referenced
>>> spring-resiliency-use-cases).
>> 
>> 
>> Indeed. We will put additional text on microloop-avoidance in
>> draft-ietf-spring-resiliency-use-cases.
>> 
>> 
>> 
>>> This also leaves me scratching my head as
>>> to why we don't see this document and the resiliency-use-cases (and
>>> others) at the same time when they are aligned? Or restructure the
>>> document to be more informative on these facets in the first case.
>>> 
>>> Can the document also be explicit that while the SPRING problem/solution
>>> space needs to be cognisant of autonomous systems that share
>>> policy/interoperate across boundaries the primary port of call is in
>>> regard to the IGP. This will certainly aide in restraining everyone
>>> (esp.
>>> the reader) from trying to boil the 'internet ocean'. (this at least
>>> should be easy to address :)
>> 
>> 
>> I agree. We have significantly revised the security section. It now talks
>> about trust boundaries.
>> 
>> s.
>> 

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

Re: [spring] Terry Manderson's Discuss on draft-ietf-spring-problem-statement-06: (with DISCUSS)

[Stefano Previdi (sprevidi)]

Hi Terry,


sorry for coming back late on this. See below:


> On Jan 19, 2016, at 4:11 AM, Terry Manderson  
> wrote:
> 
> Terry Manderson has entered the following ballot position for
> draft-ietf-spring-problem-statement-06: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-spring-problem-statement/
> 
> 
> 
> --
> DISCUSS:
> --
> 
> Thanks for putting in the effort in writing this. Firstly, I concur with
> Benoit's observation about text taken from the charter and laid in to the
> document verbatim. That tends not to help the reader and a large
> assumption is made that the reader understands the concerns of source
> based routing for partitioning VPNs, fast re-route, TE, signalling, and
> so on.


yes, the co-authors assume that the reader is already familiar with concepts 
such as source routing, TE, VPN, …

Maybe we can add references/pointers to relevant documents.


> Please consider rewriting the intro and other parts to help with
> understanding (for example in 3.2 Fast Reroute; microploop avoidance is
> listed as a requirement, however a sensible coverage of microloop
> avoidance is not found in the draft, nor in the nearby referenced
> spring-resiliency-use-cases).


Indeed. We will put additional text on microloop-avoidance in 
draft-ietf-spring-resiliency-use-cases.



> This also leaves me scratching my head as
> to why we don't see this document and the resiliency-use-cases (and
> others) at the same time when they are aligned? Or restructure the
> document to be more informative on these facets in the first case.
> 
> Can the document also be explicit that while the SPRING problem/solution
> space needs to be cognisant of autonomous systems that share
> policy/interoperate across boundaries the primary port of call is in
> regard to the IGP. This will certainly aide in restraining everyone (esp.
> the reader) from trying to boil the 'internet ocean'. (this at least
> should be easy to address :)


I agree. We have significantly revised the security section. It now talks about 
trust boundaries.

s.

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

Re: [spring] Stephen Farrell's No Objection on draft-ietf-spring-problem-statement-07: (with COMMENT)

[Stefano Previdi (sprevidi)]

Hi,

see below for some comments.


> On Mar 2, 2016, at 1:21 PM, Stephen Farrell  wrote:
> 
> Stephen Farrell has entered the following ballot position for
> draft-ietf-spring-problem-statement-07: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-spring-problem-statement/
> 
> 
> 
> --
> COMMENT:
> --
> 
> Thanks for adding the new security considerations text.
> 
> My take-away from that is:
> 
> - The architecture needs to have a clearly defined 
>  concept of domains so that you can strip source
>  routes on ingress/egress, if needed.


sure. That was also my point. The problem-statement draft is clearly not the 
document that has to contain such details.


> - We know there are (as yet unstated) security issues
>  with source routing. The architecture document is
>  where those are promised. Which document is that?
>  Is it draft-ietf-spring-segment-routing?
>  So far, that doesn't seem to be there, so we should
>  expect more discussion to be needed if that remains
>  the case.


ok


> - You figure spring is ok-ish for MPLS, or at least no 
>  worse than today, is that right?


yes. But if it turns out that additional mechanism are needed, we’ll certainly 
integrate them into the architecture and/or dataplane specific drafts (mpls and 
v6).


> - There is a need for a digital signature mechanism
>  (or similar) for the IPv6 data plane. In which document
>  would I find that? 
>  Is it draft-previdi-6man-segment-routing-header?


draft-ietf-6man-segment-routing-header

Thanks.
s.



>  If so, that seems to call for pre-shared keys, which
>  seems likely to be tricky, if we consider BCP107. I
>  think we'll be heading for yet another discussion 
>  of the need for automated key management here.
> 
> I'm ok with letting this document go ahead, but I do hope
> the WG have substantive discussion of the above topics and
> we don't leave that to IESG review of the documents
> concerned.


I agree.

Thanks.
s.


> I'm happy to try help get that done earlier if
> the WG are up for that as leaving it to IESG review is
> liable to be more painful all around.
> 
> 

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

Re: [spring] Benoit Claise's No Objection on draft-ietf-spring-problem-statement-07: (with COMMENT)

[Stefano Previdi (sprevidi)]

Hi Benoit,

Segment Routing is the solution that addresses the requirements described in 
the problem-statement draft.

Since the problem-statement draft is not supposed to include any reference to 
the solution, it has been agreed not to introduce the “Segment Routing” 
terminology.

I’m fine with adding a statement as you suggest but this is not what has been 
required during the editing and publication process of 
draft-ietf-spring-problem-statement.

Thanks.
s.


> On Mar 1, 2016, at 4:18 PM, Benoit Claise (bclaise)  wrote:
> 
> Benoit Claise has entered the following ballot position for
> draft-ietf-spring-problem-statement-07: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-spring-problem-statement/
> 
> 
> 
> --
> COMMENT:
> --
> 
> -
> It seems to me that, when speaking of SPRING, people speaks of Segment
> Routing.
> The section title 3.3.1.2.2. is "SDN/SR use-case" btw.
> Why not mention it somewhere in the doc, for this first SPRING document?
> "SPRING is also known as Segment Routing"
> 
> 

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

Re: [spring] I-D Action: draft-ietf-spring-problem-statement-07.txt

[Stefano Previdi (sprevidi)]

This is an update based on the various DISCUSS and comments received during 
IESG review.

Following (hopefully) have been addressed:

1. more appropriate use of “SHOULD and “MUST” terminology.
2. clarification on dataplanes
3. Manageability section update
4. Security Section
5. Removed comparison between SR and RSVP-TE

Thanks.
s.


> On Mar 1, 2016, at 3:54 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   : SPRING Problem Statement and Requirements
>Authors : Stefano Previdi
>  Clarence Filsfils
>  Bruno Decraene
>  Stephane Litkowski
>  Martin Horneffer
>  Rob Shakir
>   Filename: draft-ietf-spring-problem-statement-07.txt
>   Pages   : 18
>   Date: 2016-03-01
> 
> Abstract:
>   The ability for a node to specify a forwarding path, other than the
>   normal shortest path, that a particular packet will traverse,
>   benefits a number of network functions.  Source-based routing
>   mechanisms have previously been specified for network protocols, but
>   have not seen widespread adoption.  In this context, the term
>   'source' means 'the point at which the explicit route is imposed' and
>   therefore it is not limited to the originator of the packet (i.e.:
>   the node imposing the explicit route may be the ingress node of an
>   operator's network).
> 
>   This document outlines various use cases, with their requirements,
>   that need to be taken into account by the Source Packet Routing in
>   Networking (SPRING) architecture for unicast traffic.  Multicast use-
>   cases and requirements are out of scope of this document.
> 
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-spring-problem-statement/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-spring-problem-statement-07
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-problem-statement-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] Brian Haberman's Discuss on draft-ietf-spring-problem-statement-06: (with DISCUSS and COMMENT)

[Stefano Previdi (sprevidi)]

Hi,

See below some comments.

> On Feb 3, 2016, at 3:14 PM, Brian Haberman  wrote:
> 
> --
> DISCUSS:
> --
> 
> The following is a training review from the Suresh Krishnan (incoming INT
> AD)
> 
> * Section 3.4
> 
> If the intent is to create a new RH type how will the interoperability or
> backward compatibility be possible? Specifically because intermediate
> nodes (that are segment routing hops) that encounter unknown RH types are
> required to drop the packet and send an ICMPv6 Parameter Problem back.


in fact, RFC2460 states that if a node is the destination of a packet with a 
unknown routing header type, it must inspect “segments_left” field and if its 
0, then the RH is ignored (and the packet regularly processed).

Therefore, as you pointed out, it is required and assumed that any intermediate 
segment supports the new RH type described in 
draft-ietf-6man-segment-routing-header.

Still segment routing allows interoperability with non-SR nodes since only 
segment nodes must be SR capable. 

Text will be added to draft-ietf-6man-segment-routing-header in order to 
clarify this point but I’m not sure if draft-ietf-spring-problem-statement 
should incorporate this level of details.


> * Security considerations
> 
> In general this document does not talk anything about the security issues
> with IPv6 routing headers and how they would be avoided. e.g. The
> following paper describes an attack.
> 
>   [CanSecWest07]  Biondi, P. and A. Ebalard, "IPv6 Routing Header
>   Security", CanSecWest Security Conference 2007,
>   April 2007.
>   http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf
> 
> I think the security considerations are very light and need to be greatly
> improved.


Security aspects of the IPv6 Segment Routing Header are described in section 5 
of draft-ietf-6man-segment-routing-header. 


> --
> COMMENT:
> --
> 
> * Section 2
> 
> This section talks about the Routing header defined in RFC2460 but does
> not mention that the RH0 has been deprecated by RFC5095. Potentially
> worth mentioning draft-ietf-6man-segment-routing-header-00.


SR for IPv6 is implemented through a new type. 

As the problem-statement draft is not supposed to contain any solution 
description, all the aspects of the new routing header type are described in 
draft-ietf-6man-segment-routing-header.

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

Re: [spring] Joel Jaeggli's No Objection on draft-ietf-spring-problem-statement-06: (with COMMENT)

[Stefano Previdi (sprevidi)]

On Feb 4, 2016, at 10:00 AM, Joel Jaeggli  wrote:
> 
> Joel Jaeggli has entered the following ballot position for
> draft-ietf-spring-problem-statement-06: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-spring-problem-statement/
> 
> 
> 
> --
> COMMENT:
> --
> 
> I find myself rather unsatisfied by 
> 
>   The SPRING architecture SHOULD leverage the existing MPLS dataplane
>   without any modification and leverage IPv6 dataplane with a new IPv6
>   Routing Header Type (IPv6 Routing Header is defined in [RFC2460]).
> 
> in that the prospects for use of a new routing header, and ipv6
> router/extension header treatment  seem poor.


well, draft-ietf-6man-segment-routing-header describes a new routing header 
type for SR and,btw, there are already multiple interoperable implementations.

The statement above only reflects what has been already carried out.

s.


> and the potential
> consequences for chaining these for example seem worth exploring before
> electing that course of action.

> 
> 

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

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

[Stefano Previdi (sprevidi)]

The update is related to the MPLS SRGB operations as agreed in the 
conflict-relsolution discussion. Nothing has changed, it’s only more text about 
the SRGB and how it is used in MPLS operations.

s.



> On Feb 1, 2016, at 12:36 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 Working 
> Group 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-03.txt
>   Pages   : 15
>   Date: 2016-02-01
> 
> 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.  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.
> 
>   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-03
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-segment-routing-mpls-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/
> 
> ___
> 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] draft-ginsberg-spring-conflict-resolution: SRGB INCONSISTENCY

[Stefano Previdi (sprevidi)]

Hi Stephane,

I agree with you.

I also noticed that in draft-ietf-spring-segment-routing-mpls we should have 
(probably) a better description on how to use SRGB and indexes.

I propose to update draft-ietf-spring-segment-routing-mpls so that the 
conflict-resolution draft can point to it when referring to  SRGB/index 
procedures.


s.


> On Jan 19, 2016, at 9:46 AM, stephane.litkow...@orange.com wrote:
> 
> Hi Les,
>  
> IMO, “treat the sending node as NOT SR-MPLS capable for globally scoped SIDs” 
> may lead to confusion and let think that only Adj-SID can be used.
> “NOT SR-MPLS capable” is really strong, and may prevent the PHP case  Bruno 
> was describing.
> May be we can add a sentence to precise what the statement means like : “This 
> means that the sending node is not able to process MPLS labels mapped to 
> globally scope SIDs.”.
>  
>  
> Stephane
>  
>  
> From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Les Ginsberg 
> (ginsberg)
> Sent: Saturday, January 16, 2016 01:13
> To: Uma Chunduri; DECRAENE Bruno IMT/OLN
> Cc: spring@ietf.org; Henderickx, Wim (Wim)
> Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution: SRGB 
> INCONSISTENCY
>  
> Uma –
>  
> It is true that the neighbor of the dysfunctional node cannot install 
> outgoing labels for paths via the dysfunctional node. That is precisely the 
> meaning of “treat the sending node as NOT SR-MPLS capable for globally scoped 
> SIDs”.
>  
> This does not mean that “global SID advertisements should be ignored”. And I 
> do not see that it could in any way be interpreted to imply that.
>  
> Please hit the “reset button” and try looking at this with a fresh 
> perspective. J
>  
>Les
>  
>  
> From: Uma Chunduri [mailto:uma.chund...@ericsson.com] 
> Sent: Friday, January 15, 2016 3:56 PM
> To: Les Ginsberg (ginsberg); bruno.decra...@orange.com
> Cc: spring@ietf.org; Henderickx, Wim (Wim)
> Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB 
> INCONSISTENCY
>  
> Les,
>  
> In-line [Uma]:
>  
> --
> Uma C.
>  
> From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] 
> Sent: Friday, January 15, 2016 12:22 PM
> To: Uma Chunduri; bruno.decra...@orange.com
> Cc: spring@ietf.org; Henderickx, Wim (Wim)
> Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB 
> INCONSISTENCY
>  
> Uma –
>  
> I have no idea how you translate:
>  
> Receivers of an invalid SRGB MUST ignore the SRGB and treat the sending node 
> as NOT SR-MPLS capable for globally scoped SIDs.
>  
> into
>  
> Should not consider any global SIDs, because the advertised global SIDs are 
> not trustworthy any more
>  
> SRGB defines the node-local label space which has been reserved for use by SR 
> on that node.
> [Uma]:  …and also the upstream neighboring node to compute and install the 
> outgoing label J.
>  
> Global SIDs define the index which is to be used into the node specific SRGBs 
> to map the index into the correct node-specific label.
> [Uma]: ..of both advertising node’s own SRGB locally and the SRGB of computed 
> shortest path neighbor.
>  
> While I will do my best to make the language in the draft clear and 
> unambiguous,
>  
> [Uma]: thx!
>  
> I am frankly at a loss to understand how you concluded that the SRGB related 
> statement says anything whatsoever about SID advertisements.
> [Uma]: because of this
> “sending node as NOT SR-MPLS capable for globally scoped SIDs”
> hence the conclusion of not using the global SIDs!!
>  
>  
>Les
>  
>  
> From: Uma Chunduri [mailto:uma.chund...@ericsson.com] 
> Sent: Friday, January 15, 2016 10:13 AM
> To: Les Ginsberg (ginsberg); bruno.decra...@orange.com
> Cc: spring@ietf.org; Henderickx, Wim (Wim)
> Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB 
> INCONSISTENCY
>  
> Les,
>  
> Thanks. My quick response below [Uma2]:
>  
> --
> Uma C.
>  
> From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] 
> Sent: Thursday, January 14, 2016 5:28 PM
> To: Uma Chunduri; bruno.decra...@orange.com
> Cc: spring@ietf.org; Henderickx, Wim (Wim)
> Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB 
> INCONSISTENCY
>  
> Uma –
>  
> Thanx for the response.
> Inline.
>  
> From: Uma Chunduri [mailto:uma.chund...@ericsson.com] 
> Sent: Thursday, January 14, 2016 3:34 PM
> To: Les Ginsberg (ginsberg); bruno.decra...@orange.com
> Cc: spring@ietf.org; Henderickx, Wim (Wim)
> Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB 
> INCONSISTENCY
>  
> Dear Les, Bruno, 
>  
> Thanks for a great discussion on this sticky issue.
>  
> Couple of things:
>  
> 1.   Les, I support advertising explicit SR capability of the node; 
> meaning this doesn’t have  to be tied to one or more SRGB range 
> advertisements.
> Though for example, OSPF draft doesn’t say anything about ‘no srgb ranges’ in 
> SID/Label Range TLV, my vote is to be explicit about it.
> I also agree to change IS-IS document to change and to align to the 

Re: [spring] draft-ginsberg-spring-conflict-resolution: SRGB INCONSISTENCY

[Stefano Previdi (sprevidi)]

Les,


it seems I missed most of the party… bad luck ;-)

I fully agree with your approach and it looks we getting very close to “rough 
consensus” here.

s.


> On Jan 12, 2016, at 10:06 PM, Les Ginsberg (ginsberg)  
> wrote:
> 
> Bruno –
>  
> Taking a step back – resummarizing my position:
>  
> 1)SRGB configuration is a local matter. Conforming to the specification 
> requirement of NOT advertising overlapping SRGB ranges is totally within the 
> control of the local node. Misconfigurations can and MUST be detected BEFORE 
> they are advertised.
>  
> 2)Receivers of an invalid SRGB MUST ignore the SRGB and treat the sending 
> node as NOT SR-MPLS capable.
>  
> 3)All proposals to use part of the invalid advertisement run the risk of 
> making the problem worse and are based upon assumptions which cannot be 
> verified.
>  
> 4)AS there is no valid reason why a node should send an invalid range (see #1 
> above) I have no interest in investing analysis time or implementation and 
> test time in “guess work”.
>  
> When we start discussing the second topic (SID conflicts) we have a 
> qualitatively different context. There independent configurations are in play 
> – so a single node does not have full control, human error plays a role, and 
> it makes sense to analyze the best resolution strategy.
> But in the case of SRGB the local node has full control, human error can be 
> detected before it is advertised, and there simply is no justification for 
> trying to compensate for an implementation which has clearly shown it is 
> untrustworthy.
>  
>Les
>  
>  
> From: bruno.decra...@orange.com [mailto:bruno.decra...@orange.com] 
> Sent: Tuesday, January 12, 2016 9:50 AM
> To: Les Ginsberg (ginsberg)
> Cc: spring@ietf.org; Henderickx, Wim (Wim)
> Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB 
> INCONSISTENCY
>  
> Les,
>  
> Please see inline [Bruno2]
>  
> From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] 
> Sent: Tuesday, January 12, 2016 4:38 PM
> To: DECRAENE Bruno IMT/OLN
> Cc: spring@ietf.org; Henderickx, Wim (Wim)
> Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB 
> INCONSISTENCY
>  
> Bruno -
>  
> From: bruno.decra...@orange.com [mailto:bruno.decra...@orange.com] 
> Sent: Tuesday, January 12, 2016 3:51 AM
> To: Les Ginsberg (ginsberg)
> Cc: spring@ietf.org; Henderickx, Wim (Wim)
> Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB 
> INCONSISTENCY
>  
> Les,
>  
> Please see inline 1 point below [Bruno]
>  
> From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] 
> Sent: Tuesday, January 12, 2016 12:41 AM
> To: Fedyk, Don; HENDERICKX, Wim (Wim); DECRAENE Bruno IMT/OLN
> Cc: LITKOWSKI Stephane SCE/OINIS; Martin Horneffer; spring@ietf.org
> Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB 
> INCONSISTENCY
>  
> Don -
>  
> From: Fedyk, Don [mailto:don.fe...@hpe.com] 
> Sent: Monday, January 11, 2016 3:06 PM
> To: Les Ginsberg (ginsberg); HENDERICKX, Wim (Wim); bruno.decra...@orange.com
> Cc: LITKOWSKI Stephane SCE/OINIS; Martin Horneffer; spring@ietf.org
> Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB 
> INCONSISTENCY
>  
> Hi  Les
>  
> So you are saying a node that generates inconsistent SRGB (overlapping 
> ranges) all by itself should be treated Segment routing incapable and this 
> should be easy to detect by any correctly performing neighbor?
> [Les:] Yes. Detection is easy – you simply check for overlapping ranges in 
> the advertisement from an individual node.
> What is generating all the discussion is whether we should treat that node as 
> SR-MPLS incapable (a couple of variants there) or try to massage the received 
> information into a partially usable form.
>  
> This is probably as good a time as any for me to reply to the latter proposal.
>  
> All of the “use some of the information” variants (detailed at length in 
> Bruno’s posts) depend upon the node which sent the inconsistent SRGB 
> information itself performing the same transformation as the receivers.
> [Bruno] This is a good technical point to identify. Thanks. I’ll add it in 
> the text. IINM, among the options being discussed:
> Drop all, Drop from conflict, SR incapable do _not_ require any action on the 
> advertising node. not to mention consistent action with all others nodes.
>  
> [Les2:] Drop from conflict makes an assumption that the faulty node is using 
> the ranges in the order advertised and that the reason the conflict exists is 
> because the later ranges were configured incorrectly. But we don’t know this 
> for certain. For example – the intended set of ranges is:
>  
> [1000, 1099]
> [2000, 2099]
>  
> But something gets mangled when formatting the sub-TLV and what is advertised 
> turns out to be:
>  
> [1000, 2099]
> [2000, 2099]
>  
> Using drop from conflict assumes you can use SIDs 0 – 1099 safely, but in 
> fact SIDs greater than 99 will use a label that 

Re: [spring] [Idr] Comments on draft-ietf-idr-bgp-prefix-sid-01

[Stefano Previdi (sprevidi)]

> On Nov 17, 2015, at 3:52 PM, Eric C Rosen  wrote:
> 
> [Eric] Do you have an example in mind where it is useful to advertise
> an Originator SRGB when the prefix in the NLRI is not a host
> address?
> 
> [Stefano] in fact I don’t have any good example where a /32 (/128) must be
> enforced…
> 
> Well, that's not the question I asked ;-)
> 
> Given that the SRGB is a property of a node, it seems to make sense to 
> associate an advertised SRGB with the address of a node.


to me it makes sense to advertise the SRGB along with ANY prefix originated by 
that node, regardless the mask-length.

s.


>  As I explained, one can use this by pushing on a label that is computed by 
> combining a domain-wide unique SID with the node's SRGB, and then pushing on 
> a label that causes the packet to be delivered to the node in question.
> 
> However, I can see Acee's point that (if I understand it correctly) that all 
> the nodes on a given subnet might use the same SRGB.
> 
> Suppose we modify my suggested text as follows:
> 
> ---
> OLD
> 
>   When a BGP speaker attaches a Prefix-SID attribute to a given route,
>   the Originator SRGB TLV MUST NOT be included in the attribute unless
>   the following conditions hold:
> 
>   - The prefix field of the route's NLRI contains a host address
> (i.e., a /32 IPv4 address or a /128 IPv6 address).
> 
>   - The value of the Originator SRGB TLV specifies the SRGB of the node
> that is identified by the prefix field of the NLRI.
> 
>   If a BGP route is received that contains a Prefix-SID attribute with
>   an Originator SRGB TLV, but the prefix field of the NLRI does not
>   contain a host address, the attribute SHOULD be regarded as
>   malformed. If aPrefix-SID attribute contains more than one SRGB TLV,
>   it SHOULD be regarded as malformed.  See section 7 for the treatment
>   of a malformed Prefix-SID attribute.
> 
>   When a route carrying the Prefix-SID attribute is propagated, the
>   Originator SRGB TLV (if present) MUST NOT be changed.
> 
> NEW
> 
> If a BGP speaker attaches a Prefix-SID attribute to a given route, and if the 
> Prefix-SID attribute includes the Originator SRGB TLV, then:
> 
> - If the prefix field of the route's NLRI contains a host address
> (i.e., a /32 IPv4 address or a /128 IPv6 address), the Originator SRGB TLV 
> specifies the SRGB of the node to whom the host address belongs
> 
> - If the prefix field of the route's NLRI does not contain a host address, 
> the Originator SRGB TLV specifies the SRGB that is used by the set of nodes 
> whose host addresses match the prefix, but for which there is no "more 
> specific" match that specifies a different Originator SRGB.
> 
> When a route carrying the Prefix-SID attribute is propagated, the
> Originator SRGB TLV (if present) MUST NOT be changed.
> 
> 
> 
> This new text omits the enforcement, allows an SRGB to be advertised for an 
> entire subnet (as suggested by Acee), but still explains how to figure out 
> which nodes are using the specified SRGB.
> 
> Does this modification satisfy your objection?
> 
> 
> 
> 

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

Re: [spring] [Idr] Comments on draft-ietf-idr-bgp-prefix-sid-01

[Stefano Previdi (sprevidi)]

> On Nov 16, 2015, at 3:44 PM, Eric C Rosen <ero...@juniper.net> wrote:
> 
> On 11/10/2015 3:00 PM, Acee Lindem (acee) wrote:
>> I agree the predominant use case will be advertisement of a loopback.
>> However, independent of whether or not the Originator-SRGB TLV is
>> included, I see no reason why a BGP Speaker could not associate a
>> label-index with a locally attached subnet.
> 
> I agree that a label-index could be associated with a prefix, I didn't mean 
> to suggest otherwise.  But what does it mean exactly to associate an 
> originator-SRGB with a prefix (other than a host address)?
> 
> On 11/11/2015 3:00 AM, Stefano Previdi (sprevidi) wrote:
>> I don’t want to constrain the advertisement of the Originator-SRGB to
>> a /32 (or even to a loopback interface prefix).
> 
> Do you have an example in mind where it is useful to advertise an Originator 
> SRGB when the prefix in the NLRI is not a host address?


in fact I don’t have any good example where a /32 (/128) must be enforced…

s.



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

Re: [spring] [Idr] Comments on draft-ietf-idr-bgp-prefix-sid-01

[Stefano Previdi (sprevidi)]

On Nov 9, 2015, at 5:02 PM, Eric C Rosen <ero...@juniper.net> wrote:
> 
> On 11/6/2015 8:18 AM, Stefano Previdi (sprevidi) wrote:
>> A prefix may have a shorter mask than 32 (or 128) and still be ok for
>> the Originator SRGB to be there.
> 
> Stefano,
> 
> On further thought, I wonder if I misunderstood the point of your question.  
> If all the addresses falling under a given prefix are loopback addresses of 
> the same node, then the same SRGB might apply to all of them.


yes, but note that nothing mandates that we use only loopback addresses and 
nothing mandates a loopback address to be a /32.


>  In that case, it might make sense to have a shorter prefix but still 
> advertise the Originator-SRGB.  Is that what you're thinking?


yes and more widely, I don’t want to constrain the advertisement of the 
Originator-SRGB to a /32 (or even to a loopback interface prefix).

s.

 
>  But on the other hand, if a node has multiple loopback addresses, it 
> probably won't want the same SID assigned to all of them.
> 
> Eric

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

Re: [spring] [Idr] Comments on draft-ietf-idr-bgp-prefix-sid-01

[Stefano Previdi (sprevidi)]

Hi Eric,

the proposed text looks good but with one question below.


On Oct 22, 2015, at 10:16 PM, Eric C Rosen 
> wrote:

I'd like to make some suggestions for textual changes to sections 3.1 and
4.3 of draft-ietf-idr-prefix-sid.  The main purpose of these suggestions is
to clarify the use of the Originator SRGB TLV, and to remove what I
think is an excessive and distracting amount of repetition about the
inadvisability of allowing different nodes to use different SRGBs.

My proposal for the text of these sections follows.  In addition to the
changes I mentioned above, some typos in the original text are fixed, and
there is a suggestion (explained below in brackets) for slightly modifying
the text about the AFI/SAFIs with which the Prefix-SID attribute may be
used.  A few other explanations can be found in brackets below inside the
proposed text.



3.1.  MPLS Prefix Segment

   In this document, we specify "MPLS Prefix Segments" only for BGP routes
   that have an AFI/SAFI of 1/4 or 2/4.  The applicability of MPLS prefix
   segments to other AFI/SAFIs is outside the scope of this document.

[The original text said "A Multiprotocol BGP labeled IPv4/IPv6 Unicast
([RFC3107]) session type is required", I don't think that is quite precise.
If a session has multiple AFI/SAFIs, including 1/4, I don't think we want to
say that the attribute can be placed in any UPDATE on that session.  Also,
it's not quite accurate to say that RFC3107 is restricted to 1/4 and 2/4;
RFC3107 doesn't mention the AFI.  And we may want to leave it open that the
Prefix Segment notion may eventually be applied somehow to SAFI-128 routes.]

   The BGP Prefix Segment is realized on the MPLS dataplane in the
   following way:

  As described in [I-D.ietf-spring-segment-routing-msdc] the
  operator assigns a globally unique "index", L_I, to a locally
  sourced prefix of a BGP speaker N which is advertised to all other
  BGP speakers in the SR domain.

  According to [I-D.ietf-spring-segment-routing], each BGP speaker
  is configured with a label block called the Segment Routing Global
  Block (SRGB).  (While it is recommended to use the same SRGB across
  all the nodes within the SR domain, the SRGB of a node is a local
  property and could be different on different speakers).

  The index L_I is a 32 bit offset in the SRGB.  Each BGP speaker
  derives its local MPLS label, L, by adding L_I to the start value
  of its own SRGB, and programs L in its MPLS dataplane as its
  incoming/local label for the prefix.  (See section 5.1 for more
  details.)

[Added reference to section 5.1.]

  The outgoing label for the prefix is found in the NLRI of the
  Multiprotocol BGP labeled IPv4/IPv6 Unicast prefix advertisement.
  The index L_I is only used as a hint to derive the local/incoming
  label.

   Section 4.1 of this document specifies the Label-Index TLV of the BGP
   Prefix-SID attribute; this TLV can be used to advertise the label index
   of a given prefix.

   If the BGP speakers are not all configured with the same SRGB, and if
   traffic-engineering within the SR domain is required, each node may be
   required to advertise its local SRGB.  One way of advertising the local
   SRGB is to use the segment routing extensions of BGP-LS
   (draft-gredler-idr-bgp-ls-segment-routing-ext-00.txt). An alternative
   option is to use the Originator SRGB TLV of the prefix-SID attribute, as
   specified in Section 4.3 of this document.

[Rearranged last paragraphs slightly to improve flow, imo.]



4.3.  Originator SRGB TLV

   The Originator SRGB TLV is an optional TLV and has the following
   format:

 0   1 2   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type  |  Length   |Flags  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |
+-+-+-+-+-+-+-+-+

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRGB 1 (6 octets) |
|   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRGB n (6 octets) |
|   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

[I can rarely get the ascii art to render correctly, but the diagram above
is supposed to be unchanged from what appears in the draft.]

   where:

   o  Type is 3.

   o  Length is the total length of the value portion of the TLV: 2 +
  multiple of 6.

   o  Flags: 16 bits of flags.  

[spring] Fwd: New Version Notification for draft-filsfils-spring-sr-recursing-info-00.txt

[Stefano Previdi (sprevidi)]

FYI,

this is the proposal for carrying traffic using a common sid among prefixes.
It covers multiple use cases that have been described on the email thread 
exchanged a couple of weeks ago.

s.



Begin forwarded message:

From: >
Subject: New Version Notification for 
draft-filsfils-spring-sr-recursing-info-00.txt
Date: October 19, 2015 at 8:54:43 AM GMT+2
To: Stefano Previdi >, Clarence 
Filsfils >, Peter Psenak 
>, Stefano Previdi 
>, Clarence Filsfils 
>, Peter Psenak 
>


A new version of I-D, draft-filsfils-spring-sr-recursing-info-00.txt
has been successfully submitted by Stefano Previdi and posted to the
IETF repository.

Name: draft-filsfils-spring-sr-recursing-info
Revision: 00
Title: Segment Routing Recursive Information
Document date: 2015-10-18
Group: Individual Submission
Pages: 8
URL:
https://www.ietf.org/internet-drafts/draft-filsfils-spring-sr-recursing-info-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-filsfils-spring-sr-recursing-info/
Htmlized:   
https://tools.ietf.org/html/draft-filsfils-spring-sr-recursing-info-00


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.





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

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

[Stefano Previdi (sprevidi)]

just fixed the ip addresses used in the various illustrations.

s.


> On Oct 14, 2015, at 4:47 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 Working 
> Group of the IETF.
> 
>Title   : Segment Routing Architecture
>Authors : Clarence Filsfils
>  Stefano Previdi
>  Bruno Decraene
>  Stephane Litkowski
>  Rob Shakir
>   Filename: draft-ietf-spring-segment-routing-06.txt
>   Pages   : 24
>   Date: 2015-10-14
> 
> 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.
> 
>   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-06
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-segment-routing-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-msdc-00.txt

[Stefano Previdi (sprevidi)]

SPRINGers,

this is the WG item version of the MSDC draft. 


Thanks.
s.



> On Oct 12, 2015, at 11:22 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 Working 
> Group 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-00.txt
>   Pages   : 23
>   Date: 2015-10-12
> 
> Abstract:
>   This document describes the motivation and benefits for applying
>   segment routing in the data-center.  It describes the design to
>   deploy segment routing in the data-center, 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-00
> 
> 
> 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] [Isis-wg] Handling same SID mapped to different prefixes and vice versa cases

[Stefano Previdi (sprevidi)]

mailto:psar...@juniper.net>> wrote:

Hi Stefano,

From: "Stefano Previdi (sprevidi)"
Date: Wednesday, October 7, 2015 at 12:42 AM
To: Pushpasis Sarkar
Cc: Imtiyaz Mohammad, Stephane Litkowski, "Clarence Filsfils (cfilsfil)", 
Hannes Gredler, "Ahmed Bashandy (bashandy)", 
"bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>", Jeff Tantsura, 
Isis-wg, "spring@ietf.org<mailto:spring@ietf.org>"
Subject: Re: [Isis-wg] Handling same SID mapped to different prefixes and vice 
versa cases

On Oct 6, 2015, at 7:48 PM, Pushpasis Sarkar 
<psar...@juniper.net<mailto:psar...@juniper.net>> wrote:

Hi Stefano,

Thanks for your response. Please find few comments inline.

On 10/6/15, 10:22 PM, "Stefano Previdi (sprevidi)" 
<sprev...@cisco.com<mailto:sprev...@cisco.com>> wrote:

Hi,

sorry, I’m a bit late on my mail queue…

In fact your use case can be addressed by using the Node-SID of the prefix 
originator.
[Pushpasis] Actually that’s exactly what case 1) in Imtiyaz’s mail says..


Rather than allowing same sid for different prefixes (which may easy come to 
misbehaviors), I’d prefer to set the following rule:
. for all prefixes originated by the same node, the node-sid of the originator 
may be used.
[Pushpasis] But that does not mean that traffic for all the prefixes originated 
by the originator MUST be tunneled.


of course not. that’s why I did put a “may”.


The solution should be flexible to provide all options.
1. Use a single tunnel to carry traffic for all prefixes originated by a node.
2. Use separate tunnels to carry traffic for two or more prefixes originated by 
a node.
3. Use separate tunnels to carry traffic for each selected prefix-sets(groups 
of prefixes) originated by a node.


that is fine and my rule still apply. After all, there’s nothing that prevlude 
a node from having multiple sid’s.
[Pushpasis] By sids do you mean node-sids or non-node prefix sids…


a node, likely, has multiple prefixes attached to it and therefore will have 
multiple sids (each one attached to one of its prefixes).
These sids may be node-sids as well as prefix-sids.


 If the later I agree… But why do you need multiple node-sids for?


for many use cases where a node is known in the routing domain through multiple 
loopback addresses (e.g.: one for ipv4 traffic and one for vpnv4 traffic).
two (or more) loopback addresses MAY mean two or more node-sid’s.


You can associate the same node-sid for all prefixes originated from the router 
(e.g. All loopback addresses)..


I definitely don't like the idea because you can’t determine if it’s intended 
or misconfiguration. This will create a lot of room for problems.

If your use case requires to use the same label on top of packets destined to 
different prefixes, then my proposal of recursing into the node-sid works just 
fine (in addition to addressing other use cases).


s.






















I am not saying that different setting different node-sids should not be used 
for different prefixes originated, but that cannot be mandatory as well…

So, the rule would be slightly different:
. for all prefixes originated by the same node, node-sid's of the originator 
may be used.

this would address your 3 points above.
[Pushpasis] Yes it would..  But again there should not be a mandatory 
requirement to set different node-sids for each loopback address originated 
from a given node.

A single node-sid configured on the node can be associated with all the 
loopback addresses originated from the same node.

2 and 3 are useful if we the operator is interested in traffic statistics for 
each separate traffic flows destined to the node. The SR architecture should 
enable both..


the architecture already allows this.


In summary it should allow both 1:1 as well as N:1 correspondence between 
Prefix and Prefix-SID-indexes.


agreed, and it’s already the case.



Of course, it implies the ingress is capable of understanding who originated 
the prefix (even in case of multi-level/area).

In isis we have draft-ietf-isis-prefix-attributes that define a new prefix 
sub-tlv with the originator info (among other things) that is preserved across 
levels, so you have all the info you need.

The advantage of this rule, compared to advertising the same sid of multiple 
prefixes, is also that you can still advertise a prefix-sid (e.g.: a local sid) 
with the prefix.

If I take your example, you can still advertise:
local sid 123 for 30.30.30.30/32
local sid 321 for 40.40.40.40/32
[Pushpasis] If 30.30.30.30/32 and 40.40.40.40/32 are both originated from one 
single node, and there is no need to separately account traffic for each of 
these there is no need to allocate two different labels for reaching the same 
node.


but if there _is_ the need to use a label in order to switch the packet towards 
the outgoing interface (to 30 or 40), then you understand the use case, right ?

It’s a di

Re: [spring] [Isis-wg] Handling same SID mapped to different prefixes and vice versa cases

[Stefano Previdi (sprevidi)]

Pushpasis,

On Oct 7, 2015, at 3:47 PM, Pushpasis Sarkar 
<psar...@juniper.net<mailto:psar...@juniper.net>> wrote:

Hi Bruno,

From: "bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>"
Date: Wednesday, October 7, 2015 at 5:43 PM
To: Pushpasis Sarkar, "Stefano Previdi (sprevidi)"
Cc: Hannes Gredler, "spring@ietf.org<mailto:spring@ietf.org>", Isis-wg, Imtiyaz 
Mohammad, "Clarence Filsfils (cfilsfil)"
Subject: RE: [Isis-wg] Handling same SID mapped to different prefixes and vice 
versa cases

BTW, draft-ietf-isis-segment-routing-extensions does not explicitly state 
whether this is allowed or not (to advertise Special Purpose MPLS labels (aka 
Reserved labels)). My personal reading is that since this is not forbidden, 
then this is allowed.
[Pushpasis] That is exactly what I (and probably Imtiyaz too) wanted the 
authors to confirm and if possible explicitly spell out in the next version (we 
expect that draft should specifically spell out that same node-sid can be 
associated with multiple prefixes originated by the same node..


is it what Bruno intended ?  Sorry, this is not what I understood. What I agree 
with is:

. multiple prefixes may use the node-sid of their originator (the indication 
may be done through Bruno’s suggestion) and through the use of prefix-attribute.

This covers the case where you want to use:
.  the same node-sid for all prefixes of the same node
. some prefixes use one node-sid and other prefixes use another node-sid
. prefixes use the node-sid while also carry a local sid.

one solution for many use cases and without opening the door to 
misconfigurations.

s.



But not with same or different prefixes originated from different nodes). 
Otherwise implementations may interpret this in other way and expect all 
prefixes (even originated  by the same node) to have separate index associated 
and if they receive two or more prefixes form same node with same index they 
might throw and error and not install the label push for the rest of the 
prefixes (i.e. program it for only the first prefix learnt).

Thanks
-Pushpasis

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

Re: [spring] [Isis-wg] Handling same SID mapped to different prefixes and vice versa cases

[Stefano Previdi (sprevidi)]

On Oct 7, 2015, at 3:57 PM, Pushpasis Sarkar 
<psar...@juniper.net<mailto:psar...@juniper.net>> wrote:

Hi Robert,

From: <rras...@gmail.com<mailto:rras...@gmail.com>> on behalf of Robert Raszuk
Date: Wednesday, October 7, 2015 at 4:50 PM
To: Pushpasis Sarkar
Cc: "Stefano Previdi (sprevidi)", Hannes Gredler, 
"spring@ietf.org<mailto:spring@ietf.org>", Isis-wg, "Clarence Filsfils 
(cfilsfil)"
Subject: Re: [spring] [Isis-wg] Handling same SID mapped to different prefixes 
and vice versa cases

Hi Pushpasis
​,



[Pushpasis] No. I seem to be repeating myself. But your suggestion of recursing 
will result in tunnelling traffic destined for all prefixes originated (not 
only loopback addresses) though MPLS. Operator may not like/want this. So 
associating the sid-index with the loopback address with a specific address 
provides flexibility in picking which prefixes should be tunneled and which 
ones need not.

​I do not quite agree with your above statement. Clearly you are thinking in 
terms how traditional MPLS router with perhaps specific implementation resolves 
paths and building forwarding tables in MPLS domain.

Let's observe that Segment Routing imposition may but not necessarily must use 
the same imposition algorithm/mechanism.

​I can easily see a case at ingress where only carefully selected by operator 
subset of prefixes originated by exit X will be MPLS segment routed in the 
given domain. Rest may be native switched or IP tunneled/encapsulated.
[Pushpasis] That is exactly what I was saying that such usecase will not be 
possible if we follow Stefano’s suggestion. As per his suggestion (at least 
that is what I understood so far)… The exit X will associate node-sid with only 
one loopback prefix.. And then ingress should automatically use the single 
node-sid for tunneling traffic for all prefixes originated by exit X..


this is not what I suggested.

Again, sorry to repeat myself:

You decide on a per-prefix base,  which node-sid of the originator you want to 
use (if any).

This gives you all the flexibility to:
. group prefixes on different node-sids or
. use the same node-sid or
. use the prefix-prefix-sid

whatever combination you need.

s.



And I am trying to say that will not provide the operator to pick a subset of 
prefixes.. If the ingress uses tunelling only for prefixes with which a index 
is associated, then the operators will have that choice..

As examples that can be accomplished by controller driven ingress map or use 
multiple next hops (the case where you propagate by BGP).
[Pushpasis] I did not get this usecase much. But I think we maybe saying the 
same thing.

Thanks
-Pushpasis

Cheers,
R.


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