Subject: [Isis-wg] Comments on draft-ietf-isis-layer2-05.txt

From: mike shand <[email-masked]>
Date: Wed, 05 May 2010 14:17:12 +0100

I enclose some detailed comments on draft-ietf-isis-layer2-05.txt, 
mostly regarding typos and clarifications required.

However, I have more serious concerns about the inclusion of the 
overload bit in various random places, and the gratuitous introduction 
of various reserved fields.

Whatever the outcome of the ongoing major discussions about the 
document, these items also need addressing.

     Mike

comments on draft-ietf-layer2-05.txt

2.2.1.  The Group MAC Address sub-TLV

Why is there an 8 bit reserved field at the start of every group record? 
Presumably this is to attempt to word align the group records, but IS-IS 
(unlike OSPF) does not attempt word alignment.

2.2.2.  The Group IP Address sub-TLV

typo s/The Group IP Address (GIP-ADDR) sub-TLV IS-IS sub-TLV type 2 /The 
Group IP Address (GIP-ADDR) sub-TLV is IS-IS sub-TLV type 2 /

Same comment about reserved field

2.2.3.  The Group IPv6 Address sub-TLV

again, the gratuitous reserved field

2.3.  Multi Topology aware Port Capability TLV

Replicating the overload bit in a hello PDU is new to IS-IS. It would be 
helpful to have some rationale for this and/or a description of how it 
is meant to be used.

"The MT-PORT-CAP TLV may occur multiple times, and is carried only
    within a Hello PDU."

The assumption, then is that this may appear in ANY form of hello PDU. 
Is that correct?

2.3.1.  The Special VLANs and Flags sub-TLV

"The Special VLANs and Flags (VLAN and Flags) sub-TLV MUST only appear
    in a MT-PORT-CAP TLV.  It is carried exactly once in every TRILL IIH
    PDU.  It has the following format:"

The implication, then, is that a TRILL IIH which does NOT contain this 
TLV is invalid. Presumably such a TRILL IIH should therefore be ignored. 
Is that correct, and if so is there some statement in the TRILL spec to 
that effect?

2.3.2.  Enabled VLANs sub-TLV

The description of the bit vector is very confusing, especially since it 
focusses on byte 3. In fact it is simply a bit vector where the first 
bit (i.e. highest order bit of byte 3) corresponds to the VLAN with the 
starting ID.

2.3.3.  Appointed Forwarders sub-TLV

typo s/The Appointed Forwarder sub-TLV provides/
The Appointed Forwarders sub-TLV provides/

2.3.4.  Hop-by-Hop Options (HBHOPT) sub-TLV

Where are the hop by hop options defined?

2.3.5.  Base VLAN-Identifiers sub-TLV

"This information should be the same on all bridges in
    the topology identified by MT-PORT-CAP TLV it is being carried."

there is something wrong with the above sentence. I can't parse it.

"Discrepancies between neighbors with respect to this sub-TLV are
    temporarily allowed but at least the active the Base-VID must agree
    and use the same ECT-ALGORITHM."

and also this sentence, especially "the active the Base-VID "

"M-Bit (1-bit) The M-bit indicates if this is SPBM or SPBV mode."

Presumably a value of 1 indicates SPBM, but this needs to be made explicit.

2.3.6.  SPB Digest sub-TLV

typo s/ identified by MT-PORT-CAP TLV it is being carried.
/identified by the MT-PORT-CAP TLV in which it is being carried."

(I assume)

But more seriously, I'm confused by the somewhat misleading statement 
that these should be the same. Surely the MCID should be the same but 
the IS-IS agreement digests are sometimes the same and sometimes not 
depending on the propagation of the LSPs. (as it says below).

"until the LSPs are common.  "

This is a bit vague. What is meant is that the LSPDBs are synchronized.

"Discrepancies between neighbors
    with respect to this sub-TLV are temporarily allowed but the Base-VID
    must agree and use a spanning tree algorithm."

again this statement could do with clarification.

