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

resending with reduced number of recipients. Cheers, Jeff Sasha, Don’t forget – RSVP-TE FRR has explicit signaling and state associated with it, as well as well defined state transitions, SR on contrary doesn’t. Changes in topology (link/node down events) are not communicated back

[spring] Number of email recipients is limited to 9

Hi all, For your information, the number of email recipients for messages sent to the SPRING mailing list is limited. The limit seems to be 9. If you don't want your email to be delayed, you should restrict to this limit. Otherwise, note that the delay may be significant as human intervention

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

Muthu, Again lots of thanks for a prompt response. We seem to agree on the following points: · In SR some failures cannot be handled by local protection (actually, there is an expired draft that defines how this could be done, but it introduces serious complexity) · Combining

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

Muthu, Two points: 1. There are no infinite loops in Layer 3 networks because they use TTL (or Hop Count) to break them. However, real loops (which do not exist in your scenario) result in blackholoing and hence must be avoided 2. Local protection is typically employed in the

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

Rob, Lots of thanks for a prompt response. Two comments: 1. I fully agree with you that use cases drafts should not be exhaustive. But from my POV they should not be prohibitive (or be interpreted as prohibitive) either, exactly because “Operators can, and will continue to, deploy

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

Sasha, On Tue, May 16, 2017 at 4:29 PM, Alexander Vainshtein < alexander.vainsht...@ecitele.com> wrote: > Muthu, > > An additional clarification: > > · If the link BC were OK, B could pop B from the stack and send > packets to C with just D in the stack > > · When the link BC

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

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

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

Sasha, On Tue, May 16, 2017 at 4:11 PM, Alexander Vainshtein < alexander.vainsht...@ecitele.com> wrote: > Muthu, > > Again lots of thanks for a prompt response. I still do not think a loop > would really form because: > > · A sends packet to its local next hop for B with the stack (B, >

Re: [spring] Mail regarding draft-ietf-spring-conflict-resolution

> -Original Message- > From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Eric C Rosen > Sent: Friday, May 12, 2017 3:51 PM > To: Alexander Vainshtein; Les Ginsberg (ginsberg); Shraddha Hegde; > draft-ietf-spring- > conflict-resolut...@ietf.org > Cc: spring@ietf.org >

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

Stefano, Lots of thanks for a prompt response. I will borrow the quantum mechanics terminology that differentiates between pure and mixed (a.k.a. superposition) states of a quantum system. As long as "mixed" use cases are not strictly prohibited in the draft (and this was at least one

Re: [spring] Mail regarding draft-ietf-spring-conflict-resolution

Hi all, I concur with Eric, and I would like to mention yet another (albeit similar) use case where PHP MUST NOT be used with SR LSPs. RFC 8104 describes the PW egress endpoint protection mechanism that uses bypass tunnels between the PLR and the

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

Muthu, An additional clarification: · If the link BC were OK, B could pop B from the stack and send packets to C with just D in the stack · When the link BC fails, B will leave the stack as (CD) IMHO – it would be just trying to bypass the failed link BC. · If the

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

Muthu, Again lots of thanks for a prompt response. I still do not think a loop would really form because: · A sends packet to its local next hop for B with the stack (B, C, D) · B receives this packet with the stack (C, D), but the link C has failed. So B sends to its next hop

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

On Tue, May 16, 2017 at 3:27 PM, Alexander Vainshtein < alexander.vainsht...@ecitele.com> wrote: > Muthu, > > Lots of thanks for a prompt response. > > > > I do not think that the loop you have described would actually appear in > the scenario you’ve described. > > > > To the best of my

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

Stephane, Lots of thanks for a prompt response and an interesting clarification. My understanding of this clarification is that the text in question describes the following scenario: 1. “Shortest SR paths” exist (to the best of my understanding they always exist in SR) but do not require

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

Using end-to-end path protection together with local protection can result in traffic loops. Consider the foll. topology: B-C |/ \ | / \ | / \ | / \D+ A/ Z (CE) \ F+ \ / \ / \ / \E/ - All links are of equal cost. - A,

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

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

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

Hi Sasha, You said: "Path protection cannot be applied to shortest traffic paths so they must rely on local protection" What makes you think that way ? Only one specific use case of SR is TE. And could even argue that it is not the most important one. Adding protection to shortest traffic

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

Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: alexander.vainsht...@ecitele.com From: Alexander Vainshtein Sent: Tuesday, May 16, 2017 11:28 AM To: 'Stefano Previdi (sprevidi)' Cc: draft-ietf-spring-resliency-use-ca...@ietf.org; spring@ietf.org;

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

Stefano, Lots of thanks for a prompt response. A couple of short comments if you do not mind: Using 2119 language in a "use cases" document: 1. Going back to the source I see that “MUST NOT… mean that the definition is an absolute prohibition of the specification” 2. I agree

[spring] Requirements towards OAM in Segment Routing network

Dear Authors, I'd like to bring your attention to the WG document OAM Requirements for Segment Routing Network . I think that many requirements listed in your document are common requirements for OAM in Segment Routing network