I have posted version -19 of the draft with the diffs that I sent yesterday
Thanks
Ahmed
On 11/21/24 2:30 PM, Yingzhen Qu wrote:
Hi Jim,
Ack. I've been following the discussion in this thread and I agree
with your suggestion. The chairs will send an email to the mailing
list about this major change in the draft and poll the WG's opinion,
especially whether there are any objections.
Thanks,
Yingzhen
On Thu, Nov 21, 2024 at 12:08 PM James Guichard
<james.n.guich...@futurewei.com> wrote:
Hi Ahmed & WG chairs,
Thank you for the work in this latest version. However, as the
responsible AD I am still uneasy with the consensus call on this
document given the objections raised before and during the IETF
121 meeting, and the still open DISCUSSes after IESG evaluation.
The main point of contention seems to be clearly summarized in
John Scudder’s last email which was based upon Stewart Bryant’s
(and others) comments at the mic during the 121 meeting. In summary:
“/What the authors need to do is to be quite clear to the working
group if it is no longer a mandatory requirement to follow the
post-convergence path, and then there needs to be an explanation
as to why this position has changed and then the text body needs
to reflect the consensus position of the working group on whether
it is important that it follows the "post-convergence path" or
it's not important or there are times when it is and times when it
is not, and in which case those circumstances should be documented
in the text.”/
//
I believe that this discussion needs to happen, and I would ask
the chairs to please start this conversation on the mailing list
so that the WG has the chance to voice their concerns and come to
a rough consensus on what needs to be addressed in the document
(if anything) and whether relaxation of the mandatory requirement
is acceptable.
Thanks!
Jim
*From: *Ahmed Bashandy <abashandy.i...@gmail.com>
*Date: *Thursday, November 21, 2024 at 2:46 PM
*To: *Ketan Talaulikar <ketant.i...@gmail.com>, John Scudder
<j...@juniper.net>
*Cc: *RTGWG <rtgwg@ietf.org>
*Subject: *[rtgwg] Re: New Version Notification for
draft-ietf-rtgwg-segment-routing-ti-lfa-18.txt
I forgot to include this latest change in my previous email
The diffs attached to this reply contains all your previous
suggestions plus this latest pne
Thanks
Ahmed
On 11/15/24 7:23 AM, Ketan Talaulikar wrote:
Hi John,
Disclaimer: I am just catching up on the discussion on this
draft. I also missed the WG session due to a conflict but have
caught up with the recording. And I am not speaking for the
authors.
Below is an additional text proposal (over and above what I
have shared previously) to cover, what I think, may be the
essence of your discuss. It is possible though that I've still
missed your point.
f) Section 2
v18
Although not a TI-LFA requirement or constraint, TI-LFA also
brings the benefit of the ability to provide a backup path
that follows the expected post-convergence path considering a
particular failure which reduces the need of locally
configured policies that influence the backup path selection
([RFC7916
<https://www.ietf.org/archive/id/draft-ietf-rtgwg-segment-routing-ti-lfa-18.html#RFC7916>]).
The easiest way to express the expected post-convergence path
in a loop-free manner is to encode it as a list of adjacency
segments. However, this may create a long segment list that
some hardware may not be able to program. One of the
challenges of TI-LFA is to encode the expected
post-convergence path by combining adjacency segments and node
segments. Each implementation may independently develop its
own algorithm for optimizing the ordered segment list. This
document provides an outline of the fundamental concepts
applicable to constructing the SR backup path, along with the
related dataplane procedures.
New
v18
Although not a TI-LFA requirement or constraint, TI-LFA also
brings the benefit of the ability to provide a backup path
that follows the expected post-convergence path considering a
particular failure which reduces the need of locally
configured policies that influence the backup path selection
([RFC7916
<https://www.ietf.org/archive/id/draft-ietf-rtgwg-segment-routing-ti-lfa-18.html#RFC7916>]).
The easiest way to express the expected post-convergence path
in a loop-free manner is to encode it as a list of adjacency
segments. However, this may create a long segment list that
some hardware may not be able to program. One of the
challenges of TI-LFA is to encode the expected
post-convergence path by combining adjacency segments and node
segments. Each implementation may independently develop its
own algorithm for optimizing the ordered segment list. This
document provides an outline of the fundamental concepts
applicable to constructing the SR backup path, along with the
related dataplane procedures. *_Appendix A describes some of
the post-convergence path related aspects of TI-LFA in more
detail._*
The essence is that post-convergence is indeed an important
differentiating aspect of TI-LFA. The text does already
indicate the platform limitation aspect and leaves some of the
optimization to implementations - I believe this is quite
adequate already. Also, added the reference to the Appendix A
per our discussion.
Thanks,
Ketan
On Fri, Nov 15, 2024 at 8:22 PM John Scudder <j...@juniper.net>
wrote:
Hi Ketan,
On Nov 15, 2024, at 9:48 AM, Ketan Talaulikar
<ketant.i...@gmail.com> wrote:
I believe my text proposals do not dilute the
post-convergence aspect of TI-LFA. Please let me know
if you see it otherwise.
No argument. I was harking back to the debate I addressed
at (probably too much) length in my message to this thread
yesterday. I guess your proposed edits, while valuable,
are tangential to the underlying question.
Thanks,
—John
_______________________________________________
rtgwg mailing list --rtgwg@ietf.org
To unsubscribe send an email tortgwg-le...@ietf.org
_______________________________________________
rtgwg mailing list -- rtgwg@ietf.org
To unsubscribe send an email to rtgwg-le...@ietf.org
