Re: [Lsr] Benjamin Kaduk's No Objection on draft-ietf-ospf-segment-routing-msd-23: (with COMMENT)

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

Hi Ben, 

On 10/15/18, 9:58 PM, "Benjamin Kaduk" <[e-mail]> wrote:

    Benjamin Kaduk has entered the following ballot position for
    draft-ietf-ospf-segment-routing-msd-23: No Objection
    
    When responding, please keep the subject line intact and reply to all
    email addresses included in the To and CC lines. (Feel free to cut this
    introductory paragraph, however.)
    
    
    Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
    for more information about IESG DISCUSS and COMMENT positions.
    
    
    The document, along with other ballot positions, can be found here:
    https://datatracker.ietf.org/doc/draft-ietf-ospf-segment-routing-msd/
    
    
    
    ----------------------------------------------------------------------
    COMMENT:
    ----------------------------------------------------------------------
    
    Thanks for addressing my Discuss point; original ballot comment preserved below.
    
    Can SID be expanded on first usage --
    https://www.rfc-editor.org/materials/abbrev.expansion.txt does not list it
    as "well known".  (It also doesn't appear to list "Segment Identifier" as
    one of the expansions.)
    
    This is basically the same thing I said for the IS-IS document that creates
    the MSD types registry, but I'm not sure I followed correctly the meaning
    of MSD type 1 for SR-enabled vs.  non-SR-enabled networks.  In particular,
    I still don't really understand why it's okay to use the same codepoint for
    the max SID depth in SR-enabled networks and for the max label depth in
    non-SR MPLS networks.  Why couldn't they just be separate MSD Type
    codepoints?
    
    Section-by-section comments follow.
    
    Section 2
    
                      If the Node MSD TLV appears in multiple Router
       Information LSAs that have the same flooding scope, the Node MSD TLV
       in the Router Information (RI) LSA with the numerically smallest
       Instance ID MUST be used and subsequent instances of the Node MSD TLV
       MUST be ignored. [...]
    
    Unless there is a sorting requirement I've forgotten about, shouldn't this
    be "other" rather than "subsequent"?

In this context, "subsequent" refers to the instance ID rather than the ordering of RI LSAs. However, it would be rare that an OSPF router would not originate RI LSAs in order. 

Thanks,
Acee 
    
    Section 6
    
    Thanks for the updates in response to the secdir review; they help a lot.
    
       If the value is larger than supported - instantiation of a path that
       can't be supported by the head-end (the node performing the SID
       imposition).
    
    This is supposed to mean "(instantiation by the head-end) of a (path that
    can't be supported)", not "instantiation of a path (that can't be supported
    by the head-end)", right?