2.3.7.  Site Identifier sub-TLV

The Site Capability sub-TLV is carried only within the MT-PORT-CAP
    TLV and this is carried in a Hello PDU.

typo s/Capability/Identifier/

Also this implies that the Site Identifier TLV can be carried in a TRILL 
hello or p2p hello. Is that correct?

(a similar comment applies to the subsequent OTV sub-TLVs)

2.3.10.  Adjacency Server IPv4 sub-TLV

It doesn't specify that there may be more than one. Is this correct?

2.3.11.  Adjacency Server IPv6 sub-TLV

" The Adjacency Server IPv6 sub-TLV is carried within the MT-PORT-CAP
    TLV and this is carried in a Hello PDU.  Multiple such TLVs may be
    carried in a IIH PDU.

"

This seems to indicate (despite the reference to Hello PDU) that this 
can ONLY be carried in an IIH PDU, but it is very confusing to mention 
BOTH Hello PDU and specifically IIH PDU.

Also the wording here allowing multiple TLVs is different to that used 
elsewhere. It would be advisable to use the same wording  to mean the 
same thing.

2.4.1.  The TRILL Version sub-TLV

typos (extraneous commas)

s/maximum version of TRILL, it is/maximum version of TRILL it is/

s/In the event, this sub-TLV is missing, /In the event this sub-TLV is 
missing, /

Also, the diagram for this sub-TLV adopts a different style to all the 
others

and, more importantly, why is there a gratuitous reserved byte?

2.4.2.  The Nickname sub-TLV

The Nickname Priority field is apparently contained in a 9 bit byte!

Also, it may be useful to what the ordering of priority values it. e.g. 
highest value = highest priority or lowest value = highest priority.

typo

s/Maximum number of trees able to compute: This is an unsigned 16-
       bit integer that give the maximum number of threes that the
/
Maximum number of trees able to compute: This is an unsigned 16-
       bit integer that gives the maximum number of threes that the
/

2.4.6.  Interested VLANs and Spanning Tree Roots sub-TLV

Given that this sub-TLV is permitted to occur multiple times in multiple 
TLVs and presumably in multiple LSPs, the MUST and MUST NOT statements
are somewhat interesting given the possibility of dynamic conditions 
when TLVs need to be moved between LSPs etc. This contrasts with the 
similar conditions for the tree identifiers sub-TLV where transient 
overlaps etc. are permitted and the way they should be dealt with is 
explicitly called out.

Also in the diagram the Nickname field appears to be 11 bits long, and 
the following fields should indicate that they are not fixed at 2 bytes.

"The Appointed Forwarder Status
       Lost Counter is also included here.  It is a count of how many
       times a port that was appointed forwarder for the VLANs in the
       range given has lost the status of being an appointed forwarder."

A count since when? Under what conditions is the count re-set? What 
happens if the count should wrap (admittedly unlikely, but still possible)?

typo

s/see on all links for which the Intermediate System /seen on all links 
for which the Intermediate System /

2.4.7.  The VLAN Group sub-TLV

Although the top 4 bits of the VLAN ID fields are described as being 
reserved, this is not indicated in the diagram.

typo

s/Type: TLV Type, set to 11 (VLAN-GROUPs)./Type: sub-TLV Type, set to 11 
(VLAN-GROUPs)./

Unlike the previous sub-tlv definition, this doesn't say which PDU type 
it is carried in.

Perhaps this should be a general comment. Can it be assumed that a TLV 
can be carried in either normal or MGROUP LSPs, where the specific PDU 
type is not called out? Or is the default the normal LSP?

2.4.8.  The Ingress-to-Egress Options (ITEOPT) sub-TLV

"The bit-encoded options supported are indicated by an ITEOPT TLV of
    length 3: an initial value byte of 0x00 followed by two bytes in..."

this sounds as if the distinguishing factor for bit-enbcoded options is 
that the IETOPT TL V (that should be sub-TLV) is of length 3. Whereas in 
fact (I think) the distinguishing factor is that the initial option byte 
is zero, and the length of 3 is merely co-incidental.

