Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-isis-genapp-03.txt

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 4 Oct 2010 11:09:26 -0700

Nabil -

Thanx for the detailed review.
Responses inline.

> -----Original Message-----
> From: Bitar, Nabil N [mailto:[email-masked]]
> Sent: Monday, October 04, 2010 7:32 AM
> To: [email-masked]; Les Ginsberg (ginsberg); Stefano Previdi
> (sprevidi); Mike Shand (mshand)
> Cc: [email-masked];
> Subject: RtgDir review: draft-ietf-isis-genapp-03.txt
> 
> 
> Hi,
> 
> I have been selected as the Routing Directorate reviewer for this
> draft. The Routing Directorate seeks to review all routing or routing-
> related drafts as they pass through IETF last call and IESG review.
The
> purpose of the review is to provide assistance to the Routing ADs. For
> more information about the Routing Directorate, please see
> http://www.ietf.org/iesg/directorate/routing.html
> 
> Although these comments are primarily for the use of the Routing ADs,
> it would be helpful if you could consider them along with any other
> IETF Last Call comments that you receive, and strive to resolve them
> through discussion or by updating the draft.
> 
> Document: draft-ietf-isis-genapp-03.txt
> 
> Reviewer: Nabil Bitar
> Review Date: October, 03, 2010
> IETF LC End Date: date-if-known
> Intended Status: Standards
> 
> Summary:
> 
> 
> I have some minor concerns about this document that I think should be
> resolved before publication.
> 
> Comments:
> 
> This draft describes a mechanism that enables advertisement of generic
> information, and specifically application support and associated
> attributes, by a router via IS-IS. The document is generally well-
> written, but some clarifying text and re-ordering of text will improve
> completeness and readability as noted in this review. The major area
> that needs clarification is related to section 4.3 and the processing
> of different GENINFO information with same GENINFO Context (GENINFO-
> CTX) at a receiving node.
> In general, There are interesting applications that can take advantage
> of the capability introduced in this document. However, it will help
> the reader if an example or examples of applications that can make use
> of this capability are covered in the Overview section for instance.
> The authors may have applications in mind. An example of such
> applications can be the support for a Path Computation Element on a
> router, or the support for an Application Layer Transport Optimization
> (ALTO) server. The authors can choose these examples, if they believe
> they are applicable or other examples.

The introduction of GENAPP is a begrudging acceptance of the fact that
there have been requests to use the reliable flooding mechanism of the
IGPs (IS-IS in this case) to send information which is not used by the
protocol in support of routing. The authors in fact would have preferred
that this not be necessary - and don't really want to encourage this
usage - which is one of the reasons we did not provide an example.
Instead we focused on the correct way to use this extension.

PCE - as defined in RFC 5089 - uses the the router capability TLV as it
was defined BEFORE GENAPP existed. I agree it would have been a good use
case for GENAPP had GENAPP been defined at the time - and in fact PCE
was one of the reasons we decided to invent GENAPP before other use
cases come along.

To my knowledge ALTO has no requirement for using GENAPP.

> 
> Major Issues:
> 
> - Section 4.3
> In the first paragraph first sentence, you state: "Where a receiving
> system has two copies of a GENINFO TLV with the same GENINFO-CTX,
> attribute information in the two TLVs which does not conflict MUST be
> considered additive.". Additive in the sense that you take the union
of
> the two, right?

Correct.

> In addition, the last sentence leaves the behavior undefined when
> processing received GENINFO with same GENFO-CTX.  This is a concern,

This is deliberate. There is no way to reliably determine which
information is newer in such cases.

> 
> This section is not clear and the processing rules need to be
> tightened, as based on the description you are not disambiguating what
> information is valid or not (stale). It seems to me that processing
> rules based on GENINFO-CTX, flooding scope, encapsulating LSP
lifetime,
> encapsulating PDU type, and the level of the receiving node taken
> together should provide a better way for processing rules. I request
> that this section be revisited and the processing rules be better
> developed and articulated.

