Subject: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-isis-te-app-14: (with DISCUSS and COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Thu, 11 Jun 2020 00:42:07 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-isis-te-app-14: 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-isis-te-app/

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

My apologies if this is super-obvious and I'm just missing it ... but
Section 4.3 dictates that part of the value for the application-specific
SRLG TLV is a "Neighbor System-ID + pseudo-node ID (7 octets)".  Where
are these defined?  (We don't exactly say that we're reusing the structure
from, e.g., TLV 138, which I note refers to the seventh octet as
"pseudonode number", not "pseudo-node ID".  Similarly for the
interpretation of the SRLG value(s).  Do we just need to reference that
we're reusing the encoding from RFC 5307 (or similar) or are some
changes needed?

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

What is the scope over which the user-defined application bits are
defined/allocated?

And, a general question, just to check my understanding: if I do need to
specify different values of a given attribute for different
applications, I do that by putting multiple copies of the new sub-TLV in
TLV 22/23/etc., with the flags set according to which application the
contained attributes apply to?  (Mostly I ask because I forget what the
rules are for having multiple instances of a given TLV/sub-TLV as
siblings in the same container.)

Section 3.1

Maybe mention (again, I know) that this is only the subset of sub-TLVs
that are used for RSVP-TE?

Section 4.2

   When the L-flag is set in the Application Identifier Bit Mask, all of
   the applications specified in the bit mask MUST use the legacy
   advertisements for the corresponding link found in TLVs 22, 23, 25,
   141, 222, and 223 or TLV 138 or TLV 139 as appropriate.  Link

nit(?): is this "found in sub-TLVs of TLVs 22, [...]"?

   attribute sub-sub-TLVs for the corresponding link attributes MUST NOT
   be advertised for the set of applications specified in the Standard/
   User Application Identifier Bit Masks and all such advertisements
   MUST be ignored on receipt.

Does this apply to just the (sub-)TLV with the L-flag set, or to other
instances of that (sub-)TLV as well?

   For a given application, the setting of the L-flag MUST be the same
   in all sub-TLVs for a given link.  In cases where this constraint is
   violated, the L-flag MUST be considered set for this application.

editorial: I suggest "the L-flag MUST be considered set for this
application for all sub-TLVs on the link in question".

   If link attributes are advertised associated with zero length
   Application Identifier Bit Masks for both standard applications and
   user defined applications, then any Standard Application and/or any

Do we need to talk about conflicts if there are multiple such sub-TLVs
for the link in question (that contain different values in the
sub-sub-TLV(s))?

   User Defined Application is permitted to use that set of link
   attributes so long as there is not another set of attributes
   advertised on that same link which is associated with a non-zero
   length Application Identifier Bit Mask with a matching Application
   Identifier Bit set.

nit: this phrasing of "matching Application Identifier Bit set" does not
seem as clear as it could be that the bit for the application in
question is what's checked (though I have a hard time believing that
someone would accidentally misinterpret the meaning).

   the link attribute sub-sub-TLV code points.  This document defines a
   sub-sub-TLV for each of the existing sub-TLVs listed in Section 3.1
   except as noted below.  The format of the sub-sub-TLVs matches the

Just to check that I'm matching things up properly: this leaves the only
attributes that do not have some form of exception noted as
administrative group, extended administrative group, and TE default
metric?

Section 4.2.1

   Maximum link bandwidth is an application independent attribute of the
   link.  When advertised using the Application Specific Link Attributes
   sub-TLV, multiple values for the same link MUST NOT be advertised.
   This can be accomplished most efficiently by having a single
   advertisement for a given link where the Application Identifier Bit
   Mask identifies all the applications which are making use of the
   value for that link.

If I want the same maximum link bandwidth to apply to all applications,
couldn't I just put it in a sub-TLV with both SABM and UDABM length of
zero?  (Is this somehow less efficient than setting all the bits for the
applications making use of the value?)  Section 4.2.3 seems to discuss
using the zero-length bit mask option in the context of TE metrics...
(I do note the note at the end of Section 5 about the "any application"
encoding leaving ambiguous whether an application is enabled, but I
don't see how this consideration differs between maximum link bandwidth
and extended TE metrics.)

Section 4.2.2

   Maximum Reservable Link Bandwidth and Unreserved Bandwidth are
   attributes specific to RSVP-TE.  When advertised using the
   Application Specific Link Attributes sub-TLV, bits other than the
   RSVP-TE (R-bit) MUST NOT be set in the Application Identifier Bit

Just to confirm: we find the risk of some future application that also
wants to do reservation-like things sufficiently low that we're okay
with preventing it from using these attributes?

Section 4.3

What are the semantics when I specify more than one link identifier
sub-TLV?  They are all supposed to identify the same link, and in some
case might be needed to disambiguate if there are (e.g.) multiple links
to the same neighbor?

Section 5

   In the case of SRTE, advertisement of application specific link
   attributes does not indicate enablement of SRTE on that link.  The

Is the SRTE specification sufficiently final that we're comfortable
enshrining in a (different) RFC this property of it?  I note that we
only list draft-ietf-spring-segment-routing-policy as an informative
reference, so it's entirely possible that this document will be
published as an RFC before that document is done.

Section 6.1

   the writing of this document.  Therefore, such applications have been
   deployed using the legacy advertisements.  The Standard Applications
   defined in this document may continue to use legacy advertisements
   for a given link so long as at least one of the following conditions
   is true:

nit(?): do we want to say something like "may safely continue" or "may
continue to use without ill effect"?

Section 6.3.2

   advertisements as defined in this document.  Attributes for
   applications other than RSVP-TE MUST be advertised using application
   specific advertisements which have the L-flag clear.  In cases where
   some link attributes are shared with RSVP-TE, this requires duplicate
   advertisements for those attributes.

Maybe repeat that this duplication is required because the L flag
applies per-application per-link, for all attributes?

Section 6.3.4

   2)Advertise all legacy link attributes using application specific
   advertisements with L-flag clear and R-bit set.

