Subject: [trill] [rbridge] draft-hu-trill-rbridge-esadi-04

From: somnath chatterjee <[email-masked]>
Date: Fri, 20 Apr 2012 22:47:27 +0530

Hi Authors,

I have read the draft-hu-trill-rbridge-esadi-04 and support it.

I have one question regarding the problem stated in the draft

 " 2. Fast update advantages: ESADI protocol provides a fast update of
      end nodes MAC (Media Access Control) addresses.  If an end station
      is unplugged from one RBridge and plugged into another, frames
      addressed to that older RBridge can be black holed.  They can be
      sent just to the older RBridge that the end station was connected
      to until cached address information at some remote RBridge times
      out, possibly for tens of seconds [RFC6325]."

In this scenario when an end-station moves TO a link where an
RBridge(RBx) with ESADI support is serving as AF for the vlan on which
the end-station is connected, this RBridge sends the end-station MACs
through ESADI pdu to other ESADI RBridges with a higher confidence and
the old routes in other ESADI RBridges are over-written.New routes(MAC
"A" is reachable via egress RBridge RBx) exist and frames destined to
MAC "A" are not black holed.

But what if this end-station moves FROM a link which has RBridge(RB1)
with ESADI support TO a link where RBridge(RB2) donot have ESADI
support. Is there any way RB1 can notify other ESADI implemented
RBridges in the campus to flush the old route(MAC "A" is reachable via
egress RB1) so that frames for MAC "A" are not send directly to RB1
and are rather treated as unknown unicast frame and send on a DTree?
Could RB1 send to ESADI Implemented RBridges that MAC "A" is no longer
reachable via itself by sending confidence as 0 for that MAC in its
ESADI pdus?

Please correct me if my understanding is wrong.

Also could we recommend ESADI implemented RBridges to become DRB and
serve more AF for vlans.

Editorial comments and typos:

In Abstract
ESADI (End System Address Distribution Information) should be replaced by
ESADI (End Station Address Distribution Information) as per RFC6325

In section 3. ESADI DRB State
8th line: "for which RB1 is holding an ESADI-LSP zero with an ESADI
Pararmeters" , typo for "Parameters"

In section 4. ESADI PDU processing
4th line:     "are only EASDI-LSP, EASDI-CSNP and EASDI-PSNP PDUs used
in ESADI."should be changed to
   "are only ESADI-LSP, ESADI-CSNP and ESADI-PSNP PDUs used in ESADI."

In section 4.1 Sending of ESASI PDUs

Change the typo in the header itself.

4th line:    "6(Innter.MacSA)" to '6(Inner.MacSA)"

5th line:     "starting with the Intradomain Routeing Protocol
Discriminator," Typo "Routeing" to "Routing"

2nd Para, 1st line: "Once an ESADI instance is operationally up, it
multicasts it self-
   originated LSP number zero on the virtual link to announce its ESADI
   parameters."   may be changed to
"Once an ESADI instance is operationally up, it multicasts/sends its self-
   originated LSP number zero on the virtual link to announce its ESADI
   parameters."

5th Para, 2nd line: Typo "EASDI"

In section 5. ESADI-LSP Contents
7th line typo "EASDAI-LSPs

In section 5.1 ESADI Parameter Data
4th line typo "occurrnce"

Thank you,
Regards,
Somnath

---

From: [email-masked]
Date: Sun, 22 Apr 2012 11:27:31 +0800

Thanks for the reviewing and comments.

Pls see the following in line.

>reachable via itself by sending confidence as 0 for that MAC in its

[hfw] If RB1 notify that the end-station moves from the link, RB1 will 
update

 and flood the LSP originated with nulling out the end-station address. 
When other ESADI 

 RBridge receives the updated LSP, they will forget the MAC "A" from its 
MAC table.

 In this way, ESADI protocol can fast update the MAC table of remote 
RBridges when the end station attached

 is unpluged or a new end station is pluged.

>4th line typo "occurrnce"

[hfw] Thanks for the correcting, we will correct it in the next version.

somnath chatterjee <[email-masked]> 
发件人:  [email-masked]
2012-04-21 01:17

收件人
[email-masked]
抄送

主题
[trill] [rbridge] draft-hu-trill-rbridge-esadi-04

Hi Authors,

In Abstract

Thank you,
Regards,
Somnath
_______________________________________________
trill mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/trill

---

From: somnath chatterjee <[email-masked]>
Date: Mon, 23 Apr 2012 12:27:03 +0530

Hi Fangwei,

Thank you for the explanation.