There are no changes to the normal operation of the IS-IS Update process
which is defined in ISO 10589. That specification covers the issues you
raise (lifetime, PDU type, level, etc.). Any attempt to discuss them
here would be ill-advised as it would suggest that we have somehow
changed them for GENAPP - which is NOT true.

> 
> 
> Minor Issues:
> 
> -Abstract: " This draft describes the manner in which generic
> application information (i.e. information not directly related to the
> operation of the IS-IS protocol) SHOULD be advertised in IS-IS LSPs
and
> defines guidelines which SHOULD be used when flooding such
> information."
> 
> (1) The first SHOULD is justified as other mechanisms could be used
but
> this is a recommendation to use the mechanism defined in this
document.
> However, I think the second SHOULD needs to be replaced by MUST as
> relayed in the later parts of the document, and specifically in the
> flooding section and leaking section. Alternatively, you may say: ...
> and defines guidelines for flooding and leaking such information.

SHOULD is used here because we recognize that many of the guidelines
defined in the document are unenforceable i.e. as the advertisement of
new TLV information does not introduce interoperability issues a vendor
may choose (for example) to advertise GENAPP in instance 0 - despite our
strong recommendations not to do so.

> 
> (2) In addition, What is defined in this document has implication on
> the operations of IS-IS protocol, albeit it does not impact IS-IS for
> the purpose of IP routing. Therefore, I suggest the following change:
> (i.e. information not directly related to the operation of the IS-IS
> protocol)  --> (i.e., information that does not relate to IGP routing
> table computation or IP network
> topology and traffic Engineering information dissemination and
> discovery).

The manner of defining what information qualifies for GENAPP and what
does not received considerable scrutiny during the WG review. Traffic
engineering information in particular was a point of discussion. Had
GENAPP existed when TE requirements were defined it may well have been
the case that GENAPP could have been used to advertise TE information.
In Section 6 we state:

"The applicability statement above is expected to cover some
   information currently being advertised by IS-IS in previously defined
   TLVs."

Rather than specifically call out TE as something which is NOT
applicable to GENAPP we have deliberately left the door open to allow TE
to be moved to GENAPP if there is consensus to do so. Note that we do
not expect this to happen - nor are we advocating that it should happen
- but it should not be ruled out as a possible alternative.

> 
> - Section 2 (Overview):
> 
> (1)  I suggest adding text in this section for example applications
> that can take advantage of the capability introduced in this document
> as a use case. Such text will give better context to the reader.
Often,
> such examples/uses cases are found in requirements documents that
> define the reason a problem needs to be solved, but in the absence of
> that it would be useful to have a synopsis of that in this section.
> Candidate examples are mentioned earlier.
> 
> (2) second paragraph, I suggest adding the word "processing" to the
> text so that it reads as follows: This document also discusses optimal
> behavior associated with the
>    advertisement, processing, and flooding of LSPs containing GENINFO
> ......

OK

> 
> (3) Last paragraph, having the GENINFO advertisement in a non-zero
iIS-
> IS instance should be recommended but not mandated. Accordingly, I
> suggest changing MUST to SHOULD as follows: "In order to minimize the
> impact advertisement of GENINFO may have on the operation of routing,
> such advertisements MUST occur in the context of a non-zero instance
of
> the IS-IS protocol as defined in [I-D.ietf-isis-mi]."  -->  In order
to
> minimize the impact advertisement of GENINFO may have on the operation
> of routing, such advertisements SHOULD occur in the context of a non-
> zero instance of the IS-IS protocol as defined in [I-D.ietf-isis-mi].

Our choice of wording here was deliberate. We want to mandate the use of
a non-zero instance. If an exception to this policy is needed it would
need to be reviewed - which is what we state.

