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

[somnath chatterjee <[e-mail]>]

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


2012/4/24 Donald Eastlake <[e-mail]>:
> 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.
>
> 2012/4/23 somnath chatterjee <[e-mail]>:
>> 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.
>
> 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   [phone] (cell)
>  155 Beaver Street, Milford, MA 01757 USA
>  [e-mail]
>
>> Thank you,
>> Regards,
>> Somnath
>>
>> 2012/4/23 <[e-mail]>
>>>
>>>
>>> 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
>>>
>>>
>>> somnath chatterjee <[e-mail]>
>>>
>>> 2012-04-23 14:57
>>>
>>> 收件人
>>> [e-mail]
>>> 抄送
>>> [e-mail], [e-mail]
>>> 主题
>>> Re: [trill] [rbridge] draft-hu-trill-rbridge-esadi-04
>>>
>>>
>>>
>>>
>>>
>>> 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 <[e-mail]>
>>>
>>> Thanks for the reviewing and comments.
>>>
>>> Pls see the following in line.
>>>
>>> >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?
>>>
>>> [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.
>>>
>>>
>>>
>>> >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"
>>>
>>> [hfw] Thanks for the correcting, we will correct it in the next version.
>>>
>>>
>>> somnath chatterjee <[e-mail]>
>>> 发件人:  [e-mail]
>>>
>>> 2012-04-21 01:17
>>>
>>>
>>> 收件人
>>> [e-mail]
>>> 抄送
>>> 主题
>>> [trill] [rbridge] draft-hu-trill-rbridge-esadi-04
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> 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
>>> _______________________________________________
>>> trill mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/trill
>>>
>>>
>>>
>> _______________________________________________
>> trill mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/trill