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

From: Anoop Ghanwani <[email-masked]>
Date: Mon, 3 Dec 2012 19:05:13 -0800

Just wanted to say that I support this work (as a co-author).

I think this will make provisioning simpler and would allow an
operator to create multiple trees that are maximally disjoint.
In the case of fat trees, this is fairly trivial to do in a manual
way (just use different "core" RBridges as roots), but in any
other topology, this will help avoid overlapping links.

Anoop

On Fri, Nov 30, 2012 at 12:18 AM, Mingui Zhang <[email-masked]>wrote:

> Hi all,
>
> When customers deploy TRILL in their networks, they concern much about
> minimizing the disruption of their multicast service. So failure protection
> mechanisms are desired. Protection solutions for IP Multicast service have
> been developed and standardized. However, unlike unicast, multicast
> protection solutions cannot be reused by TRILL because TRILL-multicast is
> customized for TRILL. Therefore we composed the draft to provide the
> multicast protection suitable for TRILL.
>
> As we know, TRILL can intrinsically calculate multiple distribution trees.
> In the draft, this ability is leveraged to achieve multicast protection in
> a way that the pay is insignificant.
>
> We believe this work deserves our exploration. So, we would like to know,
> who have read this draft?
>
> The draft
> TRILL Resilient Distribution Trees
> http://datatracker.ietf.org/doc/draft-zhang-trill-resilient-trees/
>
> Thanks,
> Mingui
> _______________________________________________
> trill mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trill
>

---

From: Ayan Banerjee <[email-masked]>
Date: Tue, 4 Dec 2012 10:23:33 -0800

I would like to voice support for this work (as a co-author).

It is important to have some determinism to the manner in which
multi-destination trees are computed for operational purposes and
this draft is a step in that direction.

Thanks,
Ayan

On Mon, Dec 3, 2012 at 7:05 PM, Anoop Ghanwani <[email-masked]>wrote:

>> As we know, TRILL can intrinsically calculate multiple distribution
>> trees. In the draft, this ability is leveraged to achieve multicast
>> protection in a way that the pay is insignificant.
>>

---

From: Haoweiguo <[email-masked]>
Date: Wed, 5 Dec 2012 00:39:11 +0000

I have read the draft and think it's OK to provide multicast protection solutions!
Thanks
weiguo

________________________________________
发件人: Mingui Zhang [[email-masked]]
发送时间: 2012年11月30日 16:18
到: [email-masked]
主题: [trill] TRILL Resilient Distribution Trees, who have read it?

Hi all,

When customers deploy TRILL in their networks, they concern much about minimizing the disruption of their multicast service. So failure protection mechanisms are desired. Protection solutions for IP Multicast service have been developed and standardized. However, unlike unicast, multicast protection solutions cannot be reused by TRILL because TRILL-multicast is customized for TRILL. Therefore we composed the draft to provide the multicast protection suitable for TRILL.

As we know, TRILL can intrinsically calculate multiple distribution trees. In the draft, this ability is leveraged to achieve multicast protection in a way that the pay is insignificant.

We believe this work deserves our exploration. So, we would like to know, who have read this draft?

The draft

Thanks,
Mingui

---

From: <[email-masked]>
Date: Wed, 5 Dec 2012 10:18:06 +0530

Support (As a co-author)

Thanks
Jana

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ayan Banerjee
Sent: Tuesday, December 04, 2012 11:54 PM
To: [email-masked]
Subject: Re: [trill] TRILL Resilient Distribution Trees, who have read it?

Thanks,
Ayan

On Mon, Dec 3, 2012 at 7:05 PM, Anoop Ghanwani <[email-masked]<mailto:[email-masked]>> wrote:
Just wanted to say that I support this work (as a co-author).

Anoop

On Fri, Nov 30, 2012 at 12:18 AM, Mingui Zhang <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

The draft

Thanks,
Mingui
_______________________________________________
trill mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/trill

