Re: [spring] Spring protection

What I am hearing is that we all know there is an issue here, but the 
documents do not connect the dots?

Yours,
Joel

On 8/3/2020 2:36 AM, Alexander Vainshtein wrote:
> Mach, Joel and all,
> 
> I think that in most cases:
> 
> 1.There is clear differentiation between "topological" and "service" 
> instructions in SID advertisements. E.g.:
> 
> oIGP Prefix Node SIDs IGP Adj-SIDs (identified as such in the 
> corresponding IGP advertisements) represent topological instructions
> 
> oService SIDs for SRv6 (see SRv6 BGP-Based Overlay Services 
> <https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-04> 
> draft) unsurprisingly represent “service” instructions
> 
> 2.Segments that represent topological instructions can be bypassed, 
> while segments that represent service instructions require alternative 
> protection mechanisms.
> 
> This view seems to be aligned with RFC 8402 
> <https://tools.ietf.org/html/rfc8402> that says in Section 1:
> 
>     In the context of an IGP-based distributed control plane, two
> 
> topological segments are defined: the IGP-Adjacency segment and the
> 
>     IGP-Prefix segment.
> 
>     In the context of a BGP-based distributed control plane, two
> 
> topological segments are defined: the BGP peering segment and the
> 
>     BGP-Prefix segment.
> 
> In the case of SR-MPLS this differentiation is assumed in Section 3.4 of 
> the Node Protection for SR-TE Path 
> <https://datatracker.ietf.org/doc/html/draft-hegde-spring-node-protection-for-sr-te-paths-07#section-3.4> 
> draft that says:
> 
>     The node protection mechanism described in the previous sections
> 
>     depends on the assumption that the label immediately below the top
> 
> label in the label stack is understood in the IGP domain.  When the
> 
>     provider edge routers exchange service labels via BGP or some other
> 
>     non-IGP mechanism the bottom label is not understood in the IGP
> 
>     domain.
> 
>     The egress node protection mechanisms described in the draft
> 
>     [RFC8679 <https://datatracker.ietf.org/doc/html/rfc8679>] is 
> applicable to this use case and no additional changes
> 
>     will be required for SR based networks
> 
> The scenarios in which  differentiation between “topological” and 
> “service” instructions is broken are indeed problematic. E.g., consider 
> the use case in which a Node SID in the ERO of a SR-TE path identifies a 
> node that acts as a firewall for all packets it receives, i.e., provides 
> the firewall service without any dedicated service SID identifying it. 
> One could say that the Node SID of such a node would combine topological 
> and service instructions thus breaking the differentiation between the two.
> 
> I am not sure if usage of such “combined” SIDs could be prevented or at 
> least discouraged.
> 
> If not, providing an ability to identify such SIDs in the advertisement 
> mechanisms would be useful IMHO.
> 
> My 2c,
> 
> Sasha
> 
> Office: +972-39266302
> 
> Cell:      +972-549266302
> 
> Email:   Alexander.Vainshtein@ecitele.com
> 
> -----Original Message-----
> From: spring <spring-bounces@ietf.org> On Behalf Of Mach Chen
> Sent: Monday, August 3, 2020 6:30 AM
> To: Joel M. Halpern <jmh@joelhalpern.com>; spring@ietf.org
> Subject: Re: [spring] Spring protection - determining applicability
> 
> Hi Joel,
> 
> I think this is a good point that may not be discussed in the past. And 
> I also don't think there is a "can be bypassed" indication in the 
> routing advertisement for now.
> 
> IMHO, the information advertised by routing is neutral, such information 
> (can or cannot be bypassed) is more path specific, thus normally the 
> controller should be responsible for deciding whether/which SID can be 
> bypassed.
> 
> Best regards,
> 
> Mach
> 
>  > -----Original Message-----
> 
>  > From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Joel M.
> 
>  > Halpern
> 
>  > Sent: Monday, August 3, 2020 7:51 AM
> 
>  > To: spring@ietf.org <mailto:spring@ietf.org>
> 
>  > Subject: [spring] Spring protection - determining applicability
> 
>  >
> 
>  > (WG Chair hat Off, this is merely a note from a slightly confused WG
> 
>  > participant.)
> 
>  >
> 
>  > I have been reading the various repair drafts, and the various
> 
>  > networks programming and service programming draft, and I am trying to
> 
>  > figure out one aspect of the combination.
> 
>  >
> 
>  > How does a node that is doing some form of bypass (suppose, for
> 
>  > simplicity, it is Node N2 deciding to bypass the next SID for a failed
> 
>  > node N3) know that it is safe to do so?
> 
>  >
> 
>  > If the path was just for TE, then it is "safe" if the new path meets
> 
>  > the TE criteria.  or maybe it is safe if it is even close, as long as
> 
>  > it is not used for too long.
> 
>  >
> 
>  > But what if the node were a Firewall, included to meet legal 
> requirements?
> 
>  > Or was some other necessary programmatic transform (wince we are
> 
>  > deliberately vague about what nodes can do when asked suitably.)
> 
>  >
> 
>  > Is there some "can be bypassed" indication in the routing
> 
>  > advertisements that I missed?
> 
>  >
> 
>  > Thank you,
> 
>  > Yours,
> 
>  > Joel
> 
>  >
> 
>  > _______________________________________________
> 
>  > spring mailing list
> 
>  > spring@ietf.org <mailto:spring@ietf.org>
> 
>  > 
> https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=https%3A%2 
> <https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=https%3A%252>
> 
>  > F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
> 
> _______________________________________________
> 
> spring mailing list
> 
> spring@ietf.org <mailto:spring@ietf.org>
> 
> https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
> 
> 
> 
> ------------------------------------------------------------------------
> Notice: This e-mail together with any attachments may contain 
> information of Ribbon Communications Inc. that is confidential and/or 
> proprietary for the sole use of the intended recipient. Any review, 
> disclosure, reliance or distribution by others or forwarding without 
> express permission is strictly prohibited. If you are not the intended 
> recipient, please notify the sender immediately and then delete all 
> copies, including any attachments.
> ------------------------------------------------------------------------
> 
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
> 