Re: [trill] [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilevel-single-nickname

[Donald Eastlake <[e-mail]>]

Hi Sasha,

On Fri, May 27, 2016 at 1:01 AM, Alexander Vainshtein
<[e-mail]> wrote:
> Donald,
>
> Again, lots of thanks for a prompt response
>
> regarding the NGP dratf: here is the link:
>
> https://tools.ietf.org/html/draft-balaji-trill-over-ip-multi-level-05
>
> This draft has expired 4 years ago, and to me it looks as addressing the
> same problem you and your colleagues try to address with multi-level IS-IS.

I do not think it is the same. draft-balaji-trill-over-ip is about
interconnecting TRILL networks/campuses that are under different
management while draft-ietf-trill-multilevel-single-nickname is about
interconnecting parts of a TRILL campus under the same management. In
any case, they seem at least somewhat orthogonal. If you had a few
TRILL campuses under separate management, each with a couple of
thousand switches and you used draft-balaji-trill-over-ip (not to be
confused with draft-ietf-trill-over-ip) to interconnect those TRILL
campuses, I don't see why you might not want to use
draft-ietf-trill-multilevel-single-nickname to make each of those
TRILL campuses into a multi-level IS-IS routed area.

(Also a minor factor is that currently the TRILL architecture does not
impose any requirement for a TRILL switch to have an IP address. If
separate TRILL areas had BGP over TCP control plane intercommunication
it would impose a requirement on the communicating TRILL switches to
have IP addresses.)

> I think that the specific problematic point of this draft is volatility of
> the area names (that are just the collections of the nicknames of all border
> RBridges of a given area in this draft). -

I don't see that as problematic. It is likely that the number of such
border TRILL switches for an area would be a single digit, probably in
the low single digits so I don't believe the membership of the set of
border TRILL switches will be particularly volatile. There are factors
that favor using this set approach and factors that favor using the
approach of having a pseudo-nickname to represent an area.

> This may be - or may be not - a serious technical issue with the proposed
> approach. In any case I'd say it requires careful analysis.

In terms of area labeling, the border TRILL switches always have to
determine, for each Level 1 area to which they are attached, the set
of border TRILL switches for that area. With the current draft, at
that point they are done in determining the label for the area. With
the pseudo-nickname approach, they have to run an election between the
members of the set to determine the Designated Border RBridge (DBRB),
the winner has to contend in Level 2 for a pseudo-nickname and then
announce that nickname to the other members of the border set before
the area name is known.

In terms of a border TRILL switch crashing or losing connectivity to
an area, a new border TRILL switch being added, or the area
partitioning or two areas merging, in all cases the change in the
border set will be immediately clear in the level 1 link state data
base so with the set approach the remaining set members know the new
set right away.

With the psuedo-nickname approach, things are more complex. The
pseudo-nickname used can change if the DBRB crashes or loses
connectivity or a new border TRILL switch with higher priority to be
DBRB appears or for a TRILL switch in the subset of border switches
belonging to a partition without the original DBRB, or the DBRB is
configured to have lower priority to be DBRB so the election result
changes, etc.

Overall, I don't see that much difference.

> And, after re-reading your previous email, I think there is a common
> potential issue with the Aggregate Nicknames approach as such.
>
> Please consider the following scenario (actually mentioned as a security
> issue in your email)
>
> 1. There is a L1 one area with multiple border RBridges.
> 2. Due to some failure this area is partitioned
> 3. Later still, a new RBridge comes up in one of the new areas and acquires a
> nickname that is unique in this area
> 4. Now the failure that has caused partitioning f the area has been repaired.
> The areas are merged, and some RBridges now have duplicate nicknames.
>
> Again, this requires some analysis IMHO.

That is not a problem. In line with TRILL's goal of being minimal/zero
configuration, nicknames are auto configured as described in RFC 6325
Section 3.7.3 as updated by RFC 7780 Section 4. The situation you
describe is no different from two single level TRILL campuses merging,
which was considered and analyzed in the design of TRILL. There can
only be duplicate nicknames for a brief transitory period of time and
nickname assignments converge quite rapidly. Furthermore, even if two
TRILL switches in an area briefly have the same nickname, it cannot
cause a TRILL data packet to be delivered in the wrong Data Label.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]

