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

From: Alex Zinin <[email-masked]>
Date: Mon, 3 Jun 2002 12:18:12 -0700

Amir,

> Alex,
> comments inline. Thanks very much for the helpful comments and suggestions.
> As always, other suggetions, especially for terminology, are more than welcomed.
...
>> >      Extended system-id
>> 
>> Sounds like we're stretching out the normal system-id.
>> 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?

"extended" LSPs, though not perfect, make more sense--I couldn't come
up with a better name, maybe native English speakers can :)

>> >    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.

> 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.

Agreed.

>> 
>> > 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.
>> 

> 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.

I think I was confused by the illustration. Could you please specify more
explicitly which ID is put in the TLV.

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

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

No objection to this, but you need to describe sub-TLV handling
properly.

>> 
>> 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.

> 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.

I'd like the TLV format illustration to be consistent with
1195, i.e., something like this:

   x CODE - 24

   x LENGTH - total length of the value field.

   x VALUE - the following data:
                                              No. of Octets
          +--------------------------------+
          |       ALIAS SYSTEM ID          |      7
          +--------------------------------+
          |       SUB-TLV LENGTH           |      1
          +--------------------------------+
          |                                |
          .          SUB-TLVs              .
          |                                |
          +--------------------------------+

>> What about the OL bit?

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

Don't we want to have consistent values in the "normal" and "extended"
LSPs, at least for mode 2?

>> > 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...
>> 

> 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.

Note the name of the section where this text belongs ;)

>> > 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?
>> 

> 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.

Makes sense.

>> 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.
>> 

> 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.

I don't agree here. I think the most common case will be where the
network works and routers' SW gets upgraded. Once upgraded the LSP
origination behavior should not change, i.e., neither mode-1 nor
mode-2 should be activated until explicitly configured by the admin.
This should save from problems with implementations that for some
buggy reason react incorrectly to 0-cost links in non-pseudo LSPs,
or with implementations that implement your spec incorrectly,
as well as this is just a good general practice to not enable new
behavior by default, especially in routing protocols.

Thanks.

Alex

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

---

From: "Philip Christian" <[email-masked]>
Date: Wed, 5 Jun 2002 12:42:41 +0100

> > draft uses "extended" for LSPs, since they really extend 
> the original LS information an IS could advertise,

Is this is a similar concept to "Extended Local Circuit ID" in three way
handshaking?
it sounds as though it is, in which case consistency is a good thing.

Philip

---

From: Alex Zinin <[email-masked]>
Date: Fri, 24 May 2002 18:33:50 -0700

Haven't seen this getting through to the list
for some reason...

This is a forwarded message
From: Alex Zinin <[email-masked]>
To: [email-masked]
Cc: 
Date: Thursday, May 23, 2002, 7:25:01 PM
Subject: [Isis-wg] last call on draft draft-ietf-isis-ext-lsp-frags-00 ...

===8<==============Original message text===============
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 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:
..

>    The proposed IS-A TLV allows extension-capable ISs to recognize all
>    LSPs of an Originating System, and combine the original and extended
>    The IS Alias ID TLV is type 24, and contains a new data structure,
>    consisting of:
>    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.

> 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?

...
>    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

  ...
>                       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

> 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.

> 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

===8<===========End of original message text===========

-- 
Alex

---

From: "Amir Hermelin" <[email-masked]>
Date: Mon, 10 Jun 2002 16:24:12 +0300

Alex,
once again, comments inline. I've cut out the parts that were in full agreement. Thanks for the comments.

Amir.

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

> -----Original Message-----
> From: Alex Zinin [mailto:[email-masked]]
> Sent: Monday, June 03, 2002 10:18 PM
> To: Amir Hermelin
> Cc: [email-masked]
> Subject: Re: [Isis-wg] last call on draft 
> draft-ietf-isis-ext-lsp-frags-00 ...
> 
> 
> Amir,
> 
> >> 

Right, I see where the stuff in parenthesis can confuse - removed that and added more explanation in the TLV section.

> No objection to this, but you need to describe sub-TLV handling

ok.

>    x VALUE - the following data:

agreed.

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

it took me some time, but I finally got your point. Will move the sentence to describe the right direction.

> behavior by default, especially in routing protocols.

Ok, I can add the text to that. However, it's just a recommendation, since implementations can do whatever they want here - the default values are implementation specific. You're right in that I was referring more to the case where the network doesn't work well when the upgrade is done.

Thanks.