From dmbond at us.ibm.com  Wed Aug  3 11:30:09 2011
From: dmbond at us.ibm.com (David M Bond)
Date: Wed, 3 Aug 2011 14:30:09 -0400
Subject: [rbridge] comments on draft-ietf-trill-rbridge-oam-00
In-Reply-To: <D408889639FC5E4FADB4E00A3E01FA8F07C4473B@SZXEML511-MBS.china.huawei.com>
References: <D408889639FC5E4FADB4E00A3E01FA8F07C4473B@SZXEML511-MBS.china.huawei.com>
Message-ID: <OF15377FFD.522CBB40-ON852578E1.005470BB-852578E1.0065A358@us.ibm.com>

Hi Yizhou,

Thanks for the detailed review and sorry for the slow response time.
Comments inline below prefaced with DB>:

Thanks,
David



From:	Liyizhou <liyizhou at huawei.com>
To:	"rbridge at postel.org" <rbridge at postel.org>
Cc:	"d3e3e3 at gmail.com" <d3e3e3 at gmail.com>, Erik Nordmark
            <nordmark at acm.org>, "Mmokon at mokon.net" <Mmokon at mokon.net>,
            "vishwas.manral at hp.com" <vishwas.manral at hp.com>
Date:	07/27/2011 12:24 PM
Subject:	[rbridge] comments on draft-ietf-trill-rbridge-oam-00
Sent by:	rbridge-bounces at postel.org



Hi folks,

Some reviewing comments on draft-ietf-trill-rbridge-oam-00,

1. pg6, table 1 gives the header format of oam frame *in response to*
another data frame. We also need a header format table for self-initiating
oam message like echo request. Table entry for "Inner.MacDA" says
"Inner.MacDA MAY be other values as specified in subsequent sections". But
there is no other value specified indeed.  I believe it was prepared for
ping request as inner.MacDa should be a unicast mac address of destination
RB?

DB> I've added that second table. In regards to the "specified in
subsequent sections" I was referring to "The Inner.VLAN, Inner.MacSA,
Inner.MacDA, Inner.Priority, and Ingress Nickname SHOULD default to the
values specified in Table 1.  Rbridges SHOULD be configurable to change
these values to assign the TRILL data frame to a flow." This however was
for self-generated messages. Thanks, this has been corrected.

2. pg8, 4.1.1, para 3, ..continue transmitting these echo requests,
incrementing the hop-count by one each time until... Looks a bit
ambiguitous to me. Shouldn't echo request be sent with hop-count
incremented by 1 only after hop-count error notification for previous echo
request being received?

DB> My intention here was to leave those specific details up to the
implementer. Each request has a sequence number which can be used for
reordering. If someone wants to sent frames in lock step that's fine but
they can also flood oam frames out quickly if their specific implementation
would work better with that method. The results will be the same
regardless.

3. pg9, para2, "The Inner.VLAN, Inner.MacSA, Inner.MacDA, Inner.Priority,
and Ingress Nickname SHOULD default to the values specified in Table 1.
RBridges SHOULD be configurable to change these values to assign the TRILL
data frame to a flow. " For unicast tracert with specified two RBridges, if
we assume each RB has single MAC address for oam, Inner.MacSA, Inner.MacDA
and Ingress Nickname are all fixed values. Inner.vlan may take different
value (table 1 indeed says it should be 1) but does not make much sense.
Priority may have different value but very restricted. Therefore it lacks a
lot of details on how to vary those values to get different flow? I suggest
to remove this and leave it for future tool such as ecmp oam. Or say
details could be find in future draft? If we want to keep it,  better to
give some explaination, e.g. explicitly say virtual internal end station
inside RB possily allows to be configured for different MACs?

DB> These are intended to be configuration options on say a command line
implementation (ttraceroute -ivlan 2 0x1234). Remember this OAM traffic
must mimic real data which would otherwise be coming from an end station.
Each Rbridge has a single mac address but it may be attached to multiple
end stations. So let's say I'm an operator and I seeing traffic destined to
00:11:22:33:44:55 failing while traffic to 00:11:22:33:44:66 is getting
through. Both of these devices are on a single L2 LAN and are therefore
connected to the same egress rbridge. Their flows however might be
transiting through the TRILL Campus through different ECMP paths and one of
those paths might be failing. If I don't have this ability to change say
the inner dst mac from the egress Rbridges dst mac to a connected end
station's dst mac then I lack the ability to locate the failure in the
campus. Does this sentence "e.g. The Inner.MacSA might be changed to the
MAC address of an end station connected to the ingress Rbridge to alter the
ECMP path frames coming from that end station follow through the TRILL
campus." appended to the end of that paragraph help explain the meaning
better? Additionally describing how flows are classified I feel is beyond
the scope of this document since the base draft does not specify that as
well and it is up to each vendor to determine their transit hash method
works.

4. pg9, para3, "incoming port field" ->"Incoming Port ID TLV", "include its
16-bit port ID from the port on which.." ->"include its 16-bit port ID from
the port on which...in Outgoing Port ID TLV in reply..." , "If the request
is a multi-destination frame, this field..." better moves to "4.1.1.1.
Multi-Destination Targets".

DB> Agreed

5. pg9, para5, lack of description on timeout and re-transmission of echo
request

DB> This is implementation specific and does not affect interoperability. I
would prefer to leave that up to the implementers specific needs. What does
everyone else think in regards to this? Should we specify a
re-transmission/timeout algorithm?

6. pg10, 4.1.1.2, "hop-count-exceeded message" -> "Hop Count Zero error
notification"

DB> Agreed

7. pg11, table 2, column "TRILL OAM Protocol", "Hop Count Error" -> "Hop
Count Zero error notification", "hop count" for error is "N/A", what is the
value for "N/A"? is it maximun 0x3F?

