Re: [spring] Kathleen Moriarty's Discuss on draft-ietf-spring-segment-routing-13: (with DISCUSS)

Kathleen: Hi! Any thoughts on the update to this document? Thanks! Alvaro. On December 20, 2017 at 6:42:02 PM, Les Ginsberg (ginsberg) ( ginsb...@cisco.com) wrote: Kathleen - Thanx for the review. V14 has been published and it attempts to address the Security concerns raised by you and

Re: [spring] Alissa Cooper's Discuss on draft-ietf-spring-segment-routing-13: (with DISCUSS and COMMENT)

Alissa: Hi! Any thoughts on the update to this document? Thanks! Alvaro. On December 20, 2017 at 6:18:13 PM, Les Ginsberg (ginsberg) ( ginsb...@cisco.com) wrote: Alissa - Thanx for the review. V14 has been published and it attempts to address the Security concerns raised by you and others.

Re: [spring] [Dcrouting] draft-przygienda-rift-03

A. Reading the draft you'll find the overload bit on RIFT which IMO is the best out-of-production solution. B. Depends what your LEAF is. If LEAF is your TOR (most stuff today) then RIFT will do that just fine using LEAF2LEAF procedures in fact. If we start to run RIFT @ the server level then we'd

Re: [spring] [Dcrouting] draft-przygienda-rift-03

Hi Tony, Thx for elaborating ... Two small comments: A) SID/SR use case in underlay could be as simple as gracefully taking a fabric node out of service. Not much OPEX needed if your NMS is decent. Otherwise in normal link state I can do overload bit, in BGP number of solutions from shutdown to

Re: [spring] Mirja Kühlewind's Discuss on draft-ietf-spring-segment-routing-msdc-08: (with DISCUSS and COMMENT)

I'm not able to be on this week's discussion (in China, going back to bed now), but if I support Mirja's Discuss on 7.1 and 7.2. For what that's worth. Do the right thing, of course. Spencer On Thu, Jan 11, 2018 at 8:41 AM, Mirja Kühlewind wrote: > Mirja Kühlewind has

Re: [spring] [Dcrouting] draft-przygienda-rift-03

Having said that there are interesting use cases we talk of "some binding per node" but that's more of a KV store corner where people think it's very useful to have the spines pushing stuff down to all nodes or (at cost of stability) having a node push some stuff up that gets pushed down to all

Re: [spring] [Dcrouting] draft-przygienda-rift-03

Robert, productive points, thanks for raising them ... I go a bit in depth 1. I saw no _real_ use-cases for SID in DC so far to be frank (once you run RIFT). The only one that comes up regularly is egress engineering and that IMO is equivalent to SID=leaf address (which could be a HV address of

[spring] Mirja Kühlewind's Discuss on draft-ietf-spring-segment-routing-msdc-08: (with DISCUSS and COMMENT)

Mirja Kühlewind has entered the following ballot position for draft-ietf-spring-segment-routing-msdc-08: 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

[spring] Benoit Claise's No Objection on draft-ietf-spring-segment-routing-msdc-08: (with COMMENT)

Benoit Claise has entered the following ballot position for draft-ietf-spring-segment-routing-msdc-08: 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.)

[spring] draft-przygienda-rift-03

Hi, I have one little question/doubt on scalability point of RIFT ... Assume that someone would like to signal IPv6 prefix SID for Segment Routing in the underlay within RIFT. Wouldn't it result in amount of protocol state in full analogy to massive deaggregation - which as of today is designed