nit: I suggest clarifying that this involves duplicate advertisements
(legacy plus application-specific).  Or at least, I assume it does,
since step (3) is "remove legacy advertisements".

Section 7.3

   Note to IANA: For future codepoints, in cases where the document
   which defines the encoding is different from the document which
   assigns the codepoint, the encoding reference MUST be to the document
   which defines the encoding.

Why not list both as the reference?

   Note to designated experts: If a link attribute can be advertised
   both as a sub-TLV of TLVs 22, 23, 25, 141, 222, and 223 and as a sub-
   sub-TLV of the Application Specific Link Attributes sub-TLV defined
   in this document, then the same numerical code should be assigned to
   the link attribute whenever possible.

Are these notes intended to end up in the final RFC, attached to the
registry, both places, or neither place?

Section 7.4

   policy for this registry is "Standards Action" [RFC8126].  Bit
   definitions SHOULD be assigned in ascending bit order beginning with
   Bit 0 so as to minimize the number of octets that will need to be
   transmitted.  The following assignments are made by this document:

I worry a little bit that this will encourage codepoint squatting,
though in theory the user-defined bitmask should avoid the need for
squatting.

Section 7.5

   Note to IANA: For future codepoints, in cases where the document
   which defines the encoding is different from the document which
   assigns the codepoint, the encoding reference MUST be to the document
   which defines the encoding.

(As above, why not list both?)

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 11 Jun 2020 16:48:00 +0000

Benjamin -

Thanx for your review.

Responses inline.

> -----Original Message-----

> From: Benjamin Kaduk via Datatracker <[email-masked]>

> Sent: Thursday, June 11, 2020 12:42 AM

> To: The IESG <[email-masked]>

> Cc: [email-masked]; [email-masked]; [email-masked]; Acee

> Lindem (acee) <[email-masked]>; [email-masked]; Acee Lindem

> (acee) <[email-masked]>

> Subject: Benjamin Kaduk's Discuss on draft-ietf-isis-te-app-14: (with DISCUSS

> and COMMENT)

[Les:] “system ID” and “pseudo-node ID” derive from the IS-IS base specification [ISO 19589]

> defined/allocated?

[Les:] Sorry – I do not understand this question.

[Les:] You are correct.

