Re: [spring] WG Adoption Call for draft-martin-spring-segment-routing-ipv6-use-cases

I disagree. There is nothing wrong to present a use case for service chaining either in SPRING WG with draft-martin-spring-segment-routing-ipv6-use-cases or for that matter in IDR with draft-patel-raszuk-bgp-vector-routing-01 or draft-rfernando-l3vpn-service-chaining-03 at present time. Holding w

Re: [spring] WG Adoption Call for draft-previdi-spring-problem-statement - Section 3

Hi Yakov, > After all, these IGP-based tunnels are *not* source/explicitly routed. The definition of "source routing" states that source routing is the ability which allows a sender of a packet to partially or completely specify the route the packet takes through the network Let's notice that it

Re: [spring] WG Adoption Call for draft-martin-spring-segment-routing-ipv6-use-cases

Hi Yakov, > The above assumes that the already available technology, MPLS, "may > not be available or deployable for lack of support on network > elements", yet a brand new technology, a new IPv6 Segment Routing > header, will be available, deployable, and supported on network > elements. The auth

Re: [spring] WG Adoption Call for draft-martin-spring-segment-routing-ipv6-use-cases

Yakov, The topic here is traffic controll and traffic steering. In MPLS to the best of my knowledge the only tool to accomplish that is MPLS TE. That in turn requires RSVP-TE and pretty heavy IGP extensions. I am not aware of any deployments of the above MPLS control planes over GRE nor I am aw

Re: [spring] Comments on Section 3// WG Adoption Call for draft-martin-spring-segment-routing-ipv6-use-cases

Hi Robin, Please notice that mLDP and LDP have nothing in common as far as protocol itself. So those are two separate protocols. The name may be confusing ;) Cheers, R. On Mar 27, 2014 5:26 PM, "Lizhenbin" wrote: > Alvaro, > > > > Section 3 of draft-previdi-spring-problem-statement presents a

Re: [spring] Comments on Section 2// WG Adoption Call for draft-francois-spring-resiliency-use-case

I would agree with the below observation of using detailed solution to the requirement. Rgs, R. On Mar 27, 2014 5:50 PM, "Lizhenbin" wrote: > Alvaro, > > > > Section 2 of draft-francois-spring-resiliency-use-case presents as follows: > > > > " >From an SR viewpoint, we would like to highli

Re: [spring] 答复: Comments on Section 2// WG Adoption Call for draft-martin-spring-segment-routing-ipv6-use-cases

Hi Robin, > Comments is as follows: > > 1. I wonder why here mention the comparison with seamless MPLS. They are > totally different scenarios. Do authors think that if the whole seamless > MPLS network changes to only use IPv6, there will not be addtional > complexitiy comparing with seamless MPL

Re: [spring] WG Adoption Call for draft-martin-spring-segment-routing-ipv6-use-cases

> Best regards, > > Xiaohu > > > > 发件人: spring [mailto:spring-boun...@ietf.org] 代表 Robert Raszuk > 发送时间: 2014年3月27日 23:47 > 收件人: Yakov Rekhter > 抄送: Alvaro Retana, (aretana); spring@ietf.org > 主题: Re: [spring] WG Adoption Call for > draft-martin-spring-segment-routi

Re: [spring] Comments on Section 3// WG Adoption Call for draft-martin-spring-segment-routing-ipv6-use-cases

Hi Yakov, If we are to talk real - let's do it. mLDP is effectively subset of PIM control plane enhanced to carry MPLS labels over LDP transport. Unicast LDP control plane procedures have as I said in my former mail in vast majority nothing in common with mLDP and vice versa. And I am talking abo

Re: [spring] WG Adoption Call for draft-martin-spring-segment-routing-ipv6-use-cases

, 2014 at 10:30 AM, Xuxiaohu wrote: > > >> -邮件原件- >> 发件人: spring [mailto:spring-boun...@ietf.org] 代表 Robert Raszuk >> 发送时间: 2014年3月28日 16:38 >> 收件人: Xuxiaohu >> 抄送: Yakov Rekhter; spring@ietf.org; Alvaro Retana, (aretana) >> 主题: Re: [spring] WG Adopti

Re: [spring] WG Adoption Call for draft-martin-spring-segment-routing-ipv6-use-cases

Hi Yakov, >> The reality of the industry is that we have both dataplanes so >> it's obvious that we may want to provide similar functionalities >> for both without claiming one technology is the solution for >> everything. > > The reality of the industry is that while we have the MPLS dataplane,