> 
> - Section 3.1
> 
> (1)  I suggested adding "IS-IS" as noted in the following, starting on
> page 4:
> "S bit (0x01): If the S bit is set(1), the GENINFO TLV MUST be flooded
> across the entire routing domain. If  the S bit is not set(0), the TLV
> MUST NOT be leaked between levels. This bit MUST NOT be altered during
> the TLV leaking." --> S bit (0x01): If the S bit is set(1), the
GENINFO
> TLV MUST be flooded across the entire IS-IS routing domain, across IS-
> IS levels/area. If  the S bit is not set(0), the TLV MUST NOT be
leaked
> between IS-IS levels/areas. This bit MUST NOT be altered during the
TLV
> leaking.

I do not object to this change - but it seems unnecessary as clearly the
IS-IS Update process can only operate on areas/domain known to IS-IS.

> 
> (2) GENINFO-REG  acronym is used for the first time without definition
> in the definition of Application ID:  "Application ID An identifier
> assigned to this application via the GENINFO-REG." It can be defined
> earlier where you talk about establishing a new registry for
> application IDs.

Yes - this point has been made by another reviewer in a more general way
and I agree this should be done.

> 
> (3) Question: for IP addresses associated with an application,
wouldn't
> it be better if the application has an IPv4 and an IPv6 address
> associated with it to be able to advertise that in the same TLV when
> the other attributes do not change between the two. That can be
> achieved by allowing the "I" and "V" bits to be simultaneously set in
> the flag, and mandating for instance that when the I and V bits are
> set, the first IP address following the flag will be an IPv4 address
> followed by an IPv6 address. What is your current procedure in this
> case? Is it to have one GENINFO TLV with the same application ID for
> IPv4 and another for IPv6?

Use of both an IPv4 and an IPv6 address in a single TLV is allowed. In
such a case the IPv4 address would occur first in the TLV followed by
the IPv6 address. This is stated in Section 3.1 in the description of
the V bit:

" V bit (0x08): When the V bit is set, the 16 octet IPv6
                 address associated with the application immediately
                 follows either the Application ID (if I bit is clear)
                 or the IPv4 address (if I bit is set)."

> In addition, it would be good to include a
> sentence here stating that how the IP address associated with an
> application ID is generated will be application dependent and
specified
> in the a respective application-specific document that makes use of
> this mechanism.

We do state:

" The IPv4[IPv6] address associated with the application. This
                 is not necessarily an address of a router running the
                 IS-IS protocol."

This clearly leaves the manner in which the address is chosen to be
outside the scope of this document.

> 
> (4) Under  "Additional Application Specific Information" definition,
> shouldn't TLV be sub-TLV in the following: "Each application may
define
> additional information to
>                 be encoded in a GENINFO TLV following the fixed
> information." That is, change GENINFO TLV to GENINFO sub-TLV.

We allow that an application MAY choose to encode additional information
directly after the fixed information defined in the document without
using sub-TLVs - so the current wording is correct.

> 
> - Section 3.2
> 
> (1) 4th paragraph first sentence. I suggest the following change or
> similar rewording for clarity: "The use of additional levels of
subTLVs
> is discouraged due to the
>   inherent inefficiency in encoding introduced because the parent
> subTLV must encode  the nested subTLV length."  ---> Nested sub-TLVs
> introduce encoding inefficiency due to the fact that  the parent TLV
> and parent sub-TLV must account for the length of nested sub-TLVs in
> each context.
> 
> (2) Can you please explain what you mean in the following sentence. It
> is not clear to me what you mean by the "one additional octet" as the
> length is accounted in the parent TLV/sub-TLV length value.  "While
> this inefficiency  is small (one additional octet), it may be
> sufficient to extend the total information about a single application
> object beyond the
>    carrying capacity of a single GENINFO TLV. "

I agree that the current text is both inaccurate and confusing. I
suggest that the first two sentences be rewritten as follows:

"The use of additional levels of subTLVs is discouraged due to the
   inherent inefficiency in encoding introduced when the parent
   subTLV is used solely to scope the set of sub-TLVs it contains.
While this inefficiency
   is small (two additional octets),..."