_______________________________________________
trill mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/trill

---

From: "Guyingjie (Yingjie)" <[email-masked]>
Date: Wed, 5 Dec 2012 06:30:24 +0000

I read it and Support it.

The draft

Thanks,
Mingui

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 5 Dec 2012 16:31:36 +0000

Support,

Linda Dunbar

Thanks,
Ayan

Anoop

The draft

Thanks,
Mingui

---

From: Sam Aldrin <[email-masked]>
Date: Wed, 5 Dec 2012 10:02:44 -0800

I haven't paid too much attention into the details of the draft. Hence i will defer questions related to draft, for later time. But I do have few questions related to procedure.

1. I do not see this work item chartered for TRILL WG. Until it is done, it is not prudent for WG to focus on non-chartered items, atleast till the updated charter is in place.
2. Is this email a WG adoption call? Not being aware IETF procedures, can individuals call for WG adoption or is it done by chairs? If it is only by WG chairs, what is the purpose of this email.

Cheers
Sam

Sent from my iPad

---

From: [email-masked]
Date: Thu, 6 Dec 2012 08:58:00 +0800

I have read the draft and support it.

Best Regards,
Zhai Hongjun
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
 Protocol Development Dept.VI, Central R&D Institute, ZTE Corporation
 No. 68, Zijinghua Road, Yuhuatai District, Nanjing, P.R.China, 210012
 
 Zhai Hongjun
 
 Tel: +86-25-52877345
 Email: [email-masked]
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""

Linda Dunbar <[email-masked]> 
发件人:  [email-masked]
2012-12-06 00:31

收件人
"[email-masked]" <[email-masked]>, 
"[email-masked]" <[email-masked]>, "[email-masked]" 
<[email-masked]>
抄送

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

Support, 
 
Linda Dunbar

From: [email-masked] [mailto:[email-masked]] On Behalf Of 
Ayan Banerjee
Sent: Tuesday, December 04, 2012 11:54 PM
To: [email-masked]
Subject: Re: [trill] TRILL Resilient Distribution Trees, who have read it?

Thanks,
Ayan
 
On Mon, Dec 3, 2012 at 7:05 PM, Anoop Ghanwani <[email-masked]> 
wrote:
Just wanted to say that I support this work (as a co-author).

Anoop
 
On Fri, Nov 30, 2012 at 12:18 AM, Mingui Zhang <[email-masked]> 
wrote:
Hi all,

When customers deploy TRILL in their networks, they concern much about 
minimizing the disruption of their multicast service. So failure 
protection mechanisms are desired. Protection solutions for IP Multicast 
service have been developed and standardized. However, unlike unicast, 
multicast protection solutions cannot be reused by TRILL because 
TRILL-multicast is customized for TRILL. Therefore we composed the draft 
to provide the multicast protection suitable for TRILL.

The draft

Thanks,
Mingui

---

From: Mingui Zhang <[email-masked]>
Date: Thu, 6 Dec 2012 02:51:51 +0000

Hi Sam,

As you can see from the words of the email, it is not a WG adoption polling. I am cautious about this.

According to the decision that the WG had made at the Atlanta meeting, authors were asked to make sure in the TRILL mailing-list whether there is enough number of guys who have read this draft. So, this email actually intends to help chairs to decide whether this draft deserves a call. I wish I have clarified your confusion.

Actually, this draft falls in the scope depicted by the recently updated charter. It is one of those "additional ways to extend and optimize TRILL for the properties of the networks on which it is deployed".

Thanks,
Mingui

________________________________________
From: [email-masked] [[email-masked]] on behalf of Sam Aldrin [[email-masked]]
Sent: Thursday, December 06, 2012 2:02
To: Mingui Zhang
Cc: [email-masked]
Subject: Re: [trill] TRILL Resilient Distribution Trees, who have read it?

Cheers
Sam

Sent from my iPad

---