Whether multiple occurrences of the same sub-TLV is allowed is codepoint specific.

Section 4.2 states:

“Multiple Application Specific Link Attribute sub-TLVs for the same

   link MAY be advertised.”

> that are used for RSVP-TE?

[Les:] The point of Section 3.1 is to list the legacy sub-TLVs which are relevant to this draft. There are other sub-TLVs defined in https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-22-23-25-141-222-223

which are not relevant – but categorizing them as “not used by RSVP-TE” wouldn’t be completely accurate. For example, endpoint addresses (codepoints 6,8,12,13) are quite relevant to RSVP-TE as they are required to uniquely identify the link – but they aren’t in the set of sub-sub-TLVs being defined.

> nit(?): is this "found in sub-TLVs of TLVs 22, [...]"?

[Les:] The top level TLVs are the containers in which link advertisements are present. A given link advertisement consists of the fixed portion of the TLV and a set of sub-TLVs.

I think the existing text is correct.

[Les:] The scope is the set of sub-TLVs associated with the same link and the same application(s).

[Les:] This seems redundant given the first sentence of the paragraph.

??

Note that if L-flag is set, no link attribute advertisements are permitted in the sub-TLV – so there is no reason to have multiple sub-TLVs for the same link/application in such a case.

[Les:] An earlier paragraph discusses conflicts and states:

“In cases where conflicting values for the same

   application/attribute/link are advertised all the conflicting values

   MUST be ignored by the specified application.”

I think that covers the “any application” case as well.

[Les:] I also have trouble seeing how this could be misinterpreted.

Do you have a suggestion?

[Les:] The points being made in Sections 4.2.x are:

1)Maximum Bandwidth is not application specific

2)Reserved/Unreserved bandwidth are RSVP-TE specific

3)Extended TE Metrics MAY be application specific, but there are challenges in doing application specific performance measurement

Sooo, you are following along quite well, but in the case of Extended TE Metrics I would not use the term “exception”.

[Les:] You are correct. I have added:

“It is also possible to advertise a single advertisement with zero length SABM and UDABM so long as the constraints discussed in Section 4.2 and Section 6.2 are acceptable.”

> with preventing it from using these attributes?

[Les:] It would require a definition of an alternative RSVP protocol. If/when that occurs a revision to this restriction could be specified.

[Les:] It might be useful to include both IPv4 and IPv6 addresses.

It does not seem useful to include Link Identifiers and IPvX addreesses – though not in and of itself harmful.

I have added:

“Multiple occurrences of the same identifier type MUST NOT be present.”

> enshrining in a (different) RFC this property of it?

[Les:] This property exists – largely because existing RSVP-TE specifications never defined a standard definition of enablement. Implementations therefore had to come up with an ad hoc solution.

We are simply reflecting the deployed reality.

> I note that we

[Les:] My understanding of this oft discussed point is that the choice of Informative vs Normative Reference depends on the relationship between the two documents – not the current document status of the referenced document.

In this case nothing in this draft depends on content in the SR Policy draft, but it is informative in providing context for the content of this draft.

??

[Les:] There are limitations (discussed immediately below in the draft) to when this can be done.

I am comfortable with the current text.

[Les:] Perhaps this is a matter of style. I prefer that a draft confine itself to normative statements whenever possible.

You are suggesting that we should add some explanation – but as this aspect of L-bit is clearly defined earlier in the document I would prefer not to distract from the normative statement by adding an explanation which has already been provided.

I am open to revision if you really think this is important – so let me know if you feel strongly about this.

[Les:] I have added “At this point both legacy and application specific advertisements are being sent.”

> Why not list both as the reference?

[Les:] Current format in the registries is to have only one reference.

Changing that is out of scope for this document.

FWIW, I am fine with a single reference.

> registry, both places, or neither place?

[Les:] These notes will be part of the final RFC.

The RFC number will also be listed in the “Reference” at the beginning of the registry. For example, currently we have:

https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-22-23-25-141-222-223

…

Reference

    [RFC5305][RFC5316][RFC7370][RFC8668]

[Les:] Not sure why you are worried nor what you are suggesting should be changed.

??

> (As above, why not list both?)

