Hi Peter, Thanks. I’ve requested IETF LC.
—John > On Sep 12, 2022, at 7:36 AM, Peter Psenak <[email protected]> wrote: > > > Hi John, > > please see inline (##PP2) > > On 09/09/2022 17:29, John Scudder wrote: >> Hi Peter, >> >> Thanks for your reply and for the ping. >> >> Where necessary I’ve replied in line below. I’ve snipped any points that >> are agreed and don’t need further discussion. I’ve also reviewed the -21 >> diffs, basically LGTM. It looks like you missed a few of the nits, I >> don’t know if this was by choice or oversight. I’ve attached an edited >> version of -21 that captures the remaining ones, plus a few new ones I >> noticed. You can diff if you want to pick those up for inclusion in -22. > > ##PP2 > I fixed all nits, hopefully. > >> >>> On Aug 31, 2022, at 10:23 AM, Peter Psenak >>> <[email protected]> wrote: >>> >>> [External Email. Be cautious of content] >>> >>> >>> Hi John, >>> >>> thanks a lot for the thorough review. >>> >>> I incorporated all your edits and almost all of your comments. >>> >>> For the few that I have not, please see inline (loop for ##PP): >> >> [snip] >> >>>> Any change in the Flex-Algorithm definition may result in temporary >>>> disruption of traffic that is forwarded based on such Flex-Algorithm >>>> paths. The impact is similar to any other event that requires >>>> network-wide convergence. >>>> + >>>> +jgs: IMO this would merit discussion in the Operational Considerations >>>> +section. In particular, is there any advice regarding how to >>>> +stage/sequence FAD config changes in order to minimize disruption? >>> >>> ##PP >>> I don't really see much to add here. FAD changes the constraints used >>> during the algo specific SPF and as such any change in it requires all >>> routers to recompute the entire topology. In terms of the order of >>> changes, I don't see why that would be significant and why someone would >>> not want to advertise all changes at once if there are any multiple >>> changes in the FAD. >> >> I take your point, thanks. I guess about the most that you could say in >> Operational Considerations would be something like >> >> --- >> 15.X FAD Changes >> >> As [Section 5.3] notes, a change in the Flex-Algorithm definition may >> require network-wide SPF recomputation and network reconvergence. This >> potential for disruption should be taken into consideration when >> planning and making changes to the FAD. > > ##PP2 > Added above to the Operational Consideration section. > >> --- >> >> Obvs, re-word as appropriate. IMHO it's worth elevating in the O.C. >> section even if only briefly, but I don’t insist. >> >> [snip] >> >>>> +jgs: Are "sender" and "receiver" sufficiently clear to OSPF practitioners >>>> +that there would be no ambiguity? I can think of two different ways >>>> +to read them -- one is that the "sender" is the router that >>>> +originates the LSA, and the "receiver" is any router that processes >>>> +the LSA. I think that's what you mean. The other, pedantic, reading, >>>> +is the "sender" is any router that puts the LSA on the wire, and the >>>> +"receiver" is any router that takes the LSA from the wire, so anyone >>>> +participating in flooding would be both a "sender" and a "receiver" >>>> +at times. >>>> + >>>> +If this is how people write OSPF specs and talk about OSPF, fine. >>>> +But if there are more precise terms than "sender" and "receiver" in >>>> +use, it would be nice to use them. >>> >>> ##PP >>> send/receive is the standard term used, e.g >>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc8665*section-5__;Iw!!NEt6yMaO-gk!HAdyT2s3c5I_fktGSY3YPuQdVeF95m5Yb-utZWsGn9214bNEm1SkQ1dDgtbTL2tEJz4kJBwXudGrWyHF3P9zB8IEVqDz$ >> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc8665*section-5__;Iw!!NEt6yMaO-gk!HAdyT2s3c5I_fktGSY3YPuQdVeF95m5Yb-utZWsGn9214bNEm1SkQ1dDgtbTL2tEJz4kJBwXudGrWyHF3P9zB8IEVqDz$> >>> >>> I can replace sender with originator, if you prefer, but receiver would >>> remain. >> >> As you prefer. It’s not a big deal. I agree, by the way, that receiver >> is unambiguous. > > ##PP > replaced sender with originator. > >> >> [snip] >> >>>> >>>> @@ -1194,15 +1258,36 @@ >>>> | | >>>> +- TLVs -+ >>>> | ... | >>>> + >>>> +jgs: Maybe add something like >>>> >>>> + Other than where specified below, these fields' definitions are as >>>> + given in [RFC2328] Section A.4.1. >>> >>> ##PP >>> RFC2328 does not use TLVs, so that would not be correct. >> >> I looked again, and the fields that are excluded from my suggested >> statement, since they are “where specified below” are Opaque Type, >> Opaque ID, Length, and TLVs. That leaves LS Age, Options, LS Type, >> Advertising Router, LS sequence number, and LS checksum. But if my >> suggested wording is wrong, that’s fine, choose your own -- the more >> general observation is that specs that provide a packet diagram usually >> tell the reader what the fields mean, either by defining them, or by >> saying what reference to look in. > > ##PP2 > A I added reference to all fields in the Opaque LSA. > >> >> [snip] >> >>> ##PP >>> Though I agree that the order is not important for now, one can imagine >>> that in the future there could be rules added for which the order would >>> be important. I feel numbering these rules and keep them in the strict >>> order would help in such case. And mandating the order from the >>> beginning does not make any harm. So I would prefer to keep it as it is. >> >> I disagree, but it’s not a blocking disagreement, if you’ve considered >> this and decided to keep it as written, so be it. > > ##PP > yes, I would prefer to keep it as it is. > >> >> But to give a little outline of why I still don’t agree, it goes like >> >> - The rules as written are overspecified. >> - This means a savvy implementor will perceive they are free to ignore >> the ordering requirement. >> - This means an implementation might indeed ignore it. It will still >> operate per-spec. >> - If in fact a later spec introduces something where ordering is >> relevant, in part because of the foregoing observations it will be >> necessary for the spec to be clear about its ordering assumptions >> anyway. So I don’t think you’ve really relieved future spec authors, or >> implementors, of any work. >> >> But TBH that wasn’t in my mind when I wrote the comment, it was just the >> general “don’t overspecify” heuristic. >> >> Anyhow, do as you prefer, I’ve said my piece. >> >> [snip] >> >>>> Algorithm (with FAD selected includes the M-Flag) where the >>>> advertising ASBR is in a remote area, the metric will be the sum of >>>> the following: >>>> + >>>> +jgs: I don't understand what the words in parentheses are trying to >>>> say, can >>>> +you explain? >>> >>> ##PP >>> it means that the "winning" FAD includes the M-bit. >> >> Then how about this replacement text? >> >> OLD: >> In the case of OSPF, when calculating external routes in a Flex- >> Algorithm (with FAD selected includes the M-Flag) where the >> advertising ASBR is in a remote area, the metric will be the sum of >> the following: >> >> NEW: >> In the case of OSPF, when calculating external routes in a Flex- >> Algorithm, if the winning FAD includes the M-Flag, and where the >> advertising ASBR is in a remote area, the metric will be the sum of >> the following: > > ##PP2 > updated as you proposed. > > thanks, > Peter > >> >> Thanks, >> >> —John >> > _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