From: Sam Aldrin <[email-masked]>
Date: Wed, 5 Dec 2012 19:03:23 -0800

Mingui,

Thanks for the email.
When everyone starts saying 'I support', was not sure what they want to support. 
I do not think 'I've read' is what they are saying.

In regards to updated charter, where is the updated charter? I do not see that at "http://datatracker.ietf.org/wg/trill/charter/"

As far as basing the reason on  ""additional ways to extend and optimize TRILL for the properties of the networks on which it is deployed"". Pretty much every personal draft of TRILL could argue with the same reason.
For ex: take example of #1 and #2 in the charter, where it clearly outlines what work WG is chartered for. 

I do not have problem with the draft as long it is clearly identified in the WG charter.

-sam

---

From: Zhangxudong <[email-masked]>
Date: Thu, 6 Dec 2012 07:13:55 +0000

I have read it and think it's good to provide multicast protection in TRILL.

发件人: [email-masked] [mailto:[email-masked]] 代表 Linda Dunbar
发送时间: 2012年12月6日 0:32
收件人: [email-masked]; [email-masked]; [email-masked]
主题: Re: [trill] TRILL Resilient Distribution Trees, who have read it?

Support,

Linda Dunbar

Thanks,
Ayan

Anoop

The draft

Thanks,
Mingui

---

From: gayle noble <[email-masked]>
Date: Thu, 06 Dec 2012 08:54:40 -0800

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

---

From: Mingui Zhang <[email-masked]>
Date: Fri, 7 Dec 2012 02:18:14 +0000

Hi Sam,

Thanks for the points you offered.

I believe people made their responses as the email required. I’d better not make any further assumption here. I’d like to solicit the chairs to take further actions based on these feedbacks. 

Thanks,
Mingui

________________________________________
From: Sam Aldrin [[email-masked]]
Sent: Thursday, December 06, 2012 11:03
To: Mingui Zhang
Cc: [email-masked]
Subject: Re: [trill] TRILL Resilient Distribution Trees, who have read it?

Mingui,

Thanks for the email.

-sam

---

From: Mingui Zhang <[email-masked]>
Date: Fri, 7 Dec 2012 02:19:37 +0000

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: [email-masked] [[email-masked]] on behalf of gayle noble [[email-masked]]
Sent: Friday, December 07, 2012 0:54
To: [email-masked]
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.

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.

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.

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

---

From: gayle noble <[email-masked]>
Date: Thu, 06 Dec 2012 18:27:22 -0800

Mingui

Thank you so much for taking the time to explain that to me! I now know
to look up these references instead of staying confused.

gayle

At 06:19 PM 12/6/2012, Mingui Zhang wrote:

Hi
Gayle,

Thanks for your review! I will soon update the draft and embody those
changes you’ve suggested.

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: [email-masked]
Date: Fri, 7 Dec 2012 14:54:30 +0800

I have read the draft.

The draft provides to build backup distribution tree for link protection, 
which mininizes the serive disruption for multicast data forwarding.

If there is a WG adoption polling, I support it.

Mingui Zhang <[email-masked]> 
发件人:  [email-masked]
2012-11-30 16:18

收件人
"[email-masked]" <[email-masked]>
抄送

主题
[trill] TRILL Resilient Distribution Trees, who have read it?

Hi all,

The draft

Thanks,
Mingui

---

From: gayle noble <[email-masked]>
Date: Fri, 07 Dec 2012 22:19:03 -0800

(in my opinion)  grammatical corrections to document

Page 20

rbridgeBasePortStpWiringCloset OBJECT-TYPE

The value of this object MUST be retained across
reinitializations
[re-initializations] of the management
system."

Page 21

rbridgeConfidenceNative OBJECT-TYPE

The value of this object MUST be retained across
reinitializations
[re-initializations] of the management
system."

rbridgeConfidenceStatic OBJECT-TYPE

The value of this object MUST be retained across
reinitializations
[re-initializations] of the management
system."