[Les:] See my response above.

   Les

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 11 Jun 2020 13:00:58 -0700

Hi Les,

> [Les:] “system ID” and “pseudo-node ID” derive from the IS-IS base specification [ISO 19589]

Ah, so definitely "super-obvious", and just a consequence of my never
actually getting my hands on a copy of ISO 19589 (obvious paths seem to ask
for 200 CHF).

Sorry for the noise; I will go clear now (and will respond to the comment
section later).

-Ben

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 11 Jun 2020 20:29:37 +0000

Ben -

Sorry - there was a typo - correct specification number is ISO 10589.
It is freely available here: https://standards.iso.org/ittf/PubliclyAvailableStandards/index.html 

   Les

> From: Benjamin Kaduk <[email-masked]>
> Sent: Thursday, June 11, 2020 1:01 PM
> To: Les Ginsberg (ginsberg) <[email-masked]>
> Cc: The IESG <[email-masked]>; [email-masked]; lsr-
> [email-masked]; [email-masked]; Acee Lindem (acee) <[email-masked]>;
> [email-masked]
> Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-isis-te-app-14: (with
> DISCUSS and COMMENT)
> 
> Hi Les,
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 12 Jun 2020 11:57:12 -0700

Getting back to the comment section (inline)...

> [Les:] Sorry – I do not understand this question.

The "user-defined" application bits are, well defined by the user.  In
order to make sure that the bits are interpreted by the recipient in the
way that the sender intends, there needs to be agreement among all parties
in question as to which bits map to which applications.  By its nature this
user-defined mapping is deployment-specific (and presumably not IS-IS
area-specific given Level 2 routing), but I would appreciate an explicit
statement about what the expected "deployment boundary" is where these
user-defined bits have a specific meaning.

> “Multiple Application Specific Link Attribute sub-TLVs for the same

Thanks for confirming.

> which are not relevant – but categorizing them as “not used by RSVP-TE” wouldn’t be completely accurate. For example, endpoint addresses (codepoints 6,8,12,13) are quite relevant to RSVP-TE as they…

Fair point.  I was trying to focus on the "this is not all sub-TLVs" part,
in case a reminder of that is helpful.  (It's certainly not required.)

> I think the existing text is correct.

Okay.  I was just noticing that we use the same "found in TLVs"
construction for the 22/23/... case and the 138/139 case, even though the
specific sub-structure in question takes a different form between those
groupings.
> [Les:] The scope is the set of sub-TLVs associated with the same link and the same application(s).

Okay, I think that matches what I expected, from reading this text.

> Note that if L-flag is set, no link attribute advertisements are permitted in the sub-TLV – so there is no reason to have multiple sub-TLVs for the same link/application in such a case.

Agreed, there is no reason to do so.  Part of my job as SEC AD is to make
sure that the proper behavior is clear (and not harmful) if someone decides
to do so anyway, triggering an edge case. :)
This particular edge case doesn't seem especially risky, so I'm happy to
leave this as-is if you want to leave it.

> I think that covers the “any application” case as well.

I think I was looking at that text when I wrote this comment, and wanting
the language used for the explicit-bitmask and zero-length-bitmask cases to
match as closely as possible.  But I do not insist.

> Do you have a suggestion?

I think my suggestion would be s/with a matching Application Identifier Bit
set/that has that application's bit set/.  Leaving it as-is should be fine,
too -- I was a bit prone to confusion when I was reading this just due to
my own mental state.
> Sooo, you are following along quite well, but in the case of Extended TE Metrics I would not use the term “exception”.

Understood.  I was just trying to match up the "except as noted below";
"exception" is not the best word to indicate that.

> “It is also possible to advertise a single advertisement with zero length SABM and UDABM so long as the constraints discussed in Section 4.2 and Section 6.2 are acceptable.”

Thanks!  (My main goal here was to avoid having the text diverge between
sections when there is not any functional difference.)

> [Les:] It would require a definition of an alternative RSVP protocol. If/when that occurs a revision to this restriction could be specified.

Okay, thanks for confirming.

> “Multiple occurrences of the same identifier type MUST NOT be present.”