DB> Agreed, changes N/A to default (aka what the base protocol spec
specifies.

8. pg12, para4, lack of description on srcMac, destMac and hop count. It
refers to table 1, but original table 1 is only for responding oam message.

DB> Added table for self originated messages and updated reference. Thanks.

9. pg15, 4.2.1, If the request is a multi-destination frame, this field
MUST be set to all zeros.... However pg9 para3 says if it is for
multi-destination traceroute, next hop nickname should be "previous hop
nickname"? Should have some clarification. Here it talks about normal data
frame but not oam echo request frame.

DB> This is a mistake. They should both be the previous hop nickname.
Thanks, fixed.

10. pg18, 6.2, SPID is never used in error notification. Error notification
uses channel protocol number 5 while echo use 4. Can we make SPID field
here to be used for error type and make the subcode to be 16-bit long
instead?

DB> I have no objection to this. What do other people feel?

11. pg18, last line, typo, dup. Requests

DB> Fixed

12. pg19, para above 6.2.1, bullet TLVs. "For next hop errors"->"For Hop
Count Zero error"

DB> Fixed

13. pg19, 6.2.1, "The sub-code values fall into three categories...", there
are 4 error type as described in previous section bullet.  It is unclear
between permanent error and transient error.

DB> Let me get back to you on that one.

14. pg19, error code 2. I assume it is valid that the MAC Address is not a
multicast address and the M bit is one? Remember there are some discussion
regarding some corner cases of this. Not too sure. Moreover, can we call
this error M bit mismatch or something like it to make it more descriptive?

DB> Yes this is the intent. I have updated the name as suggested.

15. pg20, error 11. "exceeded its hop count.. " -> hop count reaches zero?

DB> Fixed

16. pg24, 7.1, what if next hop has multiple nicknames? list all, list one
with lowest value or list one with highest value? Duplicate description on
multi-destination traceroute and multi-destination hop-count errors.

DB> Added this sentence "If an Rbridge has multiple nicknames it SHOULD use
the numerically largest nickname in the Next Hop Nickname TLV."

Another general comment is we want to make sure traceroute tool sends out
echo request with same header contents each time until it reaches the final
destination though RB allows the different configurations for testing
flow-based path. It gurantees it follows the same path for incremental
trace in tracert.

DB> Added this sentence "An Rbridge must keep the TRILL header contents the
same for ever frame sent in a hop count traceroute."

Yizhou

 _______________________________________________
rbridge mailing list
rbridge at postel.org
http://mailman.postel.org/mailman/listinfo/rbridge



From liyizhou at huawei.com  Thu Aug  4 03:46:51 2011
From: liyizhou at huawei.com (Yizhou Li)
Date: Thu, 04 Aug 2011 18:46:51 +0800
Subject: [rbridge] comments on draft-ietf-trill-rbridge-oam-00
In-Reply-To: <OF15377FFD.522CBB40-ON852578E1.005470BB-852578E1.0065A358@us.ibm.com>
References: <D408889639FC5E4FADB4E00A3E01FA8F07C4473B@SZXEML511-MBS.china.huawei.com>
	<OF15377FFD.522CBB40-ON852578E1.005470BB-852578E1.0065A358@us.ibm.com>
Message-ID: <05b301cc5293$d1e2beb0$75a83c10$@com>

Hi David,

For item 3, I am ok with your example on varying Inner.MacSA. 
Non-trivial part for me indeed is Inner.MacDA.

draft-ietf-trill-rbridge-channel-02 section 2 says "They are identified as
RBridge Channel messages by their Inner.MacDA, which is the
All-Egress-RBridges multicast address, together with their Inner Ethertype,
which is the RBridge-Channel Ethertype." It appears Inner.MacDA must be a
fixed value.
 
Channel draft talks about "Native RBridge Channel Frames" which may use end
host's MAC as destination. So I assume we want to use this for testing
different data path by varying Inner.MacDA. My feeling is some detailed
description is needed to make it clearer and more useful for implementers.
E.g. Can we say "egress RB should handle such echo request/reply without
sending it to real destination mac"? If target(egress) RB is not connected
to destination end host, certain specific oam error should be generated? 

Yizhou

-----Original Message-----
From: David M Bond [mailto:dmbond at us.ibm.com] 
Sent: Thursday, August 04, 2011 2:30 AM
To: Liyizhou
Cc: d3e3e3 at gmail.com; Erik Nordmark; rbridge at postel.org;
vishwas.manral at hp.com
Subject: Re: [rbridge] comments on draft-ietf-trill-rbridge-oam-00

Hi Yizhou,

Thanks for the detailed review and sorry for the slow response time.
Comments inline below prefaced with DB>:

Thanks,
David



From:	Liyizhou <liyizhou at huawei.com>
To:	"rbridge at postel.org" <rbridge at postel.org>
Cc:	"d3e3e3 at gmail.com" <d3e3e3 at gmail.com>, Erik Nordmark
            <nordmark at acm.org>, "Mmokon at mokon.net" <Mmokon at mokon.net>,
            "vishwas.manral at hp.com" <vishwas.manral at hp.com>
Date:	07/27/2011 12:24 PM
Subject:	[rbridge] comments on draft-ietf-trill-rbridge-oam-00
Sent by:	rbridge-bounces at postel.org



Hi folks,

Some reviewing comments on draft-ietf-trill-rbridge-oam-00,

1. pg6, table 1 gives the header format of oam frame *in response to*
another data frame. We also need a header format table for self-initiating
oam message like echo request. Table entry for "Inner.MacDA" says
"Inner.MacDA MAY be other values as specified in subsequent sections". But
there is no other value specified indeed.  I believe it was prepared for
ping request as inner.MacDa should be a unicast mac address of destination
RB?

DB> I've added that second table. In regards to the "specified in
subsequent sections" I was referring to "The Inner.VLAN, Inner.MacSA,
Inner.MacDA, Inner.Priority, and Ingress Nickname SHOULD default to the
values specified in Table 1.  Rbridges SHOULD be configurable to change
these values to assign the TRILL data frame to a flow." This however was
for self-generated messages. Thanks, this has been corrected.

2. pg8, 4.1.1, para 3, ..continue transmitting these echo requests,
incrementing the hop-count by one each time until... Looks a bit
ambiguitous to me. Shouldn't echo request be sent with hop-count
incremented by 1 only after hop-count error notification for previous echo
request being received?

DB> My intention here was to leave those specific details up to the
implementer. Each request has a sequence number which can be used for
reordering. If someone wants to sent frames in lock step that's fine but
they can also flood oam frames out quickly if their specific implementation
would work better with that method. The results will be the same
regardless.

3. pg9, para2, "The Inner.VLAN, Inner.MacSA, Inner.MacDA, Inner.Priority,
and Ingress Nickname SHOULD default to the values specified in Table 1.
RBridges SHOULD be configurable to change these values to assign the TRILL
data frame to a flow. " For unicast tracert with specified two RBridges, if
we assume each RB has single MAC address for oam, Inner.MacSA, Inner.MacDA
and Ingress Nickname are all fixed values. Inner.vlan may take different
value (table 1 indeed says it should be 1) but does not make much sense.
Priority may have different value but very restricted. Therefore it lacks a
lot of details on how to vary those values to get different flow? I suggest
to remove this and leave it for future tool such as ecmp oam. Or say
details could be find in future draft? If we want to keep it,  better to
give some explaination, e.g. explicitly say virtual internal end station
inside RB possily allows to be configured for different MACs?

DB> These are intended to be configuration options on say a command line
implementation (ttraceroute -ivlan 2 0x1234). Remember this OAM traffic
must mimic real data which would otherwise be coming from an end station.
Each Rbridge has a single mac address but it may be attached to multiple
end stations. So let's say I'm an operator and I seeing traffic destined to
00:11:22:33:44:55 failing while traffic to 00:11:22:33:44:66 is getting
through. Both of these devices are on a single L2 LAN and are therefore
connected to the same egress rbridge. Their flows however might be
transiting through the TRILL Campus through different ECMP paths and one of
those paths might be failing. If I don't have this ability to change say
the inner dst mac from the egress Rbridges dst mac to a connected end
station's dst mac then I lack the ability to locate the failure in the
campus. Does this sentence "e.g. The Inner.MacSA might be changed to the
MAC address of an end station connected to the ingress Rbridge to alter the
ECMP path frames coming from that end station follow through the TRILL
campus." appended to the end of that paragraph help explain the meaning
better? Additionally describing how flows are classified I feel is beyond
the scope of this document since the base draft does not specify that as
well and it is up to each vendor to determine their transit hash method
works.

4. pg9, para3, "incoming port field" ->"Incoming Port ID TLV", "include its
16-bit port ID from the port on which.." ->"include its 16-bit port ID from
the port on which...in Outgoing Port ID TLV in reply..." , "If the request
is a multi-destination frame, this field..." better moves to "4.1.1.1.
Multi-Destination Targets".

DB> Agreed

5. pg9, para5, lack of description on timeout and re-transmission of echo
request

DB> This is implementation specific and does not affect interoperability. I
would prefer to leave that up to the implementers specific needs. What does
everyone else think in regards to this? Should we specify a
re-transmission/timeout algorithm?

6. pg10, 4.1.1.2, "hop-count-exceeded message" -> "Hop Count Zero error
notification"

DB> Agreed

7. pg11, table 2, column "TRILL OAM Protocol", "Hop Count Error" -> "Hop
Count Zero error notification", "hop count" for error is "N/A", what is the
value for "N/A"? is it maximun 0x3F?

DB> Agreed, changes N/A to default (aka what the base protocol spec
specifies.

8. pg12, para4, lack of description on srcMac, destMac and hop count. It
refers to table 1, but original table 1 is only for responding oam message.

DB> Added table for self originated messages and updated reference. Thanks.

9. pg15, 4.2.1, If the request is a multi-destination frame, this field
MUST be set to all zeros.... However pg9 para3 says if it is for
multi-destination traceroute, next hop nickname should be "previous hop
nickname"? Should have some clarification. Here it talks about normal data
frame but not oam echo request frame.

DB> This is a mistake. They should both be the previous hop nickname.
Thanks, fixed.

10. pg18, 6.2, SPID is never used in error notification. Error notification
uses channel protocol number 5 while echo use 4. Can we make SPID field
here to be used for error type and make the subcode to be 16-bit long
instead?

DB> I have no objection to this. What do other people feel?

11. pg18, last line, typo, dup. Requests

DB> Fixed

12. pg19, para above 6.2.1, bullet TLVs. "For next hop errors"->"For Hop
Count Zero error"

DB> Fixed

13. pg19, 6.2.1, "The sub-code values fall into three categories...", there
are 4 error type as described in previous section bullet.  It is unclear
between permanent error and transient error.

DB> Let me get back to you on that one.

14. pg19, error code 2. I assume it is valid that the MAC Address is not a
multicast address and the M bit is one? Remember there are some discussion
regarding some corner cases of this. Not too sure. Moreover, can we call
this error M bit mismatch or something like it to make it more descriptive?

DB> Yes this is the intent. I have updated the name as suggested.

15. pg20, error 11. "exceeded its hop count.. " -> hop count reaches zero?

DB> Fixed

16. pg24, 7.1, what if next hop has multiple nicknames? list all, list one
with lowest value or list one with highest value? Duplicate description on
multi-destination traceroute and multi-destination hop-count errors.

DB> Added this sentence "If an Rbridge has multiple nicknames it SHOULD use
the numerically largest nickname in the Next Hop Nickname TLV."

Another general comment is we want to make sure traceroute tool sends out
echo request with same header contents each time until it reaches the final
destination though RB allows the different configurations for testing
flow-based path. It gurantees it follows the same path for incremental
trace in tracert.

DB> Added this sentence "An Rbridge must keep the TRILL header contents the
same for ever frame sent in a hop count traceroute."

Yizhou

 _______________________________________________
rbridge mailing list
rbridge at postel.org
http://mailman.postel.org/mailman/listinfo/rbridge



From ginsberg at cisco.com  Fri Aug  5 12:23:50 2011
From: ginsberg at cisco.com (Les Ginsberg (ginsberg))
Date: Fri, 5 Aug 2011 12:23:50 -0700
Subject: [rbridge] Pseudo-node nickname
In-Reply-To: <CAFOuuo4dC0nmu2-4SzNut0u+wnmfX6hc08YOn14Twckxc1cg6Q@mail.gmail.com>
References: <CAFOuuo79zEpX26FxKin67BppkrJrZ5nnMRfOdJJ8tpUL-4w5SA@mail.gmail.com><OF7F57B841.FB504917-ON482578DB.003D40D1-482578DB.003E3D5F@zte.com.cn>
	<CAFOuuo4dC0nmu2-4SzNut0u+wnmfX6hc08YOn14Twckxc1cg6Q@mail.gmail.com>
Message-ID: <AE36820147909644AD2A7CA014B1FB520F064811@xmb-sjc-222.amer.cisco.com>

There is no need to purge LSPs owned by another RB.
 
RFC 4971 (Router Capabilities) states in Section 3:

" In order to prevent the use of stale capabilities, a system MUST NOT
   use a Capability TLV present in an LSP of a system that is not
   currently reachable via Level-x paths, where "x" is the level (1 or
   2) in which the sending system advertised the TLV.  "

When DRB changes occur neighbor advertisements to the old DRB will be removed from their non-pseudo-node LSPs by systems on the given LAN and advertisements to the new pseudo-node will be added. Similarly, the new DRB will flood a new pseudo-node LSP with reachability to the neighbors on the LAN. So two-way connectivity check to the old DRB will fail and the above logic will prevent you from using stale/unreachable nickname information.

In the event the LAN is partitioned (as opposed to the old DRB simply failing) again new LSPs (both pseudo-node and non-pseudo-node) will be flooded by the nodes on the respective segments and the partitioned two way connectivity will be discovered. In that case normal tiebreaking rules regarding conflicting nicknames can be applied.

Modifying the update process by trying to preemptively purge LSPs owned by another RB is unnecessary, will do no good, and may well cause unnecessary and potentially pathological churn if the originating system is still alive.

   Les


> -----Original Message-----
> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
> Behalf Of Radia Perlman
> Sent: Thursday, July 28, 2011 6:59 AM
> To: zhai.hongjun at zte.com.cn
> Cc: rbridge at postel.org; Erik Nordmark; rbridge-bounces at postel.org;
> hu.fangwei at zte.com.cn
> Subject: Re: [rbridge] Pseudo-node nickname
> 
> Here's an alternative to purging R1's LSP.
> 
> Background:  R1 was DRB.  R2 is the new DRB since R2 no longer receives
> R1's Hellos.
> R1's LSP will take an unacceptably long time to time out naturally if
> R1 is indeed dead.
> 
> Note:  If R2's pseudonode has higher priority for the pseudonode
> nickname than R1, then
> if R2 just usurps the nickname, then R2 does not need to purge R1's
> LSPs.
> 
> Also, I believe that it will be way more likely that R1 died than that
> the link partitioned, and
> even if the link partitioned, either the endnodes attached to R1's
> partition, or the endnodes
> attached to R2's partition will have service problems (because remote
> RBridges will have the
> wrong nickname for them).
> 
> So, an alternative to purging R1's LSP is for R2 to usurp the nickname
> by using a higher
> priority than R1.  If R1 is dead, then soon nobody will be able to
> reach that nickname via R1
> because all of R1's neighbors will declare the link to R1 down.  So it
> won't be confusing to
> have R1's unexpired LSP still claiming the nickname if R1 is down.  If
> R1 is still alive, and
> the link partitioned, then R1 loses the nickname for the pseudonode and
> has to choose
> another one.
> 
> I don't quite remember how long LSPs hang around when a node goes down.
> If a node is
> no longer reachable via the LSP database (because the node is down or
> the network is
> partitioned) is there anything that purges the LSP, or does it have to
> wait an hour or so
> before it goes away?  If the latter (it hangs around for an hour or
> so), then I could imagine
> worrying about having R2 and R1 keep increasing the priority and trying
> to take the
> pseudonode nickname back.  So there would have to be rules such as only
> increasing the
> priority once, and going back to the old priority once the dead DRB's
> LSP expires.
> 
> Though it's possible that it should be legal for R2 to purge R1's LSP
> provided that R1 is not
> reachable through the LSP database.  (R2 should not purge R1's LSP if
> the link had
> partitioned...only if R1 really is dead).
> 
> Radia
> 
> 
> 
> 2011/7/28 zhai.hongjun at zte.com.cn
> 
> 
> 
> 	>> 2011/7/27 <hu.fangwei at zte.com.cn>
> 	>> The point is that there maybe two cases that R2 loses
> conncetitvty to R1: one is R1 is died, and the other is the link
> 	>> partitioning.
> 	>> If the link is partitioned , R2 Must not purge R1's LSP.
> 
> 	> The problem is, it's hard for R2 to know that R1 is still
> alive, but the link partitioned (that was Erik's
> 	> original point). In either case (R1 is dead, or the link
> partitioned), R2 will stop hearing Hellos from R1,
> 	> but R1's LSP will not have timed out. So the possibilities are
> 
> 
> 	...
> 
> 	> c) if R2 has higher nickname priority than R1, then R2 doesn't
> need to purge R1's LSP. R2 can just start
> 	> using the pseudonode nickname, and if the link is partitioned,
> R1 will have to acquire a new nickname for
> 	> it's half of the link. (I think this case is safe and
> reasonable)
> 
> 
> 	Yes, it is reasonable and feasible.
> 
> 	But I think a purging mechanism by prematuring the stale DRB's
> psedo-nickname is required when the old DRB is not in the new DRB's
> neighbor list.
> 
> 	Assumed that there are 4 hosts(H1,H2,H3 and H4) and 4
> RBridges(RB1, RB2, RB3 and RB4, RB1 is DRB) on the initial link E1,
> which pseudo-nickname is PseNick1. A remote RBridge Rn has learned that
> the egress to H1,H2,H3 and H4 is PseNick1,and the RBn's shortest path
> to PseNick1 is through RB1. Now if the link partitions into two halves,
> RB1,RB2 and H1,H2 on the left half, the others on the right. If not
> purge the RB1's psedo-nickname from TRILL campus, RBn cannot remove(or
> update) the entries of H1,..H4 in it's forwarding table(until receiving
> traffic from H1,..,H4), even if one half link selects another psedo-
> nicknamee (for examble the right half). Then the traffic to H3 or H4 is
> discarded at the floor hop. However, if the RB1's psedo-nickname is
> purged from TRILL, RBn can remove the associated entries from
> forwarding table, and sends the frames destined to H3 or H4 as unkown
> unicast frames, which confirms these frames reach H3 or H4.
> 
> 	After introducing such a purging mechanism, the processing of
> pseudo-nickname for DRB change(including link partition) is as
> following:
> 
> 	From neighbor's Hellos or the pseu-nickname stored locally, the
> new DRB can know the pseudo-nickname used before on this link. With
> this pseudo-nickname as key, it can look up the associated pseudo LSP
> from its LSDB. If found, the new DRB purges this LSP from the TRILL
> campus if the older DRB is not in the new DRB's neighbor list. After
> that, or if not found, the new DRB contends for this nickname by common
> LSP. If successfully obtains this nickname, it can annouce this
> nickname in its pseudo LSPs and using it in data plane. Otherwise, it
> MUST contend for another nickname as pseudo nickname. Before obtaining
> a pseudo-nickname sucessfully, DRB MUST not use pseudo-nickname in
> ingressing frames into TRILL campus.
> 
> 	In brief, the key words are "Purging older DRB's pseudo LSP"
> firstly, "Contending for the pseudo-nickname" secondly, "Announcing the
> obtained pseudo-nickname in pseudo LSP", and "Using this pseudo-
> nickname in data plane" finally.
> 
> 
> 
> 
> 	Thanks,
> 	Zhai Hongjun
> 	"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
> """""
> 	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 <tel:%2B86-25-52877345>
> 	Email: zhai.hongjun at zte.com.cn
> 	"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
> """"""
> 
> 
> 
> 
> 
> Radia Perlman <radiaperlman at gmail.com>
> 
> 发件人:  rbridge-bounces at postel.org
> 
> 2011-07-27 23:13
> 收件人
> hu.fangwei at zte.com.cn
> 抄送
> rbridge at postel.org, zhai.hongjun at zte.com.cn, Erik Nordmark
> <nordmark at acm.org>
> 主题
> Re: [rbridge] Pseudo-node nickname
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 	2011/7/27 <hu.fangwei at zte.com.cn <mailto:hu.fangwei at zte.com.cn> >
> 
> 	The point is that there maybe two cases  that R2 loses
> conncetitvty to R1: one is R1 is died, and the other is  the link
> partitioning.
> 
> 	If the link is partitioned , R2 Must not purge R1's LSP.
> 
> 	The problem is, it's hard for R2 to know that R1 is still alive,
> but the link partitioned (that was Erik's original point).  In either
> case (R1 is dead, or the link partitioned), R2 will stop hearing Hellos
> from R1, but R1's LSP will not have timed out.  So the possibilities
> are
> 
> 	a) wait "awhile", upon taking over as DRB, before getting a
> nickname for the pseudonode.  Note that if R1's LSP hasn't expired, and
> R1's priority is higher, R2 cannot legally use the nickname for the
> pseudonode.
> 	b) if after "awhile" there is no path through current LSPs, to
> R1's LSP, then purge *that* LSP of R1's.  (i.e., only do it once)
> 	c) if R2 has higher nickname priority than R1, then R2 doesn't
> need to purge R1's LSP.  R2 can just start using the pseudonode
> nickname, and if the link is partitioned, R1 will have to acquire a new
> nickname for it's half of the link.  (I think this case is safe and
> reasonable).
> 	d) don't bother reusing nicknames if the DRB changes, but note
> that AF changes will still be helped by this (the simplest case).
> 
> 	Perhaps there are other possibilities.  But I think it's safe to
> do c).  The disadvantage of not doing b) is that if R1's pseudonode has
> higher priority than R2's pseudonode then if R1 dies (more likely than
> the link partitioning probably), R2 doesn't get to reuse the nickname.
> But I'm sure people will worry about allowing R2 to purge someone
> else's LSP, so only doing c)  (allowing R2 to take over the nickname if
> R2's pseudonode has higher nickname priority), is reasonable.
> 
> 	Radia
> 
> 
> 
> 	 _______________________________________________
> 	rbridge mailing list
> 	rbridge at postel.org
> 	http://mailman.postel.org/mailman/listinfo/rbridge
> 
> 
> 
> 	--------------------------------------------------------
> 	ZTE Information Security Notice: The information contained in
> this mail is solely property of the sender's organization. This mail
> communication is confidential. Recipients named above are obligated to
> maintain secrecy and are not permitted to disclose the contents of this
> communication to others.
> 	This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they
> are addressed. If you have received this email in error please notify
> the originator of the message. Any views expressed in this message are
> those of the individual sender.
> 	This message has been scanned for viruses and Spam by ZTE Anti-
> Spam system.
> 



From dmbond at us.ibm.com  Mon Aug  8 12:28:14 2011
From: dmbond at us.ibm.com (David M Bond)
Date: Mon, 8 Aug 2011 15:28:14 -0400
Subject: [rbridge] comments on draft-ietf-trill-rbridge-oam-00
In-Reply-To: <05b301cc5293$d1e2beb0$75a83c10$@com>
References: <D408889639FC5E4FADB4E00A3E01FA8F07C4473B@SZXEML511-MBS.china.huawei.com>
	<OF15377FFD.522CBB40-ON852578E1.005470BB-852578E1.0065A358@us.ibm.com>
	<05b301cc5293$d1e2beb0$75a83c10$@com>
Message-ID: <OF866A7B89.08EB955A-ON852578E6.005C935D-852578E6.006AF584@us.ibm.com>

Hi Yizhou,

My main concern here is that the data must be able to look like real data
at least up to the end of the inner ethernet header otherwise the OAM will
be useless if we can't get the data to follow a path data is failing on.

So I guess there are two questions here:
1) Do we allow the Inner.MacDA to be anything other than the reserved
address? I think we have to otherwise we face the problem mentioned above.
If we do allow this should the current channel draft be updated to allow
for this exception?
2) If we allow #1 then an egress Rbridge would have to listen for the OAM
Inner.ethertype and not de-encapsulate that data: rather it would need to
send the frame to the OAM processing. Is this what you are asking for more
explanation on below?

Also, I like your idea about using the native rbridge channel frames. If I
understand it correctly essentially this would be involving end stations in
the oam protocol, the only problem is it would only work for ping whereas
traceroute requires the hop count to be varied and the end stations can
only send "untamed" native frames.

Thanks,
David







From:	Yizhou Li <liyizhou at huawei.com>
To:	David M Bond/Bedford/IBM at IBMUS
Cc:	d3e3e3 at gmail.com, "'Erik Nordmark'" <nordmark at acm.org>,
            rbridge at postel.org, vishwas.manral at hp.com
Date:	08/04/2011 06:47 AM
Subject:	RE: [rbridge] comments on draft-ietf-trill-rbridge-oam-00



Hi David,

For item 3, I am ok with your example on varying Inner.MacSA.
Non-trivial part for me indeed is Inner.MacDA.

draft-ietf-trill-rbridge-channel-02 section 2 says "They are identified as
RBridge Channel messages by their Inner.MacDA, which is the
All-Egress-RBridges multicast address, together with their Inner Ethertype,
which is the RBridge-Channel Ethertype." It appears Inner.MacDA must be a
fixed value.

Channel draft talks about "Native RBridge Channel Frames" which may use end
host's MAC as destination. So I assume we want to use this for testing
different data path by varying Inner.MacDA. My feeling is some detailed
description is needed to make it clearer and more useful for implementers.
E.g. Can we say "egress RB should handle such echo request/reply without
sending it to real destination mac"? If target(egress) RB is not connected
to destination end host, certain specific oam error should be generated?

Yizhou

-----Original Message-----
From: David M Bond [mailto:dmbond at us.ibm.com]
Sent: Thursday, August 04, 2011 2:30 AM
To: Liyizhou
Cc: d3e3e3 at gmail.com; Erik Nordmark; rbridge at postel.org;
vishwas.manral at hp.com
Subject: Re: [rbridge] comments on draft-ietf-trill-rbridge-oam-00

Hi Yizhou,

Thanks for the detailed review and sorry for the slow response time.
Comments inline below prefaced with DB>:

Thanks,
David



From:		 Liyizhou <liyizhou at huawei.com>
To:		 "rbridge at postel.org" <rbridge at postel.org>
Cc:		 "d3e3e3 at gmail.com" <d3e3e3 at gmail.com>, Erik Nordmark
            <nordmark at acm.org>, "Mmokon at mokon.net" <Mmokon at mokon.net>,
            "vishwas.manral at hp.com" <vishwas.manral at hp.com>
Date:		 07/27/2011 12:24 PM
Subject:		 [rbridge] comments on draft-ietf-trill-rbridge-oam-00
Sent by:		 rbridge-bounces at postel.org



Hi folks,

Some reviewing comments on draft-ietf-trill-rbridge-oam-00,

1. pg6, table 1 gives the header format of oam frame *in response to*
another data frame. We also need a header format table for self-initiating
oam message like echo request. Table entry for "Inner.MacDA" says
"Inner.MacDA MAY be other values as specified in subsequent sections". But
there is no other value specified indeed.  I believe it was prepared for
ping request as inner.MacDa should be a unicast mac address of destination
RB?

DB> I've added that second table. In regards to the "specified in
subsequent sections" I was referring to "The Inner.VLAN, Inner.MacSA,
Inner.MacDA, Inner.Priority, and Ingress Nickname SHOULD default to the
values specified in Table 1.  Rbridges SHOULD be configurable to change
these values to assign the TRILL data frame to a flow." This however was
for self-generated messages. Thanks, this has been corrected.

2. pg8, 4.1.1, para 3, ..continue transmitting these echo requests,
incrementing the hop-count by one each time until... Looks a bit
ambiguitous to me. Shouldn't echo request be sent with hop-count
incremented by 1 only after hop-count error notification for previous echo
request being received?

DB> My intention here was to leave those specific details up to the
implementer. Each request has a sequence number which can be used for
reordering. If someone wants to sent frames in lock step that's fine but
they can also flood oam frames out quickly if their specific implementation
would work better with that method. The results will be the same
regardless.

3. pg9, para2, "The Inner.VLAN, Inner.MacSA, Inner.MacDA, Inner.Priority,
and Ingress Nickname SHOULD default to the values specified in Table 1.
RBridges SHOULD be configurable to change these values to assign the TRILL
data frame to a flow. " For unicast tracert with specified two RBridges, if
we assume each RB has single MAC address for oam, Inner.MacSA, Inner.MacDA
and Ingress Nickname are all fixed values. Inner.vlan may take different
value (table 1 indeed says it should be 1) but does not make much sense.
Priority may have different value but very restricted. Therefore it lacks a
lot of details on how to vary those values to get different flow? I suggest
to remove this and leave it for future tool such as ecmp oam. Or say
details could be find in future draft? If we want to keep it,  better to
give some explaination, e.g. explicitly say virtual internal end station
inside RB possily allows to be configured for different MACs?

DB> These are intended to be configuration options on say a command line
implementation (ttraceroute -ivlan 2 0x1234). Remember this OAM traffic
must mimic real data which would otherwise be coming from an end station.
Each Rbridge has a single mac address but it may be attached to multiple
end stations. So let's say I'm an operator and I seeing traffic destined to
00:11:22:33:44:55 failing while traffic to 00:11:22:33:44:66 is getting
through. Both of these devices are on a single L2 LAN and are therefore
connected to the same egress rbridge. Their flows however might be
transiting through the TRILL Campus through different ECMP paths and one of
those paths might be failing. If I don't have this ability to change say
the inner dst mac from the egress Rbridges dst mac to a connected end
station's dst mac then I lack the ability to locate the failure in the
campus. Does this sentence "e.g. The Inner.MacSA might be changed to the
MAC address of an end station connected to the ingress Rbridge to alter the
ECMP path frames coming from that end station follow through the TRILL
campus." appended to the end of that paragraph help explain the meaning
better? Additionally describing how flows are classified I feel is beyond
the scope of this document since the base draft does not specify that as
well and it is up to each vendor to determine their transit hash method
works.

4. pg9, para3, "incoming port field" ->"Incoming Port ID TLV", "include its
16-bit port ID from the port on which.." ->"include its 16-bit port ID from
the port on which...in Outgoing Port ID TLV in reply..." , "If the request
is a multi-destination frame, this field..." better moves to "4.1.1.1.
Multi-Destination Targets".

DB> Agreed

5. pg9, para5, lack of description on timeout and re-transmission of echo
request

DB> This is implementation specific and does not affect interoperability. I
would prefer to leave that up to the implementers specific needs. What does
everyone else think in regards to this? Should we specify a
re-transmission/timeout algorithm?

6. pg10, 4.1.1.2, "hop-count-exceeded message" -> "Hop Count Zero error
notification"

DB> Agreed

7. pg11, table 2, column "TRILL OAM Protocol", "Hop Count Error" -> "Hop
Count Zero error notification", "hop count" for error is "N/A", what is the
value for "N/A"? is it maximun 0x3F?

DB> Agreed, changes N/A to default (aka what the base protocol spec
specifies.

8. pg12, para4, lack of description on srcMac, destMac and hop count. It
refers to table 1, but original table 1 is only for responding oam message.

DB> Added table for self originated messages and updated reference. Thanks.

9. pg15, 4.2.1, If the request is a multi-destination frame, this field
MUST be set to all zeros.... However pg9 para3 says if it is for
multi-destination traceroute, next hop nickname should be "previous hop
nickname"? Should have some clarification. Here it talks about normal data
frame but not oam echo request frame.

DB> This is a mistake. They should both be the previous hop nickname.
Thanks, fixed.

10. pg18, 6.2, SPID is never used in error notification. Error notification
uses channel protocol number 5 while echo use 4. Can we make SPID field
here to be used for error type and make the subcode to be 16-bit long
instead?

DB> I have no objection to this. What do other people feel?

11. pg18, last line, typo, dup. Requests

DB> Fixed

12. pg19, para above 6.2.1, bullet TLVs. "For next hop errors"->"For Hop
Count Zero error"

DB> Fixed

13. pg19, 6.2.1, "The sub-code values fall into three categories...", there
are 4 error type as described in previous section bullet.  It is unclear
between permanent error and transient error.

DB> Let me get back to you on that one.

14. pg19, error code 2. I assume it is valid that the MAC Address is not a
multicast address and the M bit is one? Remember there are some discussion
regarding some corner cases of this. Not too sure. Moreover, can we call
this error M bit mismatch or something like it to make it more descriptive?

DB> Yes this is the intent. I have updated the name as suggested.

15. pg20, error 11. "exceeded its hop count.. " -> hop count reaches zero?

DB> Fixed

16. pg24, 7.1, what if next hop has multiple nicknames? list all, list one
with lowest value or list one with highest value? Duplicate description on
multi-destination traceroute and multi-destination hop-count errors.

DB> Added this sentence "If an Rbridge has multiple nicknames it SHOULD use
the numerically largest nickname in the Next Hop Nickname TLV."

Another general comment is we want to make sure traceroute tool sends out
echo request with same header contents each time until it reaches the final
destination though RB allows the different configurations for testing
flow-based path. It gurantees it follows the same path for incremental
trace in tracert.

DB> Added this sentence "An Rbridge must keep the TRILL header contents the
same for ever frame sent in a hop count traceroute."

Yizhou

 _______________________________________________
rbridge mailing list
rbridge at postel.org
http://mailman.postel.org/mailman/listinfo/rbridge





From liyizhou at huawei.com  Tue Aug  9 02:30:21 2011
From: liyizhou at huawei.com (Yizhou Li)
Date: Tue, 09 Aug 2011 17:30:21 +0800
Subject: [rbridge] comments on draft-ietf-trill-rbridge-oam-00
In-Reply-To: <OF866A7B89.08EB955A-ON852578E6.005C935D-852578E6.006AF584@us.ibm.com>
References: <D408889639FC5E4FADB4E00A3E01FA8F07C4473B@SZXEML511-MBS.china.huawei.com>
	<OF15377FFD.522CBB40-ON852578E1.005470BB-852578E1.0065A358@us.ibm.com>
	<05b301cc5293$d1e2beb0$75a83c10$@com>
	<OF866A7B89.08EB955A-ON852578E6.005C935D-852578E6.006AF584@us.ibm.com>
Message-ID: <007801cc5676$f5c3a0b0$e14ae210$@com>

Hi David,
Please see [yz]

-----Original Message-----
From: David M Bond [mailto:dmbond at us.ibm.com] 
Sent: Tuesday, August 09, 2011 3:28 AM
To: Yizhou Li
Cc: d3e3e3 at gmail.com; 'Erik Nordmark'; rbridge at postel.org;
vishwas.manral at hp.com
Subject: RE: [rbridge] comments on draft-ietf-trill-rbridge-oam-00

Hi Yizhou,

My main concern here is that the data must be able to look like real data
at least up to the end of the inner ethernet header otherwise the OAM will
be useless if we can't get the data to follow a path data is failing on.

So I guess there are two questions here:
1) Do we allow the Inner.MacDA to be anything other than the reserved
address? I think we have to otherwise we face the problem mentioned above.
If we do allow this should the current channel draft be updated to allow
for this exception?
2) If we allow #1 then an egress Rbridge would have to listen for the OAM
Inner.ethertype and not de-encapsulate that data: rather it would need to
send the frame to the OAM processing. Is this what you are asking for more
explanation on below?

[yz]Yes. I do not have a strong opinion if we should allow Inner.MacDA to be
arbitrary MAC for non-native oam frame. Checking on a reserved destination
multicast mac may be an easier way to identify the oam frame. Using
ethertype only for identifying oam frame seems also workable for me.
Otherwise any better choice? Using native frame does have the problem you
mentioned below.  

Also, I like your idea about using the native rbridge channel frames. If I
understand it correctly essentially this would be involving end stations in
the oam protocol, the only problem is it would only work for ping whereas
traceroute requires the hop count to be varied and the end stations can
only send "untamed" native frames.

Thanks,
David







From:	Yizhou Li <liyizhou at huawei.com>
To:	David M Bond/Bedford/IBM at IBMUS
Cc:	d3e3e3 at gmail.com, "'Erik Nordmark'" <nordmark at acm.org>,
            rbridge at postel.org, vishwas.manral at hp.com
Date:	08/04/2011 06:47 AM
Subject:	RE: [rbridge] comments on draft-ietf-trill-rbridge-oam-00



Hi David,

For item 3, I am ok with your example on varying Inner.MacSA.
Non-trivial part for me indeed is Inner.MacDA.

draft-ietf-trill-rbridge-channel-02 section 2 says "They are identified as
RBridge Channel messages by their Inner.MacDA, which is the
All-Egress-RBridges multicast address, together with their Inner Ethertype,
which is the RBridge-Channel Ethertype." It appears Inner.MacDA must be a
fixed value.

Channel draft talks about "Native RBridge Channel Frames" which may use end
host's MAC as destination. So I assume we want to use this for testing
different data path by varying Inner.MacDA. My feeling is some detailed
description is needed to make it clearer and more useful for implementers.
E.g. Can we say "egress RB should handle such echo request/reply without
sending it to real destination mac"? If target(egress) RB is not connected
to destination end host, certain specific oam error should be generated?

Yizhou

-----Original Message-----
From: David M Bond [mailto:dmbond at us.ibm.com]
Sent: Thursday, August 04, 2011 2:30 AM
To: Liyizhou
Cc: d3e3e3 at gmail.com; Erik Nordmark; rbridge at postel.org;
vishwas.manral at hp.com
Subject: Re: [rbridge] comments on draft-ietf-trill-rbridge-oam-00

Hi Yizhou,

Thanks for the detailed review and sorry for the slow response time.
Comments inline below prefaced with DB>:

Thanks,
David



From:		 Liyizhou <liyizhou at huawei.com>
To:		 "rbridge at postel.org" <rbridge at postel.org>
Cc:		 "d3e3e3 at gmail.com" <d3e3e3 at gmail.com>, Erik Nordmark
            <nordmark at acm.org>, "Mmokon at mokon.net" <Mmokon at mokon.net>,
            "vishwas.manral at hp.com" <vishwas.manral at hp.com>
Date:		 07/27/2011 12:24 PM
Subject:		 [rbridge] comments on
draft-ietf-trill-rbridge-oam-00
Sent by:		 rbridge-bounces at postel.org



Hi folks,

Some reviewing comments on draft-ietf-trill-rbridge-oam-00,

1. pg6, table 1 gives the header format of oam frame *in response to*
another data frame. We also need a header format table for self-initiating
oam message like echo request. Table entry for "Inner.MacDA" says
"Inner.MacDA MAY be other values as specified in subsequent sections". But
there is no other value specified indeed.  I believe it was prepared for
ping request as inner.MacDa should be a unicast mac address of destination
RB?

DB> I've added that second table. In regards to the "specified in
subsequent sections" I was referring to "The Inner.VLAN, Inner.MacSA,
Inner.MacDA, Inner.Priority, and Ingress Nickname SHOULD default to the
values specified in Table 1.  Rbridges SHOULD be configurable to change
these values to assign the TRILL data frame to a flow." This however was
for self-generated messages. Thanks, this has been corrected.

2. pg8, 4.1.1, para 3, ..continue transmitting these echo requests,
incrementing the hop-count by one each time until... Looks a bit
ambiguitous to me. Shouldn't echo request be sent with hop-count
incremented by 1 only after hop-count error notification for previous echo
request being received?

DB> My intention here was to leave those specific details up to the
implementer. Each request has a sequence number which can be used for
reordering. If someone wants to sent frames in lock step that's fine but
they can also flood oam frames out quickly if their specific implementation
would work better with that method. The results will be the same
regardless.

3. pg9, para2, "The Inner.VLAN, Inner.MacSA, Inner.MacDA, Inner.Priority,
and Ingress Nickname SHOULD default to the values specified in Table 1.
RBridges SHOULD be configurable to change these values to assign the TRILL
data frame to a flow. " For unicast tracert with specified two RBridges, if
we assume each RB has single MAC address for oam, Inner.MacSA, Inner.MacDA
and Ingress Nickname are all fixed values. Inner.vlan may take different
value (table 1 indeed says it should be 1) but does not make much sense.
Priority may have different value but very restricted. Therefore it lacks a
lot of details on how to vary those values to get different flow? I suggest
to remove this and leave it for future tool such as ecmp oam. Or say
details could be find in future draft? If we want to keep it,  better to
give some explaination, e.g. explicitly say virtual internal end station
inside RB possily allows to be configured for different MACs?

DB> These are intended to be configuration options on say a command line
implementation (ttraceroute -ivlan 2 0x1234). Remember this OAM traffic
must mimic real data which would otherwise be coming from an end station.
Each Rbridge has a single mac address but it may be attached to multiple
end stations. So let's say I'm an operator and I seeing traffic destined to
00:11:22:33:44:55 failing while traffic to 00:11:22:33:44:66 is getting
through. Both of these devices are on a single L2 LAN and are therefore
connected to the same egress rbridge. Their flows however might be
transiting through the TRILL Campus through different ECMP paths and one of
those paths might be failing. If I don't have this ability to change say
the inner dst mac from the egress Rbridges dst mac to a connected end
station's dst mac then I lack the ability to locate the failure in the
campus. Does this sentence "e.g. The Inner.MacSA might be changed to the
MAC address of an end station connected to the ingress Rbridge to alter the
ECMP path frames coming from that end station follow through the TRILL
campus." appended to the end of that paragraph help explain the meaning
better? Additionally describing how flows are classified I feel is beyond
the scope of this document since the base draft does not specify that as
well and it is up to each vendor to determine their transit hash method
works.

4. pg9, para3, "incoming port field" ->"Incoming Port ID TLV", "include its
16-bit port ID from the port on which.." ->"include its 16-bit port ID from
the port on which...in Outgoing Port ID TLV in reply..." , "If the request
is a multi-destination frame, this field..." better moves to "4.1.1.1.
Multi-Destination Targets".

DB> Agreed

5. pg9, para5, lack of description on timeout and re-transmission of echo
request

DB> This is implementation specific and does not affect interoperability. I
would prefer to leave that up to the implementers specific needs. What does
everyone else think in regards to this? Should we specify a
re-transmission/timeout algorithm?

6. pg10, 4.1.1.2, "hop-count-exceeded message" -> "Hop Count Zero error
notification"

DB> Agreed

7. pg11, table 2, column "TRILL OAM Protocol", "Hop Count Error" -> "Hop
Count Zero error notification", "hop count" for error is "N/A", what is the
value for "N/A"? is it maximun 0x3F?

DB> Agreed, changes N/A to default (aka what the base protocol spec
specifies.

8. pg12, para4, lack of description on srcMac, destMac and hop count. It
refers to table 1, but original table 1 is only for responding oam message.

DB> Added table for self originated messages and updated reference. Thanks.

9. pg15, 4.2.1, If the request is a multi-destination frame, this field
MUST be set to all zeros.... However pg9 para3 says if it is for
multi-destination traceroute, next hop nickname should be "previous hop
nickname"? Should have some clarification. Here it talks about normal data
frame but not oam echo request frame.

DB> This is a mistake. They should both be the previous hop nickname.
Thanks, fixed.

10. pg18, 6.2, SPID is never used in error notification. Error notification
uses channel protocol number 5 while echo use 4. Can we make SPID field
here to be used for error type and make the subcode to be 16-bit long
instead?

DB> I have no objection to this. What do other people feel?

11. pg18, last line, typo, dup. Requests

DB> Fixed

12. pg19, para above 6.2.1, bullet TLVs. "For next hop errors"->"For Hop
Count Zero error"

DB> Fixed

13. pg19, 6.2.1, "The sub-code values fall into three categories...", there
are 4 error type as described in previous section bullet.  It is unclear
between permanent error and transient error.

DB> Let me get back to you on that one.

14. pg19, error code 2. I assume it is valid that the MAC Address is not a
multicast address and the M bit is one? Remember there are some discussion
regarding some corner cases of this. Not too sure. Moreover, can we call
this error M bit mismatch or something like it to make it more descriptive?

DB> Yes this is the intent. I have updated the name as suggested.

15. pg20, error 11. "exceeded its hop count.. " -> hop count reaches zero?

DB> Fixed

16. pg24, 7.1, what if next hop has multiple nicknames? list all, list one
with lowest value or list one with highest value? Duplicate description on
multi-destination traceroute and multi-destination hop-count errors.

DB> Added this sentence "If an Rbridge has multiple nicknames it SHOULD use
the numerically largest nickname in the Next Hop Nickname TLV."

Another general comment is we want to make sure traceroute tool sends out
echo request with same header contents each time until it reaches the final
destination though RB allows the different configurations for testing
flow-based path. It gurantees it follows the same path for incremental
trace in tracert.

DB> Added this sentence "An Rbridge must keep the TRILL header contents the
same for ever frame sent in a hop count traceroute."

Yizhou

 _______________________________________________
rbridge mailing list
rbridge at postel.org
http://mailman.postel.org/mailman/listinfo/rbridge






From ginsberg at cisco.com  Tue Aug  9 12:13:52 2011
From: ginsberg at cisco.com (Les Ginsberg (ginsberg))
Date: Tue, 9 Aug 2011 12:13:52 -0700
Subject: [rbridge] [Isis-wg] Fwd: I-D Action:
	draft-simpson-isis-ppp-unique-02.txt
In-Reply-To: <4E4143FA.1000307@gmail.com>
References: <4E4143FA.1000307@gmail.com>
Message-ID: <AE36820147909644AD2A7CA014B1FB520F107E99@xmb-sjc-222.amer.cisco.com>

William -

Thanx for (at last) actually including the isis-wg on this thread.

I have attached an excellent review that Mike Shand provided for your 00
draft - both as context and to insure that you have seen this (I did
forward this to you once before but am not sure you ever received it).

After reviewing the latest version (02) it seems to me that you have not
addressed any of the substance of Mike's remarks.

The most relevant changes in the 02 version consist of the revision to 

Section 3 Resolving Conflicts

As rewritten this section now says (in part):

<snip>
An implementation conforming with this specification MUST generate a
   replacement System Identifier using one of the techniques specified
   above, upon:

      (a) detecting a conflicting System Identifier in

      (a)(1) 1 IS-IS Hello from any neighbor, or

      (a)(2) 2 consecutive LSPs and/or SNPs from the same source;

      (b) failing to resolve participation in an area after

      (b)(1) incrementing its Sequence Number 3 or more times, and

      (b)(2) 10 seconds.
<end snip>

None of this addresses the concerns that Mike raised in his review -
specifically:

1)How to distinguish between benign cases (receiving your own LSP and/or
receiving a hellos from yourself if you have multiple ports on the same
LAN) from genuine doppelgangers

2)How to prevent the introduction of a new system with a duplicate
system ID from causing an existing system which has been using that
system ID from having to change its ID (which is highly undesirable)

3)In general avoiding gratuitous system-id changes

For this draft to go forward it would have to be demonstrated both that
the problem needs to be addressed and that the solution is not worse
than the original problem. The former is not borne out by field
experience to date (IMHO). In its present state the proposed solution
fails the second test as well.

If you are serious about moving this draft forward please address the
substance of the review points which have been made.

   Les


> -----Original Message-----
> From: isis-wg-bounces at ietf.org [mailto:isis-wg-bounces at ietf.org] On
> Behalf Of William Allen Simpson
> Sent: Tuesday, August 09, 2011 7:28 AM
> To: IETF PPP WG
> Cc: IETF TRILL WG; IETF ISIS WG
> Subject: [Isis-wg] Fwd: I-D Action: draft-simpson-isis-ppp-unique-
> 02.txt
> 
> https://tools.ietf.org/rfcdiff?url2=draft-simpson-isis-ppp-unique-
> 02.txt
> 
> It's been months since the last update, and I'd thought we'd long
since
> be in the edit queue.  Here's the few (mostly editorial) changes.
> 
> Although I've tried mightily to keep extraneous explanatory text to a
> minimum, some folks failed to actually read the entire document.  So,
> I've duplicated a little of the abstract and various section content
in
> the Introduction.  Hopefully, that will skirt problems with folks who
> think they become "expert" by skimming specifications -- without
> understanding, operating, or implementing.
> 
> One reader thought that Resolving Conflicts is optional.  Wrong!  The
> body text clearly said, "an implementation conforming with this
> specification MUST generate...."  Moreover, that kind of thing is
> obvious to all competent protocol designers and implementers.  In
> today's IETF, we have professional meeting goers instead.  So, I've
> added an explicit statement right at the *top* of the section for the
> skimmers.  It's REQUIRED!
> 
> Also, some readers had difficulty understanding a compound sentence.
> I've divided it into labeled clauses.  And here's the only substantive
> change: the test for conflicts has been tightened slightly, while the
> timing test has been loosened.
> 
> In previous drafts, Hellos, LSPs, and SNPs were all treated the same;
> finding a conflict in any of them led to action.  That's how things
are
> specified in ISIS itself (in excruciating detail).  But one reviewer
> thought we should require consecutive LSP/SNP conflicts.  That's more
> IETF-like: be liberal in what you receive....
> 
> However, I left the Hello conflict test as 1.  There's no reason to
> hope/wait for a change, it's a fast test, and in many cases clears up
> the problem before we ever exchange LSPs/SNPs.
> 
> In previous drafts, IS-IS Hellos were used in the timing test.  Hellos
> are sent periodically, so it's very conservative design.  But one
> reviewer thought we should use Sequence Number increments instead.  It
> may speed the conflict resolution slightly, and is a bit more
> conservative in what we send -- assuming the implementation stops
> sending as it waits the full 10 seconds for old/other LSPs to clear.
> (I'm not sure all/any implementations will actually wait, but that's a
> good experiment.)
> 
> A very confused reader thought this should handle more than 1 area,
> because my *TITLE* is more universal.  That's just silly.  Heck, it
> goes
> against the IS-IS principle (violated in practice) that each system is
> only in one area.  Added a note on inter-area conflicts.
> 
> Explicitly state that remote management is beyond the scope.
> 
> Any other nits?
> 
> 
> -------- Original Message --------
> Subject: I-D Action: draft-simpson-isis-ppp-unique-02.txt
> Date: Mon, 08 Aug 2011 09:21:50 -0700
> From: internet-drafts at ietf.org
> Reply-To: internet-drafts at ietf.org
> To: i-d-announce at ietf.org
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> 
> 	Title           : Generation of Unique IS-IS System Identifiers
> 	Author(s)       : William Allen Simpson
> 	Filename        : draft-simpson-isis-ppp-unique-02.txt
> 	Pages           : 9
> 	Date            : 2011-08-08
> 
>     The IS-IS routing protocol (Intermediate System to Intermediate
>     System, ISO 10589) requires unique System Identifiers at the link
>     layer.  A common practice has been to use an existing IEEE 802 MAC
>     link-layer interface identifier.  When no unique MAC is available,
>     this document specifies automatic generation of identifiers.  It
is
>     fully interoperable with systems that do not support this
> extension.
> 
>     Additionally, the extension automatically resolves conflicts
> between
>     System Identifiers.
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-simpson-isis-ppp-unique-
> 02.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> This Internet-Draft can be retrieved at:
>
ftp://ftp.ietf.org/internet-drafts/draft-simpson-isis-ppp-unique-02.txt
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce at ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> _______________________________________________
> Isis-wg mailing list
> Isis-wg at ietf.org
> https://www.ietf.org/mailman/listinfo/isis-wg
-------------- next part --------------
An embedded message was scrubbed...
From: "Mike Shand (mshand)" <mshand at cisco.com>
Subject: Re: [Isis-wg] draft-simpson-isis-ppp-unique-00
Date: Tue, 26 Apr 2011 04:17:11 -0700
Size: 7009
Url: http://mailman.postel.org/pipermail/rbridge/attachments/20110809/b90c2bdc/attachment.mht

From ginsberg at cisco.com  Tue Aug  9 18:23:29 2011
From: ginsberg at cisco.com (Les Ginsberg (ginsberg))
Date: Tue, 9 Aug 2011 18:23:29 -0700
Subject: [rbridge] [Isis-wg] Fwd: I-D Action:
	draft-simpson-isis-ppp-unique-02.txt
In-Reply-To: <4E41A666.4090200@gmail.com>
References: <4E4143FA.1000307@gmail.com><AE36820147909644AD2A7CA014B1FB520F107E99@xmb-sjc-222.amer.cisco.com>
	<4E41A666.4090200@gmail.com>
Message-ID: <AE36820147909644AD2A7CA014B1FB520F1080B3@xmb-sjc-222.amer.cisco.com>

William -

The majority of your reply consists of bashing - which is simply rude
and unprofessional and violates the rules of common courtesy to which
all of us are expected to abide. I won't respond further to any of those
remarks other than to say that this should stop immediately.

In regards to technical points...

> > 1)How to distinguish between benign cases (receiving your own LSP
> and/or
> > receiving a hellos from yourself if you have multiple ports on the
> same
> > LAN) from genuine doppelgangers
> >
> Indeed, I've repeatedly rejected suggestions from various folks to
> provide extraneous explanation.  This draft has only 5 or 6 sentences
> of
> protocol.  It's one of the simplest I've ever written.

The fact that it is simple does not mean it is correct. It is
commonplace for an IS to receive copies of its own LSPs during the
operation of the update process. In cases of router restart it is
commonplace for a router to receive copies of its LSPs from the previous
incarnation which may not be in any way identical to LSPs generated by
the new incarnation. Such cases are benign and are handled correctly by
the protocol today - but your proposal makes no distinction between
these cases and the case you are actually trying to solve. This is one
example of a "gratuitous system-id change" which could occur under your
proposed rules.

> 
> 
> > 2)How to prevent the introduction of a new system with a duplicate
> > system ID from causing an existing system which has been using that
> > system ID from having to change its ID (which is highly undesirable)
> >
> (Says you.)  The randomization of the delay jitter is explicitly for
> ensuring that neither new nor old has any advantage over the other.

I don't believe that a network operator wants the system-id of an IS
that has been operating in a stable network to be changed because of the
introduction of a new IS into the network that has (by accident or
maliciously) used the same system-id. So the premise that it is equally
desirable for the new or the old IS to change its system-id is flawed.
Yet another example of gratuitous change which could occur under your
proposed rules.

What is most relevant about gratuitous changes is that rather than
stabilizing the network they will do just the opposite - introducing
churn where none is desired or needed.

> IS-IS has explicit support for changing System Identifiers on the fly.
> See 7.3.6 Event driven LSP Generation:
> 
>     In addition to the periodic generation of LSPs, an Intermediate
>     system shall generate an LSP when an event occurs which would
cause
>     the information content to change. The following events may cause
>     such a change.
>     ...
>     -    a change in systemID

Here you confuse robustness with advocacy. There is nothing in the
specification which recommends changing the system-id of an IS once it
becomes operational. However, for correctness and completeness the
specification states that in the event that a system-id change occurs
LSP Generation SHALL be triggered.

There are really two parts to your draft.

1)A proposal for an alternate way of generating a unique identifier that
could be used as a system-id by an IS. This in fact requires no
standardization. Vendors could choose to adopt this if they believe it
is desirable. The IS-IS specification does not impose a system-id
assignment scheme - it simply requires that IDs be unique within an area
for L1 and within a domain for L2. The current common convention for
using MAC addesses is suggested in ISO 10589:2002 Annex B 1.1.3 (with
some substantive reasons) - but that section is explicitly labeled as
informative.

I have yet to hear from anyone (other than yourself) - either within the
context of discussing this draft or outside of it - who feels that we
have encountered deployment issues to date which would require the
proposal you make. If there are such advocates I would appreciate
hearing from them. Absent that this seems to be a solution in search of
a problem.

2)Protocol extensions which require dynamic changes to the system-id
used by a given IS under given conditions. This indeed would require a
standard - and it is this functionality to which most of the comments
have been focused. The concerns regarding filtering out false positives
need to be addressed before I would consider your proposal to be
deployable. Otherwise, as Mike states:

"accidentally invoking a changed system ID would seem to make the cure
worse than the disease..."

   Les



From ginsberg at cisco.com  Tue Aug  9 12:13:52 2011
From: ginsberg at cisco.com (Les Ginsberg (ginsberg))
Date: Tue, 9 Aug 2011 12:13:52 -0700
Subject: [rbridge] [Isis-wg] Fwd: I-D Action:
	draft-simpson-isis-ppp-unique-02.txt
In-Reply-To: <4E4143FA.1000307@gmail.com>
References: <4E4143FA.1000307@gmail.com>
Message-ID: <AE36820147909644AD2A7CA014B1FB520F107E99@xmb-sjc-222.amer.cisco.com>

William -

Thanx for (at last) actually including the isis-wg on this thread.

I have attached an excellent review that Mike Shand provided for your 00
draft - both as context and to insure that you have seen this (I did
forward this to you once before but am not sure you ever received it).

After reviewing the latest version (02) it seems to me that you have not
addressed any of the substance of Mike's remarks.

The most relevant changes in the 02 version consist of the revision to 

Section 3 Resolving Conflicts

As rewritten this section now says (in part):

<snip>
An implementation conforming with this specification MUST generate a
   replacement System Identifier using one of the techniques specified
   above, upon:

      (a) detecting a conflicting System Identifier in

      (a)(1) 1 IS-IS Hello from any neighbor, or

      (a)(2) 2 consecutive LSPs and/or SNPs from the same source;

      (b) failing to resolve participation in an area after

      (b)(1) incrementing its Sequence Number 3 or more times, and

      (b)(2) 10 seconds.
<end snip>

None of this addresses the concerns that Mike raised in his review -
specifically:

1)How to distinguish between benign cases (receiving your own LSP and/or
receiving a hellos from yourself if you have multiple ports on the same
LAN) from genuine doppelgangers

2)How to prevent the introduction of a new system with a duplicate
system ID from causing an existing system which has been using that
system ID from having to change its ID (which is highly undesirable)

3)In general avoiding gratuitous system-id changes

For this draft to go forward it would have to be demonstrated both that
the problem needs to be addressed and that the solution is not worse
than the original problem. The former is not borne out by field
experience to date (IMHO). In its present state the proposed solution
fails the second test as well.

If you are serious about moving this draft forward please address the
substance of the review points which have been made.

   Les


> -----Original Message-----
> From: isis-wg-bounces at ietf.org [mailto:isis-wg-bounces at ietf.org] On
> Behalf Of William Allen Simpson
> Sent: Tuesday, August 09, 2011 7:28 AM
> To: IETF PPP WG
> Cc: IETF TRILL WG; IETF ISIS WG
> Subject: [Isis-wg] Fwd: I-D Action: draft-simpson-isis-ppp-unique-
> 02.txt
> 
> https://tools.ietf.org/rfcdiff?url2=draft-simpson-isis-ppp-unique-
> 02.txt
> 
> It's been months since the last update, and I'd thought we'd long
since
> be in the edit queue.  Here's the few (mostly editorial) changes.
> 
> Although I've tried mightily to keep extraneous explanatory text to a
> minimum, some folks failed to actually read the entire document.  So,
> I've duplicated a little of the abstract and various section content
in
> the Introduction.  Hopefully, that will skirt problems with folks who
> think they become "expert" by skimming specifications -- without
> understanding, operating, or implementing.
> 
> One reader thought that Resolving Conflicts is optional.  Wrong!  The
> body text clearly said, "an implementation conforming with this
> specification MUST generate...."  Moreover, that kind of thing is
> obvious to all competent protocol designers and implementers.  In
> today's IETF, we have professional meeting goers instead.  So, I've
> added an explicit statement right at the *top* of the section for the
> skimmers.  It's REQUIRED!
> 
> Also, some readers had difficulty understanding a compound sentence.
> I've divided it into labeled clauses.  And here's the only substantive
> change: the test for conflicts has been tightened slightly, while the
> timing test has been loosened.
> 
> In previous drafts, Hellos, LSPs, and SNPs were all treated the same;
> finding a conflict in any of them led to action.  That's how things
are
> specified in ISIS itself (in excruciating detail).  But one reviewer
> thought we should require consecutive LSP/SNP conflicts.  That's more
> IETF-like: be liberal in what you receive....
> 
> However, I left the Hello conflict test as 1.  There's no reason to
> hope/wait for a change, it's a fast test, and in many cases clears up
> the problem before we ever exchange LSPs/SNPs.
> 
> In previous drafts, IS-IS Hellos were used in the timing test.  Hellos
> are sent periodically, so it's very conservative design.  But one
> reviewer thought we should use Sequence Number increments instead.  It
> may speed the conflict resolution slightly, and is a bit more
> conservative in what we send -- assuming the implementation stops
> sending as it waits the full 10 seconds for old/other LSPs to clear.
> (I'm not sure all/any implementations will actually wait, but that's a
> good experiment.)
> 
> A very confused reader thought this should handle more than 1 area,
> because my *TITLE* is more universal.  That's just silly.  Heck, it
> goes
> against the IS-IS principle (violated in practice) that each system is
> only in one area.  Added a note on inter-area conflicts.
> 
> Explicitly state that remote management is beyond the scope.
> 
> Any other nits?
> 
> 
> -------- Original Message --------
> Subject: I-D Action: draft-simpson-isis-ppp-unique-02.txt
> Date: Mon, 08 Aug 2011 09:21:50 -0700
> From: internet-drafts at ietf.org
> Reply-To: internet-drafts at ietf.org
> To: i-d-announce at ietf.org
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> 
> 	Title           : Generation of Unique IS-IS System Identifiers
> 	Author(s)       : William Allen Simpson
> 	Filename        : draft-simpson-isis-ppp-unique-02.txt
> 	Pages           : 9
> 	Date            : 2011-08-08
> 
>     The IS-IS routing protocol (Intermediate System to Intermediate
>     System, ISO 10589) requires unique System Identifiers at the link
>     layer.  A common practice has been to use an existing IEEE 802 MAC
>     link-layer interface identifier.  When no unique MAC is available,
>     this document specifies automatic generation of identifiers.  It
is
>     fully interoperable with systems that do not support this
> extension.
> 
>     Additionally, the extension automatically resolves conflicts
> between
>     System Identifiers.
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-simpson-isis-ppp-unique-
> 02.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> This Internet-Draft can be retrieved at:
>
ftp://ftp.ietf.org/internet-drafts/draft-simpson-isis-ppp-unique-02.txt
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce at ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> _______________________________________________
> Isis-wg mailing list
> Isis-wg at ietf.org
> https://www.ietf.org/mailman/listinfo/isis-wg
-------------- next part --------------
An embedded message was scrubbed...
From: "Mike Shand (mshand)" <mshand at cisco.com>
Subject: Re: [Isis-wg] draft-simpson-isis-ppp-unique-00
Date: Tue, 26 Apr 2011 04:17:11 -0700
Size: 7009
Url: http://mailman.postel.org/pipermail/rbridge/attachments/20110809/b90c2bdc/attachment-0003.mht
-------------- next part --------------
_______________________________________________
Isis-wg mailing list
Isis-wg at ietf.org
https://www.ietf.org/mailman/listinfo/isis-wg

From zhai.hongjun at zte.com.cn  Fri Aug 12 02:46:35 2011
From: zhai.hongjun at zte.com.cn (zhai.hongjun@zte.com.cn)
Date: Fri, 12 Aug 2011 17:46:35 +0800
Subject: [rbridge] Pseudo-node nickname
In-Reply-To: <AE36820147909644AD2A7CA014B1FB520F064811@xmb-sjc-222.amer.cisco.com>
Message-ID: <OFD334DF35.9270A4A1-ON482578EA.0035AF32-482578EA.0035C91D@zte.com.cn>

Very good comments.
 
We should try to avoid purging LSPs owned by another RB, if we can find 
better solution for removing stale entries in TRILL forwarding table in 
the issue of DRB changes and LAN partition.

In TRILL, there are two forwarding tables in data plane for unicast data 
frame. The first is MAC forwarding table, the entry in this table has the 
forming of {Dest_MAC, VLAN-ID, Egress_Nickname}. The second is TRILL ECMP 
table, whose entry has the form of {Egress_nickname, out_port, 
next_hop_mac,...}. The information in the first table is obtained by 
self-learning when decapsulating TRILL data frames. The second table is 
established from the TRILL LSPs. Only if an RBrige is reachable in ECMP 
table, the entry using this RBridge as egress can be added into MAC 
forwarding table. On the other hand, when an RBridge is un-reachable, the 
entry using this RBridge as egress must be removed from MAC forwarding 
table.

So, at the first, in order to aviod the TRILL data frame is discarded at 
the floor hop when LAN is partitioned, we wanted to use the purging 
mechanism to remove the incorrect entries in MAC forwarding table. But, at 
present, another solution is obtained for the issues of DRB changes and 
LAN partition.

A flag for pseudo-node nickname conflicting is introduced in the 
pseudo-node nickname structure. After receiving a pseudo LSP where this 
flag is set in one pseudo-node nickname, the RBridge MUST remove the 
entries associated with this pseudo-node nickname from the ECMP table and 
MAC table. If an RBridge, RB1, detects another RBridge, RB2, is using the 
same pseudo-node nickname as its own in pseudo-node LSPs, RB1 starts a 
non-cyclic waiting timer and updates it pseudo-node LSP where this flag is 
set to 1 in the pseudo-node nickname. After RB2 finds this conflicting, 
the same thing does it. For the tie-breaking of nickname conflicting, the 
RBridge, for example RB2, with higher priority obtains the pseudo-node 
nickname, and the other RBriges, RB1, uses another pseudo nickname. RB2, 
which obtains the pseudo-node nickname, MUST not reset this flag from the 
pseudo-node nickname in its pseudo LSP until the waiting timer expires, 
which ensures the associated entries are removed from other RBridges’ 
forwarding tables.

It is difficult for an RBridge to distinguish between DRB down and LAN 
partition, but it is easy for an RBridge to find conflict in nickname, 
especially in pseudo-node nickname used by its own. In issue of LAN 
partition, pseudo-node nickname conflict will be detected by DRBs at two 
part of partitioned LAN. After elected as new DRB, the RBridge just reuses 
the pseudo-node nickname already existing on the link in its pseudo-node 
LSPs. Once it detects pseudo-node nickname conflict issue occurs, in which 
another RBridge uses the same pseudo-node nickname in pseudo-node LSPs as 
its own, it will use the above mechanism to eliminate this conflicting.



Thanks,
Zhai Hongjun
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
 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: zhai.hongjun at zte.com.cn
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""





"Les Ginsberg (ginsberg)" <ginsberg at cisco.com> 
发件人:  rbridge-bounces at postel.org
2011-08-06 03:23

收件人
"Radia Perlman" <radiaperlman at gmail.com>, <zhai.hongjun at zte.com.cn>
抄送
rbridge at postel.org, Erik Nordmark <nordmark at acm.org>, 
rbridge-bounces at postel.org, hu.fangwei at zte.com.cn
主题
Re: [rbridge] Pseudo-node nickname






There is no need to purge LSPs owned by another RB.
 
RFC 4971 (Router Capabilities) states in Section 3:

" In order to prevent the use of stale capabilities, a system MUST NOT
   use a Capability TLV present in an LSP of a system that is not
   currently reachable via Level-x paths, where "x" is the level (1 or
   2) in which the sending system advertised the TLV.  "

When DRB changes occur neighbor advertisements to the old DRB will be 
removed from their non-pseudo-node LSPs by systems on the given LAN and 
advertisements to the new pseudo-node will be added. Similarly, the new 
DRB will flood a new pseudo-node LSP with reachability to the neighbors on 
the LAN. So two-way connectivity check to the old DRB will fail and the 
above logic will prevent you from using stale/unreachable nickname 
information.

In the event the LAN is partitioned (as opposed to the old DRB simply 
failing) again new LSPs (both pseudo-node and non-pseudo-node) will be 
flooded by the nodes on the respective segments and the partitioned two 
way connectivity will be discovered. In that case normal tiebreaking rules 
regarding conflicting nicknames can be applied.

Modifying the update process by trying to preemptively purge LSPs owned by 
another RB is unnecessary, will do no good, and may well cause unnecessary 
and potentially pathological churn if the originating system is still 
alive.

   Les


> -----Original Message-----
> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
> Behalf Of Radia Perlman
> Sent: Thursday, July 28, 2011 6:59 AM
> To: zhai.hongjun at zte.com.cn
> Cc: rbridge at postel.org; Erik Nordmark; rbridge-bounces at postel.org;
> hu.fangwei at zte.com.cn
> Subject: Re: [rbridge] Pseudo-node nickname
> 
> Here's an alternative to purging R1's LSP.
> 
> Background:  R1 was DRB.  R2 is the new DRB since R2 no longer receives
> R1's Hellos.
> R1's LSP will take an unacceptably long time to time out naturally if
> R1 is indeed dead.
> 
> Note:  If R2's pseudonode has higher priority for the pseudonode
> nickname than R1, then
> if R2 just usurps the nickname, then R2 does not need to purge R1's
> LSPs.
> 
> Also, I believe that it will be way more likely that R1 died than that
> the link partitioned, and
> even if the link partitioned, either the endnodes attached to R1's
> partition, or the endnodes
> attached to R2's partition will have service problems (because remote
> RBridges will have the
> wrong nickname for them).
> 
> So, an alternative to purging R1's LSP is for R2 to usurp the nickname
> by using a higher
> priority than R1.  If R1 is dead, then soon nobody will be able to
> reach that nickname via R1
> because all of R1's neighbors will declare the link to R1 down.  So it
> won't be confusing to
> have R1's unexpired LSP still claiming the nickname if R1 is down.  If
> R1 is still alive, and
> the link partitioned, then R1 loses the nickname for the pseudonode and
> has to choose
> another one.
> 
> I don't quite remember how long LSPs hang around when a node goes down.
> If a node is
> no longer reachable via the LSP database (because the node is down or
> the network is
> partitioned) is there anything that purges the LSP, or does it have to
> wait an hour or so
> before it goes away?  If the latter (it hangs around for an hour or
> so), then I could imagine
> worrying about having R2 and R1 keep increasing the priority and trying
> to take the
> pseudonode nickname back.  So there would have to be rules such as only
> increasing the
> priority once, and going back to the old priority once the dead DRB's
> LSP expires.
> 
> Though it's possible that it should be legal for R2 to purge R1's LSP
> provided that R1 is not
> reachable through the LSP database.  (R2 should not purge R1's LSP if
> the link had
> partitioned...only if R1 really is dead).
> 
> Radia
> 
> 
> 
> 2011/7/28 zhai.hongjun at zte.com.cn
> 
> 
> 
>                >> 2011/7/27 <hu.fangwei at zte.com.cn>
>                >> The point is that there maybe two cases that R2 loses
> conncetitvty to R1: one is R1 is died, and the other is the link
>                >> partitioning.
>                >> If the link is partitioned , R2 Must not purge R1's 
LSP.
> 
>                > The problem is, it's hard for R2 to know that R1 is 
still
> alive, but the link partitioned (that was Erik's
>                > original point). In either case (R1 is dead, or the 
link
> partitioned), R2 will stop hearing Hellos from R1,
>                > but R1's LSP will not have timed out. So the 
possibilities are
> 
> 
>                ...
> 
>                > c) if R2 has higher nickname priority than R1, then R2 
doesn't
> need to purge R1's LSP. R2 can just start
>                > using the pseudonode nickname, and if the link is 
partitioned,
> R1 will have to acquire a new nickname for
>                > it's half of the link. (I think this case is safe and
> reasonable)
> 
> 
>                Yes, it is reasonable and feasible.
> 
>                But I think a purging mechanism by prematuring the stale 
DRB's
> psedo-nickname is required when the old DRB is not in the new DRB's
> neighbor list.
> 
>                Assumed that there are 4 hosts(H1,H2,H3 and H4) and 4
> RBridges(RB1, RB2, RB3 and RB4, RB1 is DRB) on the initial link E1,
> which pseudo-nickname is PseNick1. A remote RBridge Rn has learned that
> the egress to H1,H2,H3 and H4 is PseNick1,and the RBn's shortest path
> to PseNick1 is through RB1. Now if the link partitions into two halves,
> RB1,RB2 and H1,H2 on the left half, the others on the right. If not
> purge the RB1's psedo-nickname from TRILL campus, RBn cannot remove(or
> update) the entries of H1,..H4 in it's forwarding table(until receiving
> traffic from H1,..,H4), even if one half link selects another psedo-
> nicknamee (for examble the right half). Then the traffic to H3 or H4 is
> discarded at the floor hop. However, if the RB1's psedo-nickname is
> purged from TRILL, RBn can remove the associated entries from
> forwarding table, and sends the frames destined to H3 or H4 as unkown
> unicast frames, which confirms these frames reach H3 or H4.
> 
>                After introducing such a purging mechanism, the 
processing of
> pseudo-nickname for DRB change(including link partition) is as
> following:
> 
>                From neighbor's Hellos or the pseu-nickname stored 
locally, the
> new DRB can know the pseudo-nickname used before on this link. With
> this pseudo-nickname as key, it can look up the associated pseudo LSP
> from its LSDB. If found, the new DRB purges this LSP from the TRILL
> campus if the older DRB is not in the new DRB's neighbor list. After
> that, or if not found, the new DRB contends for this nickname by common
> LSP. If successfully obtains this nickname, it can annouce this
> nickname in its pseudo LSPs and using it in data plane. Otherwise, it
> MUST contend for another nickname as pseudo nickname. Before obtaining
> a pseudo-nickname sucessfully, DRB MUST not use pseudo-nickname in
> ingressing frames into TRILL campus.
> 
>                In brief, the key words are "Purging older DRB's pseudo 
LSP"
> firstly, "Contending for the pseudo-nickname" secondly, "Announcing the
> obtained pseudo-nickname in pseudo LSP", and "Using this pseudo-
> nickname in data plane" finally.
> 
> 
> 
> 
>                Thanks,
>                Zhai Hongjun
> """""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
> """""
>                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 <tel:%2B86-25-52877345>
>                Email: zhai.hongjun at zte.com.cn
> """""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
> """"""
> 
> 
> 
> 
> 
> Radia Perlman <radiaperlman at gmail.com>
> 
> 发件人:  rbridge-bounces at postel.org
> 
> 2011-07-27 23:13
> 收件人
> hu.fangwei at zte.com.cn
> 抄送
> rbridge at postel.org, zhai.hongjun at zte.com.cn, Erik Nordmark
> <nordmark at acm.org>
> 主题
> Re: [rbridge] Pseudo-node nickname
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>                2011/7/27 <hu.fangwei at zte.com.cn <
mailto:hu.fangwei at zte.com.cn> >
> 
>                The point is that there maybe two cases  that R2 loses
> conncetitvty to R1: one is R1 is died, and the other is  the link
> partitioning.
> 
>                If the link is partitioned , R2 Must not purge R1's LSP.
> 
>                The problem is, it's hard for R2 to know that R1 is still 
alive,
> but the link partitioned (that was Erik's original point).  In either
> case (R1 is dead, or the link partitioned), R2 will stop hearing Hellos
> from R1, but R1's LSP will not have timed out.  So the possibilities
> are
> 
>                a) wait "awhile", upon taking over as DRB, before getting 
a
> nickname for the pseudonode.  Note that if R1's LSP hasn't expired, and
> R1's priority is higher, R2 cannot legally use the nickname for the
> pseudonode.
>                b) if after "awhile" there is no path through current 
LSPs, to
> R1's LSP, then purge *that* LSP of R1's.  (i.e., only do it once)
>                c) if R2 has higher nickname priority than R1, then R2 
doesn't
> need to purge R1's LSP.  R2 can just start using the pseudonode
> nickname, and if the link is partitioned, R1 will have to acquire a new
> nickname for it's half of the link.  (I think this case is safe and
> reasonable).
>                d) don't bother reusing nicknames if the DRB changes, but 
note
> that AF changes will still be helped by this (the simplest case).
> 
>                Perhaps there are other possibilities.  But I think it's 
safe to
> do c).  The disadvantage of not doing b) is that if R1's pseudonode has
> higher priority than R2's pseudonode then if R1 dies (more likely than
> the link partitioning probably), R2 doesn't get to reuse the nickname.
> But I'm sure people will worry about allowing R2 to purge someone
> else's LSP, so only doing c)  (allowing R2 to take over the nickname if
> R2's pseudonode has higher nickname priority), is reasonable.
> 
>                Radia
> 
> 
> 
>                 _______________________________________________
>                rbridge mailing list
>                rbridge at postel.org
>                http://mailman.postel.org/mailman/listinfo/rbridge
> 
> 
> 
>                --------------------------------------------------------
>                ZTE Information Security Notice: The information 
contained in
> this mail is solely property of the sender's organization. This mail
> communication is confidential. Recipients named above are obligated to
> maintain secrecy and are not permitted to disclose the contents of this
> communication to others.
>                This email and any files transmitted with it are 
confidential and
> intended solely for the use of the individual or entity to whom they
> are addressed. If you have received this email in error please notify
> the originator of the message. Any views expressed in this message are
> those of the individual sender.
>                This message has been scanned for viruses and Spam by ZTE 
Anti-
> Spam system.
> 