Re: [spring] WG Adoption Call for draft-martin-spring-segment-routing-ipv6-use-cases

Hi Hannes, > since most v6 hardware implementations i am familiar with, do not have > support for parsing SRH processing, what you are suggesting here > *is* a migration to a different dataplane. + > those are by no means "minor extensions" - those are "major, intrusive > changes which often requi

Re: [spring] WG Adoption Call for draft-martin-spring-segment-routing-ipv6-use-cases

Hi Hannes, > agreed that customers buying kit are making a call on this, not IETF - > however IETF should keep honesty in the discussion. > unfortunately the current way of promoting v6-sr is an 'oversell'. > > "look we have this new dataplane, it comes at (almost) zero cost, >and is going t

Re: [spring] Fwd: New Version Notification for draft-previdi-spring-problem-statement-01.txt - section 4

Hi Yakov, > Section 4 ("Fast Reroute") should be removed, What's wrong in including all possible problems in problem statement document and treating it as a reading roadmap document to more specific drafts describing each problem in more details ? I think such approach may be helpful for the rea

Re: [spring] Mail regarding draft-francois-spring-resiliency-use-case

Hi Greg & Pierre, More seriously, yes, in SR, you have to pay attention to label allocation > when installing your failover entries in the FIB. However I do not see why > it leads to having intermediate nodes maintain path information. > > Can you expand on this part of your comment? > > > > GIM>

Re: [spring] use case vs requirements

Hi Yakov, As a WG member not a chair I would like to ask for your clarification. Let's take some other IETF's WG use case document namely LISP Traffic Engineering Use Cases document: https://tools.ietf.org/html/draft-farinacci-lisp-te-06 It covers LISP TE Use Cases using natural language of LIS

Re: [spring] Comments on Section 2.4//WG Adoption Call for draft-martin-spring-segment-routing-ipv6-use-cases

Hello Robin, > Regarding the section IPv6 Segment Routing in the Core networks, > I have following comments: > In order to justify the requirement, I think it tries to romove all possible > options for the designed core network: > > -- MPLS: it is definitely be removed firstly. No - no one is sug

Re: [spring] [sfc] Why Transport Dependence is deemed as a problem?//re: I-D Action: draft-ietf-sfc-problem-statement-04.txt

Hi Xu, How to simply use the MPLS label stack to realize the SFC has been > described in http://tools.ietf.org/html/draft-xu-spring-sfc-use-case-00. > Any comments are welcome. > ​The draft says:​ "that packet, SN1 could further consume the metadata contained in the NSH and meanwhile decrease t

Re: [spring] [sfc] 答复: Why Transport Dependence is deemed as a problem?//re: I-D Action: draft-ietf-sfc-problem-statement-04.txt

> [Xiaohu] Your observation is correct. The SF proxy must strip the NSH and the SR header before sending the packets to the directly attached legacy service functions. When the packets was returned by service functions, the SF proxy must reimpose those headers on the packets. Meanwhile, the SF prox

Re: [spring] [sfc] 答复: Why Transport Dependence is deemed as a problem?//re: I-D Action: draft-ietf-sfc-problem-statement-04.txt

; From: sfc [mailto:sfc-boun...@ietf.org] On Behalf Of Robert Raszuk >> Sent: Tuesday, April 22, 2014 3:28 PM >> To: Xuxiaohu >> Cc: spring@ietf.org; Ron Parker; s...@ietf.org >> Subject: Re: [sfc] 答复: Why Transport Dependence is deemed as a >> problem?//re: I-D Action: dra

Re: [spring] draft-gredler-spring-mpls-05.txt as SPRING WG document

Hi, Two comments on this document. Question: Assume there is label binding received for a given FEC from/by multiple protocols. Which one should be chosen by the LSR to be used in data plane? Choosing wrong one may jeoparadise the hope of stitching. Is consistent manual configuration across mu

Re: [spring] draft-gredler-spring-mpls-05.txt as SPRING WG document

, > > On Fri, May 16, 2014 at 08:21:38PM +0200, Robert Raszuk wrote: > | Hi, > | > | Two comments on this document. > | > | > | Question: > | > | Assume there is label binding received for a given FEC from/by > | multiple protocols. Which one should be chosen by t

Re: [spring] draft-gredler-spring-mpls-05.txt as SPRING WG document

