Subject: [Isis-wg] last call on draft draft-ietf-isis-ext-lsp-frags-00 ...

From: Tony Przygienda <[email-masked]>
Date: Wed, 08 May 2002 09:10:13 -0700

We are starting last call on draft-ietf-isis-ext-lsp-frags-00. The last call
will end 5/22/02

    thanks

    -- tony

_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://spider.juniper.net/mailman/listinfo/isis-wg

---

From: Alex Zinin <[email-masked]>
Date: Thu, 23 May 2002 19:25:01 -0700

Sorry I'm one day late with the comments.

> Status
...
>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>    "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
>    document are to be interpreted as described in RFC 2119 [BCP14].

Pls, move this somewhere within the document (not the Abstract,
though, probably the Intro).

Also, please go through the text and make sure all occurrences of
must/should/may/etc are capitalized when used to express the
requirements level.

> 1.  Introduction
...
>    A number of factors can contribute to exceeding this limit:
...
>      -  The growing size of route tables and AS topologies.

The size of the RT contributes to the LSP size in case
of redistribution and inter-level propagation mentioned
in the following item. Here you probably mean the increasing
number of destinations (amount of reachability info) to
be distributed.

> 1.1  Definitions of Commonly Used Terms
> 
>    This section provides definitions for terms that are used throughout
>    the text.
> 
>      Originating System
>         A router running the IS-IS protocol.

The term hints there should be some words about LSP origination here.

>      Original system-id
>         The system-id of an Originating System.

Isn't this supposed to be the "normal" system-id (as opposed
to the additional ones)? I mean you should explain what
is "original" about it.

>      Extended system-id

Sounds like we're stretching out the normal system-id.
Maybe "Virtual system-id" would be a better choice?

...
>
>      Extended LSP
>         An LSP using an extended system-id in its LSP ID.

Same comment about "extended".

> 1.2  Operation Modes
> 
>    Two administrative operation modes are provided:
..
>
>    These modes may be configured per level.  There is no restriction
>    that an L1/L2 IS operates in the same mode, for both L1 and L2.

Shouldn't the modes be on a per-level & area basis. This
text also sounds like all routers within a level (or an area
if corrected) need to work in the same mode, which is not true,
since modified SPF is a requirement regardless of the LSP
origination mode.

> 2.0  IS Alias ID TLV (IS-A)
> 
>    The proposed IS-A TLV allows extension-capable ISs to recognize all
>    LSPs of an Originating System, and combine the original and extended
>    LSPs for the purpose of SPF computation.
> 
>    The IS Alias ID TLV is type 24, and contains a new data structure,
>    consisting of:
>      7 octets of system Id and pseudonode number
>      1 octet of length of sub-TLVs
>      0-247 octets of sub-TLVs,
>         where each sub-TLV consists of a sequence of
>            1 octet of sub-type
>            1 octet of length
>            0-245 octets of value
> 
>    Without sub-TLVs, this structure consumes 8 octets per LSP set.  This
>    TLV MUST be included in fragment 0 of every LSP set belonging to an
>    Originating System.

Couldn't find any info on how to put S' and S'' in the TLV.

Couldn't find description of any sub-TLVs that would be
used to do the above.

Couldn't find any rules about sub-TLV handling, i.e., padding
and length calculation with it.

The format description above should use the illustration
style from 1195.

> 3.1  Both Operation Modes
>
>    Under both modes, the Originating System MUST include information
>    binding the Original LSP and the Extended ones.  It can do this since
>    it is trivially an extension-capable IS.  This is to ensure other
>    routers correctly process the extra information in their SPF
            ^
       "implementing this specification" or something like this

> 3.1.1  The Attached Bits
...
> 3.1.2  The Partition Repair Bit

What about the OL bit?

> 3.2  Operation Mode 1 Additions
...
>    When an extended LSP belonging to extended system-id S' is first
>    created, the original LSP MUST specify S' as a neighbor, with metric
>    set to zero.  This in order to satisfy the two-way connectivity check
>    on other routers, as well as to consider the cost of reaching the

I thought that the S'->S link would be needed to satisfy
the TWC check for the S->S' one, not the other way around...

> 4.  Purging Extended LSP Fragments
  ...
>                       However, an extended LSP fragment zero should not
>    be purged until all of the fragments in its set (i.e. belonging to a
>    particular extended system-id), are empty as well.  This is to ensure
>    implementations consider the fragments in their SPF computations, as
>    specified in section 7.2.5.

Given what section 5 says about ignoring non-0 fragments when
fragment zero is missing, what does the above rule give us?

> 5.  Modifications to LSP handling in SPF
...
>    If LSP fragment 0 of the original LSP set is missing, all of the LSPs
>    generated by that Originating System (extended as well) MUST NOT be
>    considered in the SPF.  That is, the large logical LSP isn't
>    considered in the SPF.  If an LSP fragment 0 of an extended LSP set
>    is missing, only that LSP set MUST NOT be considered in the SPF.

 This text should also say that fragment 0's RemainingLifetime
 should be > 0