page 28

rbridgeVlanDisableLearning OBJECT-TYPE

The value of this object MUST be retained across
reinitializations [re-initializations]
of the management system."

page 30

rbridgeVlanPortAnnouncing OBJECT-TYPE

The value of this object MUST be retained across
reinitializations
[re-initializations] of the management
system."

page 31

As another example,frames
[example, frames]discarded due to excessive
frame size are reported in the port counter MTU Exceeded Discards in the
Bridge MIB.

page 32

"The number of times a
multidestination
[multi destination] frame was dropped on
this port because the RPF check failed.

page 34

rbridgeEsadiEnable OBJECT-TYPE

The value of this object MUST be retained across
reinitializations
[re-initializations] of the
management system."

page 35

rbridgeEsadiDrbPriority OBJECT-TYPE

The value of this object MUST be retained across
reinitializations
[re-initializations] of the management
system."

rbridgeEsadiDrbHoldingTime OBJECT-TYPE

The value of this object MUST be retained across
reinitializations
[re-initializations] of the management
system."

page 37

rbridgeSnoopingPortAddrType OBJECT-TYPE

"The IP address type of an IP multicast router
detcted
[detected]on this port and VLAN. If
only IPv4 router(s) are detected, the value returned
in
[is]'ipv4'.

page 39

rbridgeDtreePriority OBJECT-TYPE

The value of this object MUST be retained across
reinitializations
[re-initializations] of the management
system."

page 41

rbridgeTrillMinMtuDesired OBJECT-TYPE

The value of this object MUST be retained across
reinitializations
[re-initializations] of the management
system."

page 42

rbridgeTrillMaxMtuProbes OBJECT-TYPE

The value of this object MUST be retained across
reinitializations
[re-initializations] of the management
system."

thanks

gayle

---

From: Thomas Narten <[email-masked]>
Date: Fri, 14 Dec 2012 11:59:59 -0500

Hi.

Per the Atlanta minutes:

> Donald Eastlake (Huawei, co-Chair): OK how many people have read this
> draft? That's a pretty small number so I suggest a message to the list
> urging people to read this draft.
> 
> Thomas Narten (IBM): I have a high level question. How important is
> this document to the core of what we have to do as a WG? Seems like
> this assumes you have a distribution tree, which we have now, and the
> model is that if something goes wrong you just re-build the
> tree. Maybe there is a brief period during which things don't
> work. What we are doing here is building up a stand-by path. How
> important is this? Do we know that convergence is too slow? It seems
> to be to be pre-mature to work on this.
> 
> Donald: I agree that that is the relevant question. How important is
> this draft? Perhaps you should post that question to the list.

I'm asking this question on the list.

Thomas

---

From: Mingui Zhang <[email-masked]>
Date: Mon, 17 Dec 2012 07:12:41 +0000

Hi Thomas,

Thanks for posting the question.

TRILL provides multicast service using ISIS link state routing. When there is a failure, RBridges are notified through the propagation of LSPs, which will trigger a campus-wide convergence on distribution trees. The convergence includes the following major processes: 1) the propagation of LSPs around the whole campus; 2) the recalculation of trees on affected RBridges; 3) the update of forwarding information on those RBridges. These processes make the convergence time-consuming. As we know, most multicast traffic is generated by applications which are sensitive to interrupt latency. Therefore, the convergence will lead to the disruption of multicast service.

Due to the propagation delay of LSPs, the distribution trees are calculated and installed on RBridges at different time, which brings _inconsistence_ of forwarding states among RBridges. Before the convergence finishes, multicast frames may be trapped by forwarding loops and finally dropped. This increases the volume of broadcast/multicast traffic. 

Protection is not a new topic for link state routing. It was proposed to reduce traffic disruption and resolve inconsistence during convergence using backup paths pre-installed. TRILL specified to calculate multiple distribution trees in those first days, which offers kind of ability for protection. The draft "TRILL Resilient Distribution Trees" makes use of this feature to provide the multicast protection without significant pay, which is natural rather than premature.

