Subject: [Isis-wg] Comments on draft-ietf-isis-ieee-aq-02.txt

From: mike shand <[email-masked]>
Date: Thu, 02 Dec 2010 16:01:44 +0000

I have some initial minor comments and questions about this draft. 
Many of the comments may well be caused by my lack of detailed 
understanding of the SPB protocol, for which I apologise.

     Mike

General comments

Since I found myself totally confused by the use of metrics and MTIDs,
it might be advisable to have a small section in the overview which 
explains this. Especially that SPB has its own metric field.

13. Hello (IIH) protocol extensions

802.1aq computations MUST consider

    an adjacency that has not advertised 0xC1 NLPID in both directions
    as non-existent (infinite link metric) and MUST ignore any SPB TLV's
    they receive over such adjacencies

I assume this refers to SPB TLVs in IIHs, and not those in LSPs. I don't 
see how the latter could be achieved.

It also appears that there is an assumption that the SPB information is 
associated with a
separate topology (MTID) from any "normal" IS-IS information.

SPB neighbors MAY support an optional mechanism to verify that the
    contents of their topology databases are synchronized (for the
    purposes of loop prevention). This is done by exchanging a digest of
    the topology information and taking specific actions on forwarding
    entries when the digests indicate a mismatch in topology. This
    digest is carried in the optional SPB Digest sub-TLV.

Does this digest information apply ONLY to SPB information? Again there 
seems to be an assumption that it is in a seperate MTID.

13.2. SPB Digest sub-TLV

The IS-IS Agreement Digest is
    computed based on currently topology and is designed to change only

TYPO: s/currently/current/

Its not really clear to me how the digest works in the presence of other 
topology information in the same set of LSPs. So, for example,
when significant topology changes occur within a non-SPB topology TLV, 
does that get included in the digest? Or is the digest somehow formed 
only over the information in this MTID? I had the impression that the 
digest algorithm formed a digest of each complete LSP (omitting seq 
number etc.), and then formed an XOR of those digests. But perhaps that 
has changed since I last looked.

    o  Agreement Digest. This digest is use to determine when IS-IS is

TYPO: s/use/used/

13.3. SPB Base VLAN-Identifiers sub-TLV

Is that any bridge or any reachable bridge? i.e. if there is an 
unreachable bridge still in the LSPDB "using" this ECT algorithm does it 
remain set?

14.1.  SPB Instance sub-TLV

   o  A bit, The A bit (SPB) when set declares this is an SPVID with
       auto allocation.  The VID allocation logic details are in IEEE
       [802.1aq].  Since SPVIDs are from a small pool of resources
       (typically 1000 or less) the chances of collision are high.  To
       allow auto allocation LSPs are exchanged with the allocated
       bridge setting the SPVID to 0 and the allocating bridge sets the
       SPVID when it learns the allocated space.

I don't understand what the last sentence means. Could it be clarified?

   o  ECT-ALGORITHM (4-bytes) ECT-ALGORITHM is advertised when the
       bridge supports a given ECT-ALGORITHM (by OUI/Index) on a given
       VID. This declaration must match the declaration in the Hello PDU
       originating from the same bridge.  The ECT-ALGORITHM, BASE-VID
       should match what is generated in the Hellos of the same node.
       The ECT-ALGORITHM, BASE-VID tuples can come in any order however.
       There are currently 17 world wide unique 802.1aq defined ECT-
       ALGORITHMS given by values 00-80-C2-00 through 00-80-C2-10.

Is the must a MUST, and is the should a SHOULD or a MUST?

15.1. SPB Link Metric sub-TLV

So this is really a sub-topology metric within an MTID. i.e. 
irrespective of the MTID, SPB ONLY uses this metric and not the normal 
IS-IS metric. So what are you supposed to put in the metric field of the 
TLV22 or 222? Or can you somehow run SPB AND normal routing in the same 
MTID?

16.2. SPBV Mac Address sub-TLV

Unicast MAC addresses will normally be
    distributed by reverse path leaning, but carrying them in this TLV

TYPO: s/leaning/learning/

  o  SPVID (12-bits) The SPVID and by association Base VID and the
       ECT-ALGORITHM and SPT Set that the MAC addresses defined below
       will use. If the SPVID is not allocated the SPVID Value is 0.
       Note that if the ECT-Algorithm in use is Spanning Tree Algorithm
       this value should be populated with the Base VID and the MAC can