> 
> - Section 3.3
> 
> This section refers to public documents in the first and last
> paragraph. Public document is a very broad reference. What form of a
> public document? An IETF draft/RFC, a specification generated by
> another standard body maybe after liaising with IETF (or not)?
Document
> published by a vendor that can appliy for an application ID from IANA
> as stated earlier? Or anything that is made public?. I am not sure why
> this should be referenced here. If something is done by a vendor for
> instance or an application developer but not by a standard body, it is
> categorically proprietary or vendor-specific although it is publically
> made available. Is the assumption that applications can come from
other
> standards bodies as well? Are there restrictions or obligations? For
> instance, does assigning an application ID require review by IETF as
it
> is carried by IS-IS?
> This section requires clarification. Your clarification is appreciated
> as to the intention(s).

The forum in which the document used to define the application is beyond
the scope of this draft. However, we do make two very important
stipulations:

1)In Section 3.3 we require that there be a public document. We
specifically do NOT allow proprietary/experimental use of GENAPP.

2)In Section 8 we stipulate "Specification Required" as defined in RFC
5226.

> 
> - Section 3 overall:
> 
> Some procedural description that relates to the generation of GENINFO
> TLVs is missing from this section. In particular, it seems to me that
> to complete this section, you should explicitly state that one or more
> GENINFO TLVs can appear in each LSP (it does not come out explicitly).
> In addition, what makes a GENINFO TLV unique is the GENINFO-CTX
defined
> by the application ID and associated IP address. Thus, GENINFO TLVs
> that share the same GENINFO-CTX with the same flooding scope (in a
way,
> it seems to make sense if the flooding scope is part of the GENINFO
> context definition) are comparable in terms of generating updates,
> comparing attributes, and/or determining what is more current. I
> suggest that some of the text in the first two sentences of the second
> paragraph under section 4 be pulled within section 3 under a separate
> subsection titled "Rules for GENINFO encoding" and have the section of
> title 3 changed to "GENINFO encoding".

Section 3 discusses the format of the information within a given TLV.
Section 4 discusses issues associated with flooding/leaking encoded
information.

I don't think mixing these two types of information in a single section
(even partially) would aid clarity.

I would be happy to add the following to Section 3.1:

"GENINFO TLVs may appear in any LSP and multiple GENINFO TLVs may appear
in the same LSP."

> 
> - Section 4.1
> First paragraph, it should state clearly what is being compared to
> determine duplication or more recent update. In particular, as stated
> in an earlier comment, it seems to me that you can compare two GENINFO
> TLVs  for duplication or currency when they share the same context and
> flooding scope. Would you agree?  If you do, that should be spelled
> out.

As stated above, in cases of duplication it is impossible to know in any
reliable way which copy is newer.

> 
> - Section 4.2
> Last paragraph suggests a holddown time from the reception of a
GENINFO
> TLV before processing.  While the benefit is mentioned, the tradeoff
> should also be mentioned. That is, the longer the holddown time is,
the
> more latency can be incurred in propagating potentially current
> information.

The section is discussing how to address cases where the complete update
may be contained in multiple LSPs. It does not suggest that the holddown
time should be applied to proagation. It only suggests that the local
system may wish to delay processing for a time so that it does not
process a partial update. Whether or not this strategy is beneficial to
a given application depends on the information advertised.

> 
> 
> Section 6:
> (1) I suggest the following change for the first sentence:
> "The GENINFO TLV supports the advertisement of application specific
> information in IS-IS LSPs which is not directly related to the
> operation of the IS-IS protocol." -->
> The GENINFO TLV supports the advertisement of application specific
> information in IS-IS LSPs which is not directly related to the
> operation of IP routing or Traffic Engineering as provided by the
IS-IS
> protocol.

I have responded to this above.

> 
> 
> 
> 
> Nits:
> 
> (1) Make sure IS-IS is used consistently across the document. In
> certain cases you use ISIS, and in others IS-IS. Replace ISIS with IS-
> IS

Agreed.

> (2) Replace subTLV with sub-TLV

Agreed - this is consistent w RFC 5305.

> (3) The first reference in section 10.1, make sure that the reference
> description starts on the same line as the reference code.

Agreed.

  Les

> Thanks,
> Nabil

---

