Re: [trill] TRILL Resilient Distribution Trees, who have read it?

[Mingui Zhang <[e-mail]>]

Hi Gayle,

Thanks for your review! I will soon update the draft and embody those changes you’ve suggested.
Responses to your questions are offered as follows.

>Question: if this computation is done independently what do they mean by "the same result is got across the whole campus" ??

same [consistent]

>question: Similar as [CMT] .. what does this mean?

In the CMT draft, the nickname of the originator of the Affinity TLV is not explicitly included. When an RBridge receives this TLV, it knows the originator, therefore it can pinpoint the Affinity Link (from ‘originator’ to the RB specified in the ‘AFFINITY RECORD’). This also means, only the upstream-attached node can announce an Affinity Link.

>tag for RPFC relaxing

It would be great if we can introduce a tag here. I’d like to take one step further. I suggest using one bit from the Multi-Topology field as the tag. With this tag, RPFC relaxing will become unnecessary. I remember a guy also mentioned whether we can make use of MT technique in an offline discussion. Unfortunately, the MT feature is not supported by TRILL yet.

RPFC relaxing is expensive. That is why I once suggested in a TRILL face-to-face meeting that the content about the local protection is offered in the draft for the clarification purpose. The rationale is like this: most guys from vendors and operators prefer local protection to global protection. If no local protection content is included, they will be confused.

If the MT feature is supported by TRILL in the future. We can treat the content of local protection as the place-holder. It can easily be updated to make use of the MT technique to replace the RPFC relaxing.

Thanks,
Mingui



________________________________
From: [e-mail] [[e-mail]] on behalf of gayle noble [[e-mail]]
Sent: Friday, December 07, 2012 0:54
To: [e-mail]
Subject: Re: [trill] TRILL Resilient Distribution Trees, who have read it?


(in my opinion) corrections:
1. Introduction
Normally, network [Normally, a network] fault will be recovered through a network wide reconvergence of the forwarding states but [states, but] this process is too slow to meet the tight SLA requirements on the service disruption duration.

in the next paragraph:
With backup forwarding states installed in advance, a protection mechanism is possible to restore a interrupted [an interrupted] multicast stream in tens of milliseconds which guarantees the stringent SLA on service disruption

However, the way TRILL constructs distribution trees (DT) is different from the way multicast trees are computed under IP/MPLS therefore [IP/MPLS, therefore] a multicast protection mechanism suitable for TRILL is required.

Global 1:1 protection is used to refer to the mechanism having the multicast source RBridge normally injects [inject] one multicast stream onto the primary DT.

When this stream is detected to be interrupted, the source RBridge switches to the backup DT to inject subsequent multicast stream [streams] until the primary DT is recovered.

Global 1+1 protection is used to refer to the mechanism having the multicast source RBridge always injects [inject] two copies of multicast streams onto the primary DT and backup DT respectively.

In [the] normal case, multicast receivers pick the stream sent along the primary DT and egress it to its local link.


2.2
When RBridges receive an Affinity Link which is an incoming link of RB2. RB2's [RB2, RB2's] incoming links other than the Affinity Link are removed from the full graph of the campus to get a sub graph.

(point four)
  In order to protect a node on the primary tree, a backup tree can be
  set up as lack of this [setup without this] node [mMRT].

A DT does [DT that does] not span all RBridges in the campus may not cover all receivers of many a multicast [many multicast] group (This is different from the multicast trees construction signaled by PIM [RFC4601] or mLDP [RFC6388].).
3.2.1
For example, in Figure 3.1, the backup DT is set up maximally disjoint to the primary DT(The full topology is an combination [a combination] of these two DTs, which is not shown in the figure.).

Except the [Except for the] link between RB1 and RB2, all other links on the primary DT do not overlap with links on the backup DT.

It means that every link on the primary DT except link RB1-RB2 can DT, except link RB1-RB2, can] be protected by the backup DT.

