*//*
There are some other comments I have on the draft, but I do not
see them as an obstacle for WG adoption.
Ahmed: Thanks a lot again
Regards,
Sasha
Office: +972-39266302
Cell: +972-549266302
Email: [email protected]
<mailto:[email protected]>
*From:*rtgwg [mailto:[email protected]] *On Behalf Of *Robert
Raszuk
*Sent:* Tuesday, May 29, 2018 12:03 PM
*To:* Chris Bowers <[email protected]> <mailto:[email protected]>
*Cc:* [email protected] <mailto:[email protected]>;
[email protected] <mailto:[email protected]>;
[email protected]
<mailto:[email protected]>;
[email protected] <mailto:[email protected]>; [email protected]
<mailto:[email protected]>
*Subject:* Re: Request for RTGWG Working Group adoption for
draft-bashandy-rtgwg-segment-routing-ti-lfa
Hi Chris,
I am afraid you have it completely backwards :)
Current status of the document is individual submission and it is
up to the authors to decide what is and what is not in the scope
of their work. It can't be that anyone asking for scope extension
can block the work or even WG adoption call by throwing the stones
at it. That would be pretty insane.
Now once the doc is accepted as working group document its
ownership transitions from given set of authors to WG and indeed
WG could ask to extend or narrow the scope. Again WG not an
individual.
For me (a WG member) the document looks good as is and should
proceed fast since it addresses very important technology gap. I
do sincerely hope that any attempt to derail it or stretch it so
much that it will break will be stopped by WG chairs and ADs.
Best,
Robert.
On Tue, May 29, 2018 at 1:30 AM, Chris Bowers
<[email protected] <mailto:[email protected]>> wrote:
Ahmed,
Several participants in the WG (including Stewart) have
provided feedback requesting that the draft address particular
issues.
The response you have provided to this feedback is that these
issues are out-of-scope for the draft, so they will not be
addressed.
I have seen no change in the text of the draft to incorporate
this feedback.
It is up to the working group to decide what is the scope of a
document it works on. I do not think that it would be productive
to conduct a poll for WG adoption until the scope of the draft
is broadened to address the feedback that has already been
provided.
Chris
*From:* Jeff Tantsura <[email protected]
<mailto:[email protected]>>
*Sent:* Monday, May 28, 2018 4:27 PM
*To:* Ahmed Bashandy <[email protected]
<mailto:[email protected]>>; [email protected]
<mailto:[email protected]>; Stewart Bryant
<[email protected] <mailto:[email protected]>>
*Cc:* [email protected]
<mailto:[email protected]>;
[email protected]
<mailto:[email protected]>; [email protected]
<mailto:[email protected]>; [email protected]
<mailto:[email protected]>; [email protected]
<mailto:[email protected]>;
[email protected]
<mailto:[email protected]>; [email protected]
<mailto:[email protected]>; [email protected]
<mailto:[email protected]>
*Subject:* Re: Request for RTGWG Working Group adoption for
draft-bashandy-rtgwg-segment-routing-ti-lfa
Hi Ahmed,
I’m awaiting Stewart’s response.
Thanks!
Cheers,
Jeff
*From: *Ahmed Bashandy <[email protected]
<mailto:[email protected]>>
*Date: *Monday, May 28, 2018 at 13:59
*To: *Jeff Tantsura <[email protected]
<mailto:[email protected]>>, rtgwg-chairs
<[email protected] <mailto:[email protected]>>
*Cc: *<[email protected]
<mailto:[email protected]>>,
<[email protected]
<mailto:[email protected]>>, <[email protected]
<mailto:[email protected]>>, <[email protected]
<mailto:[email protected]>>, <[email protected]
<mailto:[email protected]>>,
<[email protected]
<mailto:[email protected]>>, <[email protected]
<mailto:[email protected]>>, RTGWG <[email protected]
<mailto:[email protected]>>
*Subject: *Re: Request for RTGWG Working Group adoption for
draft-bashandy-rtgwg-segment-routing-ti-lfa
Hi Jeff
All comments have been addressed as shown in the email below
Can we initiate the WG adoption
Ahmed
On 5/19/18 12:20 PM, Ahmed Bashandy wrote:
Hi Jeff
These comments are already addressed with the exception of
the minor comment about section 5.3.1 and 5.3.2. But for
the convenience of everyone, I will respond to each
specific comment here
See "#Ahmed" below
Thanks
Ahmed
> Reviewer: Stewart Bryant
> Review result: Has Issues
>
> These review comments were incorrectly posted against the uloop
draft,
> apologies for any confustion.
>
> I have been asked to perform an early review of this document on
> behalf of the Routing Directorate.
>
> Summary:
>
> A document on this subject is something that the WG should
publish,
> but I think that there are number of issues that the WG need to
> discuss and reach consensus on before deciding whether or not they
> should adopt this draft as a starting point for that work.
>
>
> Major Issues:
>
> Before I get into the substance I am surprised that there are no
IPR
> disclosures. In an earlier and related work
> (draft-francois-segment-routing-ti-lfa-00) there were three IPR
> disclosures.
#Ahmed
The IPR link is
https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-bashandy-rtgwg-segment-routing-ti-lfa
<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_ipr_search_-3Fsubmit-3Ddraft-26id-3Ddraft-2Dbashandy-2Drtgwg-2Dsegment-2Drouting-2Dti-2Dlfa&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=mIF18ha_B3lsg_QPPZ0uZE5Mp5Q7LXQIPJHrP9QhvL4&m=hRw9JYX16QjABo0X8NzFeA4qtZ406HEzUaYNGbxzzGQ&s=i0BSrEO9trtQg-svJmisngedg7C2ALPRCMA49HKC8Jg&e=>
If there is anything else for us to do regarding IPR I will be more
than happy to take care of
>
> The work has four basic components, the concept of resolving the
> problem of P and Q being non-adjacent, the use of SR to solve the
> non-adjacency, the use of the post convergence path following
failure
> and the applicability of these techniques to an SR network. The
first
> and second points seem of utility in non-SR networks, and so I am
> surprised that they are not called out as such, in the first case
> perhaps with consideration to strategically places RSVP tunnels,
or
> binding segments.
The draft already mentions that the work builds on top of existing
FRR work. For example
the second statement of the abstract already says
builds on proven IP-FRR concepts being
LFAs, remote LFAs (RLFA), and remote LFAs with directed
forwarding
(DLFA).
The statement about the possibility of using RSVP is clearly
outside the scope of document as mentioned in first paragraph of the
introduction.
>
> The issue of mapping repair path to the post convergence path to
the
> something that has always concerned me in this concept. It is true
> that traffic that always passes through the PLR will experience
the
> properties the authors describe, but not all traffic will pass
through
> the PLR post convergence. The post failure path will be topology
> dependent, and may take a different path from the point of
ingress.
#Ahmed
The fourth paragraph in the introduction clearly mentions that we
are protecting the traffic passing through the PLR.
>
> I am also concerned that the authors do not discuss the need for
loop
> free convergence, since although traffic going through the repair
path
> will be loop-free, traffic arriving at the PLR might not be..
Consider
> for example a topology fragment that looks like a clock with a
router
> at each minute. Traffic enters at 9 o'clock, leave at 3 o'clock
and
> goes via 12 o'clock and 12 o'clock fails. The routers 9..12 will
> re-converge at different times and this may give rise to the
> micro-looping of traffic trying to get to the PLR. A summary of
the
> problem and a pointer to the companion draft may be sufficient.
#Ahmed
The last statement in the first paragraph in the introduction
refers the reader to the uloop avoidance draft which handles non-local failures
>
> Finally on the basic concept it would be good to state up from
whether
> the proposal is constrained solely to SR networks, or whether the
> authors believe that the concept is of wider applicability. It
see no
> reason why it would be constrained to only work on SR networks.
#Ahmed
As it is quite clear from the title of the draft as well as many
statements inside it, the scope of document is restricted to segment routing.
>
> There is no discussion of multiple failures, nor as far as I can
see
> of failures that are worse than anticipated. This is an important
> point that needs to be established early. Some methods, (MRT)
> intrinsically address multiple failures, others (NV) intrinsically
> exclude them. Simple LFA needs a supervisor to quickly abandon all
> hope when they occur.
#Ahmed
As specified in the 3rd paragraph of the introduction the scope of
the document is limited to single link, single node, and single local SRLG
failure.
>
> In an SR network the paths used are not the shortest paths, they
are a
> collection of shortest paths, so there needs to be some
discussion on
> the interaction between the SR paths and repair paths to consider
> whether it is unconditionally safe against forwarding loops.. It
would
> presumably be so if the authors borrowed the concept of repair
> addresses rather than normal forwarding addresses from not-via,
but I
> don't think they have done this.
#Ahmed
Again the second statement of the 1st paragraph of the Introduction
says
By relying on segment routing this document provides
a local repair mechanism for standard IGP shortest path
So the scope of the document is quite clear
>
> There should also be some discussion on the original path
constraints
> that are applicable to the repair. Presumably the ingress node
> constrained the traffic to go though failed node F for a reason.
If
> the repair is unconstrained that reason could be violated, but
this is
> not discussed in the text.
#Ahmed
Same response as the response to the previous comment. The scope is
standard IGP shortest paths
>
>
> In the Security section you say:
>
> The behavior described in this document is internal
functionality
> to a router that result in the ability to guarantee an upper
bound
> on the time taken to restore traffic flow upon the failure of
a
> directly connected link or node. As such no additional
security
> risk is introduced by using the mechanisms proposed in this
> document.
>
>
> SB> I am not sure that the above is correct. There may be a
security
> reason
> SB> why a packet was steered along a path which breaks when you
use
> this
> SB> technique.
#Ahmed
The security consideration section has been modified to to indicate
that
the traffic is being steered over the post convergence path and
hence there
is no security risk because this is the path that the operator
intended to use
after the failure through the metrics configured on the links. In
fact by expediting
rerouting the traffic over the intended post convergence path
without waiting
for IGP reconvergence, we have introduced a minor security
enhancement by reducing
misforwarding and/or traffic drop
>
> In the conclusion you say:
>
> The
> mechanism is able to calculate the backup path irrespective
of the
> topology as long as the topology is sufficiently redundant.
>
>
> SB> That is certainly true in classic. I am not sure this is
> universally
> SB> true under SR which includes the use of non-shortest path and
> SB> binding segments.
#Ahmed
Again the document is restricted to IGP shortest path as mentioned
in the introduction
> Minor issues:
>
> For each destination in the network, TI-LFA prepares a
data-plane
> switch-over to be activated upon detection of the failure of a
> link used to reach the destination.
>
> SB> To make the scaling clearer to the reader, I think you need
> SB> to make it clear that for each protected link, you determine
> SB> the repair needed to reach every destination reachable over
that
> SB> link. You sort of say that, but it's a bit hidden.
#Ahmed
I do not understand the difference between the text in the draft
and the
text that you are proposing. We think that our text is quite clear
> We provide the TI-LFA approach that achieves guaranteed
coverage
> against link, node, and local SRLG failure, in any IGP
network,
> relying on the flexibility of SR.
>
> SB> Should that be any SINGLE link.... failure?
#Ahmed
As mentioned above few times above, the introduction clearly
mentions *single*
> In the text (and the text that follows)
>
> To do so, S applies a "NEXT" operation on Adj(S-F) and then
two
> consecutive "PUSH" operations: first it pushes a node segment
for
> F,
> and then it pushes a protection list allowing to reach F while
> bypassing S-F.
>
> You need to reference the SR operations.
#Ahmed
This paragraph is in Section 5.2.1. The latest version refers to
the SR draft
>
> Also you are considering Adj segments, and presumably they were
there
> for a reason, but you do not discuss that.
#Ahmed
Section 5.2 discusses protecting adjacency segments
>
> In 5.3.1 and 5.3.2 you have a list of conditions, but do not make
it
> clear whether any or all must be true.
>
#Ahmed
The intention is for all of the conditions to be true. I will make
it clear in the next version
> Nits
>
> 1. Introduction
>
> Segment Routing aims at supporting services with tight SLA
> guarantees [1]. This document provides a local repair
mechanism
> relying on SR-capable of restoring end-to-end connectivity in
the
> case of a sudden failure of a network component.
>
> SB> Grammar needs a little work in the last sentence.
#Ahmed
Addressed in the latest version of the document
> In Fig 1, I assume that the blobs are network fragments.
>
> In the conclusion you say:
> This document proposes a mechanism that is able to
pre-calculate a
> backup path for every primary path so as to be able to protect
> against the failure of a directly connected link or node.
> SB> you need to add SRLG
#Ahmed
Addressed in the latest version of the draft
On 5/10/18 9:40 AM, Jeff Tantsura wrote:
Hi Ahmed,
We would like you to address the comments from Early Review and
get OK from Stewart, before progressing the document
https://datatracker.ietf.org/doc/review-bashandy-rtgwg-segment-routing-ti-lfa-00-rtgdir-early-bryant-2017-05-31/
<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_review-2Dbashandy-2Drtgwg-2Dsegment-2Drouting-2Dti-2Dlfa-2D00-2Drtgdir-2Dearly-2Dbryant-2D2017-2D05-2D31_&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=mIF18ha_B3lsg_QPPZ0uZE5Mp5Q7LXQIPJHrP9QhvL4&m=hRw9JYX16QjABo0X8NzFeA4qtZ406HEzUaYNGbxzzGQ&s=xMxNv--9p-MRxL0OnPyOZs76OvnidWNl7oTWWXG7B3g&e=>
Please let us know when this could be done.
Cheers,
Jeff
On 4/25/18, 02:17, "Ahmed Bashandy"<[email protected]>
<mailto:[email protected]> wrote:
Hi
We would like to request the WG adoption of
draft-bashandy-rtgwg-segment-routing-ti-lfa-04.
The draft has been stable for a long while and the IPR
declaration has
been recorded
The latest version addresses all comments and the draft
has been
presented in IETF-96 and IETF-99
Thanks
Ahmed
_______________________________________________
rtgwg mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/rtgwg
___________________________________________________________________________
This e-mail message is intended for the recipient only and
contains information which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you
have received this
transmission in error, please inform us by e-mail, phone or fax,
and then delete the original
and all copies thereof.
___________________________________________________________________________
___________________________________________________________________________
This e-mail message is intended for the recipient only and contains
information which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have
received this
transmission in error, please inform us by e-mail, phone or fax, and
then delete the original
and all copies thereof.
___________________________________________________________________________