So, RB1 doesnot include the end-stations MAC in its LSP. What if RB1 has
opted not to send this end-station MAC in its ESADI-LSP earlier? The other
ESADI RBridges has no way to learn that this MAC has to be flushed(which
may be learned through other procedures except ESADI). It would be good if
ESADI RBridges could explicitly tell other RBridges to forget a MAC.

Regards,
Somnath

2012/4/22 <[email-masked]>

>  *somnath chatterjee <[email-masked]>*

---

From: [email-masked]
Date: Mon, 23 Apr 2012 16:14:12 +0800

Hi, chatterjee

By my understanding, If RB1 supports ESADI, it advertises all the 
end-station MAC attached to the remote RBridges.

The remote RBridge can do some policy forwarding based on the MAC address, 
but I think it is no need to opt to send the end-station MAC by the local 
RBridge.

Regards

2012-04-23 14:57

收件人
[email-masked]
抄送
[email-masked], [email-masked]
主题
Re: [trill] [rbridge] draft-hu-trill-rbridge-esadi-04

Hi Fangwei,

Regards,
Somnath

收件人
[email-masked] 
抄送

主题

Hi Authors,

In Abstract

Thank you,
Regards,
Somnath

---

From: somnath chatterjee <[email-masked]>
Date: Mon, 23 Apr 2012 14:10:01 +0530

Hi ,

In introduction of draft-hu-trill-rbridge-esadi-04
"  An RBridge that is announcing connectivity to VLAN-x (normally a
   VLAN-x appointed forwarder) MAY use the (ESADI) protocol to announce
   the end station address of some or all of its attached VLAN-x end
   nodes to other RBridges that are running ESADI for VLAN-x."

An ESADI supported RBridge MAY selectively send about end-station MACs
and MAY opt to not send all the end-station MACs.

I am only suggesting to send MAC in updated ESADI-LSP with confidence
zero(for every lost MAC), so that other ESADI RBridges could easily
recognize that this MAC needs to be deleted, rather than compare it
with previously stored information and then delete.

Thank you,
Regards,
Somnath

2012/4/23 <[email-masked]>
>
>
> Hi, chatterjee
>
> By my understanding, If RB1 supports ESADI, it advertises all the end-station MAC attached to the remote RBridges.
>
> The remote RBridge can do some policy forwarding based on the MAC address, but I think it is no need to opt to send the end-station MAC by the local RBridge.
>
> Regards
>
>
> So, RB1 doesnot include the end-stations MAC in its LSP. What if RB1 has opted not to send this end-station MAC in its ESADI-LSP earlier? The other ESADI RBridges has no way to learn that this MAC has to be flushed(which may be learned through other procedures except ESADI). It would be good if ESADI RBridges could explicitly tell other RBridges to forget a MAC.
>
> Regards,
> Somnath
>
> [hfw] If RB1 notify that the end-station moves from the link, RB1 will update
>
> and flood the LSP originated with nulling out the end-station address. When other ESADI
>
> RBridge receives the updated LSP, they will forget the MAC "A" from its MAC table.
>
> In this way, ESADI protocol can fast update the MAC table of remote RBridges when the end station attached
>

---

From: [email-masked]
Date: Mon, 23 Apr 2012 16:55:39 +0800

See in-line, pls.

Thanks,
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]
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""

2012-04-23 16:40

收件人
[email-masked]
抄送
[email-masked], [email-masked]
主题
Re: [trill] [rbridge] draft-hu-trill-rbridge-esadi-04

> with previously stored information and then delete.

Thanks for your good suggestion. I think it is feasible.

Thank you,
Regards,
Somnath

>
> The remote RBridge can do some policy forwarding based on the MAC 
address, but I think it is no need to opt to send the end-station MAC by 
the local RBridge.
update
When other ESADI
MAC table.

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 23 Apr 2012 21:39:31 +0000

I have read through the draft-hu-trill-rbridge-esadi-04 and support it.

Linda Dunbar

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 23 Apr 2012 19:32:51 -0400

Hi Somnath,

Generally speaking, on your questions about what happens if a end
station moves from being connected to an ESADI RBridge that is
advertising the end stations MAC address to a non-ESADI RBridge, where
both are Appointed Forwarders for the stations VLAN, what happens. If
the "from" RBridge notices, it removed that MAC address from its
ESADI-LSP. By the ESADI flooding, that updated LSP without the MAC
address will get to all other participating ESADI RBridges for that
VLAN.

If the "to" RBridge is not an ESADI RBridge, then, of course, you do
not get any benefit from ESADI for the connection to it.

