Re: [Lsr] Rtgdir last call review of draft-ietf-ospf-mpls-elc-13

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

Hi Peter, Dhruv,

On 5/6/20, 12:00 PM, "Peter Psenak" <[e-mail]> wrote:

    Hi Dhruv,

    please see inline:

    On 06/05/2020 17:40, Dhruv Dhody wrote:
    > Hi Peter,
    > 
    > Thanks for your reply, snipping to points that need further discussion...
    > 
    >> What about:
    >>
    >> Segment Routing with the MPLS Data Plane relies on Interior Gateway
    >> Protocols (IGP) such as OSPFv2 [RFC8665] and OSPFv3 [RFC8666] to signal
    >> labels.
    >>
    > 
    > Much better.
    > 
    > 
    >>> (3) Section 4
    >>>
    >>>      The absence of ERLD-MSD advertisements indicates only that the
    >>>      advertising node does not support advertisement of this capability.
    >>>
    >>>      Do you mean to differentiate between support for the capability itself v/s
    >>>      support for 'advertisement' only. But RFC 8662 says that ERLD value is
    >>>      advertised only when following conditions are met:
    >>
    >> What is meant is that even though all the below conditions are set, if
    >> the node does not support the advertisement, one can not conclude what
    >> its ERLD is.
    >>
    >> If the node supports the advertisement of the ERLD, but the below
    >> conditions are not met, the node should not advertise the ELC capability
    >> in a first place.
    >>
    > 
    > There are two things here - (a) the actual load balancing capability
    > of a node (b) the capability to advertise the ELC/ERLD. Usually
    > capability and the advertisement of the capability go together. In
    > this case we want to be explicit that the absence of ERLD-MSD
    > indicates just (b) and not (a).
    > 
    > You do use the word "only", so may its all fine! I will leave it to
    > you/shepherd.

    yes, the absence of ERLD-MSD advertisements only indicates that a node 
    does not support advertisement of (b).

    It can not be interpreted that (b) is not supported.  Old nodes that do 
    not advertise ERLD-MSD can not be assumed not to support non-zero ERLD.

    The "only" is there to express the above.

As document shepherd, I think this aligns with other OSPF functional capabilities.

Thanks,
Acee

    > 
    >>>
    >>>      *  MUST be entropy label capable and, as a consequence, MUST apply
    >>>         the data-plane procedures defined in [RFC6790].
    >>>
    >>>      *  MUST be able to read an ELI/EL, which is located within its ERLD
    >>>         value.
    >>>
    >>>      *  MUST take into account an EL within the first ERLD labels in its
    >>>         load-balancing function.
    >>>
    >>>      Thus, I am not sure about this sentence. Maybe you mean to say that the
    >>>      absence only indicates that the ERLD-MSD value of the node is unknown (and
    >>>      it might still be capable of handling ELI/EL)?
    >>>
    >>> (4) Section 4
    >>>
    >>>       What would be the behavior if an OSPF router receives a ERLD of the node
    >>>       but no ELC set for the corresponding prefix? That would be an error as per
    >>>       RFC 8662, we should specify how one handles it within OSPF. If it is to
    >>>       just ignore the ERLD, we should explicitly say that.
    >>
    >> the behavior is specified in the RFC 8662.  OSPF is just a messenger,
    >> not the consumer of this information.
    >>
    > 
    > Is there some text in RFC 8662 the clarify what one does on the
    > receiving side? I found only the sending conditions in section 4. How
    > does a receiving node behaves when he receives conflicting
    > information, which one does he trust (no ELC present or ERLD=10). We
    > could have interop issues here if you leave it open.

    well, if the node does not support ELC, then ERLD value is irrelevant. 
    It's like having a speed limit for a road with no entry.

    But that is something that does not belong to protocol drafts.

    thanks,
    Peter


    > 
    > Thanks!
    > Dhruv
    > 
    > PS. Since the comments are the same for the IS-IS I-D, no need duplicate them.
    > 
    >