Re: [Lsr] AD review of draft-ietf-lsr-flex-algo-20

["Acee Lindem (acee)" <[e-mail]>]

Thanks John - I the changes in -21 and -22 improve the specification. 
Acee

On 9/12/22, 8:41 AM, "Lsr on behalf of John Scudder" <[e-mail] on behalf of jgs=[e-mail]> wrote:

    Hi Peter,

    Thanks. I’ve requested IETF LC.

    —John

    > On Sep 12, 2022, at 7:36 AM, Peter Psenak <[e-mail]> 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 <ppsenak=[e-mail]> 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
    [e-mail]
    https://www.ietf.org/mailman/listinfo/lsr