> Regards,
> Sasha
>
>
> ________________________________
> From: Donald Eastlake <[e-mail]>
> Sent: Friday, May 27, 2016 2:41 AM
>
> To: Alexander Vainshtein
> Cc: Mingui Zhang; Zhangxian (Xian); [e-mail];
> [e-mail]; Susan Hares;
> [e-mail]; Jonathan Hardwick; [e-mail]
> Subject: Re: [RTG-DIR] RTG-DIR QA review for
> draft-ietf-trill-multilevel-single-nickname
>
> Hi Sasha,
>
> On Thu, May 26, 2016 at 2:08 AM, Alexander Vainshtein
> <[e-mail]> wrote:
>>
>> Donald,
>> Lots of thanks for a very detailed response!
>>
>> Lots of thanks for very important information about the actual and
>> expected scale of TRILL deployments as well as for presenting some of the
>> factors (line active-active TRILL operation) that affect the consumption of
>> the nickname space. It addresses my question about the reason to go for
>> multi-level IS-IS at all. Flat IGP configuration (both IS-IS and OSPF) are
>> very popular in IP/MPLS deployments due to LDP  (and, now, IP/LDP FRR
>> techniques), so this information was important to me in order to understand
>> that the multi-level TRILL drafts solve a real problem. I would suggest
>> adding this information to the multi-level TRILL draft.
>
>
> Sounds reasonable. Something like that can be added to
> draft-ietf-trill-rbridge-multilevel.
>
>>
>> However, I am still not sure if the Single Nickname draft (one I have been
>> reviewing)  represents an attempt to solve a real problem. My understanding
>> so far has been that it follows the Aggregate Nicknames approach in the
>> multi-level TRILL draft, but eliminates the need to assign nicknames to L1
>> areas. I do not see if, even with the scale you have mentioned) this could
>> be a serious issue (e.g., contribute significantly to depletion of the
>> nickname space). Do I  miss something here?
>
>
> I'm not sure it matters. If you believe that there is a good reason for
> aggregated nicknames, this draft is the only aggregated nickname draft that
> is current active and the only such draft that has been adopted by the TRILL
> WG. So unless there is some problem with its approach, it seems to me that
> it should be progressed.
>
>>
>> The swapping vs. re-write issue I have discussed with Mingui is a pure
>> case of terminology. AsI have said, I consider it as closed.
>>
>> As for the metadata issue  - I am perfectly ready to follow the guidance
>> of ADs and WG chairs. especially since this policy has recently undergone
>> serious changes.
>>
>> Two additional questions - for the sake of my curiosity:
>>
>> Can possibly you explain what has happened to draft that proposed using
>> BGP with TRILL?
>
> If you give me a pointer to the specific expired draft, I might remember
> something about its history. By the way, there is currently a draft in IDR:
> draft-idr-ietf-ls-trill.
>>
>> Did anybody consider combining IPFRR techniques with TRILL
>
> While I don't recall any specific mention of it, I don't see that any change
> would be required to existing TRILL standards. Fast ReRoute would run off
> the existing link state databases.
>
> Actually, the above applies only to unicast data. TRILL uses distribution
> trees for multi-destination data and there is
> draft-ietf-trill-resilient-trees which provides back-up distribution trees
> sort of like FRR provides back-up paths.
>
> Thanks,
> Donald
> ===============================
>  Donald E. Eastlake 3rd   [phone] (cell)
>  155 Beaver Street, Milford, MA 01757 USA
>  [e-mail]
>
>>
>> Regards, and lots of thanks in advance,
>> Sasha
>>
>>
>>
>> ________________________________________
>> From: Donald Eastlake <[e-mail]>
>> Sent: Thursday, May 26, 2016 12:03 AM
>> To: Alexander Vainshtein
>> Cc: Mingui Zhang; Zhangxian (Xian); [e-mail];
>> [e-mail]; Susan Hares;
>> [e-mail]; Jonathan Hardwick; [e-mail]
>>
>> Subject: Re: [RTG-DIR] RTG-DIR QA review for
>> draft-ietf-trill-multilevel-single-nickname
>>
>> Hi Alexander,
>>
>> Thanks from me also for your review.  I'd like to chime in with a few
>> thoughts:
>>
>> On Wed, May 25, 2016 at 8:23 AM, Alexander Vainshtein
>> <[e-mail]> wrote:
>> >
>> > Hi Mingui,
>> > I will try to summarize our agreements and disagreements.
>> >
>> > 1.       The scale of TRILL deployments:
>> >
>> > a. I have not seen any specific numbers or references to any
>> > specific topologies that could really make single-level TRILL not
>> > scalable enough - neither in the TRILL drafts I've read nor in our
>> > discussions so far
>>
>> I am puzzled as to why you think there would be some specific numeric
>> hard boundary, other than number space or memory space exhaustion,
>> beyond which you cannot scale. Can you point to a documentation of
>> such a thing for IP use of IS-IS? Surely it depends on how much
>> computer power the routers have, link stability, and numerous other
>> factors.
>>
>> Just looking at convergence time and approximating it as the amount of
>> computation required at a typical router in the TRILL campus, it is on
>> the order of N*(log N) for computation of least cost routes where
>> there are N routers in a single level campus while it is on the order
>> of (sqrt N)*(log N) for multi-level, in both cases assuming optimized
>> calculations. The largest TRILL campuses I am aware of are on the
>> order of 3,000 routers. So one would expect that converting such a
>> campus to multi-level TRILL would reduce convergence time by
>> approximately a factor of 50. Furthermore, one would expect the rate
>> of failures within each Level 1 area in the multi-level case to be
>> approximately proportional to the number of links/routers and thus
>> also fall by one and a half orders of magnitude. Do you claim these
>> improvements would never be valuable?
>>
>> There are many other scaling factors such as the size of the link
>> state database, etc. I believe the informational
>> draft-ietf-trill-rbridge-multi-level gives a good summary.
>>
>> > b. Regarding your reference to multiple interconnected TRILL-based
>> > campuses in your last email: I do not think that TRILL is an
>> > alternative to or competes with Internet.
>>
>> I agree that TRILL does not compete with the Internet.  :-)
>>
>> I believe this facet of the discussion was in connection with the
>> possibility of TRILL nickname space exhaustion. Consider the following
>> factors:
>>
>> 1) TRILL supports active-active connection of end stations at the
>> TRILL edge. Using the techniques in RFC 7781 (Pseudo-Nickname for
>> Active-Active Access) consumes TRILL nicknames for active-active edge
>> groups.
>>
>> 2) Assuming, for the moment, you are using multi-level with unique
>> nicknames, the nickname allocation mechanism will waste many nicknames
>> due to hierarchical assignment, the same way power-of-two sized IP
>> subnets waste IP addresses.
>>
>> 3) There is a desire to interconnect TRILL campuses that are under
>> joint or cooperative management with limited control plane coupling so
>> as to limit error propagation, etc. There are various possible ways to
>> do this but most of them assume non-conflicting nicknames (or
>> non-conflicting level 2 nicknames if the campuses are multi-level).
>>
>> I admit that even taking the largest existing TRILL campuses I know
>> about and adding extensive active-active end station support at the
>> edge and multi-level with unique nicknames that are hierarchically
>> allocated, you would still probably not exhaust the TRILL nickname
>> space. But you could be getting close to that hard limit. This seems
>> like enough reason to me to be advancing a standard where Level 1
>> areas are aggregated (whether by a single nickname or set of border
>> router nicknames) to, for all practical purposes, eliminate the
>> nickname space restriction.
>>
>> > c. I have also noticed that, once upon a time (4 years ago) there
>> > was an attempt to use BGP with TRILL. I wonder why this draft has
>> > been left to expire because, from my POV, BGP is greatly preferable
>> > to multi-level IS-IS when it comes to scalability issues.
>> >
>> > 2. Nickname Re-write vs Nickname Swapping: Looks like a clear case
>> > of misunderstanding between us, probably due to the fact that I am
>> > not a TRILL expert:
>> >
>> > a.       I have used the term "swapping" in the same way it is used
>> > in MPLS (e.g., see RFC 3031 discussing label swapping). In other
>> > words, from my POV "nickname swapping" and "nickname re-write" were
>> > synonyms.
>> >
>> > b.      It seems that some yet to be standardized extension of TRILL
>> > considers some dedicated nickname swapping mechanism that carries
>> > new nicknames in some extension of the TRILL header.  In this
>> > parlance "nickname re-write" and "nickname swapping" are different.
>>
>> Right. The possibility was discussed some time ago of expanding the
>> TRILL header so that, for TRILL Data packets going between different
>> Level 1 Areas, there could be, in effect, two ingress nicknames (an
>> ingress RBridge nickname and an ingress Area nickname) and two egress
>> nicknames (an egress RBridge nickname and an egress Area nickname).
>> Appropriate swapping would occur at border routers to avoid changes in
>> fast path logic at all non-border routers. Within Level 2, the Area
>> nicknames would be in the existing header slots that are routed on,
>> etc. However, as far as I can recall, no specification was ever been
>> produced for this "nickname swapping" although it is mentioned in the
>> informational multi-level draft.
>>
>> > c.       I think that we now safely consider this discussion issue
>> > as closed.
>> >
>> > 3.       Metadata:
>> >
>> > a.       I fully agree that we should hear from other RTG-DIR
>> > members on what exactly (if at all) should be specified to clarify
>> > the relationship between the Single Nickname draft and RFC 6325
>>
>> I would note that the IESG policy on "updates" has become very strict
>> recently. It used to be a judgment call. Now, when a Standards Track
>> RFC merely extends another such RFC so you could implement an instance
>> of the earlier standard as specified without reference to or violating
>> the subsequent specification, the IESG will generally prohibit you
>> from claiming that the subsequent specification "updates" the first.
>> (I do not particularly agree with this policy change myself.)
>>
>> > b.      I can only add that, AFAIK, the Multi-Level TRILL draft,
>> > being positioned as an Informational, can neither update nor
>> > obsolete RFC 6325 (which is Standards Track). So there is no issue
>> > with its metadata being empty.
>> >
>> > There is one issue in my original review that we have not discussed
>> > at all - namely, the behavior implied by the Single Nickname draft
>> > when a new border RBridge is added to a certain area.
>>
>> I agree that what needs to be done when border RBridges are
>> added/deleted needs to be clear in the draft.
>>
>> Thanks,
>> Donald
>> ===============================
>> Donald E. Eastlake 3rd   [phone] (cell)
>> 155 Beaver Street, Milford, MA 01757 USA
>> [e-mail]
>>
>> > Regards,
>> > Sasha
>> >
>> > Office: [phone]
>> > Cell:      [phone]
>> > Email:   [e-mail]
>> >
>> > From: Mingui Zhang [mailto:[e-mail]]
>> > Sent: Wednesday, May 25, 2016 6:07 AM
>> > To: Alexander Vainshtein
>> > Cc: '[e-mail]'; Zhangxian (Xian); [e-mail];
>> > [e-mail]; Susan Hares;
>> > [e-mail]; Jonathan Hardwick
>> > Subject: RE: [RTG-DIR] RTG-DIR QA review for
>> > draft-ietf-trill-multilevel-single-nickname
>> >
>> > Hi Sasha,
>> >
>> > Thanks for the comments.
>> >
>> >
>> > [[Sasha]] Do you (or the authors of the multi-level TRILL draft)
>> > consider deployment scenarios with more than 64K RBridges in a single TRILL
>> > campus? Is this a realistic scenario?
>> > [Mingui] We can also doubt whether a domain with more that 2^32 IP
>> > routers is a realistic scenario. The fact is that a single campus is usually
>> > not allowed to use up the entire 64K namespace. Please consider the scenario
>> > that lots of TRILL campuses are to be interconnected.
>> >
>> >
>> > [[Sasha]] In other words, your draft explicitly states that the area
>> > border RBridges modify the nicknames in the TRILL header of a packet that
>> > crosses the Level 2 domain. How is this different from swapping (save from
>> > the name of the operation)?
>> > [Mingui] As I said, there is no "swap nickname field" conception in the
>> > draft.  Yes, the border RBridge needs to modify the nickname but it does not
>> > have to modify it through the "swapping" operation. Instead, the border
>> > RBridge "replaces" the nickname in the TRILL data packets with its own
>> > nickname (rather than a nickname in the "swap nickname field" provided by
>> > the originating RBridge). Why authors prefer the replacing operation than
>> > the swapping operation? Because the swapping operation requires a new TRILL
>> > header (two additional 16-bit fields) which has not been standardized yet.
>> >
>> > As for the "Updates" metadata, let's see if people on the RTG-DIR list
>> > would give directions.
>> >
>> > Best regards,
>> > Mingui
>> > From: Alexander Vainshtein [mailto:[e-mail]]
>> > Sent: Tuesday, May 24, 2016 6:45 PM
>> > To: Mingui Zhang
>> > Cc: '[e-mail]'; Zhangxian (Xian);
>> > [e-mail]<mailto:[e-mail]>;
>> > [e-mail]<mailto:[e-mail]>;
>> > Susan Hares; [e-mail]<mailto:[e-mail]>; Jonathan
>> > Hardwick
>> > Subject: RE: [RTG-DIR] RTG-DIR QA review for
>> > draft-ietf-trill-multilevel-single-nickname
>> >
>> > Mingui hi!
>> > Lots of thanks for a prompt response.
>> >
>> > A few short comments inline below.
>> >
>> > Regards,
>> > Sasha
>> >
>> > Office: [phone]
>> > Cell:      [phone]
>> > Email:
>> > [e-mail]<mailto:[e-mail]>
>> >
>> > From: Mingui Zhang [mailto:[e-mail]]
>> > Sent: Tuesday, May 24, 2016 11:23 AM
>> > To: Alexander Vainshtein
>> > Cc: '[e-mail]'; Zhangxian (Xian);
>> > [e-mail]<mailto:[e-mail]>;
>> > [e-mail]<mailto:[e-mail]>;
>> > Susan Hares; [e-mail]<mailto:[e-mail]>; Jonathan
>> > Hardwick
>> > Subject: RE: [RTG-DIR] RTG-DIR QA review for
>> > draft-ietf-trill-multilevel-single-nickname
>> >
>> > Hi Sasha,
>> >
>> > Thanks for your comments. Please see responses inline below.
>> >
>> > Thanks,
>> > Mingui
>> >
>> > From: Alexander Vainshtein [mailto:[e-mail]]
>> > Sent: Monday, May 23, 2016 6:13 PM
>> > To: Mingui Zhang
>> > Cc: '[e-mail]'; Zhangxian (Xian);
>> > [e-mail]<mailto:[e-mail]>;
>> > [e-mail]<mailto:[e-mail]>;
>> > Susan Hares ([e-mail]<mailto:[e-mail]>);
>> > [e-mail]<mailto:[e-mail]>; Jonathan Hardwick
>> > ([e-mail]<mailto:[e-mail]>)
>> > Subject: RE: [RTG-DIR] RTG-DIR QA review for
>> > draft-ietf-trill-multilevel-single-nickname
>> >
>> >
>> > Mingui hi!
>> >
>> > Lots of thanks for a prompt response to some of the issues I've raised
>> > in the review.
>> >
>> >
>> >
>> > Please see some comments to you responses inline below.
>> >
>> >
>> >
>> > Regards,
>> >
>> > Sasha
>> >
>> >
>> >
>> > Office: [phone]
>> >
>> > Cell:      [phone]
>> >
>> > Email:
>> > [e-mail]<mailto:[e-mail]>
>> >
>> >
>> >
>> > -----Original Message-----
>> > From: rtg-dir [mailto:[e-mail]] On Behalf Of Mingui
>> > Zhang
>> > Sent: Monday, May 23, 2016 12:31 PM
>> > To: Alexander Vainshtein; Jonathan Hardwick
>> > ([e-mail]<mailto:[e-mail]>)
>> > Cc: '[e-mail]'; Zhangxian (Xian);
>> > [e-mail]<mailto:[e-mail]>;
>> > [e-mail]<mailto:[e-mail]>;
>> > Susan Hares ([e-mail]<mailto:[e-mail]>);
>> > [e-mail]<mailto:[e-mail]>
>> > Subject: Re: [RTG-DIR] RTG-DIR QA review for
>> > draft-ietf-trill-multilevel-single-nickname
>> >
>> >
>> >
>> > Hi Alexander,
>> >
>> >
>> >
>> > Thanks for the review!
>> >
>> >
>> >
>> > The multilevel conception itself is abstract and not easily
>> > understandable.
>> >
>> > [[Sasha]] Do you refer to the multi-level IS-IS in general or
>> > multi-level TRILL specifically? I am asking because I believe am reasonably
>> > well aware of the multi-level architecture of IS-IS as used for IP routing.
>> > It is somewhat different from that of OSPF, but I would not call it
>> > "abstract and not easily understandable".  And there are quite a few
>> > excellent introductions to the subject (again in the context of IP routing).
>> > However, I am definitely not a TRILL expert, and have stated that in the
>> > review.
>> >
>> >
>> >
>> > [Mingui] Yes, multi-level arch of IS-IS has already been well
>> > understood. However, the extending TRILL to multi-levels brings new
>> > challenges. As stated in the informational draft, one issue is on processing
>> > the TRILL switch nicknames and the other issue is on handling
>> > multi-destination packet distribution trees. In order not to make the
>> > specifications "abstract", the draft carefully designed two walking-through
>> > examples in Section 3. If the examples were understood, it would be
>> > non-abstract as well. ;-)
>> >
>> >
>> >
>> > However, it was really interesting in designing such a solution.
>> > Appreciate the review and the time on relevant documents to figure out the
>> > whole scheme.
>> >
>> >
>> >
>> > > ?  Nor provides any explanations about the reasons that make
>> >
>> > > single-level IS-IS used by TRILL less scalable that single-level IS-IS
>> >
>> > > when it is used for distributing IP reachability
>> >
>> >
>> >
>> > The reason comes from the fact that the length of a nickname is
>> > different from an IP address.
>> >
>> > [[Sasha]] I must admit that I do not understand the connection. By this
>> > logic, IS-IS for CLNS and IPv6 should be much more scalable than IS-IS for
>> > IPv4, but I have never seen such claims before. Could you please elaborate?
>> > Could somebody on the RTG-DIR list to comment on that?
>> >
>> >
>> >
>> > [Mingui] For a single-level IS-IS instance, the length of the address
>> > determines the name space. In the informational draft, Section 1.1 TRILL
>> > Scalability Issues, the following statement is relevant
>> >
>> > "   5. the limit of the number of TRILL switches, due to the 16-bit
>> > nickname space,"
>> >
>> > [[Sasha]] Do you (or the authors of the multi-level TRILL draft)
>> > consider deployment scenarios with more than 64K RBridges in a single TRILL
>> > campus? Is this a realistic scenario?
>> >
>> >
>> >
>> >
>> >
>> > I think this could be addressed in the updated version of the draft:
>> > https://datatracker.ietf.org/doc/draft-ietf-trill-rbridge-multilevel/?include_text=1.
>> >
>> >
>> >
>> > > *         The draft positions itself as an alternative to the
>> > > Aggregate
>> >
>> > > Nicknames approach while, from my POV, it is just provides additional
>> >
>> > > details on one of the possible flavors of this approach
>> >
>> >
>> >
>> > The WG used to discuss several ways to address the "Aggregate Nickname"
>> > approach.
>> >
>> > [[Sasha]] I do not follow the TRILL WG mailing list, so I am not aware
>> > of any discussions that have been hold there. I am only speaking about what
>> > I could find in the two drafts mentioned in my review.
>> >
>> >
>> >
>> > [Mingui] Actually, the informational draft had included the information
>> > of those alternatives as well. Please see "Section 2.2.2.2 Swap Nickname
>> > Field Aggregated Nicknames" and read the words about "pseudonode" of Section
>> > 2.5
>
>