"Length: variable, minimum 1."

Is this true? i.e. an option need not have any option dependent variable 
length information?

Since the value is described as

     "Value: Either 0x00 followed by implementation information for bit
       encoded options or a non-zero option type byte followed by option
       dependent information for that option."

It sounds as if the option type MUST be followed by such information.

2.4.9.  VLAN Mapping (VMAP) sub-TLV

typo

s/From VLAN ID: This is the VLAN ID that, when received on a port 
connect to the/From VLAN ID: This is the VLAN ID that, when received on 
a port connected to the/

2.5.  Multi Topology Aware Capability TLV

typo

s/This is different from Router Capability TLV /This is different the 
from Router Capability TLV /

The description says "which allows a router to announce its capabilities
    for a particular topology within an IS-IS level or the entire routing
    domain."

and yet there are no D or S bits which could control this.

It is also not clear why the O bit is included in this TLV, when it is 
normally included in the RFC 5120 multi-topology TLV (229).

Is the intention that this should be used instead of the TLV229, or as 
well as. If as well as what are the semantics of conflicting settings of 
the O bit, etc. (or even multiple instances of this TLV)

     Also the O bit is normally required to be carried in LSP zero, and 
there seems to be no such requirement here.

2.5.1.  SPB Instance sub-TLV

"   This sub-TLV MUST be carried within the MT-Capability TLV in the"

but presumably there is no requirement to carry it in the case of TRILL. 
So perhaps it should say

" This sub-TLV, if present, MUST..."

Also, I really don't like the term "fragment ZERO LSP". This is not a 
term used in ISO/IEC 10589, which uses the term "zeroth LSP". (though 
sadly is IS used in RFC5120)

2.5.1.  SPB Instance sub-TLV

" CIST External Root Path Cost (32-bits) The CIST External Root Path
       Cost is the cost from the Spanning tree algorithm to the Root."

perhaps revise to

"... is the cost to root, derived from the spanning tree algorithm".

"*  M-Bit (1-bit) The M-bit indicates if this is SPBM or SPBV mode."

again, it would be as well to clarify that the bit being set means SPBM

" SPVID (12-bits) The SPVID is the Shortest Path VID when using
          SPBV mode.  It is not defined for SPBM Mode and should be 0 in
          SPBM mode."

Should that "should" be a MUST?

2.5.3.  SPBM Service Identifier and Unicast Address sub-TLV

"The SPBM Service Identifier sub-TLV SHOULD be carried within the MT-
    Capability TLV and can occur multiple times in any LSP fragment."

So this means that the O-bit in the MT-Capability TLV CAN occur in a 
non-zero LSP!

Also, it is not clear what SHOULD means in this context. Does it mean 
that the carrying of it is optional, or that where it is carried is 
optional?

2.6.  Sub-TLVs of the Extended Reachability TLV

"   This section specifies three new sub-TLVs that appear only within the
    Extended Reachability TLV (type 22)."

...  but the sub-TLVs are defined to appear in either TLV 22 OR 222!

"   o  an opaque ECT Data sub-TLV (type TBD) whose first 32 bits are the
       ECT-ALGORITHM to which this data applies."

It is not clear what this is supposed to be. There is no corresponding 
field in the diagram, and field has no name.

2.6.3.  MTU sub-TLV

"It occurs nested as within the Extended Reachability TLV (type 22)."

Perhaps better as "It is carried within...."

2.7.  TRILL Neighbor TLV

Why is there a 15 bit reserved field? Why not just a single byte holding 
the F bit and 7 reserved bits?

2.8.1.  The Group MAC Active Source sub-TLV

Why the reserved byte at the front of the group record?

2.8.2.  The Group IP Active Source sub-TLV

As above

2.8.3.  The Group IPv6 Active Source sub-TLV

As above

I don't know too much about IPv6 group addresses, but is there not a 
more compact encoding?