Xiaohu, > Since there are just label distribution protocols which don't affect the route > selection at all, why do you care about that consistency among routers? We are talking about label selection and not route selection. This is about the same FEC so same route hence route selection does not

Re: [spring] 答复: draft-gredler-spring-mpls-05.txt as SPRING WG document

; Robert, > >> -邮件原件- >> 发件人: rras...@gmail.com [mailto:rras...@gmail.com] 代表 Robert Raszuk >> 发送时间: 2014年5月21日 15:25 >> 收件人: Xuxiaohu >> 抄送: Hannes Gredler; Yakov Rekhter; spring@ietf.org; Alvaro Retana (aretana); >> John G. Scudder >> 主题: Re: [spring] d

Re: [spring] 答复: 答复: draft-gredler-spring-mpls-05.txt as SPRING WG document

learnt, the packet would definitely be forwarded to the node > identified by that FEC along the shortest path. > > Could you give a concrete example to illustrate why the forwarding result is > rather poor? > > Best regards, > Xiaohu > >> -邮件原件- >> 发件人: r

Re: [spring] draft-gredler-spring-mpls-05.txt as SPRING WG document

in this document is to prefer the one obtained >from (targeted) LDP. An implementation MUST support the >ability to override the default behavior via configuration. > > Yakov. > >> >> Cheers, >> R. >> >> >> On Tue, May 20, 2014 at

Re: [spring] 答复: 答复: 答复: 答复: draft-gredler-spring-mpls-05.txt as SPRING WG document

; label (e.g., 44) allocated by the LDP module. In other word, when receiving a > packet with top label of either 1033 or 44, that top label would be swapped > to 33. > > Best regards, > Xiaohu > >> -邮件原件- >> 发件人: spring [mailto:spring-boun...@ietf.org] 代表 Robe

Re: [spring] 答复: 答复: 答复: 答复: 答复: draft-gredler-spring-mpls-05.txt as SPRING WG document

Hi Xu, > If the implementation doesn't support interoperation between different > label distribution protocols, the implementation should have separate > LFIB entries for each distribution protocol. In this way, there are still > multiple LFIB (MPLS2MPLS) entries for a given prefix anyway. How wo

Re: [spring] 答复: 答复: 答复: 答复: 答复: 答复: draft-gredler-spring-mpls-05.txt as SPRING WG document

Hey Hannes, By "hack" I mean someting very cool, brilliant and positive here .. ;) Cheers, R. On May 22, 2014 2:18 AM, "Hannes Gredler" wrote: > On Thu, May 22, 2014 at 04:01:06AM +, Xuxiaohu wrote: > [ ... ] > | > Moreover I am not sure that this is always possible with the index > based l

Re: [spring] WG Adoption Call for draft-martin-spring-segment-routing-ipv6-use-cases

Hi Yakov, I read Eric's email and included its main point a bit differently. It is known for a fact that in large network (say 1000 routers) it is sufficient to force traffic only via few key core boxes (perhaps 10 or so) in order to perform good traffic engineering. With SR it is possible while

Re: [spring] WG Adoption Call for draft-martin-spring-segment-routing-ipv6-use-cases

Hey Hannes, > if *just* loose source routing is required, then the same can get achieved > using nested IP tunnels. I would agree with above. In fact one could state a question which encap would be more efficient two IPv6 extension headers or 6 IPv4 headers :) Also data plane processing wise on

Re: [spring] WG Adoption Call for draft-martin-spring-segment-routing-ipv6-use-cases

Hi Hannes, > we have heard of many customer requirements requiring to to disjoint > routing True if you are talking end to end between PEs. I have heard of those between 2004-2006 when MTR fashion was at the peak too :) And I must have missed that SR claims to address those without all nodes sup

Re: [spring] WG Adoption Call for draft-martin-spring-segment-routing-ipv6-use-cases

> the use cases i am talking are specifically: > http://tools.ietf.org/html/draft-filsfils-spring-segment-routing-use-cases-00#section-3.2.1 I would not say that context segment is the same as adj-SID > http://tools.ietf.org/html/draft-filsfils-spring-segment-routing-use-cases-00#section-4.1.2

Re: [spring] FW: New Version Notification for draft-xu-spring-sfc-use-case-01.txt

Hello Xu, I have the following concern regarding your proposal. The draft says: In addition, they have allocated and advertised segment IDs (SID) for the service functions they are offering. For example, SN1 allocates and advertises an SID, i.e., SID(SF1) for service function SF1 wh

