[Teas] Benjamin Kaduk's practice ballot (No Objection) on draft-ietf-teas-rsvp-egress-protection-13 (with COMMENT)

[Benjamin Kaduk <[e-mail]>]

[incoming AD ramping up on document reviews; please consider this as
if it was a ballot of No Objection with COMMENT]

In general it's hard for me to get excited about publishing this
document as-is, though most of this is not in areas that qualify for
a DISCUSS ballot.  Perhaps the suggested security considerations
changes could qualify for a DISCUSS, though.

Mostly I feel that the overall document organization is a little
jumbled and potentially under-specified.  I'd like to see in the
Introduction some overview of the different ways this technology
could be deployed -- it seems like there are options for both the
ingress and the primary egress to initiate its use, and it could be
helpful to get some advance indication of which subsections
correspond to which of those.

I also would like to see a little discussion about why this new protocol is
useful -- I can understand what it *does*, but why is putting the PLR closer
to egress beneficial, and why is the egress considered more likely to fail
than an arbitrary node on the LSP?

There are also some areas where the organization seems surprising,
such as Section 4.1 where we learn that the SERO to be used for this
new protection scheme will have three subobjects, but we only get
told what the first and third subobjects will do, not what type(s)
they might be.  The second subobject does get a diagram for its
structure, since it's new in this document, but the discussion of
the third subobject in the SERO is interspersed between that
description and the structure of the optional subobjects that it
could contain (which could confuse the reader into thinking that
these optional subobjects being defined are candidates for the third
subobject in the SERO and not sub-subobjects within the C-Type 3
subobject.  (The mathematician in me gets unhappy about seeing a
thing called a "subobject" that itself has "subobjects" that are a
different semantic type, but I expect this is common in the field
and I should just get used to it.)

There are also several places where we are told of a need to
construct new SERO (or other) (sub)objects but only told about
(presumably) the "new" parts of them, with no description or
reference for how the remaining parts should be constructed.


Some more specific comments follow:


Section 4.1 says "Reserved parts MUST set to zero" (missing a "be"),
but these should also be ignored by the recipient, presumably?


Why do the optional subobjects get a 17-bit length when the outer
subobject only has an 8-bit length?  (Also, if the length is
intentionally 17 bits instead of 16, that should probably be called
out as not an error in the figure.)

I would prefer to see a table of the type values for the optional
subobjects instead of spreading them throughout the subsections, but
concede that it is an editorial point.

For the "new SERO based on the SERO received" (in the second-to-last
paragraph of section 4.1), what is the first subobject of the three?

Section 5.1:

    The ingress MUST send a Path message for the LSP with the objects
    above and the SEROs for protecting egresses of the LSP.

Presumably this is only if protection of the egress is desired?


Section 5.2

   If the LSP carries the service traffic with a service label, the
   primary egress sends its corresponding backup egress the information
   about the service label as a UA label and the related forwarding.

Do you want to say anything about what protocol messages are used
for this or give a reference?  Or is this the same sort of thing
labelled as out-of-band or out-of-scope later in the document?


Section 5.4

I assume "upstream node" means the PLR, i.e., directly upstream (as
opposed to just on the LSP) -- is this a term of art or should it be
clarified?


Section 5.4.2

   It indicates that the primary egress MUST send the backup egress
   the service label as UA label and the information about forwarding
   the traffic to its destination using the label if there is a service
   carried by the LSP and the primary LSP label as UA label if the label
   is not implicit null.  How UA label is sent is out of scope for this
   document.

It's hard to be happy about MUST-level requirements that require the implementor
to do their own protocol design.  Or could this be done by BGP, as
implied later in the document?


Section 5.4.4

   Moreover, the PLR MUST let the upstream part of the primary LSP stay
   after the primary egress fails through sending Resv message to its
   upstream node along the primary LSP.

What does "stay" mean here?


Section 6.1, Figure 3, item 4 makes me think that the use or a virtual node
and binding the same local address on both L1 and La is mandatory, but the
earlier text in section 5.4 made me think that the use of a virtual node was
optional, only needed in the case when the backup egress is not configured
explicitly for protecting a primary address.  Is the use of a virtual node
mandatory or not?


The security considerations refers to RFC 4090, which itself claims to add
no new security considerations other than those of RFC 2205 (and then says a
little bit more anyway).  Probably this document should reference RFC 2205
directly.  RFC 4875's security considerations also have this "In principle
this document does not introduce any new security issues above those defined in
[...]", followed by two additional paragraphs of additional security
considerations.  It seems simpler to just say something like "The security
considerations of RFCs 4090, 2205, and 4875 all apply here.  Additionally,
[...]".  The cross-protocol identity management mentioned in this document is
indeed a key issue, and could probably be worded more clearly.  Perhaps:

    This document builds upon existing work, so in particular the security
    considerations of RFCs 4080, 2205, and 4875 continue to apply.  Additionally,
    this protocol introduces a requirement for out-of-band communication between
    primary egress and secondary egress, in order to convey UA label and LFIB
    information.  It is important to confirm that the identifiers used to identify
    the primary and backup egress nodes in the LSP are verified to match with the
    identifiers used in the out-of-band protocol (such as BGP).

I would also encourage adding some text about providing integrity protection
for the out-of-band channel between primary and backup egress (it's less clear
to me whether confidentiality protection is desired), including the obligatory
disclaimer about the sad state of affairs for BGP.


The IANA considersations are a bit sparse, in particular a descriptive name
could probably be used instead of just "Type 3" (the precedent
notwithstanding), and IANA likes to get more information when creating new
(sub)registries.  It's also useful to cite RFC 8126 for the "IETF Review"
policy.


-Benjamin