2.9.1.  The Multicast Group PDU

I will leave the merits or demerits of this PDU for other discussions, 
but one question arises.

Is the code space for top level TLVs shared with normal LSPs or is it 
seperate? My preference would be that it is shared.

2.9.4.1.  Enhancements to the flooding process

"Nodes running IS-IS in an L2 domain MUST... "

Although the intent is fairly obvious, it would be better to say "Layer 
2 domain", since L2 could be confused with a Level 2 IS-IS domain.

"In a similar fashion a MGROUP-CSNP MUST also be exchanged"

Since the CSNP on P2P links is just an optimization, perhaps SHOULD 
would be more appropriate, unless the RFC 5306 mechanisms are being invoked.

"There need not be any more correlation between the
    updates of the regular PDU and the MGROUP-PDU."

Its not clear what is meant here. Does it mean there need not be ANY 
correlation?

2.9.5.  The TRILL-Hello PDU

"necessary that a single Designated RBridge (DIS)"

Isn't the abbreviation for a Designated RBridge, DRB?

"The TRILL-Hello PDU has the same general structure as an IS-IS LAN PDU."

s/IS-IS LAN PDU/LAN IIH PDU/

"IS-IS LAN Hello PDU."

The term "LAN Hello" is not used in ISO/IEC 10589. The correct term is 
LAN IIH PDU

6.1.  Normative References

    [IS-IS]    ISO/IEC 10589, "Intermediate System to Intermediate System
               Intra-Domain Routing Exchange Protocol for use in
               Conjunction with the Protocol for Providing the
               Connectionless-mode Network Service (ISO 8473)", 2005.

The date of the second edition is 2002 not 2005

[END of COMMENTS]

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 6 May 2010 10:23:30 -0400

Hi Mike,

Thanks for these detailed comments!

On Wed, May 5, 2010 at 9:17 AM, mike shand <[email-masked]> wrote:
> I enclose some detailed comments on draft-ietf-isis-layer2-05.txt, mostly
> regarding typos and clarifications required.
>
> However, I have more serious concerns about the inclusion of the overload
> bit in various random places, and the gratuitous introduction of various
> reserved fields.

On the overload bits, I don't understand them either. TRILL doesn't
need or use them.

> Whatever the outcome of the ongoing major discussions about the document,
> these items also need addressing.
>
>    Mike

My responses below are mostly in reference to TRILL related things.

> (unlike OSPF) does not attempt word alignment.

I've got no problem with dropping that byte.

> helpful to have some rationale for this and/or a description of how it is
> meant to be used.

Yeah. TRILL uses this TLV to hold various sub-TLVs but does not use
that overload bit.

> The assumption, then is that this may appear in ANY form of hello PDU. Is
> that correct?

TRILL could use it in both TRILL Hellos and P2P Hellos.

> The implication, then, is that a TRILL IIH which does NOT contain this TLV
> is invalid. Presumably such a TRILL IIH should therefore be ignored. Is that
> correct, and if so is there some statement in the TRILL spec to that effect?

Ignoring such an invalid TRILL Hello would be reasonable but it does
not say that you must ignore such a Hello in the TRILL spec, just that
it must contain certain information.

> focusses on byte 3. In fact it is simply a bit vector where the first bit
> (i.e. highest order bit of byte 3) corresponds to the VLAN with the starting
> ID.

OK. I'm sure the wording can be improved.

> The Appointed Forwarders sub-TLV provides/

Thanks.

> Where are the hop by hop options defined?

They are not in the TRILL base protocol standard but in
draft-ietf-trill-options-00.txt which is not yet approved so perhaps
that sub-TLV should probably be taken out of the draft.

> But more seriously, I'm confused by the somewhat misleading statement that
> these should be the same. Surely the MCID should be the same but the IS-IS
> agreement digests are sometimes the same and sometimes not depending on the
> propagation of the LSPs. (as it says below).
>

TRILL doesn't use this so if it appeared in a TRILL Hello, it would
just be ignored.