From: "Bitar, Nabil N" <[email-masked]>
Date: Thu, 7 Oct 2010 09:26:05 -0400

Hi Les,
You are welcome. Please see inline as denoted by <NB>.

Thanks,
Nabil

On 10/4/10 2:09 PM, "Les Ginsberg (ginsberg)" <[email-masked]> wrote:

Nabil -

The

<NB> Understood and I understand the concern.  However, the fact is that this was triggered by
requests as you state that must have been triggered by applications that made
 enough of a case to define the extension in this document. The concerns are expressed in the document
 when you discuss the strong recommendation to run in a non-zero instance of IS-IS. Given all that, I still think
it would helpful to mention an example of an application that probably was expressed as part of the requests.
I am not sure if I would consider that an encouragement but the fact is the extension in this document will be availble
for use and people will make jusdgment how to use tit or enable it.

<NB> That is what I thought. I understand the existing support for PCE. However, what triggered my suggestion
is the applicability of the extension here to the PCE application, and what you state in the applicability section of this
         document: " The applicability statement above is expected to cover some information currently being advertised by IS-IS in previously defined
TLVs.  It is expected and seen as desirable that an effort be made to migrate the advertisement of such information to utilize the
  procedures defined in this document." So, why not mention this as ana application example?

To my knowledge ALTO has no requirement for using GENAPP.
<NB> Understand. So, Iwas thinking about potential uses. If an ALTO server is running on a router and there is need for ALTO servers to discover and communicate
with each other, there can be an application here. It is fair though to say that was not expressed or documented. You may disregard that.  Gaian, I was stating examples that
could have been used to make the case for the extensions here.
of

Correct.

lifetime,

<NB> I am suggesting to discuss them here in the general sense nor to change them. What I am suggesting
is to use to define how that information can be used to determine which GENINFO is newer since this is explicitely stated as you also noted
above remains unresolved. I think that information in combination of how GENINFO is generated should provide rules for determining what GENINFO
is newer, which is important. Otherwise, applications may be acting on stale information.  I am still not clear why this cannot be done.
Can you please explain?

and
but
document.

<NB> To be clear, I am referring to the guidelines on flooding. I am fine
with the recommendation on using non-zero instance (what I referred to as the first SHOULD) and
I agree that cannot be enforced. SO, I am referring to the SHOULD that relates to flooding and the suggestion
to change that to MUST. In the document section 4 last paragraph before section 4.1, you state:
"Each GENINFO TLV contains information regarding exactly one
  application instance as identified by the GENINFO-CTX[NB17].  When it is
  necessary to advertise sets of information with the same GENINFO-CTX
   which have different flooding scopes, a router MUST originate a
  minimum of one GENINFO TLV for each required flooding scope.  GENINFO
   TLVs which contain information having area/level scope will have the
   S bit clear.  These TLVs MUST NOT be leaked into another level.
  GENINFO TLVs which contain information which has domain scope will
   have the S bit set.  These TLVs MUST be leaked into other IS-IS
  levels.  When a TLV is leaked from level-2 to level-1, the D bit MUST
   be set in the level-1 LSP advertisement."
 This paragraph uses MUST in defining  the flooding and leaking procedures This is
Not inline to what is expressed in the abstract. Are you saying that the MUSTs in this paragraph
Need to be changed to SHOULD's then? I don't think that should be the case. I think the change
Needs to be made in the abstract to be in sync with this paragraph. The MUSTs and SHOULDs are not because
What can be enforced or not but because what is needed to have correct behavior.

<NB> Understood. However, the current wording says the information does not relate to the operation
of IS-IS. What I am simply suggesting that to clarify that as this information has implication on IS-IS protocol operation, but it does
not impact IP routing. If you think that TE does not need to be mentioned for the reasons you stated, it is fine although I may have different opinion on
the applicability of moving TE to GENAPP but this is not the place to discuss that and not needed either.

Often,

OK

<NB> Thanks.
iIS-
of
to

