Subject: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-ospf-segment-routing-msd-21: (with DISCUSS and COMMENT)

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 26 Sep 2018 15:02:00 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-ospf-segment-routing-msd-21: Discuss

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/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

This is essentially a process discuss, and hopefully easy to resolve.

In Section 4, we say:

   The meaning of the absence of both Node and Link MSD advertisements
   for a given MSD type is specific to the MSD type.  Generally it can
   only be inferred that the advertising node does not support
   advertisement of that MSD type.  However, in some cases the lack of
   advertisement might imply that the functionality associated with the
   MSD type is not supported.  The correct interpretation MUST be
   specified when an MSD type is defined.

I don't think we can make this sort of normative requirement on a registry
created by a different document, at least not without updating the registry
to also point to this document.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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"?

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?

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 26 Sep 2018 22:14:21 +0000

Hi Ben, 

On 9/26/18, 6:02 PM, "Benjamin Kaduk" <[email-masked]> wrote:

    

    In Section 4, we say:

Would you be satisfied if the same text were in both the IS-IS and OSPF document? We really want a copy registry for IGPs (which are really only disseminating the information) to Segment Routing capable routers in the routing domain. 

Thanks,
Acee

    

    Section 2

    
    Section 6

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 26 Sep 2018 17:20:13 -0500

Hi Acee,

>     https://datatracker.ietf.org/doc/draft-ietf-ospf-segment-routing-msd/

I think that depends on which text you're thinking about.  In particular, I
also asked for the IS-IS document to include in the IANA considerations
some guidance to the experts that the experts need to check this
requirement, and I'm not sure if that would result in just adding text to
the IANA considerations or also removing text from earlier in the document.

On a slightly different note, we do occasionally have things like "[this
other document] placed some requirements on [foo].  Those requirements also
apply here, so we are copying the following paragraph from [this other
document] below for the convenience of the reader", and I could see a
copy+reference working here.

So, if the other document enforces the normative requirement we need, but
we want to call attention to the requirement in this document as well,
copying the text with a note about where it came from should suffice.

Thanks,

Benjamin

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 26 Sep 2018 22:25:54 +0000

Hi Ben, Authors,

On 9/26/18, 6:20 PM, "Benjamin Kaduk" <[email-masked]> wrote:

    Hi Acee,

    

I think this is the best path since we want the documents to be independent of one another even though they share the registry and semantics. If we'd have merged the OSPF and IS-IS WGs earlier, we'd have had a single document and have done so with the Flex Algorithm draft.  

Thanks,
Acee 

    Thanks,
    
    Benjamin

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 26 Sep 2018 17:29:35 -0500

> I think this is the best path since we want the documents to be independent of one another even though they share the registry and semantics. If we'd have merged the OSPF and IS-IS WGs earlier, we'…

Indeed, and sorry for having to toss a stumbling block in the works.

-Benjamin