> This seems to indicate (despite the reference to Hello PDU) that this can
> ONLY be carried in an IIH PDU, but it is very confusing to mention BOTH
> Hello PDU and specifically IIH PDU.
>
> elsewhere. It would be advisable to use the same wording  to mean the same
> thing.
>
>

The commas should be fixed. I'm not sure I see anything wrong with the
diagram style but I have no problem with changing it to be closer to
the others.

> and, more importantly, why is there a gratuitous reserved byte?

This seems like a sub-TLV that you might want to add some flags to if
there are TRILL implementation characteristics you wanted to
communicate that were not captured in the version supported number or
elsewhere. However, you could do that by making the length variable
and saying that the flags, if and when any are defined, would come
after the version number.

> The Nickname Priority field is apparently contained in a 9 bit byte!

Hummm, well, it does say "(1 byte)". It's probably an unreasonable
requirement to say that implementations need computers with the
occasional 9 bit byte so I would say this should be fixed :-)

> highest value = highest priority or lowest value = highest priority.

There is extensive discussion of how nicknames are dynamically and/or
statically allocated, etc., in the TRILL spec. Perhaps the right thing
is adding a pointer to that section of the TRILL spec.

>      bit integer that gives the maximum number of threes that the

I assume the correction is "threes" -> "trees"

> are somewhat interesting given the possibility of dynamic conditions when
> TLVs need to be moved between LSPs etc. This contrasts with the similar
> conditions for the tree identifiers sub-TLV where transient overlaps etc.
> are permitted and the way they should be dealt with is explicitly called
> out.

That should probably be fixed.

> Also in the diagram the Nickname field appears to be 11 bits long, and the
> following fields should indicate that they are not fixed at 2 bytes.

Misleading scaling in the diagram should be fixed.

> A count since when? Under what conditions is the count re-set? What happens
> if the count should wrap (admittedly unlikely, but still possible)?

Should probably be initialized when that is done for the LSP sequence
numbers. However, it is not particularly a problem if it wraps so it
is not clear that it ever needs to be reset. Detecting that it has
changed is used as a criteria for trimming the expiration time of some
cached MAC addresses to be sure that behavior is similar to similarly
configured learning bridges. Neither false positives nor false
negatives would be particularly fatal, as far as I can see.

> typo
>
> s/see on all links for which the Intermediate System /seen on all links for
> which the Intermediate System /

Thanks.

> reserved, this is not indicated in the diagram.

OK.

> s/Type: TLV Type, set to 11 (VLAN-GROUPs)./Type: sub-TLV Type, set to 11

OK.

> Unlike the previous sub-tlv definition, this doesn't say which PDU type it
> is carried in.

All of the subsections of 2.4 are sub-TLVs carried in the Router
Capabilities TLV and this is also shown in the table in Section 5, but
the description here should be consistent with other sub-TLV
descriptions.

> Perhaps this should be a general comment. Can it be assumed that a TLV can
> be carried in either normal or MGROUP LSPs, where the specific PDU type is
> not called out? Or is the default the normal LSP?

The default is the normal LSP. This is also indicated by the table in Section 5.

> this sounds as if the distinguishing factor for bit-enbcoded options is that
> the IETOPT TL V (that should be sub-TLV) is of length 3. Whereas in fact (I
> think) the distinguishing factor is that the initial option byte is zero,
> and the length of 3 is merely co-incidental.

OK. That should be clarified.

> Is this true? i.e. an option need not have any option dependent variable

Yes.

> It sounds as if the option type MUST be followed by such information.

That implication should be fixed. The way I think about it, option
dependent information being the null byte string is fine but I can
understand why that might confuse some people.

However, as with the HBHOPT, the options details are in
draft-ietf-trill-options-00.txt so this sub-TLV should probably be
dropped for now.

> s/From VLAN ID: This is the VLAN ID that, when received on a port connect to
> the/From VLAN ID: This is the VLAN ID that, when received on a port
> connected to the/

OK.