3.2.1.1
But it is desirable that each RBridge independently computes Affinity Links for a backup DT while the same result is got across the whole campus, which enables a distributed deployment and also minimizes configuration . [ configuration.]

Question: if this computation is done independently what do they mean by "the same result is got across the whole campus" ??


Algorithms for MRT [mMRT] may be used to figure out Affinity Links on a backup DT which is maximally disjoint [disjointed] to the primary DT but it only provides a subset of all possible solutions.

Two disjoint [disjointed] (or maximally disjoint [disjointed ]) trees may root from  different nodes, which significantly augments the solution space.

In order to reduce the amount of Affinity TLVs flooded across the campus, only those will not [those not] picked by conventional DT calculation process ought to be recognized as Affinity Links.

3.2.1.2
Similar as [CMT], every Parent RBridge (PRB) of an Affinity Link take [takes] charge of announcing this link in the Affinity TLV.

question: Similar as [CMT] .. what does this mean?

3.2.2. Backup DT Calculation without Affinity Links

This section aims to provide an alternative method to set up the disjoint [disjointed] DT without Affinity Links.

In other words, the two trees will be maximally disjoint [disjointed ].

To sum up, RBridges do precompute [pre-compute] all the trees that might be used but [used, but] only install part of them according to each ingress.

Since the backup DT is intentionally built up maximally disjoint [disjointed ] to the primary DT, when a link fails and interrupts the ongoing multicast traffic sent along the primary DT, it is probably that the backup DT is not affected.


4.1. Pruning the Backup Distribution Tree
  Backup [The backup] DT should be pruned per-VLAN.
But the way backup [way a backup] DT being [is] pruned is different from the way that the primary DT is pruned.

Even though a branch contains no downstream receivers, it is probably [probable] that it should not be pruned for the purpose of protection.

Those redundant links [that] ought to be pruned will not be protected.

4.2
However, when global 1+1 protection or local protection is applied, traffic duplication will happen if multicast receivers accept both copies of multicast [of the multicast] frame from two RPF filters.

In order to avoid such duplication, multicast receivers (egress RBridge) MUST act as merge points to active [activate] a single RPF filter and discard the duplicated frames from the other RPF filter.

5.1
Upon [When] the ingress RBridge is notified about the failure, it immediately makes this switch over.

[The] Ingress RBridge will switch ongoing multicast traffic based on this judgment.

For example, if RB9 does not response while RB10 still responses [ responds], RB7 will presume that link RB1-RB5 and RB5-RB9 are failed.

Accurate link failure detection might help ingress RBridge [RBridges] to make smarter decision but it's out of the scope of this document.

RBridges may make use of [the] RBridge Channel to speed up the failure propagation [RBch]. LSPs for the purpose of failure notification may be sent to the ingress RBridge as unicast TRILL Data using [the] RBridge Channel.

5.2.2. Traffic Forking and Merging

For the sake of protection, transit RBridges SHOULD active [activate] both primary and backup RPF filters, therefore both copies of the multicast frames will pass through transit RBridges.

 5.3.
In the local protection, the Point of Local Repair (PLR) happens at the upstream RBridge connecting the failed link who [link. It is this RBridge that] makes the decision to replicate the multicast traffic to recover this link failure.

Since the ingress RBridge is not necessarily the root of the distribution tree in TRILL, a multicast downstream point may be not [may not be] the descendants of the ingress point on the distribution tree.

5.3.1
But the ingress of the multicast frame MUST be remained [MUST remain] unchanged.


5.3.2. Duplication Suppression

When a PLR starts to sent [send] replicated multicast frames on the backup DT, multicast frames sent along the primary DT are still going on.

5.4
c
However, if the PLR stops redirecting earlier than the ingress RBridge switches to the new primary DT, packet loss may happen; [.]



[my concern: Relaxing the Reverse Path Forwarding check could cause problems unless some additional magic is added. Could a tag be added stating path down. example: RB1-RB5 down. Thus the receiving RBridge knows it can relax its Reverse Path Forwarding check for that path. ]