John,
The objective of this email thread as well as the discussion during the
RTGWG meeting on Tuesday Nov/5 is to address the DISCUSS items. I hope
the latest modifications to draft resolve these DISCUSS items. I also
incorporated the suggestions from Ketan. So let's resolve the DISCUSS
items even using ABSTAIN as you suggested
IMO other comments should be on a different thread.
Ahmed
On 11/14/24 2:16 PM, John Scudder wrote:
Hi Ahmed,
Thanks for the update. I read the diff, and I listened to the
recording of your rtgwg presentation.
I've written a long message. For convenience, the bottom line (TL;DR
as it were) is that I think the conversation that was started with
Stewart and Sasha at the mic line at IETF-121 needs to be worked
through. Once the RTGWG chairs and AD are satisfied, I'll abide by that.
Now the long version:
On Nov 13, 2024, at 3:01 PM, Ahmed Bashandy
<abashandy.i...@gmail.com> wrote:
I uploaded version 18 of the ti-lfa draft to address the two DISCUSS
items in
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-rtgwg-segment-routing-ti-lfa/ballot/__;!!NEt6yMaO-gk!Dhbz2cZyaM1s3x99GGj8o3EmDms0MLvUF97k-_fYkmiRooU3ofACGYnn2oXLzk8yYNKcT3uUxTjpe1x_LjTNsQ$
- To address John Scudder's Discuss, I made the modifications to remove
the word "key" from the abstract as suggested by Sasha at
https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/rtgwg/nWR4uYaT3T30XRiyRdAoIqO22AM/__;!!NEt6yMaO-gk!Dhbz2cZyaM1s3x99GGj8o3EmDms0MLvUF97k-_fYkmiRooU3ofACGYnn2oXLzk8yYNKcT3uUxTjpe1ytjIan9Q$
and Pierre at
https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/rtgwg/zHP2qvP2Ew1oWl5G7Gq8niu8vy8/__;!!NEt6yMaO-gk!Dhbz2cZyaM1s3x99GGj8o3EmDms0MLvUF97k-_fYkmiRooU3ofACGYnn2oXLzk8yYNKcT3uUxTjpe1wFAV_5AQ$
- To address Murray Discuss (as well as as comments from others) I
removed the word "SHOULD" from sections 6.2, 6.3, and 9 as I suggested
during my presentation during the rtgwg meeting last Tuesday Nov/5/24.
The entire recording of the RTGWG meeting can be found in
https://urldefense.com/v3/__https://meetecho-player.ietf.org/playout/?session=IETF121-RTGWG-20241105-0930__;!!NEt6yMaO-gk!Dhbz2cZyaM1s3x99GGj8o3EmDms0MLvUF97k-_fYkmiRooU3ofACGYnn2oXLzk8yYNKcT3uUxTjpe1yu45oEfQ$
The slides that I presented in in PDF format can be found in
https://urldefense.com/v3/__https://datatracker.ietf.org/meeting/121/materials/slides-121-rtgwg-02-tilfa-bgppic-00.pdf__;!!NEt6yMaO-gk!Dhbz2cZyaM1s3x99GGj8o3EmDms0MLvUF97k-_fYkmiRooU3ofACGYnn2oXLzk8yYNKcT3uUxTjpe1zaUaCWtg$
Please take a look and see if the modifications are good to address the
two DISCUSS Items
In your update you've gotten rid of "key". That's fine as far as it
goes, and I agree it resolves the inconsistency between the abstract
and body. But that was just an editorial issue, the canary in the coal
mine as it were, that illuminated the more general point. Perhaps I
expressed myself poorly in the DISCUSS and that's what led us down
this rabbit hole of focusing on the word "key". I apologize for that.
My larger concern was expressed very ably by Stewart in the Q&A of
your presentation. Rather than try to paraphrase him, I've taken the
liberty of starting with the transcript [1] and cleaning it up,
appended below. Stewart nails it. (I kept most of it as close to
verbatim as I could but did remove a little bit of procedural "keep it
quick" stuff from the chair. This is of course not an official
transcript anyway.)
To elaborate a bit, though: as far as I can tell, the contribution
(and it is a big contribution!) of the spec is to show how to use
post-convergence paths for restoration. If you remove that (which I
can because it's optional), it seems as though there is nothing left
that wasn't already specified before (for example in RFC 7490, and
others).
You mentioned in your comments at the meeting that post-convergence
was made optional "because some platforms cannot do it". Normally,
when we have a platform that can't do a specification, that's fine,
the platform simply wouldn't claim conformance to that specification.
If you have, say, a platform that can only forward based on the IPv4
or IPv6 header but not on the MPLS header, you don't change the MPLS
specification to say forwarding on the MPLS header is not mandatory.
You just don't claim conformance with MPLS. (I chose an extreme case,
of course, in hopes of clearly illustrating the point.)
If I were confident that the WG consensus is yes, absolutely the WG
wants to publish this document in its current "post-convergence is
explicitly optional" state, I would move from DISCUSS to ABSTAIN. I
would choose ABSTAIN rather than NOOBJ because of the observation
above, that as far as I can tell once you remove post-convergence
there's nothing left that hasn't been done before. (Note that ABSTAIN
is a non-blocking, though also non-supporting, ballot position.)
However, it is not clear to me that this is, indeed, a solid WG
consensus. In addition to Stewart and Sasha's comments, you also
mentioned that you've gotten private emails raising the same concern.
Calling consensus for RTGWG isn't my job, I would defer to the chairs
and AD (Jim) on that point, but it sounded to me from the RTGWG
meeting like this was the next action.
One last point, right at the end of the discussion of the draft you
say, "I avoid shoulds because of the pushback that I get. But in my
opinion it should be a should. [...] Either you guys want me to put it
back as a mandatory or say why it's not mandatory. I have a reason why
it is not mandatory and I just mentioned it and I can put that."
Interestingly, this coincides closely with Murray's DISCUSS ballot,
about SHOULD. I get it that you have different views on the use of
SHOULD, but per my reading of RFC 2119 the case under discussion here
is exactly the kind of situation where it becomes useful. To remind us
of what 2119 says:
```
3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.
```
As far as I can tell, that is what you are saying: an implementation
SHOULD use the post-convergence path unless (conditions you will name,
e.g., "length of the SID stack is long enough, hardware cannot support
it"), in which case that implementation MUST fall back to (whatever
the right fallback posture is, RFC 7490 perhaps).
I don't insist you use that language or even that approach, nor am I
sure it would satisfy the WG -- I just offer it as a point to consider.
Thanks,
--John
My edited transcript:
Stewart (17:12)
So, Ahmed when this piece of work started, many of us have tracked
this piece of work since the first day it was presented at the IETF.
When it was presented, the word "key" was important because it was a
fundamental concept of the design that the repair path had to follow
the post-convergence path and the document kind of has that sort of
subtly written in, in various places, except in the places where it
doesn't.
So I think what is... what the authors need to do is to be quite clear
to the working group if it is no longer key, if it is no longer a
mandat- a requirement to follow the post-convergence path, 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.
Ahmed (18:21)
So the document really says that it is not mandatory and it is
important and it explains why it is important like I can read part of
the document and I'll point them out, actually, I'll reply to your
email, but the point here is that we don't really try to put
justifications because then I will go into the details of the
implementation. I just put the spec there and say, you know what? It
is important, but it's not mandatory. You don't have to follow it.
Your implementation doesn't have to follow it. If you want to follow
it, I have paragraphs that says how you follow it in certain scenarios
like that is...
(cross-talk)
Stewart (18:54)
I think you're skipping the important point. The original thesis was
that this was a required congruence. That has been dropped, the least
you need to do is to explain to the working group why the requirement
for congruence has been changed. And then we need to decide what text
needs to go in the document to reflect that change of positions. But
absolutely, this was a fundamental of the original design and it seems
to have been quietly and subtly changed without explanation.
Ahmed (19:28)
Okay so I thought it's uh yeah I can add a statement that's why it is
I thought it's obvious basically because some platforms cannot do it.
It's as simple as that. I'll put the sentence if this is why it has
been dropped. This was basically a feedback that we got I can try and
dig the emails it has been a long while that some hardware simply
cannot support it or some software cannot support it if the number if
the length of the SID stack is long enough, hardware cannot support it
so we can still do topology independent which means you can still get
your backup up but it will not be over the post-convergence path. That
is the only reason really.
Stewart (20:08)
I think this probably needs a longer conversation than we can have in
this working group and I think uh John I mean Jim probably needs to
convene a group of experts.
Ahmed (20:19)
[elided]
Sasha (20:34)
I just wanted to second... to say exactly what Stewart has said. I
have nothing to add. [Garbled] ... something is called the key aspect
of a feature and then called non-mandatory is not... creates a
confusion to put it mildly. This has to be resolved one way or another
with explanations because there is a loss of history behind this
change of requirements. I actually... I second what Stuart has said.
Ahmed (21:13)
Okay sure, okay, I think I got the point. So I'm open to discussions I
have no problem really. Okay sure.
JeffT (21:23)
Ahmed, do you feel we need another discussion on this? Is it clear
what working group is expecting from you in terms of changes and
clarifications?
Ahmed (21:31)
Yeah, my understanding, and again, I'm talking about Stuart and
Sasha's comments that the original draft was... I'll have to dig it
out to be honest, it's been a long while... that to be TI-LFA the
repair path has to be post-convergence. This has been dropped from
must-have to important, and I avoid shoulds because of the pushback
that I get. But in my opinion it should be a should. But it seems like
Sasha and Stuart want it back. And not only Sasha and Stewart, there
are other but also other [garbled] exchange email privately, but
because it's private I'm not going to divulge their names that also
think that it should be put back to mandatory and I'm open to either
way. Either you guys want me to put it back as a mandatory or say why
it's not mandatory. I have a reason why it is not mandatory and I just
mentioned it and I can put that. I'll discuss it with the co-authors
and see what they want, but I understand Stuart and Sasha's comments.
[1]
https://meetecho-player.ietf.org/playout/?session=IETF121-RTGWG-20241105-0930
_______________________________________________
rtgwg mailing list -- rtgwg@ietf.org
To unsubscribe send an email to rtgwg-le...@ietf.org