_______________________________________________
rbridge mailing list
rbridge at postel.org
http://mailman.postel.org/mailman/listinfo/rbridge




--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20110812/8a9cca65/attachment-0001.html

From d3e3e3 at gmail.com  Sun Aug 14 16:58:23 2011
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Sun, 14 Aug 2011 19:58:23 -0400
Subject: [rbridge] Preliminary minutes from Quebec City uploaded
Message-ID: <CAF4+nEG19fgJS1mP9nU4dCwSoYje6jJPh4DruzunAV3gS0Mcpg@mail.gmail.com>

Hi,

Preliminary minutes from the TRILL WG meeting in Quebec City have been
uploaded to the Meeting Materials page:
https://datatracker.ietf.org/meeting/81/materials.html

Thanks,
Donald
=============================
?Donald E. Eastlake 3rd?? +1-508-333-2270 (cell)
?155 Beaver Street
?Milford, MA 01757 USA
?d3e3e3 at gmail.com


From nordmark at acm.org  Tue Aug 16 16:52:45 2011
From: nordmark at acm.org (Erik Nordmark)
Date: Tue, 16 Aug 2011 16:52:45 -0700
Subject: [rbridge] FYI: Please publish draft-ietf-trill-rbridge-af-04.txt
In-Reply-To: <4E42B994.4020603@sonic.net>
References: <4E42B994.4020603@sonic.net>
Message-ID: <4E4B02CD.7030607@acm.org>