There is little, if any benefit, from trying to play around with
dymanically set confidences in this case. If both the "from" and "to"
RBridges are ESADI RBridges and they both think MAC address M is
connected in VLAN V for which they are participating in ESADI, then
both with advertise this in their ESADI-LSP. An implementation could
keep track of when if gets LSP updates and try to figure out which was
more recent.

See below.

> with previously stored information and then delete.

It is stronger to just drop the MAC for your ESADI-LSP. Other EASDI
RBridges need to look at your update to figure out if/how to update
their FIB in any case.

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

---

From: somnath chatterjee <[email-masked]>
Date: Tue, 24 Apr 2012 14:28:11 +0530

Hi Donald,

Please consider a scenario where the "from" RBridge has ESADI(RB1),
the "to" RBridge is non-ESADI(RB2) and there is another ESADI
RBridge(RB3) which is neither "to" or "from" but in the campus. I was
concerned about the this RB3 which will receive ESADI LSP from RB1. If
the RB1 had previously chosen not to include the End-Station MAC in
its earlier ESADI-LSP, the RB3 has no way to know that the this MAC is
to be flushed when it receives the updated ESADI-LSP from RB1.
I assume that ESADI RBridges will compare previous ESADI-LSP and
latest ESADI-LSP to find the lost MACs. As ESADI RBridges MAY send
partial information about End-Stations connected to it, comparing
previous and latest ESADI-LSPs may not always give complete
information about lost MACs. So if there was a way to notify
explicitly about the lost MACs it would be easy for an ESADI RBridge
to conclude about the lost MACs, also comparing previous and current
ESADI-LSPs overhead will not exist.
Please correct me if my understanding is wrong.

Thank you,
Regards,
Somnath

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 24 Apr 2012 20:10:18 -0400

Hi Somnath,

> to be flushed when it receives the updated ESADI-LSP from RB1.

As a very general comment, TRILL provides many tools and does not
generally demand that they be used in some specify way. It was
important in designing TRILL that default operations, without various
options, be something reasonable. But if someone starts to implement
various optional feature or to configure priorities or whatever, it is
general up to them to figure out how to do this to get a good result.
Some things, like how the DRB should determine what, if any, other
RBridges on a multi-RBridge link should be appointed forwarders for
what VLANs were deliberately left out of scope because it seems
complicated, with lots of factors that could be taken into account,
and an area where different implementors could compete.

Your statement above about what might happen seem right, but so what?
Why did the network manager choose not to use ESADI to advertise the
MAC address involved? Is data plane address learning also enabled at
these RBridges?

Shouldn't it be obvious that if you have data plane learning enabled
(which is the default) and you don't use ESADI for MAC address M1,
then you get data plane / time-out driven behavior for M1? What else
would you expect?

> latest ESADI-LSP to find the lost MACs.

Well, at least logically, that's not the way I look at it. An RBridge
can have various MAC address learning information including manually
configured addresses, data plane learned addresses, and addresses in
its ESADI link state database. So, if any of this information changes,
then potentially it needs to update its MAC forwarding tables, using
the rules in RFC 6325 to reconcile conflicts between these different
types of information. There are various ways it can optimize this
update process including comparing old versus new information.

> As ESADI RBridges MAY send
> information about lost MACs.

I would guess that there would normally be some specific reason  for
leaving some MAC address out. For example, there are a few MAC
attachments that are more important to transmit securely or that are
more dynamic and it is important to update quickly, and for which the
data being sent/received is usually to other RBridges that implement
ESADI. So it makes sense to include those MACs. While there is another
set of MAC attachments for which security / rapid update is less
important and/or it is known that most of the other RBridges for which
data from/to such MACs is communicated don't implement ESADI so it is
pointless to communicate them in ESADI.

> So if there was a way to notify

But you would have the overhead of processing the new MAC unlearn
message, which might have to be sent to all RBridges attached to a
VLAN unless you carefully tracked every RBridge that might have
learned the MAC...

Adding some optional way to remotely delete one or more MAC addresses
is a reasonable idea but I don't think you would necessarily always
want to use it even if it was available. Sometimes the existing data
plane learning is fine...

Thanks,
Donald

---

From: somnath chatterjee <[email-masked]>
Date: Wed, 25 Apr 2012 16:39:59 +0530

Hi Donald,

Thank you for the explanation. I agree with you that it is a corner
case and might be a type
of misconfiguration. In such case it would be good to fall back to
aging out routes/fdbs normally.

Regards,
Somnath