Okay, thanks.  I assume this feels pretty natural to people that run this
stuff, and recognize that there's a lot of common knowledge that I don't
have :)

> We are simply reflecting the deployed reality.

Okay.

> In this case nothing in this draft depends on content in the SR Policy draft, but it is informative in providing context for the content of this draft.

I agree that it's correctly characterized as an informative reference.  I
was just noting that a consequence of that characterization,
draft-ietf-isis-te-app could be published/finalized before
draft-ietf-spring-segment-routing-policy, which introduces a (theoretical)
risk that we make a statement about the SR behavior that later becomes
false.  Given your explanation, I agree this risk seems purely theoretical
in this case, so we shouldn't do anything about it.

> I am comfortable with the current text.

Okay.

> I am open to revision if you really think this is important – so let me know if you feel strongly about this.

This is an editorial matter, and your preference reigns.

> FWIW, I am fine with a single reference.

Okay, I didn't know that the registry format was restricted in that way.

>     [RFC5305][RFC5316][RFC7370][RFC8668]

Sounds good.

> [Les:] Not sure why you are worried nor what you are suggesting should be changed.

If everyone expects a sequential allocation policy, then when
developing/testing, it's natural to look at "what's in the registry now"
and write code that uses the next value.  If three people do that at the
same time, we can end up with deployed software that has conflicting
interpretation of that value.  (This has happened for TLS, yes, with three
different extensions using the same value.)  My suggestion would be to not
say "SHOULD be assigned in ascending bit order", and perhaps just note
(without normative language) that it is advisable to allocate from the
lowest byte that has bits remaining, to allow for compact encoding.  It's
not actually necessary to be strictly sequential in order to minimize the
number of octets transmitted.

Thanks,

Ben

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 12 Jun 2020 19:45:00 +0000

Ben -

Top posting the open issues - as I think there are only two.

Issue #1

> > What is the scope over which the user-defined application bits are

LES: User defined applications are - by definition - outside the scope of this document/standardization.
We have simply defined the syntax of how to advertise associated bit mask.

How, for example, interoperability is achieved is up to implementors.
Whether they want an application to be area scoped or domain-wide is also up to them.

Issue #2

> > though in theory the user-defined bitmask should avoid the need for

You replied:

" If everyone expects a sequential allocation policy, then when
number of octets transmitted."

LES: I understand this concern. How about if we change policy to "Expert Review"?

   Les

> Sent: Friday, June 12, 2020 11:57 AM
> > [Les:] The point of Section 3.1 is to list the legacy sub-TLVs which are
> relevant to this draft. There are other sub-TLVs defined in
> https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-
> codepoints.xhtml#isis-tlv-codepoints-22-23-25-141-222-223
> >
> > which are not relevant – but categorizing them as “not used by RSVP-TE”
> wouldn’t be completely accurate. For example, endpoint addresses
> (codepoints 6,8,12,13) are quite relevant to RSVP-TE as they are required to
> uniquely identify the link – but they aren’t in the set of sub-sub-TLVs being
> defined.
> 
> > [Les:] The top level TLVs are the containers in which link advertisements
> are present. A given link advertisement consists of the fixed portion of the
> TLV and a set of sub-TLVs.
> >
> > Note that if L-flag is set, no link attribute advertisements are permitted in
> the sub-TLV – so there is no reason to have multiple sub-TLVs for the same
> link/application in such a case.
> 
> > 3)Extended TE Metrics MAY be application specific, but there are
> challenges in doing application specific performance measurement
> >
> >
> >
> > Sooo, you are following along quite well, but in the case of Extended TE
> Metrics I would not use the term “exception”.
> 
> > “It is also possible to advertise a single advertisement with zero length
> SABM and UDABM so long as the constraints discussed in Section 4.2 and
> Section 6.2 are acceptable.”
> 
> > [Les:] It would require a definition of an alternative RSVP protocol. If/when
> that occurs a revision to this restriction could be specified.
> 
> > [Les:] This property exists – largely because existing RSVP-TE specifications
> never defined a standard definition of enablement. Implementations
> therefore had to come up with an ad hoc solution.
> >
> > [Les:] My understanding of this oft discussed point is that the choice of
> Informative vs Normative Reference depends on the relationship between
> the two documents – not the current document status of the referenced
> document.
> >
> > In this case nothing in this draft depends on content in the SR Policy draft,
> but it is informative in providing context for the content of this draft.
> >
> > ??
> 
> > You are suggesting that we should add some explanation – but as this
> aspect of L-bit is clearly defined earlier in the document I would prefer not to
> distract from the normative statement by adding an explanation which has
> already been provided.
> >
> > The RFC number will also be listed in the “Reference” at the beginning of
> the registry. For example, currently we have:
> >
> >
> >
> > https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-
> codepoints.xhtml#isis-tlv-codepoints-22-23-25-141-222-223
> >
> > …
> >
> > Reference
> >

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 12 Jun 2020 21:15:01 -0700