Re: [spring] FW: New Version Notification for draft-xu-spring-sfc-use-case-01.txt

do question need for this set of new drafts. Best, R. On Wed, Jun 18, 2014 at 9:50 AM, Xuxiaohu wrote: > Hi Robert, > > Thanks a lot for your comments. Please see my response inline. > >> -Original Message- >> From: rras...@gmail.com [mailto:rras...@gmail.

Re: [spring] FW: New Version Notification for draft-xu-spring-sfc-use-case-01.txt

ert, > >> -Original Message- >> From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Robert Raszuk >> Sent: Wednesday, June 18, 2014 8:06 PM >> To: Xuxiaohu >> Cc: >> Subject: Re: [spring] FW: New Version Notification for >> draft-xu-spring-s

Re: [spring] FW: New Version Notification for draft-xu-spring-sfc-use-case-01.txt

>> The benefit for me is clear - to avoid new protocol extensions required for >> what >> you call SFC use case. > > I don't understand what you meant. Without protocol extensions, how could > service functions be discovered in my mind? Via indirection. Do not flood those service functions in IG

Re: [spring] The rationale of draft-xu-spring-islands-connection-over-ip

Hi Xu, We discussed this work before, however I have a new question ... It is an informational draft so you relay on proper configuration of RS nodes in the islands. Note that today you may have out of the box SR node supporting IPv4, IPv6 (say without SR) + MPLS. So you must select your operati

Re: [spring] How to carry metadata/context in an MPLS packet

All, Is the idea of using data plane to carry complete metadata is "the way" or "a way" of approaching the problem ? Has this been already discussed ? I would rather consider to carry metadata in control plane and only attach a reference_id (and only when it is needed) to the data plane. Rgs, R.

Re: [spring] How to carry metadata/context in an MPLS packet

; > If that “reference_id” is attached to the MPLS packet, it seems that you > still need some way to indicate the presence of that “reference_id” in the > MPLS packet. > > > > Best regards, > > Xiaohu > > > > *From:* rras...@gmail.com [mailto:rras...@gmail.com]

Re: [spring] [sfc] How to carry metadata/context in an MPLS packet

Hi Lloyd, I think and I do hope that we see only mpls centric proposals as this is one encapsulation used in the networks. I hope other proposals will also address v6 encapsulations and that any encapsulation will use same metadata control plane. Best, R. On Jul 18, 2014 12:23 PM, wrote: > No,

Re: [spring] [sfc] How to carry metadata/context in an MPLS packet

nts. > > > >Ron > > > > *From:* sfc [mailto:sfc-boun...@ietf.org] *On Behalf Of *Robert Raszuk > > *Sent:* Friday, July 18, 2014 3:27 AM > *To:* Xuxiaohu; s...@ietf.org > *Cc:* m...@ietf.org; > *Subject:* Re: [sfc] [spring] How to carry metadata/context in

Re: [spring] Comments on draft-filsfils-spring-segment-routing-central-epe-02

​Hi Robin,​ +-+ +--+ >| | | | >|HB--D G >| | +---/| AS 2 |\ +--+ >| |/ +--+ \ | |---L/8 >A AS1 C---+\| | >| |\\ \ +--+ /| AS 4 |---M/8 >|

Re: [spring] [Idr] Comments on draft-filsfils-spring-segment-routing-central-epe-02

ocol extensions required for making this work at all. > > tx, > > /hannes > > On Mon, Jul 21, 2014 at 09:20:56AM +0200, Robert Raszuk wrote: > |*Hi Robin,* > | > | +-+ +--+ > | | | | | > | |HB-

Re: [spring] SPRING MPLS and Entropy Label

All, Observing this discussion I have a question why the draft as well as this discussion is only limited to one solution for efficient load balancing across parallel links in the network - namely entropy labels ? Let's observe that unlike in general MPLS label allocation per FEC in SPRING labels

Re: [spring] SPRING MPLS and Entropy Label

advertise at least as big block as you have max parallel links on any interface you should be fine. Best , R. On Jul 24, 2014 2:12 PM, "Kireeti Kompella" wrote: > Hi Robert, > > On Jul 24, 2014, at 03:21 , Robert Raszuk wrote: > > Therefor an alternative of using any form

Re: [spring] SPRING MPLS and Entropy Label

cussion we already had together. I think you are trying to sell IPv6 SR > that I will unfortunately not buy again J > > > > *From:* spring [mailto:spring-boun...@ietf.org] *On Behalf Of *Robert > Raszuk > *Sent:* Thursday, July 24, 2014 08:48 > *To:* Kireeti Kompella >

Re: [spring] SPRING MPLS and Entropy Label

el aggregation” scheme … > > Or we need to change of labels are allocated from the label space for all > label consumers … to permit this aggregation. > > > > > > *From:* rras...@gmail.com [mailto:rras...@gmail.com] *On Behalf Of *Robert > Raszuk > *Sent:* Thursday, July

Re: [spring] SPRING MPLS and Entropy Label

can be optimized to reduce number of LFIB entries. And that's it. How you use it seems just natural both on ingress as well as on the transit nodes. Best, r. On Thu, Jul 24, 2014 at 8:31 PM, Rob Shakir wrote: > Hi Robert, > > On 24 Jul 2014, at 03:21, Robert Raszuk wrote: &

Re: [spring] SPRING MPLS and Entropy Label

ssue with the lookup structure. > ​The lookup is trivial as there is no LPM needed. You simply do partial match on your mpls labels in the LFIB. thx, R. > > > > > > > *From:* rras...@gmail.com [mailto:rras...@gmail.com] *On Behalf Of *Robert > Raszuk > *Sent:* Thurs

Re: [spring] SPRING MPLS and Entropy Label

​Hi Rob,​ > ​ > It introduces a requirement, where failure detection is required, to run N > different OAM probes to be able to monitor reachability (one for each > Node-SID assigned to the remote device - even in cases where we have 1 > available path). > ​When you get today /24 IP prefix ​do y

Re: [spring] SPRING MPLS and Entropy Label

> > I don’t think this is analogous — there is only one forwarding entry for a > /24 if it has a single next-hop. With the multiple SIDs (and 1:1 SID to > label mapping) then there will be multiple LFIB entries. > ​Nope. The entire idea is to have a single LFIB entry as well. Best, r. ​ ___

Re: [spring] SPRING MPLS and Entropy Label

> > Perhaps you can expand on how an LSR programs its LFIB such that it has > multiple labels matched with a single entry please? > ​When you install a label to LFIB you also pass its depth ie number of significant bits to match on. Hardware will treat the remaining bits as "do not care". That is

Re: [spring] SPRING MPLS and Entropy Label

> - We need to check whether the top-most label is within the block of > labels that we are using for this function. > - If it is, we do a lookup based on the first N-bits to determine the > next-hop. > - if it’s not, we need to do a lookup based on the entire label. > ​Nope. Sorry. We al

Re: [spring] WGLC for draft-ietf-spring-problem-statement

Hi Alvaro, And as a co-author I support advancement of this draft. As to your explicit question "why" - It describes set of valid problems to be solved. I am not aware of any IPR related to draft-ietf-spring-problem-statement. Best regards, Robert. On Tue, Sep 23, 2014 at 8:28 PM, Alvaro Reta

Re: [spring] IPR Claims related to draft-ietf-spring-problem-statement

Hi Alvaro, I’m not aware of an IPR relating to this draft. Kind regards, r. On Tue, Sep 23, 2014 at 8:34 PM, Alvaro Retana (aretana) wrote: > Hi! > > In parallel to the WGLC for this draft, I want to formally ask the > authors (no additional contributors are listed in the latest version of t

Re: [spring] Comments on draft-filsfils-spring-segment-routing-msdc-00

Hi, While I do agree with all comments made by Bruno below I have few a bit higher level questions to the applicability of this work. 1. Assume I have CLOS non blocking DC fabric. Why would I want to complicate life by breaking full ECMP rather then utilize it as efficiently as possible ? Two u

Re: [spring] New Comments on Segment Routing(4): Challenge of Route Dependency for SR-BE Path

Hi Robin, I think your question is not applicable to SR architecture. The right SR analogy to LDP would *NOT* be hop by hop LDP like in your example, but targeted (aka directed) LDP session. In those how to get to FEC's address is just regular lookup in the RIB/FIB (global or vrf depends on use c

Re: [spring] 答复: New Comments on Segment Routing(4): Challenge of Route Dependency for SR-BE Path

fer to my inline '[Robin]'. > > > > Regards, > > Robin > > > -- > *发件人:* rras...@gmail.com [rras...@gmail.com] 代表 Robert Raszuk [ > rob...@raszuk.net] > *发送时间:* 2015年1月22日 15:46 > *收件人:* Lizhenbin > *抄送:* spring@ietf.or

Re: [spring] New Comments on Segment Routing(8): Loop Prevention and Error Handling for SR

Robin, Most if not of your observations circle around idea to use segment routing as MPLS label signalling mechanism. I do not think this is that interesting scenario. Personally I would not deploy it for such purpose of hop by hop MPLS switching. We have LDP for that. Contrary I would use SR for

Re: [spring] anycast segments and indexed SIDs

I agree. I think introducing indexes especially that they do not solve all problems is not so great of an idea. That is why I proposed a new clean complete label space for SR in draft-raszuk-mpls-domain-wide-labels. Of course an alternative is not to use mpls as a transport at all :-)) Cheers,