> s/This is different from Router Capability TLV /This is different the from
> Router Capability TLV /
>
>
> Is the intention that this should be used instead of the TLV229, or as well
> as. If as well as what are the semantics of conflicting settings of the O
> bit, etc. (or even multiple instances of this TLV)
>
>    Also the O bit is normally required to be carried in LSP zero, and there
> seems to be no such requirement here.
>
>
> but presumably there is no requirement to carry it in the case of TRILL. So
> perhaps it should say
>
> Also, I really don't like the term "fragment ZERO LSP". This is not a term
> used in ISO/IEC 10589, which uses the term "zeroth LSP". (though sadly is IS
> used in RFC5120)
>
>
> Also, it is not clear what SHOULD means in this context. Does it mean that
> the carrying of it is optional, or that where it is carried is optional?
>
>
> It is not clear what this is supposed to be. There is no corresponding field
> in the diagram, and field has no name.
>
> 2.6.3.  MTU sub-TLV
>

OK.

> 2.7.  TRILL Neighbor TLV
>
>
> Why is there a 15 bit reserved field? Why not just a single byte holding the
> F bit and 7 reserved bits?

That can be changes to a single byte.

> I don't know too much about IPv6 group addresses, but is there not a more
> compact encoding?
>
> I will leave the merits or demerits of this PDU for other discussions, but
> one question arises.
>

Everything I've seen implies it is shared.

> Although the intent is fairly obvious, it would be better to say "Layer 2
> domain", since L2 could be confused with a Level 2 IS-IS domain.
>
>
> Since the CSNP on P2P links is just an optimization, perhaps SHOULD would be
> more appropriate, unless the RFC 5306 mechanisms are being invoked.
>
>

Yes, but in the TRILL context DRB and DIS are the same thing... I'm
fine with changing that to DRB.

> s/IS-IS LAN PDU/LAN IIH PDU/

OK.

> "IS-IS LAN Hello PDU."
>
> The term "LAN Hello" is not used in ISO/IEC 10589. The correct term is LAN
> IIH PDU

OK.

> The date of the second edition is 2002 not 2005

Yes, thanks,
Donald

---

From: Peter Ashwood-Smith <[email-masked]>
Date: Thu, 06 May 2010 12:01:49 -0400

Mike, couple of quick responses to your detailed comments .. by the way
thanks.

The overload is not intended to be included in the hello. Not sure why its
there, probably a cut and paste error that we did not spot. 

There is only supposed to be a single overload bit used in exactly the same
manner as normal MT is-is uses it and we are not trying to impose any new
semantics or eliminate any existing overload semantics, anything otherwise
is an error that we need to clarify or fix.

SPB's philosophy is to simply piggy back on existing IS-IS the data needed
to compute or decide to compute the FDB. Any violation of existing IS-IS
semantics in any way shape or form is a mistake which we will of course
correct.

Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Donald Eastlake
Sent: Thursday, May 06, 2010 10:24 AM
To: mike shand
Cc: isis mailing list
Subject: Re: [Isis-wg] Comments on draft-ietf-isis-layer2-05.txt

Hi Mike,

Thanks.

> A count since when? Under what conditions is the count re-set? What
happens

> s/see on all links for which the Intermediate System /seen on all links
for

Thanks.

OK.

OK.

> not called out? Or is the default the normal LSP?

The default is the normal LSP. This is also indicated by the table in
Section 5.

> this sounds as if the distinguishing factor for bit-enbcoded options is
that

Yes.

OK.

> Is the intention that this should be used instead of the TLV229, or as
well
>    Also the O bit is normally required to be carried in LSP zero, and
there
> but presumably there is no requirement to carry it in the case of TRILL.
So
> It is not clear what this is supposed to be. There is no corresponding
field

OK.

> Why is there a 15 bit reserved field? Why not just a single byte holding
the

OK.

OK.

Yes, thanks,
Donald

> [END of COMMENTS]
_______________________________________________
Isis-wg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isis-wg