> 7.  Interoperating between extension-capable and non-extension-capable
>    ISs.
...
>    It is possible to transition a live network, using the following
>    steps:
>      - Upgrade the routers, one-by-one, to run this extension in
>      Operation Mode 1. The other non-extension-capable routers will
>      interoperate correctly.
>      - When all routers are extension-capable, configure them one-by-one
>      to run in Operation Mode 2.  All extension-capable routers
>      interoperate correctly, regardless of what mode they're run in.

We don't have to go through mode-1 to get to mode-2. An upgrade of
SW does not necessarily mean changing the LSP origination process.
In fact, I would argue that the default setting MUST be the standard
one, i.e., neither mode 1 nor mode 2, and it would be really great
if this was spelled out.

> 9.  Acknowledgments
> 
>    The author would like to thank Tony Li and Radia Perlman for helpful
               ^"s"
               
>    comments and suggestions on the subject.

> 10.  References
...
>
>    [ISIS-CODES] Work in progress, "Reserved TLV Codepoints in ISIS", T.
>    Przygienda

Unused ref. Check if you have others.

> 11.  Authors' Address
                       ^"es"

Alex

---

From: "Amir Hermelin" <[email-masked]>
Date: Thu, 30 May 2002 18:09:47 +0300

Alex,
comments inline. Thanks very much for the helpful comments and suggestions. As always, other suggetions, especially for terminology, are more than welcomed.

--
Amir Hermelin                    < mailto:[email-masked]>
Charlotte's Web Networks Inc.     < http://www.cwnt.com>

> -----Original Message-----
> From: Alex Zinin [mailto:[email-masked]]
> Sent: Friday, May 24, 2002 5:25 AM
> To: [email-masked]
> Subject: Re: [Isis-wg] last call on draft 
> draft-ietf-isis-ext-lsp-frags-00 ...
> 
> 

right. I'll put this into a subsection of the Introduction section.

> number of destinations (amount of reachability info) to

agreed. Will re-word.

> The term hints there should be some words about LSP origination here.

I agree it might be a little ambigous here, although when terming "LSP origination", it does appear to routers as if Extended (or Virtual) systems also originate LSPs. I'll think of an additional desciprtion here.

> to the additional ones)? I mean you should explain what

probably bad naming on my behalf. I'll confer the other authors for a better term. I agree it's important, not only because of the document, but also because this will probably be the term presented to users of routers.

> Maybe "Virtual system-id" would be a better choice?

again, could be bad naming. However, I originally thought "Virtual" to be a little confusing, as a "virtual link" term is already used in the IS-IS spec, for a completely different purpose. The draft uses "extended" for LSPs, since they really extend the original LS information an IS could advertise, as opposed to "Virtual System", which doesn't really add any additional info. Does that make sense?

> since modified SPF is a requirement regardless of the LSP

agreed, that's the original intent. I'll add "per area". The actual requirement is "per spf", but I think it will confuse more than it will clarify.

> Couldn't find any info on how to put S' and S'' in the TLV.

Actually, what you need to put here is S (or the is-alias-id, which could be different). The S' and S'' (and also S) appear in the LSP header.

> Couldn't find description of any sub-TLVs that would be

It's just put there for future or proprietary use - doesn't take up any space, I think we should keep it.

> The format description above should use the illustration

I don't fully understand what's missing, but I will add an example. I've used the format from the TE-extensions draft, which I think to be clear and well-discussed. Please clarify what you'd like to see here.

>        "implementing this specification" or something like this

added.

> > 3.1.2  The Partition Repair Bit

The 3.1.* sections are exceptions. The OL bit should be set/unset in original and extended LSPs the same as before.

> the TWC check for the S->S' one, not the other way around...

Depends on which node (S or S') was first considered in SPF. In Mode 1, it's true that always S will be reached first, but this isn't guaranteed in mode 2.

> fragment zero is missing, what does the above rule give us?

the above rule is specifically to ensure section 5 works well: if we have info in other fragments, but the zero-fragment is empty (and we don't re-arrange information, as we shouldn't), we still need to keep that fragment so other fragments are considered. I guess this is true regardless of this draft or not - we just wanted to clarify it.

>  This text should also say that fragment 0's RemainingLifetime

right you are!

> one, i.e., neither mode 1 nor mode 2, and it would be really great

Your upgrade option is identical to what the draft suggests - since "standard one" is really Mode 1 (you can either have mode-1 or mode-2). The difference between mode-1 and the "standard" way, is that the standard way asserts when the maximum fragments are reached ;-) There's also the additional tlv, but there's no harm in advertising it.

> >    The author would like to thank Tony Li and Radia Perlman 

whoops...

> Unused ref. Check if you have others.

whoops again...

> Alex

Thanks! very helpful comments!