<NB> To your point earlier point on the inability to enforce a guideline, I am not sure how this can be enforced.
In addition, the document leaves the option of using non-zero instance of IS-IS as open, although rightfully
though is not recommended.  Here is what the document says leaving that option open in the following sentence to what is
stated above: " Advertisement of GENINFO therefore MUST occur in the context of a  non-zero instance of the IS-IS protocol as defined in
  [I-D.ietf-isis-mi].  Exceptions to this policy MAY be allowed only when there exists a standards track RFC which defines the
  application."   I think allowing execeptions to happen and using the MAY, makes the first sentence as a strong recommendation but not a mandate.

GENINFO
leaked
TLV

<NB> I agree. I thought it would make it clearer. However, I am fine if that change is not made.

<NB> Thanks.
wouldn't

<NB> Somehow I missed that. I am good with it as it captures what I intended to say. It is
also implied in the encoding diagram.

specified

We do state:

<NB> It could be implied. I am suggesting to state more explicitly that the application-specific document must
define that.

define

<NB> I read it differently based on the word ordering.  I can see the option of  allowing
additional information to be encoded without using sub-TLVs. If I may suggest another
word ordering that I think would make it clearer:  "Each application may define additional
information to follow the fixed information part in a GENINFO TLV".
subTLVs

<NB> Sound good.

Document
other
it

<NB> Section 8 is fine. I would suggest that in section 3.3., you add a sentence or 2 at the end that say something to the extent of:
"The application must be registered with IANA as discussed in Section 8. The public document describing the application must support the registration process as defined in RFC 5226 [RFC 4226]".

defined
way,

<NB> I am not suggesting mixing the two. What I am suggesting that these two sentences really belong
in section 3 as they are related to how to generate GENINFO TLVs not how to flood them. The remaining part in section 4
remains in the flooding section. The 2 sentences I am suggesting to move are:
" Each GENINFO TLV contains information regarding exactly one
  application instance as identified by the GENINFO-CTX.  When it is
  necessary to advertise sets of information with the same GENINFO-CTX
   which have different flooding scopes, a router MUST originate a
 minimum of one GENINFO TLV for each required flooding scope."

If you decide not to move them, it is fine.

<NB> That will be fine.

<NB> Let me try the following reasoning and what I am thinking, and please tell where the gap is or the fallacy
(1) If a receiving node receives two IGENINFO TLVs in two different LSPs (different ID's) with the same GENFO-CTX and same local flood scope then the one contained in an LSP with the longer lifetime is newer. If there iare common attributes being shared between two GENINFO T:Vs one with IS-IS domain-wide flooding scope and a local-area scope, the same attributes must be present in each and the values in the local scope GENINFO TLV will take precedence.
(2)  If a receiving node receives two GENINFO TLVs in two different LSPs (different IDs) with the same GENFO-CTX and domain-level scope but with IPv4/IPv6 application address that is reachable in another area (ie., a GENINFO TLV generated in level 1 but leaked into level2,  then the one contained in the the LSP with longest lifetime is more recent
(3)  If a receiving node receives two GENINFO TLVs in two different LSPs (different IDs) with the same GENFO-CTX and domain-level scope but with IPv4/IPv6 application address that is reachable in another area with D-bit set (leaked from level2 to level1), then the one contained in the the LSP with longest lifetime is more recent
....

GENINFO
the

The section is discussing how to address cases where the complete update
may be contained in multiple LSPs. It does not suggest that the holddown
time should be applied to proagation.
<NB> So, (1) are you saying you propagate that information before you process it?
and (2) locally, you have the implication that you may be holding on processing most recent information.
I agree you that is application dependent and configuration dependent.

 It only suggests that the local
system may wish to delay processing for a time so that it does not
process a partial update. Whether or not this strategy is beneficial to
a given application depends on the information advertised.

IS-IS

Agreed.

Agreed.

  Les

> Nabil

---------------------------------------------
Nabil Bitar, PhD
Principal Member of Technical Staff
Packet Network Technology
Verizon Corporate Network and Technology

117 West Street
Waltham, MA 02451
Office Phone: (781) 466-2161