Re: [spring] Poll for adoption: draft-kumar-spring-sr-oam-requirement

Support. Very well written and needed piece of work. Cheers R. On Wed, Jun 10, 2015 at 5:06 PM, wrote: > Hello working group, > > > > This email starts a two-week poll on adopting > draft-kumar-spring-sr-oam-requirement as a working group item. > > “OAM Requirements for Segment Routing Network

Re: [spring] Poll for adoption: draft-litkowski-spring-sr-yang-01

Support. Best, R. On Jun 29, 2015 7:21 PM, wrote: > Hello working group, > > This email starts a two-week poll on adopting > draft-litkowski-spring-sr-yang-01 as a working group item. > "YANG Data Model for Segment Routing " > https://tools.ietf.org/html/draft-litkowski-spring-sr-yang-01 > > Ple

Re: [spring] New Version Notification for draft-filsfils-spring-large-scale-interconnect-00.txt

Hi Dennis, I have read your proposal and have one major question ... It says: "It is out of the scope of this document to describe how the SID lists are computed and programmed at the source nodes. As an example, a centralized controller could be the source of the Prefix SID allocation. The cont

Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang

Hi Les, > ​ This makes no sense to me operationally or architecturally. Fundamentally I fully agree with you. However architecturally: However at least looking at group of folks who claim that it is impossible to get same SRGB block in *any* network between two or more vendors I think Stephan

Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang

Hi Les, One additional point ... Assume I am using a virtual router with BGP module from vendor A and OSPF module from vendor B. Assume the traditinal monolithic physical or virtual router is not being used. Who and where would implement this notion of "global SRGB concept" ? How would it talk t

Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang

Hi Les, Wouldn't you agree that for Multi-topology or Multi_Instance you already need multiple SIDs ? Assuming that you support the above I find it a bit quite bizzare that you are arguing for global SRGB rather then having this explicit under protocol instance or topology. Keep in mind that sys

Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang

ther by myself or Pushpasis) that has suggested that SRGBs > are defined in a way which is outside of the operator’s control. > > > >Les > > > > > > *From:* rras...@gmail.com [mailto:rras...@gmail.com] *On Behalf Of *Robert > Raszuk > *Sent:* Tuesday,

Re: [spring] SRGBs, indexes, and topologies within a domain

Hi Peter, And in that case of smart configuration you describe is there any spring document describing how do you deal with advertisements collisions where box A topo X advertised in its smart way identical SID as equally "smart" box B in the same topo X ? It could be as simple as box with lower

Re: [spring] SRGBs, indexes, and topologies within a domain

Les, I simply were trying to politely and gently point out (in the form of the question) the problem with "smart configuration" auto picking SIDs from global block. To me there is fundamental difference in accidental or buggy collisions vs design which will likely result in such on a regular basi

Re: [spring] SRGBs, indexes, and topologies within a domain

Peter, "You can partition it in many ways, but the block is just one." As you recall mpls architecture does not have such limitation. You can have per interface overlapping label space. Likewise to me SRGB blocks for MT or MI do not need to be continuos what your earlier suggestion regarding off

Re: [spring] SRGBs, indexes, and topologies within a domain

Peter, In first sentence you say "single block" in second one you say "multiple blocks" so which one it is ? Thx, R. On Aug 25, 2015 11:25 AM, "Peter Psenak" wrote: > Robert, > > On 8/25/15 11:05 , Robert Raszuk wrote: > >> Peter, >> &

Re: [spring] SRGBs, indexes, and topologies within a domain