should = SHOULD or MUST? (similarly for T-bit and R-bit)

18. IANA Considerations

    Note that the NLPID value 0xC1 [NLPID] used in the IIH PDUs has
    already been assigned by IANA for the purpose of 802.1aq therefore
    no further action is required for this code point.

    Since 802.1aq operates within the IS-IS Multi Topology framework
    every sub-tlv MUST occur in the context of the proper MT TLV. There
    are three Multi Topology TLV's in which 802.1aq requests allocation
    of sub-TLV's. These are the MT-Port-Capability used in the IIH, the
    MT-Capability (new) used within the LSP and finally the MT-
    Intermediate-System TLV used to contain adjacency information within

I'm confused. Elsewhere it defines sub-TLVs of TLV 22, which is NOT MTID 
qualified.
e.g. SPB Link Metric sub-TLV

END OF COMMENTS

---

From: Peter Ashwood-Smith <[email-masked]>
Date: Thu, 02 Dec 2010 15:16:11 -0500

Thanks Mike,

Comments below preceeded with [PAS].

Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of mike shand
Sent: Thursday, December 02, 2010 11:02 AM
To: isis mailing list
Subject: [Isis-wg] Comments on draft-ietf-isis-ieee-aq-02.txt

[PAS] not a problem, appreciate the feedback and if there are things we can
do to make this draft more self contained we'll certainly try as long as
there is minimal overlap with the IEEE 802.1aq document.

     Mike

General comments

[PAS] noted - I can see from you comments below that you figured it out as
you went but we'll see if we can find a sentence or two upfront to save the
next reader the trouble.

[PAS] Yes. We could change it to 'MUST ignore any IIH SPB TLV's' 

[PAS] That's not the intention. Our goal is that MTID operates normally and
various protocols can fit within a given MTID (including #0) or could have
their own MTID. We don't want to mandate separation. It should remain the
operator's choice. Your suggestion about a comment upfront will hopefully
clarify this.

[PAS] Yes - the digest for a given MTID is specific only to the SPB
adjacencies within that MTID. Its 100% selective. The MTID could contain
other protocols/adjacencies but the SPB topology digest will only reflect
the SPB adjacencies within that MTID. There is one special case which is the
digest under MTID#0 which digests all the SPB Adjacencies for all MTIDs ..
that was done for space saving reasons in the IIH. 

13.2. SPB Digest sub-TLV

[PAS] noted thanks.

[PAS] its changed ... all the gory details are in 802.1aq but the digest for
a given MTID is computed over the SPB adjacencies for that MTID only. We
decided not to try to take the entire topoogy database byte by byte since it
includes too much that could change that does not cause a computation
difference. Therefore we have created a digest that contains only the
information that can result in output changes for a given MTID. Obviously
you can't just start scanning the LSP's to compute it, you'd probably
compute it after extracting and creating per MTID graphs. Its also designed
so that you can add/remove SPB adjacencies without total recomputation.

TYPO: s/use/used/

[PAS] noted.

[PAS] I take it you are talking to the 'use' bit for an ECT-ALGORITHM? It
would have to age out like all the other information in the LSP associated
with this unreachable bridge. That is the conservative approach. Was there
some optimization you feel we may have missed here? 

[PAS] - yes we'll take a shot at adding a sentence or two to clear it up.

[PAS] Thanks, Yes the 'must' is a 'MUST' and the SHOULD is a 'MUST'
Will change.

[PAS] Correct, SPB never uses the normal IS-IS metric TLV field as input.
This means you can easily run SPB and normal routing in the same MTID.
Infact this is common in the pre-standard deployments where the management
IP routing runs in parallel in MTID#0. Granted in 99% of the cases the two
metrics had the same value but that is by operator choice and not something
we want to enforce, hence the separate fields.

[PAS] noted thanks.

[PAS] they are MUST's - noted thanks.

18. IANA Considerations

[PAS] Hmmm yes that MUST needs qualification because standard IS-IS topology
is implicitly MTID#0 [RFC5120]. I'd suggest qualification like 'with the
exception of the SPB Link Metric Sub-TLV which may occur within TLV 22 where
its MTID MUST be considered to be #0.'

Peter

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