-------- Original Message --------
Subject: Please publish draft-ietf-trill-rbridge-af-04.txt
Date: Mon, 08 Aug 2011 18:29:36 -0700
From: Erik Nordmark <nordmark at acm.org>
To: Ralph Droms <rdroms.ietf at gmail.com>
CC: Donald Eastlake <d3e3e3 at gmail.com>, iesg-secretary at ietf.org


Ralph,

There is TRILL WG consensus to advance
draft-ietf-trill-rbridge-af-04.txt as a proposed standard. Here is the
PROTO statement.

    Erik

----


(1.a) Who is the Document Shepherd for this document? Has the
       Document Shepherd personally reviewed this version of the
       document and, in particular, does he or she believe this
       version is ready for forwarding to the IESG for publication?

    Erik Nordmark is the Document Shepherd.
    I have reviewed the document and believe it is ready.

(1.b) Has the document had adequate review both from key WG members
       and from key non-WG members?

    I believe the review has been good. Earlier versions of the document
    received good comments from both TRILL and IS-IS WG participants (we
    cc'ed the last call to the IS-IS WG).

(1.c) Does the Document Shepherd have concerns that the document
       needs more review from a particular or broader perspective,
       e.g., security, operational complexity, someone familiar with
       AAA, internationalization or XML?

    No.

(1.d) Does the Document Shepherd have any specific concerns or
       issues with this document that the Responsible Area Director
       and/or the IESG should be aware of? Has an IPR disclosure
       related to this document been filed?

    No specific concerns. No IPR disclosure has been filed for this
    document.

(1.e) How solid is the WG consensus behind this document? Does it
       represent the strong concurrence of a few individuals, with
       others being silent, or does the WG as a whole understand and
       agree with it?

    The consensus for the document is solid.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
       discontent?

    No.

(1.g) Has the Document Shepherd personally verified that the
       document satisfies all ID nits? (See the Internet-Drafts Checklist
       and http://tools.ietf.org/tools/idnits/). Has the document
       met all formal review criteria it needs to, such as the MIB
       Doctor, media type and URI type reviews?

    Yes. idnits reports 4 warnings related to the TRILL and IS-IS having
been issued as RFCs, and the ID hasn't been updated since then.

(1.h) Has the document split its references into normative and
       informative? Are there normative references to documents that
       are not ready for advancement or are otherwise in an unclear
       state?

    References are split into normative and informative. Normative
    references include IEEE and ISO standards.

(1.i) Has the Document Shepherd verified that the document IANA
       consideration section exists and is consistent with the body
       of the document?

    Yes. (No IANA actions are needed.)

(1.j) Has the Document Shepherd verified that sections of the
       document that are written in a formal language, such as XML
       code, BNF rules, MIB definitions, etc., validate correctly in
       an automated checker?

    N/A.

(1.k) The IESG approval announcement includes a Document
       Announcement Write-Up. Please provide such a Document
       Announcement Write-Up:

  Technical Summary

    TRILL supports multi-access LAN (Local Area Network) links that can
    have multiple end stations and RBridges attached. Where multiple
    RBridges are attached to a link, native traffic to and from end
    stations on that link is handled by a subset of those RBridges called
    Appointed Forwarders, with the intent that native traffic in each
    VLAN (Virtual LAN) be handled by at most one RBridge.  The purpose of
    this document is to improve the documentation of the Appointed
    Forwarder mechanism.

  Working Group Summary

    There was consensus in the document to advance this document after
    previous versions had elicited requests for clarifications and
    changes from both TRILL and IS-IS.

  Document Quality

    There are interoperable implementations of TRILL that were developed
    without the benefits of this additional document. The assumptions is
    that future implementors will benefit from the additional level of
    detail in this document.




From anoop at alumni.duke.edu  Wed Aug 17 18:26:44 2011
From: anoop at alumni.duke.edu (Anoop Ghanwani)
Date: Wed, 17 Aug 2011 18:26:44 -0700
Subject: [rbridge] comment about draft-ietf-trill-rbridge-channel-02
Message-ID: <CA+-tSzyDqnrAFAnDZVEx+4o3s1QnRZ1P+2qOUdfpg+KmOFgmAQ@mail.gmail.com>

This pertains to the following text in Section 2.2:

>>>>
When an RBridge Channel message is originated, the Hop Count field
defaults to the maximum value, 0x3F, but particular RBridge Channel
protocols MAY specify other values. For messages sent a known number
of hops, such as one-hop messages or two-hop neighbor echo messages,
setting the Hops field to the maximum value and checking the Hop
Count field on receipt provides an additional validity check as
discussed in [RFC5082].
>>>>

And then later:

>>>>>
If the channel message is a multi-hop
unicast message, then the egress nickname is a nickname of the target
RBridge; this includes the special case of an "echo" OAM message
where the originator places one of its own nicknames in both the
ingress and egress nickname fields.
>>>>>>

Technically we could have an echo message that has
both the ingress and egress nicknames the same, or it
could have them different (i.e. the actual egress RBridge).
Would it be possible to disambiguate these two?
Perhaps we could refer to the generic echo message
as a loopback, and the one with the identical ingress
and egress nickname as an echo?

From dromasca at avaya.com  Thu Aug 18 06:40:03 2011
From: dromasca at avaya.com (Romascanu, Dan (Dan))
Date: Thu, 18 Aug 2011 15:40:03 +0200
Subject: [rbridge] [MIB-DOCTORS] Volunteer needed to
	reviewdraft-ietf-trill-rbridge-mib-03
In-Reply-To: <EDC652A26FB23C4EB6384A4584434A04037E1827@307622ANEX5.global.avaya.com>
References: <EDC652A26FB23C4EB6384A4584434A04037E1827@307622ANEX5.global.avaya.com>
Message-ID: <EDC652A26FB23C4EB6384A4584434A040385FE8B@307622ANEX5.global.avaya.com>

Hi,

We did not receive any volunteering offers. The list is still open and
the MIB doctors are invited to step ahead. 

Bert and me did however a quick review of the I-D. Here are our
findings. Please treat them as review comments, but keep in mind that
the list is not final and more things may accumulate. 

I would also note that I reviewed a previous version of the MIB module
and document and made a number of comments. Not all were taken into
consideration. 

1. The relationship with other MIB module sections refer to the IETF
RFCs. However, since 2006 the development of the Bridge MIB modules and
their successors were transferred to IEEE 802.1. I suggest to define the
relationship sections in relation to the IEEE MIB modules

2. There are several tables with read-create objects but no rowStatus
object - rbridgeBaseNicknameTable, rbridgeBasePortTable,
rbridgeVlanPortTable, etc.

3. There are several writeable objects and tables with writeable objects
but no rowStorageType or any indication about persistency

4. In several places SYNTAX of Integer32 is used for range positive
integers. RFC 4181, section 4.6.1.1 says: 

- If the value range is between 0..4294967295 (inclusive), and values
     greater than 2147483647 are possible, and the value of the
     information being modelled does not increase above the maximum
     value nor decrease below the minimum value, then:

     - Unsigned32 is RECOMMENDED;
     - Gauge32 is acceptable;
     - INTEGER and Integer32 MUST NOT be used.

5. Use of Inter32 (0-65535) for port numbers instead of using
InetPortNumber from RFC4001

6. SMICng strict checking gives:

W: f(trill-rbridge.mi2), (46,17) The first revision should match the
last update for MODULE-IDENTITY rbridgeMIB
W: f(trill-rbridge.mi2), (299,4) Sequence "RBridgeBasePortEntry" and Row
"rbridgeBasePortEntry" should have related names
E: f(trill-rbridge.mi2), (299,4) Row "rbridgeBasePortEntry" may not have
columns with MAX-ACCESS of read-write if any column is read-create
E: f(trill-rbridge.mi2), (608,18) Index item "dot1qFdbId" must be
defined with syntax that includes a range
W: f(trill-rbridge.mi2), (810,20) Item "rbridgeMultiFibPorts" should
have SIZE specified
E: f(trill-rbridge.mi2), (838,18) Index item "dot1qVlanIndex" must be
defined with syntax that includes a range
E: f(trill-rbridge.mi2), (912,18) Index item "dot1qVlanIndex" must be
defined with syntax that includes a range
E: f(trill-rbridge.mi2), (1113,18) Index item "dot1qVlanIndex" must be
defined with syntax that includes a range
E: f(trill-rbridge.mi2), (1272,17) Index item "dot1qVlanIndex" must be
defined with syntax that includes a range
W: f(trill-rbridge.mi2), (1265,4) Row "rbridgeSnoopingAddrEntry" has
indexing that may create variables with more than 128 sub-ids
W: f(trill-rbridge.mi2), (1310,20) Item "rbridgeSnoopingAddrPorts"
should have SIZE specified
W: f(trill-rbridge.mi2), (838,18) Row "rbridgeVlanEntry" does not have a
consistent indexing scheme - index items must be in same order as used
in INDEX cl ause for "base row" dot1qVlanCurrentEntry
W: f(trill-rbridge.mi2), (912,18) Row "rbridgeVlanPortEntry" does not
have a consistent indexing scheme - cannot specify an index item from
additional "bas e row" dot1qVlanCurrentEntry, since can have only one
"base row" which is rbridgeBasePortEntry
W: f(trill-rbridge.mi2), (1113,18) Row "rbridgeEsadiEntry" does not have
a consistent indexing scheme - index items must be in same order as used
in INDEX clause for "base row" dot1qVlanCurrentEntry
W: f(trill-rbridge.mi2), (1272,17) Row "rbridgeSnoopingAddrEntry" does
not have a consistent indexing scheme - index items must be in same
order as used in  INDEX clause for "base row" dot1qVlanCurrentEntry

7. Objects like rbridgeBaseUniMultipathEnable or
rbridgeBaseMultiMultipathEnable could use the TruthValue TC as SYNTAX.

8. UNITS clauses would be useful for counter objects.

9. There is no indication about the behavior of tables that contain
counters wrt. counters discontinuity or any discontinuity indicator
objects defined. (see section 4.6.1.2 in RFC 4181 for this)


Regards,

Dan



> -----Original Message-----
> From: mib-doctors-bounces at ietf.org [mailto:mib-doctors-
> bounces at ietf.org] On Behalf Of Romascanu, Dan (Dan)
> Sent: Thursday, August 11, 2011 3:27 PM
> To: mib-doctors at ietf.org
> Cc: Ralph Droms
> Subject: [MIB-DOCTORS] Volunteer needed to reviewdraft-ietf-trill-
> rbridge-mib-03
> 
> MIB-Doctors,
> 
> We need a volunteer to review
> http://www.ietf.org/id/draft-ietf-trill-rbridge-mib-03.txt. The
> document
> is co-authored by Anil Rijhsinghani (author of the original Bridge
MIB)
> and looks in pretty good shape.
> 
> Thanks and Regards,
> 
> Dan
> 
> 
> 
> 
> _______________________________________________
> MIB-DOCTORS mailing list
> MIB-DOCTORS at ietf.org
> https://www.ietf.org/mailman/listinfo/mib-doctors


From d3e3e3 at gmail.com  Thu Aug 25 16:44:21 2011
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Thu, 25 Aug 2011 19:44:21 -0400
Subject: [rbridge] Fwd: RFC 6361 on PPP Transparent Interconnection of Lots
 of Links (TRILL) Protocol Control Protocol
In-Reply-To: <20110825231229.5442198C257@rfc-editor.org>
References: <20110825231229.5442198C257@rfc-editor.org>
Message-ID: <CAF4+nEEdd6vs-R1n3bmZE-gQ4cufo+ZMk1WfFj8w+2Dcn7NA8w@mail.gmail.com>

---------- Forwarded message ----------
From:  <rfc-editor at rfc-editor.org>
Date: Thu, Aug 25, 2011 at 7:12 PM
Subject: RFC 6361 on PPP Transparent Interconnection of Lots of Links
(TRILL) Protocol Control Protocol
To: ietf-announce at ietf.org, rfc-dist at rfc-editor.org
Cc: rfc-editor at rfc-editor.org


A new Request for Comments is now available in online RFC libraries.


? ? ? ?RFC 6361

? ? ? ?Title: ? ? ?PPP Transparent Interconnection of Lots
? ? ? ? ? ? ? ? ? ?of Links (TRILL) Protocol Control Protocol
? ? ? ?Author: ? ? J. Carlson, D. Eastlake 3rd
? ? ? ?Status: ? ? Standards Track
? ? ? ?Stream: ? ? IETF
? ? ? ?Date: ? ? ? August 2011
? ? ? ?Mailbox: ? ?carlsonj at workingcode.com,
? ? ? ? ? ? ? ? ? ?d3e3e3 at gmail.com
? ? ? ?Pages: ? ? ?8
? ? ? ?Characters: 17705
? ? ? ?Updates/Obsoletes/SeeAlso: ? None

? ? ? ?I-D Tag: ? ?draft-ietf-pppext-trill-protocol-08.txt

? ? ? ?URL: ? ? ? ?http://www.rfc-editor.org/rfc/rfc6361.txt

The Point-to-Point Protocol (PPP) defines a Link Control Protocol
(LCP) and a method for negotiating the use of multiprotocol traffic
over point-to-point links. ?This document describes PPP support for
the Transparent Interconnection of Lots of Links (TRILL) Protocol,
allowing direct communication between Routing Bridges (RBridges) via
PPP links. ?[STANDARDS-TRACK]

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements. ?Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol. ?Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
?http://www.ietf.org/mailman/listinfo/ietf-announce
?http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor at rfc-editor.org. ?Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


_______________________________________________
IETF-Announce mailing list
IETF-Announce at ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce


From nordmark at acm.org  Fri Aug 26 08:40:34 2011
From: nordmark at acm.org (Erik Nordmark)
Date: Fri, 26 Aug 2011 08:40:34 -0700
Subject: [rbridge] TRILL agenda items?
Message-ID: <4E57BE72.3090909@acm.org>


Donald and I are starting to prepare the agenda outline for Taipei, thus 
we need to know what drafts, discussions, and presentations we need to 
cover.

We'd like to find out now so we can determine whether we should ask for 
one or two slots (the last meetings have had a quite compressed agenda 
fit into one slot).

Thus if you have a draft or a topic you think should be on the agenda, 
let us now.

As always, we'd like to have discussion on the mailing list before the 
meeting so the WG can determine what are the key things to discuss 
face-to-face.

     Erik





From iesg-secretary at ietf.org  Tue Aug 30 16:33:59 2011
From: iesg-secretary at ietf.org (The IESG)
Date: Tue, 30 Aug 2011 16:33:59 -0700
Subject: [rbridge] Last Call: <draft-ietf-trill-rbridge-af-04.txt>
	(RBridges: Appointed	Forwarders) to Proposed Standard
Message-ID: <20110830233359.5756.28528.idtracker@ietfa.amsl.com>


The IESG has received a request from the Transparent Interconnection of
Lots of Links WG (trill) to consider the following document:
- 'RBridges: Appointed Forwarders'
  <draft-ietf-trill-rbridge-af-04.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf at ietf.org mailing lists by 2011-09-13. Exceptionally, comments may be
sent to iesg at ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


   The IETF TRILL (TRansparent Interconnection of Lots of Links)
   protocol provides least cost pair-wise data forwarding without
   configuration in multi-hop networks with arbitrary topology, safe
   forwarding even during periods of temporary loops, and support for
   multipathing of both unicast and multicast traffic. TRILL
   accomplishes this by using IS-IS (Intermediate System to Intermediate
   System) link state routing and by encapsulating traffic using a
   header that includes a hop count. Devices that implement TRILL are
   called RBridges.

   TRILL supports multi-access LAN (Local Area Network) links that can
   have multiple end stations and RBridges attached. Where multiple
   RBridges are attached to a link, native traffic to and from end
   stations on that link is handled by a subset of those RBridges called
   Appointed Forwarders, with the intent that native traffic in each
   VLAN (Virtual LAN) be handled by at most one RBridge.  The purpose of
   this document is to improve the documentation of the Appointed
   Forwarder mechanism.





The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-trill-rbridge-af/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-trill-rbridge-af/


No IPR declarations have been submitted directly on this I-D.



From liyizhou at huawei.com  Tue Aug 30 18:02:04 2011
From: liyizhou at huawei.com (Yizhou Li)
Date: Wed, 31 Aug 2011 09:02:04 +0800
Subject: [rbridge] FW: New Version Notification
	for	draft-yizhou-trill-multi-destination-ping-00.txt
Message-ID: <042201cc6779$992c41e0$cb84c5a0$@com>

Appreciate any comments.

A new version of I-D, draft-yizhou-trill-multi-destination-ping-00.txt has been successfully submitted by Yizhou Li and posted to the IETF repository.

Filename:	 draft-yizhou-trill-multi-destination-ping
Revision:	 00
Title:		 OAM tool for RBridges: Multi-destination Ping
Creation date:	 2011-08-26
WG ID:		 Individual Submission
Number of pages: 12

Abstract:
   This document specifies the extensions to the TRILL OAM tool for
   multi-destination ping. New OAM echo format and TLVs are defined.



                                                                                  


The IETF Secretariat