So as long you can also configure multiple SRGBs per node the discussion is over :) But that perhaps is a topic outside of IETF and one should express preferences directly with their vendors. Thx Peter ! R. On Aug 25, 2015 11:44 AM, "Peter Psenak" wrote: > On 8/25/15 11:36 ,

Re: [spring] SRGBs, indexes, and topologies within a domain

e both igp have congruent base topologies which such condition seems not easy to avoid if you treat block as something sitting above both of them. Thx, R. On Aug 25, 2015 12:53 PM, "Peter Psenak" wrote: > Robert, > > On 8/25/15 11:50 , Robert Raszuk wrote: > >> So a

Re: [spring] SRGBs, indexes, and topologies within a domain

Cool ... as long as I can have a freedom to run multiple instances of ISIS (one per topology) with different blocks I am happy ! Cheers, R. On Aug 25, 2015 1:19 PM, "Peter Psenak" wrote: > Robert, > > On 8/25/15 13:14 , Robert Raszuk wrote: > >> Peter, >> &g

Re: [spring] SRGBs, indexes, and topologies within a domain

Les, How do you do anycast in data plane in your proposal ? Thx, R. On Tue, Aug 25, 2015 at 9:53 PM, Les Ginsberg (ginsberg) wrote: > Robert (and Stephane) - > > > > *From:* spring [mailto:spring-boun...@ietf.org] *On Behalf Of *Robert > Raszuk > *Sent:* Tuesday, August 2

Re: [spring] SRGBs, indexes, and topologies within a domain

get complicated is when SRGBs differ. Read Pushpasis’s > draft: > https://www.ietf.org/id/draft-psarkar-spring-mpls-anycast-segments-00.txt > > > >Les > > > > > > *From:* rras...@gmail.com [mailto:rras...@gmail.com] *On Behalf Of *Robert > Raszuk > *Sent:* T

Re: [spring] SRGBs, indexes, and topologies within a domain

Peter, Your example is ok for the indexed srgb case. Yes I agree that in such case what you present seems fine. But if (as most operators I spoke with) are planning deployment of absolute srgb why would I need to introduce indexes at all to deal with per topology blocks rather then just advertise

Re: [spring] [SPRING] Query related to SR Architecture

Hi Anil, Another possibility here would be to allocate not 1 but 10 SR labels for a given segment and embed the service notion in it. For 10 services I think the scale is ok. Perhaps for 1000 services this could bring label space scaling concerns, but this is very specific to particular deployment

Re: [spring] [mpls] [SPRING] Query related to SR Architecture

​Hey Acee, ​ > In MPLS, one label is like any other label (except for the first 15 which > are reserved). I think you are missing a whole lot of context here - you > can’t just declare a new label type with different semantics. > ​That is actually quite incorrect :) We do declare new semantics

Re: [spring] [mpls] [SPRING] Query related to SR Architecture