> LES: User defined applications are - by definition - outside the scope of this document/standardization.

Yes.

> We have simply defined the syntax of how to advertise associated bit mask.

But if my implementation is built around (say) the meanings of the bits in
the bit mask being local to a single area, and your implementation is built
around them having meaning local to a full domain, when you try to send me
something from out of area it's not going to work so well.  Even without
saying what any given bit means, we can still say that "all systems in the
same <X> need to interpret each bit in the same way.  What is the smallest
<X> such that deployment is safe?

> Whether they want an application to be area scoped or domain-wide is also up to them.

I think leaving the question of area vs. domain up to the application is a
recipe for interop failures.

(A similar question presumably applies to the OSPF document, though I
didn't get a chance to actually review that one.)

> LES: I understand this concern. How about if we change policy to "Expert Review"?

I think that's moving on an orthogonal axis -- the TLS registry where we
had three extensions squatting on the same codepoint is a registry with
expert review.  (My expectation is that Standards Action is actually safer
in this regard than Expert Review would be, since there's enough points of
coordination in the process of advancing a standard that someone is likely
to notice the issue, but I don't have any hard data or proof to support
that expectation.)

To throw another concrete suggestion out there for focusing comments,
perhaps

OLD:

                                                              Bit
   transmitted.  

NEW:

   Allocating all bits from the first octet before allocating any bits from
   the second octet, etc., provides for the smallest possible encoding when
   transmitted.

(After all, who is supposed to adhere to the original's "SHOULD"?  The IETF,
as it undertakes its Standards Actions?  Our track record on one RFC
constraining what future RFCs do is hardly perfect.)

-Ben

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sat, 13 Jun 2020 17:01:41 +0000

Ben -

Inline.

> Sent: Friday, June 12, 2020 9:15 PM

[Les:] If interoperability between implementations is a concern, then the obvious choice is to use a standardized application.

Placing limits on the scope of a user defined application is both unnecessary and unenforceable. I say "unenforceable" because, if you have a mixed vendor network, there is no guarantee that User Bit X means the same thing to both implementations. And since I cannot tell the identity of the implementation originating an advertisement, I cannot tell if the User Bit advertised in Area Scoped LSPs (Level-1 in IS-IS speak) has the same meaning as the same bit advertised in Domain-wide LSPs. So I cannot detect when a violation occurs.

To me, User Defined Application is a space for implementations to do whatever they choose - subject to the syntax rules defined in the draft. Maybe they use it as an experimental space for something they will eventually standardize. Maybe they use it to implement a proprietary application that they have no intention of standardizing. As it does not impact operation of the standard applications, I see no reason or benefit for the draft to impose restrictions.

As context, User Defined was added based on comments received from some WG members. It isn't needed to support the goals of the draft. It is an option that at least some members felt was desirable to have.

> to notice the issue, but I don't have any hard data or proof to support
[Les:] Standards action is limited (by https://tools.ietf.org/html/rfc8126#section-4.9 ) to Standards track and BCP.
This does not allow for Experimental track. So I think it is better to move to "Expert Review".

>    the second octet, etc., provides for the smallest possible encoding when

[Les:] OK. How about:

"Bit definitions SHOULD be assigned such that all bits in the lowest available octet are allocated before assigning bits in the next octet. This minimizes the number of octets that will need to be transmitted."

??

   Les

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 13 Jun 2020 12:03:14 -0700

Also inline.

> Placing limits on the scope of a user defined application is both unnecessary and unenforceable. I say "unenforceable" because, if you have a mixed vendor network, there is no guarantee that User B…

I see your point about being able to "detect a violation".  That you are
focusing on this aspect makes me suspect that my point did not come across
quite as intended, though.  I don't feel a need to make a normative
statement like "User Bits MUST be agreed upon at Domain-wide scope", since
if anything that's trying to place a requirement on the operator, and our
role is mostly just to inform the operator so they can make their own
decisions.  As such, I'd be thinking more along the lines of "when
user-defined bits are used, all routers that receive such information have
to agree on their meaning, or breakage can occur.  Minimally, this implies
that all machines in a given area need to use the same mapping of user-bit
to application, and it's safest to ensure agreement across the entire
domain."  (But with more wordsmithing, of course.)

> To me, User Defined Application is a space for implementations to do whatever they choose - subject to the syntax rules defined in the draft. Maybe they use it as an experimental space for somethin…

It's also interesting to me that you are picturing this as a
per-implementation thing -- the "user" in the name had me expecting it to
be something that implementations expose as a configuration knob, so that
the operator would control what bit maps to which application.  If there is
such a configuration knob then our guidance to the operator gains
importance; if not, then any discussion of how to choose user-bits would
only be targetted to the implementation, in which case your stance of not
saying anything makes a fair bit of sense.

> As context, User Defined was added based on comments received from some WG members. It isn't needed to support the goals of the draft. It is an option that at least some members felt was desirable…

It does seem useful to me, to have a defined path for experimentation that
cannot conflict with the standards-assigned space.

> "Bit definitions SHOULD be assigned such that all bits in the lowest available octet are allocated before assigning bits in the next octet. This minimizes the number of octets that will need to be…

Ship it :)

Thanks,

Ben

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 15 Jun 2020 23:31:58 +0000

Ben -

V16 has been published addressing your comments on the new registry.

At this point I am not planning any additional changes to the document.

If you still want to discuss UDA related issues (or anything else), please let me know.

Thanx.

    Les

> Sent: Saturday, June 13, 2020 12:03 PM
> > > > LES: User defined applications are - by definition - outside the scope of
> this
> > > document/standardization.
> > >
> > > Yes.
> > >
> > > > Whether they want an application to be area scoped or domain-wide is
> also
> > > up to them.
> > >
> > [Les:] If interoperability between implementations is a concern, then the
> obvious choice is to use a standardized application.
> >
> > Placing limits on the scope of a user defined application is both unnecessary
> and unenforceable. I say "unenforceable" because, if you have a mixed
> vendor network, there is no guarantee that User Bit X means the same thing
> to both implementations. And since I cannot tell the identity of the
> implementation originating an advertisement, I cannot tell if the User Bit
> advertised in Area Scoped LSPs (Level-1 in IS-IS speak) has the same meaning
> as the same bit advertised in Domain-wide LSPs. So I cannot detect when a
> violation occurs.
> 
> > To me, User Defined Application is a space for implementations to do
> whatever they choose - subject to the syntax rules defined in the draft.
> Maybe they use it as an experimental space for something they will
> eventually standardize. Maybe they use it to implement a proprietary
> application that they have no intention of standardizing. As it does not impact
> operation of the standard applications, I see no reason or benefit for the
> draft to impose restrictions.
> 
> > As context, User Defined was added based on comments received from
> some WG members. It isn't needed to support the goals of the draft. It is an
> option that at least some members felt was desirable to have.
> 
> > > > LES: I understand this concern. How about if we change policy to
> "Expert
> > > Review"?
> > >
> > [Les:] Standards action is limited (by
> https://tools.ietf.org/html/rfc8126#section-4.9 ) to Standards track and BCP.
> > "Bit definitions SHOULD be assigned such that all bits in the lowest available
> octet are allocated before assigning bits in the next octet. This minimizes the
> number of octets that will need to be transmitted."
> >
> > ??
> 
> Ship it :)
> 
> Thanks,
> 
> Ben
> 
> >    Les
> >
> > >