Re: [spring] Spring protection - determining applicability

[Greg Mirsky <[e-mail]>]

Hi Andrew,
thank you for your expedient response. I understand why operators are using
S-BFD to monitor the continuity of p2p SR-MPLS tunnel. But I'd note that
S-BFD does not support monitoring of multicast trees, ones that now can be
realized using the Replication SID defined in
draft-voyer-spring-sr-replication-segment
<https://tools.ietf.org/html/draft-voyer-spring-sr-replication-segment-02>.
But that can be achieved using RFC 8563
<https://tools.ietf.org/html/rfc8563>. Multicast and Composite polling
methods might not provide the required defect detection by the head of the
multicast tree. There's a faster option mentioned in RFC 8563, Unsolicited
notification. Applicability of the Unsolicited mode to SR-MPLS is described
in draft-mirsky-spring-bfd
<https://datatracker.ietf.org/doc/draft-mirsky-spring-bfd/?include_text=1>.

Regards,
Greg

On Mon, Aug 3, 2020 at 5:05 PM Andrew Alston <
[e-mail]> wrote:

> Greg we effectively get this using sbfd and fall back paths at the moment
> – far from ideal – but it does work.
>
>
>
> There are also other methods of detecting end to end reachability to do
> blackhole detection etc – particularly in the face of the fact that I’ve
> yet to see a functional implication of the sid verification flag.
>
>
>
> Could things be improved this regard? 100% but for now – the deep seated
> and critical need for the requirement overrides the drawbacks of the
> protection mechanisms we are forced to use at this point
>
>
>
> Andrew
>
>
>
>
>
> *From:* Greg Mirsky <[e-mail]>
> *Sent:* Tuesday, 4 August 2020 01:40
> *To:* Andrew Alston <[e-mail]>
> *Cc:* Joel M. Halpern <[e-mail]>; Robert Raszuk <
> [e-mail]>; [e-mail]
> *Subject:* Re: [spring] Spring protection - determining applicability
>
>
>
> Hi Andrew,
>
> would such requirements support using e2e protection?
>
>
>
> Regards,
>
> Greg
>
>
>
> On Mon, Aug 3, 2020 at 2:46 PM Andrew Alston <
> [e-mail]> wrote:
>
> So –
>
>
>
> One of the use cases, in fact, some very major use cases in any spring
> technology for us revolve around the following
>
>
>
> a.      The explicit avoidance of certain nodes
>
> b.      The explicit avoidance of certain sections of the network
>
>
>
> Anything that could result in that explicit avoidance being violated –
> would create, shall we say significant problems.
>
>
>
> Much of the use case is not a case of which nodes the packets flow through
> – but rather – which nodes / network segments it can never touch or flow
> through.  Effectively, to be used as a technology to avoid certain things
> for specific reasons.
>
>
>
> This is also one of the reasons for needing such deep label stacks – this
> kind of detailed path programming tends to deepen the stack because you
> sometimes have to be pretty explicit.
>
>
>
> It is absolutely critical to us that this functionality is there – and
> that we can avoid situations which could cause traffic to accidently hit
> things explicitly avoided.
>
>
>
> I wish I could be more specific than this, but it is what it is.
>
>
>
> Thanks
>
>
>
> Andrew
>
>
>
>
>
> *From:* spring <[e-mail]> *On Behalf Of *Joel M. Halpern
> *Sent:* Monday, 3 August 2020 21:36
> *To:* Robert Raszuk <[e-mail]>
> *Cc:* [e-mail]
> *Subject:* Re: [spring] Spring protection - determining applicability
>
>
>
> (Since the thread has gotten long enough, reiterating that this is as a
> participant, not a WG chair.)
>
> Yes, we are talking IP networks. And yes, I have seen IP networks that
> choose to drop packets. For all sorts of reasons.
> I think there are likely other reasons why one may not want a random
> path rather than a chosen TE path. I think it is important we be clear
> about what constraints may be / are violated when we tell people they
> have this tool (protective rerouting) that is intended to preserve QoS.
>
> Let's be clear. I am not arguing that this is not a good idea. It is a
> good idea. And useful. I am trying to figure otu what combination of
> additional mechanisms and clear descriptions will lead to everyone
> getting the behavior they expect (which may not be the behavior they
> desire, but sometimes is the best we can do.)
>
> Yours,
> Joel
>
> On 8/3/2020 2:30 PM, Robert Raszuk wrote:
> > Joel,
> >
> > Are we still talking about IP networks here ? Or perhaps some hard
> > slicing with real resource reservations or detnets ?
> >
> > Because if we are talking about IP networking I have two observations:
> >
> > A) If you need to traverse via a specific node (ie. firewall) you better
> > apply IP encapsulation to that node. I don't think IP encapsulation can
> > be hijacked today such that destination address of the packet is ignored.
> >
> > B) Have you seen any IP network where upon topology change (link or node
> > failure) you suddenly start dropping flows in spite of SPT offering
> > perhaps few ms longer path with 10 ms more jitter ?
> >
> > Or are some SR marketing slides promise to turn IP networks in
> > something new ? Worse ... do they mention path quality guarantees,
> > resource reservations ? I hope not.
> >
> > Thx,
> > R.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On Mon, Aug 3, 2020 at 8:10 PM Joel M. Halpern <[e-mail]
> <[e-mail]%20%0b>> <mailto:[e-mail]
> <[e-mail]>>> wrote:
> >
> > Well less serious for TE SIDs, I am not sure the problem is restricted
> > to just service SIDs.
> >
> > Suppose that the PCE has specified the path to meet some complex te
> > objective.  The bypass node has no way of knowing what those
> > constraints
> > were.  And for some kinds of traffic, it is better to drop the packet
> > than to deliver it outside the envelop.  I suspect that the right
> > answer
> > to this is "too bad".  If so, as with the distinction regarding service
> > nodes, we should say so, shouldn't we?
> >
> > 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: [phone]
> > >
> > > Cell:      [phone]
> > >
> > > Email: [e-mail]
> > <mailto:[e-mail]
> <[e-mail]>>
> > >
> > > -----Original Message-----
> > > From: spring <[e-mail]
> <[e-mail]%0b>> <mailto:[e-mail]
> <[e-mail]>>> On Behalf Of Mach Chen
> > > Sent: Monday, August 3, 2020 6:30 AM
> > > To: Joel M. Halpern <[e-mail]
> <[e-mail]%0b>> <mailto:[e-mail]
> <[e-mail]>>>; [e-mail] <mailto:[e-mail]
> <[e-mail]>>
> > > 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:[e-mail]
> > <mailto:[e-mail]>
> <[e-mail]%0b%3e%20%3cmailto:[e-mail]%3e>]
> On Behalf Of Joel M.
> > >
> > >  > Halpern
> > >
> > >  > Sent: Monday, August 3, 2020 7:51 AM
> > >
> > >  > To: [e-mail] <mailto:[e-mail] <[e-mail]>>
> > <mailto:[e-mail] <mailto:[e-mail]
> <[e-mail]%20%3cmailto:[e-mail]>>>
> > >
> > >  > 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
> > >
> > >  > [e-mail] <mailto:[e-mail] <[e-mail]>>
> > <mailto:[e-mail] <mailto:[e-mail]
> <[e-mail]%20%3cmailto:[e-mail]>>>
> > >
> > >  >
> > >
> > https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=https%3A%2
> > >
> > <
> https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=https%3A%252>
> > >
> > >  > F%2Fwww.ietf.org
> > <http://2Fwww.ietf.org>%2Fmailman%2Flistinfo%2Fspring
> > >
> > > _______________________________________________
> > >
> > > spring mailing list
> > >
> > > [e-mail] <mailto:[e-mail] <[e-mail]>> <
> mailto:[e-mail]
> <[e-mail]%0b>> <mailto:[e-mail] <[e-mail]>>>
> > >
> > >
> >
> 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
> > > [e-mail] <mailto:[e-mail] <[e-mail]>>
> > > https://www.ietf.org/mailman/listinfo/spring
> > >
> >
> > _______________________________________________
> > spring mailing list
> > [e-mail] <mailto:[e-mail] <[e-mail]>>
> > https://www.ietf.org/mailman/listinfo/spring
> >
>
> _______________________________________________
> spring mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spring
>
> _______________________________________________
> spring mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spring
>
>