lobal label values. Cheers, R. On Thu, Sep 10, 2015 at 8:44 PM, Acee Lindem (acee) wrote: > Hi Robert, > > On Sep 10, 2015, at 2:38 PM, Robert Raszuk wrote: > > Hey Acee, > >> >> In MPLS, one label is like any other label (except for the first 15 which >> are

Re: [spring] Query related to SR Architecture

Stefano, How SR controller is to be aware about amount of multicast traffic on a per link basis in a given network to wisely select optimal paths for unicast ? Are you advocating completely disjoined topologies for unicast and multicast ? If so it would be great to document it somewhere ... perha

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 addres

Re: [spring] [Idr] Regarding "Semantics Independent" Flowspec//答复: 答复: New draft - Flowspec Path Redirect

g is a very powerful tool. > > G/ > > From: Haoweiguo > Date: Tuesday 27 October 2015 at 03:24 > To: Gunter Van de Velde , > Lizhenbin , Gunter Van De Velde < > guntervandeveld...@icloud.com>, Robert Raszuk > Cc: "i...@ietf.org" , "spring@ietf.org

Re: [spring] [Idr] Regarding "Semantics Independent" Flowspec//答复: 答复: New draft - Flowspec Path Redirect

ng service… > > G/ > > From: on behalf of Robert Raszuk > Date: Tuesday 27 October 2015 at 10:37 > To: Gunter Van de Velde > Cc: "rt...@ietf.org" , "spring@ietf.org" , > "i...@ietf.org" , Gunter Van De Velde < > guntervandeveld...@iclo

Re: [spring] Implementation Report on draft-ietf-spring-segment-routing-ldp-interop

> The mapping server is already implemented. And it is not that complex at > all > ​Great news ! Can you send link to github containing the src code ? Thx, Robert​. ___ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring

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

Hi Stephane, > For example, if user tries to configure a BGP SRGB that > overlaps with ISIS SRGB Can you elaborate why that would be a bad thing to have two protocols advertise even not partially overlapping but identical SRGB from a given node ? Also while we are at the node doing the check dur

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

etween protocols. > > > > I agree with you that using a common SRGB for all protocols works well and > only SID conflict management in necessary in this case. > > > > Brgds, > > > > Stephane > > > > > > *From:* rras...@gmail.com [mailto:rras

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

as we > can still compute the path towards the SID (now we inherit IP path). > > -Original Message- > From: Stewart Bryant [mailto:stewart.bry...@gmail.com] > Sent: Friday, January 08, 2016 14:52 > To: LITKOWSKI Stephane SCE/OINIS > Cc: Robert Raszuk; Les Ginsberg (gin

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

Hi Eric, Why don't we go a bit further on that and consider section 3.2.3 of arch draft: 3.2.3 . IPv6 Dataplane When SR is used over the IPv6 dataplane: o The Prefix-SID is the prefix itself. ^^^

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

Les, Your draft represents a view from only a single domian perspective and a lot of wording there seems to imply that conflict resolution must be global per router and does not depend on the RIB/FIB context. Perhaps you are not considering identical SIDs to be used for example by L3VPN customer

Re: [spring] draft-ietf-spring-conflict-resolution - Policy

Hi Les Please notice that in general we have no notion of term "VPN" in protocol nor implementation. (Let's put aside vpn_id for radius authentication). What determines a VPN is intersection of import and export RTs for specific L2/3VPN case. So if you want to start relaxing the rules they must m

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

Hi Tal, > drafts seem to imply Where say in draft draft-quinn-vxlan-gpe do you see such statement that would imply that v6 NxtHdr must be only equal to 17 (UDP) and not be a pointer to any other type of extension header further followed by UDP ? Thx, R. On Mon, May 23, 2016 at 7:50 AM, Tal Miz

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

| > > > > > > There is a similar figure in draft-ietf-nvo3-geneve. > > > > Best regards, > > Tal. > > > > *From:* nvo3 [mailto:nvo3-boun...@ietf.org] *On Behalf Of *Robert Raszuk > *Sent:* Mon

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

order to avoid ambiguity, it would be great if the authors could > explicitly mention that IPv6 extension headers are permitted. > > > > Regards, > > Tal. > > > > *From:* rras...@gmail.com [mailto:rras...@gmail.com] *On Behalf Of *Robert > Raszuk > *Sent:* M

Re: [spring] [Idr] New draft for data center gateways

Hi Adrian, Many thx for sharing the document. Just starting to read it one assertion repeated at least twice got my attention: "Segment routing (SR) [I-D.ietf-spring-segment-routing] is a popular protocol mechanism for operating within a DC" By "popular protocol mechanism" when building non bloc

Re: [spring] [Idr] New draft for data center gateways

- Example: LISP. Not sure if we need additional flat protocol extensions here. On Mon, May 23, 2016 at 8:14 PM, Robert Raszuk wrote: > Hi Adrian, > > Many thx for sharing the document. Just starting to read it one assertion > repeated at least twice got my attention: > > "Segment

Re: [spring] [Idr] New draft for data center gateways

Hi John, *[JD] We were assuming that a) GW/backbone links would be advertised in > BGP LS (optionally w/ EPE) and b) a GW that is disconnected from the > backbone does not advertise an auto-discovery route. This will be made > explicit in the next revision. * > ​Ad a) - EPE works fine with nex

Re: [spring] [Idr] New draft for data center gateways

nstead of tunnel encapsulation attribute. On Tue, May 24, 2016 at 11:27 PM, Robert Raszuk wrote: > Hi John, > > *[JD] We were assuming that a) GW/backbone links would be advertised in >> BGP LS (optionally w/ EPE) and b) a GW that is disconnected from the >> backbone

Re: [spring] New draft for networking request for comments and look for interested people, thank you.

Hi Tan, I have read your proposal and to me it looks an attempt to reinvent vanilla RSVP Int-Serv in 80% of your document. The remaining 20% is ability to map such signalling to SR segments at each hop which may perhaps be something SPRING could consider to look at. Not sure. However before even

  1   2   3   4   5   6   >