Thanks,
Mingui

>-----Original Message-----
>From: Thomas Narten [mailto:[email-masked]]
>Sent: Saturday, December 15, 2012 1:00 AM
>To: Mingui Zhang
>Cc: [email-masked]

---

From: Thomas Narten <[email-masked]>
Date: Tue, 18 Dec 2012 10:35:51 -0500

Hi.

I understand at a high level what the reational is. What I'm really
trying to get at is: does the cost/complexity justify the benefit? For
this, some quantifiable metrics would help - not just generalities
like "convergence will be faster", etc.

> TRILL provides multicast service using ISIS link state routing. When
>  there is a failure, RBridges are notified through the propagation
>  of LSPs, which will trigger a campus-wide convergence on
>  distribution trees. The convergence includes the following major
>  processes: 1) the propagation of LSPs around the whole campus; 2)
>  the recalculation of trees on affected RBridges; 3) the update of
>  forwarding information on those RBridges. These processes make the
>  convergence time-consuming.

I take issue with this. The whole point of link-state flooding
approaches is that they are fast - much faster than alternatives.

And as a data point, back in Paris, Paul Unbehagen gave a presentation
in the IS-IS WG on SPB deployment where (according to my notes):

    They are seeing 34-100ms convergence times and think this can be
    further reduced by an order of magnitude (recommendation 7)

Won't TRILL have similar convergence times? Are we talking about using
failover to shave off a few tens of milliseconds? Or is there some
sort of expectation that this will shave seconds or more off the
recovery time?

That is, do we have any evidence (or targets) for TRILL convergence
times (after a topology change) that are "too long"? Just "how fast"
reconvergence is considered fast enough, and what is considered
problematical?

> As we know, most multicast traffic is
>  generated by applications which are sensitive to interrupt
>  latency. Therefore, the convergence will lead to the disruption of
>  multicast service.

Which applications are those? Are there particular deployment
scenarios that are being targetted, or is this just a general
argument?

> Due to the propagation delay of LSPs, the distribution trees are
>  calculated and installed on RBridges at different time, which
>  brings _inconsistence_ of forwarding states among RBridges. Before
>  the convergence finishes, multicast frames may be trapped by
>  forwarding loops and finally dropped. This increases the volume of
>  broadcast/multicast traffic.

And just how long does this period of "inconsistency" last? And just
how quickly will a node know that a path that it is using has failed
and that it needs to fallback to using the precomputed backup path?
Won't it also take time for news of a failure to propagate through the
network? In other words, won't the network already be reconfiguring
itself even before a node realizes that a path has failed and it
should switch to a backup?

So again, I'm really trying to understand just how much of an
improvement the proposed approach is expected to produce.

To be clear, I'm not necessarily opposed to this work. But I would
like a better understanding of exactly how much benefit we can really
expect, so I can understand how to weigh the tradeoffs between
increased complexity vs. actual benefit.

Thomas

---

From: Mingui Zhang <[email-masked]>
Date: Wed, 19 Dec 2012 09:30:07 +0000

Hi Thomas,

>    further reduced by an order of magnitude (recommendation 7)

When you say convergence time can be as short as 34 ms, it certainly does not include the failure detection time. Since failures are detected in ISIS by non-receipt of Hellos within three holding timers, which are "commonly set to a value of tens of seconds and, in any case, has a minimum expressible value of one second [rbBFD]". When the presenter mentioned the convergence time, I believe he meant "the time elapsed from a failure event realized by the control protocol until the forwarding has been recovered [CONVERGE]". However, the service disruption does include the failure detection time, during which the forwarding paths via the failure spot are already cut off. So, the service disruption time at least includes the following two parts: 1) Failure detection time; 2) Service resuming time (a.k.a. convergence time).

