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

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

Hi Elwyn, 

On 5/11/20, 2:10 PM, "Elwyn Davies" <[e-mail]> wrote:

    Hi, Peter.

    In the light of some of your responses here, I would just like to 
    clarify that one of the reasons for gen-art reviews is to try and make 
    extremely complicated technical documents more accessible for those who 
    are not as deeply embedded in the jargon and technicalities of the 
    subject as well as making sure that readers can quickly determine 
    whether a document is relevant to work that they are doing.

    Please take this into account when considering your further actions.

    Note that the optionality of ERLD-MSD advertisements appears on 
    reflection to be a more serious issue than just an editorial nit.

So what would you suggest? There are existing implementations that support multipath forwarding entropy using MPLS entropy labels but do not signal that capability in OSPF. We can't have a document that retroactively mandates that they signal it. This wouldn't be backward compatible. How can you possibly see this as a serious issue? 

Thanks,
Acee


    Regards,

    Elwyn

    On 07/05/2020 08:53, Peter Psenak wrote:

    > Hi Elwyn,
    >
    > please see inline:
    >
    > On 06/05/2020 16:25, Elwyn Davies via Datatracker wrote:
    >> Reviewer: Elwyn Davies
    >> Review result: Ready with Nits
    >>
    >> I am the assigned Gen-ART reviewer for this draft. The General Area
    >> Review Team (Gen-ART) reviews all IETF documents being processed
    >> by the IESG for the IETF Chair.  Please treat these comments just
    >> like any other last call comments.
    >>
    >> For more information, please see the FAQ at
    >>
    >> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
    >>
    >> Document: draft-ietf-ospf-mpls-elc-13
    >> Reviewer: Elwyn Davies
    >> Review Date: 2020-05-06
    >> IETF LC End Date: 2020-05-05
    >> IESG Telechat date: 2020-05-21
    >>
    >> Summary:
    >> Ready with nits.  Aside:  I have to say that the convolutions and
    >> cross-referencing of doing the OSPF and IS-IS  extensions plus BGP-LS 
    >> added to
    >> the cross-linking with MPLS is leading to mind-blowing complexity.  
    >> Sooner or
    >> later something is going to blow up here!
    >>
    >> Major issues:
    >> None
    >>
    >> Minor issues:
    >> None
    >>
    >> Nits/editorial comments:
    >>
    >> Abstract and title :  The application to BGP-LS (s5) is not mentioned 
    >> in the
    >> abstract or the title.  Also the first use of BGP-LS needs to be 
    >> expanded.
    >
    > Why would the BGP-LS need to be mentioned in the abstract?
    At present BGP-LS is the subject of a separate document and this 
    document extends the BGP add-on called BGP-LS as well as OSPF v2 and 
    v3.  It is therefor important that implementers of BGP-LS can easily 
    find documents that are relevant to their work.
    >
    > I have expanded the first use of BGP-LS
    >
    >>
    >> Abstract: s/tunnel/LSP/
    >
    > done
    >
    >>
    >> s1: Suggest s/SR-MPLS/Segment Routing with the MPLS Data Plane/
    >>
    >> s1: Query:  As a non-expert in this area, I was wondering if the 
    >> signalling
    >> capability is or will be implemented in IS-IS?  A brief comment on 
    >> the status
    >> wrt IS-IS would be helpful.  [It turns out that you already reference 
    >> the
    >> document that implements this later in this draft.]
    >
    > yes, it is being added to ISIS. Yes, this draft reference the ISIS 
    > draft. I see no reason to to include ISIS draft status in this 
    > document though.
    As has been mentioned in other reviews of this document and the 
    corresponding IS-IS document, having two documents that cover this 
    extension is not very desirable.  As a non-expert, but who knows that 
    OSPF and IS-IS provide closely related functionality, one gets to this 
    point in the document and wonders why OSPF and not IS-IS. If the WG does 
    not bite the bullet and combine the drafts, it would be highly desirable 
    to point out that the same functionality is being proposed for all three 
    protocols
    >
    >
    >>
    >> s1, last sentence: s/it's/it is/
    >
    > done
    >
    >>
    >> s3: It would be a good idea to expand 'prefix' to 'address prefix
    >> advertisement' on its first occurrence here.  Thereafter 'prefix' is 
    >> fine by me.
    >
    > "prefix" is being used in almost all OSPF and ISIS document, we never 
    > use address prefix.
    Really? Revisiting RFC 2328 (OSPFv2) we see that prefix is not used at 
    all and in RFC 5340 (OSPF for IPv6)  the term prefix is introduced as 
    'IP address prefix'.  In order to make it clear of what this is a 
    prefix, and what is going on here, expanding the initial usage is highly 
    desirable.
    >
    >
    >>
    >> s3, para 3: Why would a router not advertise the ELC with all 
    >> prefixes?  Can
    >> you say why this ought not to be a MUST.
    >
    > advertising ELC property with prefix advertisement is optional. We can
    > not mandate it. It would make all routers not advertising this data
    > violating this spec.
    Er, no.  Nothing is said or would be said about routers that do not 
    support ELC at all or do not support it on all interfaces.  I am 
    assuming that it is not intended to make implementation of this 
    capability mandatory in all OSPF deployments. I was trying to understand 
    why a router that satisfies the previous condition so that it is 
    legitimate for it to announce ELC with any IP address prefix might wish 
    to only announce it with some prefixes and not others.  This is an 
    interesting question for implementers as the SHOULD implies that an 
    implementation has to provide a configuration option on a per prefix basis
    >
    >>
    >> s4, para 3: In that case, what does the absence signify?  Should we 
    >> care?
    >
    > the absence of ERLD-MSD advertisements only indicates that a node
    > does not support advertisement of ERLD
    >
    > It can not be interpreted that ERLD is not supported.  Old nodes that do
    > not advertise ERLD-MSD can not be assumed not to support non-zero ERLD.
    >
    There are just too many negatives in this last sentence!  OK.. so if the 
    router does not suport ERLD-MSD advertisements what can or must the 
    ingress router do to usefully position ELs it is intending to send that 
    might pass through this router?  On further reflection, it seems to me 
    that either there should be some sort of default value for the label 
    stack depth that would otherwise be distributed with ERLD-MSD or routers 
    that support ELs MUST advertise the depth they support.

    This is looking rather like an issue rather than just a nit.

    >
    >>
    >> s4, para 4:
    >> This needs a correction and a reference to where the Link MSD Sub-TLV is
    >> defined.  As a matter of interest, is there any reason why this 
    >> should be sent
    >> in an OSPF context?  If not why not just prohibit sending it? If it 
    >> is received
    >> should it provoke an error rather than being ignored? OLD: When the ERLD
    >> MSD-Type is received in the OSPFv2 or OSPFv3 Link MSD Sub-TLV, it 
    >> MUST be
    >> ignored. NEW:
    >>   When the ERLD-MSD type is received in the OSPFv2 or OSPFv3 Link MSD 
    >> Sub-TLV
    >>   [RFC8476], it MUST be ignored.
    >
    > done.
    Did you address the question of whether should actually provoke an error 
    since it appears to be a protocol error?
    >
    >> ENDS
    >>
    >> s5:  This section needs to be rewritten to be 'future proof' rather than
    >> referring to the temporary allocations.  A note about the temporary 
    >> allocations
    >> can be added with a RFC Editor note requesting its removal on final 
    >> publication.
    >
    > I suppose you meant section 6 - IANA Considerations.
    Yes, I did.  Sorry.
    >
    > I have updated the IANA section.
    Good.
    >
    > thanks,
    > Peter
    >>
    >>
    >>
    >>
    >>
    >