Re: Opsdir last call review of draft-ietf-ospf-ospfv3-segment-routing-extensions-16

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

Hi Les,

On 10/30/18, 11:15 AM, "Les Ginsberg (ginsberg)" <[e-mail]> wrote:

    Acee -
    
    >     > Section 3.2
    >     >
    >     > "When a router receives multiple overlapping ranges, it MUST
    >     >        conform to the procedures defined in
    >     >        [I-D.ietf-spring-segment-routing-mpls]."
    >     >
    >     > It would be useful to include a section pointer here.  I think your referring
    >     > to Section 2.3 where the router ignores the range?   Is it likely that will
    >     > change to something other than "ignore?"  If not, maybe it's just worth
    >     > mentioning that here.
    > 
    >     ##PP
    >     I don't think it is good to specify the behavior which is described
    >     somewhere else. Regarding the section, the
    >     ietf-spring-segment-routing-mpls is still being worked on and the
    >     section may changes. We used the same text in OSPFv2 and ISIS SR drafts.
    >     I would like to be consistent here.
    > 
    > Given that this is a normative reference, I don't think it would create too
    > much of a dependency to include the section in the reference. We've had a
    > protracted discussion (1-2 years) on the whole SID overlap topic in SPRING
    > and I believe we've finally come up with behavior and the specification of
    > such behavior with which everyone agree (or at least doesn't strongly
    > disagree).
    > 
    [Les:] I strongly agree with Peter (and disagree with you).
    Why would we want to risk having an incorrect section reference to a document which is still being revised? This needlessly introduces a dependency such that if the section numbering changes in the SR-MPLS draft we would then have to update the dependent document(s).
    Note this has nothing to do with the SID overlap discussion itself. The compelling reason to NOT discuss this in the IGP documents but simply refer to the document that defines the solution is so that whatever the outcome in SPRING the IGP documents do not also have to be changed.

While I don't feel as strongly as either of you, this could improve the readability. For example, if you read RFC 8362 you'll see that I have referred extensively to sections in RFC 5340. I may be overoptimistic but I'm hoping we are finally done with the SR-MPLS draft as it is blocking all our LSR SR documents. 

Thanks,
Acee
    
       Les