>sort of expectation that this will shave seconds or more off the

We expect that "TRILL Resilient Distribution Trees" reduce the whole recovery time.

>scenarios that are being targetted, or is this just a general

Video distribution (e.g., IPTV) is such kind of application [RDT].

>should switch to a backup?

The figure on page 4 of [CONVERGE] also tells us that inconsistence introduces a sky-high deal of looping traffic. This period can last seconds. RDT not only reduces the service disruption time but also decreases the looping traffic.

There are three kinds of protection described in the draft. Only the global 1:1 protection relies on the "news of a failure" to determine to switch to a backup.

We catch the issue in Section 5.4 of the draft. You will find there is no problem that network reconfiguration and the use of backup take place in parallel.

>improvement the proposed approach is expected to produce.

Let me quantify the improvement we expected to produce:
"Service disruption time should be magnitude shorter than one second [RFC5714]". 
Exactly, we expect [RDT] meets "Realistic availability requirements (sub-second to sub-200msec)... [MOFRR]". 

References
[rbBFD] http://www.ietf.org/id/draft-ietf-trill-rbridge-bfd-07.txt
[CONVERGE] http://www.ieee802.org/1/files/public/docs2010/new-farkas-convergence-1110.pdf
[RDT] http://datatracker.ietf.org/doc/draft-zhang-trill-resilient-trees/?include_text=1
[RFC5714] http://tools.ietf.org/html/rfc5714
[MOFRR] http://tools.ietf.org/html/draft-karan-mofrr-02

Thanks,
Mingui

>Sent: Tuesday, December 18, 2012 11:36 PM
>To: Mingui Zhang
>Cc: [email-masked]

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 19 Dec 2012 11:41:43 -0500

Hi Thomas,

> approaches is that they are fast - much faster than alternatives.

They are also more stable than distance-vector methods.

> sort of expectation that this will shave seconds or more off the

Absolute values of convergence time seem meaningless to me without
knowing how much horsepower the routing computation CPU has, how many
nodes there are, and how much computation you are doing (for example,
how many distribution trees you are computing in a TRILL campus).

> reconvergence is considered fast enough, and what is considered

Any loss of traffic is bad. A typical acceptable limit for one kind of
inherently redundant traffic, voice, is 50 milliseconds.

A common rule of thumb is that it is good to test every 10
milliseconds so that, after a few successive test packets fail you
can, even allowing for various overhead, bound the switchover time to
be less than 50 milliseconds.

> scenarios that are being targetted, or is this just a general

What I hear about most are real time streaming media, like voice and
video, and distribution of financial information.

>>  broadcast/multicast traffic.

Unicast frames can loop briefly during a transient unless you use
ordered FIBs; however, although there is no technique I am aware of
similar to ordered FIBs for multicast distribution, due to the reverse
path forwarding check, I think it is much more likely that multicast
traffic will be dropped than that they will loop.

> And just how long does this period of "inconsistency" last?

For failures, conditions that will lose traffic really can extend from
the initial failure until the tree forwarding and RPFC information at
all RBridges is consistent with the new topology. Inconsistency of
that information depends on the fastest and slowest RBridges to
adjust. So you could have an RBridge with a particularly powerful
processor that gets the LSPs indicting the change in topology early
and that only has a few ports connected to an RBridge with a
particularly feeble processor that gets the LSPs indicating the change
in topology late and has a zillion ports connected...

> And just

Sometimes you can tell quickly that an directly connected link has
failed due to physical layer or link layer test protocol indications.
For a "path", you may have to send test messages at that level and how
quickly you find out depends on how frequently you test.

> should switch to a backup?

Probably. But if you are a source multiple hops away from the failure
and have detected the failure due to your path test messages, you
might prefer to "instantly" switch to a pre-configured maximally
disjoint alternative tree rather than wait for the slowest
reconfiguring RBridge along some new path the network is trying to
configure itself to before your traffic starts getting through again.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]