Subject: [rbridge] Connection-Oriented Rbridge

From: Shahram_Davari at pmc-sierra.com (Shahram Davari)
Date: Mon, 31 Jul 2006 14:02:45 -0700

Hi,

Is there any plan/thoughts to add GMPLS or other TE control-planes to Rbridge to make it connection-oriented?

Thanks,
Shahram

From: Shahram Davari <[email-masked]>
To: [email-masked]
Date: Mon, 31 Jul 2006 14:02:45 -0700
Subject: [rbridge] Connection-Oriented Rbridge
Status: RO
Content-Length: 132

Hi,

Is there any plan/thoughts to add GMPLS or other TE control-planes to Rbridge to make it connection-oriented?

Thanks,
Shahram

Content-class: urn:content-classes:message
Date: Fri, 28 Jul 2006 15:07:43 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: <[email-masked]>, "Radia Perlman" <[email-masked]>
Subject: Re: [rbridge] Need help sorting out IP multicast with RBridges
Status: RO
Content-Length: 7973

Hi,

Since no one else has responded to this message, see some comments from
me as a TRILL WG member below at @@@

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
Sent: Friday, July 14, 2006 10:58 AM
To: [email-masked]
Subject: [rbridge] Need help sorting out IP multicast with RBridges

IP multicast is really hairy. I'd like some opinions on what RBridges
should do with multicast, since it was pointed out to me that what's in
the current spec is not optimal. I have 4 orthogonal questions below,
numbered Question 0 through question 3. If you don't understand what I'm
saying, ask me to explain.

The current spec says:

a) RBridges discover whether they have IP routers on their own link.
Actually what's in the spec for this won't quite work since I asked what
messages IP multicast routers send, and was pointed to a lovely spec (IP
multicast router
discovery) but was told at this meeting that it isn't actually
implemented. So I'll have to change it to something else.
currently I think the "something else" is "listen to PIM messages". This
is ugly, since in theory there could be other IP multicast protocols.

Question 0: How should RBridges discover which links have IP multicast
routers on them?

@@@ I'm sure others know more, but it seems to me that you want to look
for both PIM messages, to work now, and Multicast Router Discovery
messages in the hope that they will be implemented and you will thus
work for various IP multicast protocols in the future.

b) RBridges inform (in the core instance LSP) the other RBridges that
they have an attached IP multicast router
c) When an RBridge sees an IGMP report, it sends it to all the links
(and only the links) that have IP multicast routers, and also puts
information about the requested groups in its (not sure if it should be
per-VLAN instance or core instance) LSP
d) an IP multicast data packet for group G, tagged with VLAN A, will be
sent to all the links in VLAN A that have an IGMP-reported join from a
listener, and also to links in VLAN A that have multicast routers.

Question 1) Should the group membership for VLAN A be reported in the
core instance or the per-VLAN instance? The reason for putting it in the
core instance is so that core RBridges can filter sooner, for branches
of the ingress-RBridge tree that have no receivers downstream. The
reason to put it in the per-VLAN instance is that this is potentially a
large and volatile information, especially if an obnoxious endnode
decides to join and unjoin zillions of groups...why annoy the core
bridges in that case.

I'd argue for putting it in the per-VLAN instance, and I suspect most
installations that are heavily depending on high volume IP multicast
applications won't be also using VLANs.

@@@ I agree.

***********
Question 2: IGMPv2 suppresses a host report if an endnode E hears
someone else has joined G.  RBridges are making E think the whole campus
is a single link, but RBridges are trying to optimize IP multicast and
only send G to links that requested G. I was worried about the case
where an endnode E and an IP router R were sharing a link...if the IGMP
report was sent to R, then E would see the report and not join. But I
was told that all IP multicast would be sent to all links with IP
multicast routers, so it's OK not to see E's join...the data would be
sent on that link anyway. So what's in the spec now works, but as I'll
explain in question 3, if we try to optimize IP multicast delivery so
that it isn't sent to
*all* IP multicast routers, then we don't want to suppress E's IGMP
report.

We could solve the problem of suppressing E's IGMP report (if we do what
I'll describe in question 3) in several ways:
a) assume that nobody is using IGMPv2 anymore and don't worry about that
case
b) Have the Designated RBridge notice that the IGMP report it is about
to forward to the link is version 2, and in that case, rather than
multicasting the report on the link to the multicast MAC address derived
from the IP multicast address (which is what version 2 does), unicasting
to the multicast router. I suspect this might confuse the IP multicast
router, since it's receiving it unicast rather than what the spec says,
but I also suspect that implementations might not check for this, so it
might work.

My inclination is to not stand on our head for version 2, and
furthermore not to bother with what I'll explain in question 3, since I
don't want supporting IP multicast to get so complicated that RBridges
become prohibitive.

@@@ The answer here depends somewhat on knowing just how common the
implementation is of which versions which I'm sure others can answer
better than me. What is the level of use of IGMPv2? It would be nice to
be able to ignore older versions if their use is insignificant or
rapidly declining towards insignificance.

*********
Question 3: Should we optimize delivery of IP multicast data to only get
sent to the "right" multicast router?

Not all IP multicast routers will be "interested" in data for G. I
believe in "dense mode", they all will be. But in "sparse mode"
I believe only one IP multicast router needs to receive G. Which IP
multicast router should receive G is the following:
PIM has a Designated Multicast Router election (similar to IS-IS),
electing DR. The default is that all groups go to DR.
However, sometimes it is discovered (through PIM sparse mode magic) that
R2 should receive G, and not the DR. In that case RBridges should
deliver G to R2 and not to DR. This could be done by having R2
explicitly ask for G, just like an endnode would.

Various potential solutions

a) RBridges send all IP mutlicasts to all IP multicast routers. Too bad
if it's not completely optimized.
b) RBridges listen to the PIM election to decide which IP multicast
router is the DR, and also listen to PIM asserts (or whatever it is that
tells which IP multicast router other than DR should get G), to know
which groups to send to which IP multicast routers.
c) RBridges send G only to the DR. If an IP multicast router R2 that is
not DR wants to receive G, it joins G, just like an endnode would do, so
that RBridges will deliver G to R2, in addition to sending it to DR.
d) as default, RBridges send all IP multicast traffic to all IP
multicast routers, but define a message to be sent between an IP
multicast router R2 and its RBridge, that says "send me only these
groups". Without receipt of that message, the RBridges send all IP
multicast traffic to R2.

I personally prefer a, since the others seem to be getting real
comlicated.

@@@ Based on the arguments thus far, I think "a" should be the mandatory
to implement level of optimization.

b) seems way too PIM specific, and RBridges would have to change when
PIM changed
c) won't work with IP multicast routers today that don't explicitly join
the groups, since they wouldn't join G explicitly
d) at least has correct behavior without expecting the IP multicast
routers to change. The extra message to be defined is only an
optimization beyond a).

@@@ It seems reasonable to specify this sort of thing as an optional
additional level of optimization. Defining a message from a multicast
router to its Rbridge saying what groups it wants seems good for the
future. However, so the optimization would work for current multicast
routers, is it all that hard to just monitor the PIM election? Assuming
that sending multicast to the PIM DR would cause it to be forwarded to
the "right" multicast router(s) if that isn't the DR, them I'm not sure
monitoring PIM assertion of such other routers would be worth it.

@@@ Monitoring PIM and also incorporating a better future solution for
this optimization seems somewhat parallel to PIM & MRD for finding
multicast routers in the first place.

So I prefer a) as simplest. My second choice is d).

Radia

@@@ Anyway, the above is my current opinion as a WG member.

@@@ Thanks,
@@@ Donald

Content-class: urn:content-classes:message
Date: Thu, 27 Jul 2006 14:00:57 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: <[email-masked]>
Subject: [rbridge] July TRILL Minutes uploaded, draft comments solicited
Status: RO
Content-Length: 751

Hi,

I've uploaded minutes for TRILL to the Proceedings for the July IETF
minutes. They are linked from
https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=66
. 
(These have only very minor differences from those posted to the list by
Stewart Bryant.)

We are making good progress but I would again request that people READ
THE DRAFTs and post comments to this list, particularly the two drafts
that are still personal drafts.

http://www.ietf.org/internet-drafts/draft-gray-trill-rbridge-arch-01.txt
http://www.ietf.org/internet-drafts/draft-gray-trill-routing-reqs-01.txt
http://www.ietf.org/internet-drafts/draft-ietf-trill-prob-00.txt
http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-protocol-00
.txt

Thanks,
Donald

Date: Mon, 24 Jul 2006 18:52:35 +0100
From: Stewart Bryant <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: [rbridge] Draft Trill Minutes for IETF66
Status: RO
Content-Length: 7854

TRILL Working Group
TRansparent Interconnection of Lots of Links
IETF-66 (Montreal), 1300-1500, Monday 25th July

Administrativia (scribe etc), Agenda, Chairs

Charter milestones Chairs

o Completed base protocol spec as WG document.
o Accepted problem statement and applicability as WG
  work item.
o Expect to start work with routing area WGs on TRILL
  extensions by July

o One year from now work should be completed and will
  need to recharter

Problem and Applicability Statement
draft-ietf-trill-prob-00.txt, Joe Touch, Radia Perlman

Changes since last IETF  diagram cleanup, scale
  estimates
Not intended to scale beyond large bridge deployments
  but may be able to do so.
Which version of Ethernet is baseline for Trill?
  802.1D. Need to support transport of VLANs.
Try hard to avoid duplication and maintain in order
  delivery, but do not need to be unconditionally achieved.
  Multiple spanning tree not needed
No answer on whether regions were needed.
Some addresses not forwarded - BPU, Pause Other bridge
  specific addresses - we are not sure what to do but
  must make a statement in each case - solution must
  be carefully considered.
Next step - summary of problem statement and requirements
Address remaining notes in doc
Target - final revision by end of July
  LC early August and then forward to IESG
Mailing list has been silent - please discuss on list.
  Is this document useful?
  (Silence)
  Chair: how many have read doc?
  Answer: 7-8
  Doe any have an opinion as to usefullness of doc?
  (Silence) bring to list.
  Joe Touch: Give such lack of feedback that hard to know what to do.
  Andy Malis: I read and saw a history of Ethernet, but didn't
  understand the applications for TRILL.
  Joe Touch: Not sure, except to say when STP is a problem
  (in draft)
  Yaakov Stein: Once again, this is another statement of
  the fact that we need a good statement at the front of the doc.

The Architecture of an RBridge Solution to TRILL
draft-gray-trill-rbridge-arch-01.txt, Eric Gray

Changes to draft: remove 2119 standards language from
  informational draft
Intro has been expanded, definitions clarified
Removed options and aligned with protocol spec,
  removed references to "campus"
Added clarifying examples
Intro includes text on "strategy"
Definitions have been changed. Campus replaced with
"CRED" CRED - co-op Rbridge and encap tunnels (Domain)

Shows very complex and colorful slide
Is this a "campus"? No-one considers a campus to
  extend beyond the "domain" but does it include the routers?
  Now CRED has all cooperating RBridges.
  When there are several paths between RBridges, STP would
  shut down, but this would lose BW
Role of desginated RBridge clarified. There is always a
  designated RBridge.
Still need to discuss - need "pseudo-node" use ?
Is this too detailed for architectures?
Should we remove distinctins between hubs, switches
  and bridges?
Need a better security statement, even though not a normative doc.
  But don't want too much to be configured

Stewart: the wiring closet problem. is this still an issue?
Eric: there was a discussion
Stewart: IEEE people have said that RBridge needs to address,
   otherwise inferior to existing implementation
Eric: need to discuss how to solve.
Radia: Maybe not solvable.
Eric: that would be nice to know too.
Stewart: Need to admit if can't be solved.
Eric: need more comments
Eric: ccept as WG doc?
Chair: how many have read?
  (very few)
  Of those who have read - how many for and
  against? (2 yeses)
  Jon opposes just for it to be 2:1 rather than 2:0

Rbridges: Base Protocol Specification
draft-ietf-trill-rbridge-protocol-00.txt, Radia Perlman, Joe Touch

A few minor things left to do.
Fold in Stewart's draft using MPLS-like header (4 bytes)
rather than 6 byte header originally proposed
for this we need to use nicknames

Also there are 3 differnt kinds of IS-IS packets
(L3 IS-IS, RBridge IS-IS core instance, desginated
RBridges per VLAN)
First and third type are forwarded by RBridges,
second type always consumed
Shim header has 19-bit label + 1-bit specifying if
   ingress or egress RBridge
MPLS header has EXP and S bits, but never need S
   bit as hierarchy shouldn't be needed

Shahram: Is there a field for OAM packets?
Radia: not at the moment
Radia: can use BFD if needed
Dino: Is there a new Ethertype?
Radia: yes need a new one.
Radia: should we reserve fields in MPLS label
(e.g. priority, S-bit) or define them?
Radia: we probably do not want to use Ethertype for MPLS
Yaakov S: IETF asked ITU NOT to use a separate Ethertype
   for T-MPLS
Dino: Takes opposite view + says may need to use PRI to
  do L2 QOS - may be problems with RBRIDGE and MPSL traffic
  on same LAN
Mark T: probably want to keep different, but that reduces the
  utility of existing hardware
Radia: Regular L3 IS-IS packet just like normal
  traffic (what about OSPF?)
Dino: IS-IS needle in a haystack but may need
   prioritization.
Radia: good reason to use priority field but don't
   need to prune the flood.
   per VLAN packets: endnodes and multicast receivers for
   IGMP-joined groups
decided to differentiate, so need 3 different multicast addresses
    1) Ordinary data
    2) Core IS-IS RB instances
    3)VLAN case
shows format (for core instance payload is entire IS-IS
   packet as emitted)
core instance is generated by RBridges, so there is an
IS-IS packet without Ethernet header
Per VLAN: also don't need inner layer 2 header, but
  need VLAN tag (+ align to 16 bits) - everything
  is in the outer header
Outer header is for classical bridges to function correctly
Radio asks if this is OK
New algorhyme written by Radia's son (Ray) (written in
1 hour) Radia suggests that the poem should be the abstract
to the spec and furthermore, that all RFCs should have
rhyming abstracts

Multicast Address Assignment for Standards
Donald Eastlake 3rd

Chair: need to request multicast address from IEEE
   registration authority
Should we request a small block?
Donald Eastlake plans to meet (informally) with 802.1
  chair Tony Jeffree to discuss 802.11s multicast
  addresses he will bring up TRILL requirements
Dino: Allocated two to ISO for ISIS - why whould
  they allocate a block for this
Radia: Would any company with an OUI donate one
  multicast address?
Chair: Also need an Ethertype.

TRILL Routing Requirements in Support of Rbridges
draft-gray-trill-routing-reqs-01.txt, Eric Gray

There have been changes after detailed view.
- Clarified purpose of document and importance of multicast
- Reduced size of sections 3 and 4.2
- Candidate routing protocol requirements
- Security section somewhat expanded
- Purpose - why we want a routing protocol for multicast?
- Still need to discuss - STP termination
  (need to clarify or remove)
- Need to number requirements? (somewhat asked for this)
- Obtain address prefix for IS-IS (in order to make it
  configuration-free)

Radia: Area address needs to be zero.
Eric: may be reserved.
Dino: need to specify size of address
Radia: Could be one byte area address
Eric: For the variant of ISIS that trill uses -
  what NSAPs should be used?
Dino: no longer a body that does NSAP address allocation
  so group should do it.
Dino: doesn't matter since different transport
Eric: need one more round of editing - please send comments
Eric: Can we accept as a WG document?
Chair : How many have read the draft? 3-4
Chair: anyone want to bring up anything else?
Mark: lot of people in room - please participate.
Jon Zwiebel: How is multicast traffic handled?
Radia: explains - PIM & IGMP snooping
      - text needs to be read and reviewed
Dino: haven't seen anyone implementing
Chair: yes please tell mailing list if implement -
   otherwise this will all die
Dino: have you polled the list?
Chair: not explicitly, but have heard large companies
   mention customer demand

Date: Wed, 19 Jul 2006 12:21:53 -0400
From: "Masanori Takashima" <[email-masked]>
To: [email-masked]
Subject: [rbridge] Ridirect, default VLAN ID, node ID and more
Status: RO
Content-Length: 2768

Hi,

I have comments and a question.

(1) Redirect situation
We may have a situation that we want to redirect frames.

  h1--R1----b1----R2
                |      (DR)
               h2

Suppose
 - h2 sends a frame to h1,
 - and h1 is learned by R1 already,
 - and R2 is DR on the shared link on that b1 and h2 are located,

apparently, the frame h2 to h1 goes through h2->b1->R2->b1->R1->h1,
although h2->b1->R1->h1 is a better path.

(2) default VLAN ID
Since all endnode information are carried by per VLAN instance of
routing protocol, all RBridge need to know what VLAN ID is assinged on
an interface defaultly if we keep to consider "less configuration". (I
don't know if I can say "zero configuration" or not.) So we need to
have a default VLAN ID that all interfaces of RBridge are defaultly
assigned.

(3) Node ID of shared link
Node ID of link state information is suggested in
"draft-perlman-trill-rbridge-protocol-00.txt" as follows,
2.2. Ingress Rbridge Tree Calculation
     .......               If the "node" is a pseudonode, i.e., a shared link,
   then one RBridge, say R1, on the link, is elected Designated RBridge,
   and R1 initiates a link state packet on behalf of the pseudonode. In
   this case the ID of the pseudonode is a 7-byte quantity which R1 can
   be sure is unique within the campus, usually the 6-byte system ID of
   R1, concatenated with a byte chosen by R1 to differentiate this
   pseudonode from any other link for which R1 might also be Designated
   RBridge.

But I think that those ID should not use the 6-byte system ID of DR.
Because RBridge could be replaced in case of failure, and the replaced
RBridge might be returned to the network with same system ID after it
is repaired.

We can say that the node ID of that shared link is changed to a new
DR's system ID. Removing the old ID and adding the new ID from/to an
adjacency list is not a good way, if the shared link does not
disappear but only the old DR disappear.

I don't think that we can keep using the node ID of that shared link
generated by disappearing DR's system id, because, as I mention
earlier, the removed old DR might come back to network with same
system id, and it might eventually be a new DR on another shared link.

I think that it is better to use "19-bit nickname" or random number
instead of system ID.

(4) Fast reroute
I wonder if Trill intends to have fast reroute mechaninsm or not in future?

(5) Ingress RBridge Tree (IRT)
I would like to clarify if my understanding is right or not.
If there are 100 RBridges, all RBridges will make 100 of IRT. Right?

Since there is no ingress tree distribution mechanism proposed, all
RBridges need to know its IRT and other RBridges' IRT from link state
in order to create tunnels.

Masanori

Date: Sat, 15 Jul 2006 09:36:49 +0200
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[email-masked]>
To: Pierre Francois <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] How to deal with RBridge-Rbridge link metrics ?
Status: RO
Content-Length: 8575

OK. So the "anomaly" cases may happen only with links between standard 
neighbour bridges with small bandwidth, cost is not visible to RBridges, 
as in RB=b-b=RB.
Guillermo

Pierre Francois wrote:
> 
> Guillermo,
> On Fri, 14 Jul 2006, Guillermo Ib??ez wrote:
> 
> 
>>I agree. It was only the asymmetry in costs issue that I exposed but it
>>is acceptable provided the worst case cost is applied at both RBridges.
> 
> 
> 
>>But it seems that the default link costs can not be applied to links
>>directly but need previous crosscheck with the path cost received from
>>neighbour RBridges (those separated by only  std bridges)and apply the
>>maximum (?) of them. It can be seen like some kind of agreement phase
>>between neighbours on costs to be applied prior to running the
>>algorithm. Link failures may introduce transients due to the reagreement
>>of costs.
> 
> 
> If you apply a two-way connectivity check "? la" IS-IS, you will not have
> a transient issue, as a link A--B will only be useable if A advertises
> A->B and B advertises B->A, with their respective metrics. So that, when a
> link is being considered for SPT computation by an RBridge in the campus,
> it knows the metrics for both directions, and can pick the largest one.
> 
> Pierre.
> 
> 
>>Guillermo
>>
>>Gray, Eric wrote:
>>
>>>Guillermo,
>>>
>>>	Just to be clear, having a manual configuration capability
>>>does not prevent "zero-configuration" as long as a well understood
>>>default exists (either a set of specific values, or something that
>>>can be derived).
>>>
>>>--
>>>Eric
>>>
>>>--> -----Original Message-----
>>>--> From: [email-masked]
>>>--> [mailto:[email-masked]] On Behalf Of Guillermo Ib??ez
>>>--> Sent: Thursday, July 13, 2006 2:31 PM
>>>--> To: Pierre Francois
>>>--> Cc: [email-masked]; Radia Perlman
>>>--> Subject: Re: [rbridge] How to deal with RBridge-Rbridge
>>>--> link metrics ?
>>>-->
>>>--> It seems that choosing worst case metric would be the
>>>--> logical decision.
>>>--> Manual configuration is against zero configuration
>>>--> objectives stated on
>>>--> RBridge origins.
>>>--> Universal metric regardless bandwidth seems irrational having 10**n
>>>--> bandwidth range with Ethernet.
>>>-->
>>>--> Pierre Francois wrote:
>>>-->
>>>--> >Guillermo,
>>>--> >
>>>--> >Thinking top of my head there, but, in your particular
>>>--> case, where there
>>>--> >is only one bridge in the middle, you could rely on what follows :
>>>--> >
>>>--> >RBridgeA has a link metric of x,
>>>--> >RBridgeB has a link metric of y < x.
>>>--> >
>>>--> >All the RBridges detect an asymetrical link metric,
>>>--> consider the largest,
>>>--> >x, as the metric for RbridgeA->RBridgeB and
>>>--> RbridgeB->RBridgeA so that
>>>--> >no one will consider that the link A->B is a 1Gbps link.
>>>--> >
>>>--> >Once you have two bridges in the middle, I don't see how
>>>--> >to make the metric be accurate without a manual configuration...
>>>--> >
>>>--> >Pierre.
>>>--> >
>>>--> >On Thu, 13 Jul 2006, Guillermo Ib??ez wrote:
>>>--> >
>>>--> >
>>>--> >
>>>--> >>I did not follow the whole discussion. I apologize in advance.
>>>--> >>A suggestion and a doubt.
>>>--> >>For link metrics I would suggest to refer to 802.1D
>>>--> default link costs
>>>--> >>for bridges. (20.000.000/Link speed in Mbps), but what happens if
>>>--> >>between two RBridges A and B there is standard bridge and
>>>--> the link to
>>>--> >>one RBridge is 100 Mbps and the link to the other is 1 Gbps?
>>>--> >>Guillermo
>>>--> >>
>>>--> >>Russ White wrote:
>>>--> >>
>>>--> >>
>>>--> >>>-----BEGIN PGP SIGNED MESSAGE-----
>>>--> >>>Hash: SHA1
>>>--> >>>
>>>--> >>>
>>>--> >>>
>>>--> >>>
>>>--> >>>
>>>--> >>>>When we said "zero configuration" we weren't intending
>>>--> to preclude
>>>--> >>>>configuration for tuning. So perhaps we have
>>>--> >>>>to change the wording in the documents. VLANs almost
>>>--> certainly require
>>>--> >>>>configuration, and there will always
>>>--> >>>>be tuning.
>>>--> >>>>
>>>--> >>>>Should we consider setting of link metrics, and what
>>>--> the defaults are,
>>>--> >>>>to be an implementation issue? I agree
>>>--> >>>>with Pierre that it would be good, for instance, to
>>>--> choose defaults in
>>>--> >>>>the base TRILL document, so that all
>>>--> >>>>implementations use the same logical defaults.
>>>--> >>>>
>>>--> >>>>
>>>--> >>>The first question we actually need to answer is--wide metrics or
>>>--> >>>narrow? Since IS-IS has two metric types, if we do "zero
>>>--> configuration,"
>>>--> >>>we need to worry about the type of metric chosen in the
>>>--> default state.
>>>--> >>>IMHO, it would be better to specify wide metrics only.
>>>--> >>>
>>>--> >>>
>>>--> >>>
>>>--> >>>
>>>--> >>>>Should we pick a single default for link cost for all
>>>--> types of links? (I
>>>--> >>>>think not)
>>>--> >>>>Should we pick a default value for each link type?
>>>--> (say, a link of this
>>>--> >>>>speed would have this default). I think I
>>>--> >>>>favor this, but I'd certainly prefer someone who has
>>>--> been working with
>>>--> >>>>IS-IS recently decide.
>>>--> >>>>
>>>--> >>>>
>>>--> >>>I would say that if we want to go this route, some type
>>>--> of "x/bandwidth"
>>>--> >>>would work, but, we must be careful on two fronts:
>>>--> >>>
>>>--> >>>- -- We don't really want to specify x, unless we
>>>--> specify it so close to
>>>--> >>>infinity that we'll never hit a link with greater than x
>>>--> available
>>>--> >>>bandwidth. There have been many points in the past when
>>>--> we've chosen
>>>--> >>>what we think x should be, and we're always wrong, in a
>>>--> sense. In fact,
>>>--> >>>it's hard to know what x should be, since it's not
>>>--> really derived from
>>>--> >>>the maximum link bandwidth in the network, but it's
>>>--> rather a balance of
>>>--> >>>the min and max link bandwidths available.
>>>--> >>>
>>>--> >>>- -- We want to make certain that there is a way to
>>>--> change x in the
>>>--> >>>network without undue downtime (none would be preferred).
>>>--> >>>
>>>--> >>>The first problem is something we, the trill community,
>>>--> need to address.
>>>--> >>>Perhaps we could specify a default metric of "x/bandwidth," with
>>>--> >>>operators able to set what they want (tune), and
>>>--> operators also setting
>>>--> >>>x, and the assumption that vendors may choose x for
>>>--> their products. The
>>>--> >>>second problem is outside the scope of TRILL, so we can
>>>--> ignore it, for now.
>>>--> >>>
>>>--> >>>Or, another option is, as Radia says, simply make up a
>>>--> list. The problem
>>>--> >>>here is that no matter how you cut it, you're
>>>--> essentially doing some
>>>--> >>>form of x/bandwidth anyway, and you always run into some problems
>>>--> >>>figuring out what x should be. (Remember, as well, that
>>>--> x may not be a
>>>--> >>>single value, it may be a formula containing the
>>>--> bandwidth, as well).
>>>--> >>>
>>>--> >>>
>>>--> >>>
>>>--> >>>
>>>--> >>>>The easiest thing would be to ignore this issue and
>>>--> claim that the IS-IS
>>>--> >>>>specification deals with it, but I think
>>>--> >>>>it would be nice to suggest defaults.
>>>--> >>>>
>>>--> >>>>
>>>--> >>>It doesn't, really--in IS-IS today, you must tune if you
>>>--> want tuning,
>>>--> >>>the default metric is set such that we don't fall over
>>>--> the maximum with
>>>--> >>>narrow metrics in fairly large networks. I don't think
>>>--> that's really a
>>>--> >>>"good idea" for TRILL, if we can avoid it, since we want
>>>--> this to be
>>>--> >>>configuration less, if possible (?).
>>>--> >>>
>>>--> >>>:-)
>>>--> >>>
>>>--> >>>Russ
>>>--> >>>
>>>--> >>>
>>>--> >>>-----BEGIN PGP SIGNATURE-----
>>>--> >>>Version: GnuPG v1.4.1 (Darwin)
>>>--> >>>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>>>--> >>>
>>>--> >>>iD8DBQFEtNqsER27sUhU9OQRAkAHAKDC2ud3T7cooyQK7YMpEKd91ZuPyACaA9rR
>>>--> >>>FhZQutTJj+LMyAB6rrSw0L8=
>>>--> >>>=kl90
>>>--> >>>-----END PGP SIGNATURE-----
>>>--> >>>_______________________________________________
>>>--> >>>rbridge mailing list
>>>--> >>>[email-masked]
>>>--> >>>http://mailman.postel.org/mailman/listinfo/rbridge
>>>--> >>>
>>>--> >>>
>>>--> >>>
>>>--> >>_______________________________________________
>>>--> >>rbridge mailing list
>>>--> >>[email-masked]
>>>--> >>http://mailman.postel.org/mailman/listinfo/rbridge
>>>--> >>
>>>--> >>
>>>--> >>
>>>--> _______________________________________________
>>>--> rbridge mailing list
>>>--> [email-masked]
>>>--> http://mailman.postel.org/mailman/listinfo/rbridge
>>>-->
>>>
> 

Date: Fri, 14 Jul 2006 23:04:18 +0200 (CEST)
From: Pierre Francois <[email-masked]>
To: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] How to deal with RBridge-Rbridge link metrics ?
Status: RO
Content-Length: 8533

Guillermo,
On Fri, 14 Jul 2006, Guillermo Ib??ez wrote:

> I agree. It was only the asymmetry in costs issue that I exposed but it
> is acceptable provided the worst case cost is applied at both RBridges.

> But it seems that the default link costs can not be applied to links
> directly but need previous crosscheck with the path cost received from
> neighbour RBridges (those separated by only  std bridges)and apply the
> maximum (?) of them. It can be seen like some kind of agreement phase
> between neighbours on costs to be applied prior to running the
> algorithm. Link failures may introduce transients due to the reagreement
> of costs.

If you apply a two-way connectivity check "? la" IS-IS, you will not have
a transient issue, as a link A--B will only be useable if A advertises
A->B and B advertises B->A, with their respective metrics. So that, when a
link is being considered for SPT computation by an RBridge in the campus,
it knows the metrics for both directions, and can pick the largest one.

Pierre.

> Guillermo
>
> Gray, Eric wrote:
> > Guillermo,
> >
> > 	Just to be clear, having a manual configuration capability
> > does not prevent "zero-configuration" as long as a well understood
> > default exists (either a set of specific values, or something that
> > can be derived).
> >
> > --
> > Eric
> >
> > --> -----Original Message-----
> > --> From: [email-masked]
> > --> [mailto:[email-masked]] On Behalf Of Guillermo Ib??ez
> > --> Sent: Thursday, July 13, 2006 2:31 PM
> > --> To: Pierre Francois
> > --> Cc: [email-masked]; Radia Perlman
> > --> Subject: Re: [rbridge] How to deal with RBridge-Rbridge
> > --> link metrics ?
> > -->
> > --> It seems that choosing worst case metric would be the
> > --> logical decision.
> > --> Manual configuration is against zero configuration
> > --> objectives stated on
> > --> RBridge origins.
> > --> Universal metric regardless bandwidth seems irrational having 10**n
> > --> bandwidth range with Ethernet.
> > -->
> > --> Pierre Francois wrote:
> > -->
> > --> >Guillermo,
> > --> >
> > --> >Thinking top of my head there, but, in your particular
> > --> case, where there
> > --> >is only one bridge in the middle, you could rely on what follows :
> > --> >
> > --> >RBridgeA has a link metric of x,
> > --> >RBridgeB has a link metric of y < x.
> > --> >
> > --> >All the RBridges detect an asymetrical link metric,
> > --> consider the largest,
> > --> >x, as the metric for RbridgeA->RBridgeB and
> > --> RbridgeB->RBridgeA so that
> > --> >no one will consider that the link A->B is a 1Gbps link.
> > --> >
> > --> >Once you have two bridges in the middle, I don't see how
> > --> >to make the metric be accurate without a manual configuration...
> > --> >
> > --> >Pierre.
> > --> >
> > --> >On Thu, 13 Jul 2006, Guillermo Ib??ez wrote:
> > --> >
> > --> >
> > --> >
> > --> >>I did not follow the whole discussion. I apologize in advance.
> > --> >>A suggestion and a doubt.
> > --> >>For link metrics I would suggest to refer to 802.1D
> > --> default link costs
> > --> >>for bridges. (20.000.000/Link speed in Mbps), but what happens if
> > --> >>between two RBridges A and B there is standard bridge and
> > --> the link to
> > --> >>one RBridge is 100 Mbps and the link to the other is 1 Gbps?
> > --> >>Guillermo
> > --> >>
> > --> >>Russ White wrote:
> > --> >>
> > --> >>
> > --> >>>-----BEGIN PGP SIGNED MESSAGE-----
> > --> >>>Hash: SHA1
> > --> >>>
> > --> >>>
> > --> >>>
> > --> >>>
> > --> >>>
> > --> >>>>When we said "zero configuration" we weren't intending
> > --> to preclude
> > --> >>>>configuration for tuning. So perhaps we have
> > --> >>>>to change the wording in the documents. VLANs almost
> > --> certainly require
> > --> >>>>configuration, and there will always
> > --> >>>>be tuning.
> > --> >>>>
> > --> >>>>Should we consider setting of link metrics, and what
> > --> the defaults are,
> > --> >>>>to be an implementation issue? I agree
> > --> >>>>with Pierre that it would be good, for instance, to
> > --> choose defaults in
> > --> >>>>the base TRILL document, so that all
> > --> >>>>implementations use the same logical defaults.
> > --> >>>>
> > --> >>>>
> > --> >>>The first question we actually need to answer is--wide metrics or
> > --> >>>narrow? Since IS-IS has two metric types, if we do "zero
> > --> configuration,"
> > --> >>>we need to worry about the type of metric chosen in the
> > --> default state.
> > --> >>>IMHO, it would be better to specify wide metrics only.
> > --> >>>
> > --> >>>
> > --> >>>
> > --> >>>
> > --> >>>>Should we pick a single default for link cost for all
> > --> types of links? (I
> > --> >>>>think not)
> > --> >>>>Should we pick a default value for each link type?
> > --> (say, a link of this
> > --> >>>>speed would have this default). I think I
> > --> >>>>favor this, but I'd certainly prefer someone who has
> > --> been working with
> > --> >>>>IS-IS recently decide.
> > --> >>>>
> > --> >>>>
> > --> >>>I would say that if we want to go this route, some type
> > --> of "x/bandwidth"
> > --> >>>would work, but, we must be careful on two fronts:
> > --> >>>
> > --> >>>- -- We don't really want to specify x, unless we
> > --> specify it so close to
> > --> >>>infinity that we'll never hit a link with greater than x
> > --> available
> > --> >>>bandwidth. There have been many points in the past when
> > --> we've chosen
> > --> >>>what we think x should be, and we're always wrong, in a
> > --> sense. In fact,
> > --> >>>it's hard to know what x should be, since it's not
> > --> really derived from
> > --> >>>the maximum link bandwidth in the network, but it's
> > --> rather a balance of
> > --> >>>the min and max link bandwidths available.
> > --> >>>
> > --> >>>- -- We want to make certain that there is a way to
> > --> change x in the
> > --> >>>network without undue downtime (none would be preferred).
> > --> >>>
> > --> >>>The first problem is something we, the trill community,
> > --> need to address.
> > --> >>>Perhaps we could specify a default metric of "x/bandwidth," with
> > --> >>>operators able to set what they want (tune), and
> > --> operators also setting
> > --> >>>x, and the assumption that vendors may choose x for
> > --> their products. The
> > --> >>>second problem is outside the scope of TRILL, so we can
> > --> ignore it, for now.
> > --> >>>
> > --> >>>Or, another option is, as Radia says, simply make up a
> > --> list. The problem
> > --> >>>here is that no matter how you cut it, you're
> > --> essentially doing some
> > --> >>>form of x/bandwidth anyway, and you always run into some problems
> > --> >>>figuring out what x should be. (Remember, as well, that
> > --> x may not be a
> > --> >>>single value, it may be a formula containing the
> > --> bandwidth, as well).
> > --> >>>
> > --> >>>
> > --> >>>
> > --> >>>
> > --> >>>>The easiest thing would be to ignore this issue and
> > --> claim that the IS-IS
> > --> >>>>specification deals with it, but I think
> > --> >>>>it would be nice to suggest defaults.
> > --> >>>>
> > --> >>>>
> > --> >>>It doesn't, really--in IS-IS today, you must tune if you
> > --> want tuning,
> > --> >>>the default metric is set such that we don't fall over
> > --> the maximum with
> > --> >>>narrow metrics in fairly large networks. I don't think
> > --> that's really a
> > --> >>>"good idea" for TRILL, if we can avoid it, since we want
> > --> this to be
> > --> >>>configuration less, if possible (?).
> > --> >>>
> > --> >>>:-)
> > --> >>>
> > --> >>>Russ
> > --> >>>
> > --> >>>
> > --> >>>-----BEGIN PGP SIGNATURE-----
> > --> >>>Version: GnuPG v1.4.1 (Darwin)
> > --> >>>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> > --> >>>
> > --> >>>iD8DBQFEtNqsER27sUhU9OQRAkAHAKDC2ud3T7cooyQK7YMpEKd91ZuPyACaA9rR
> > --> >>>FhZQutTJj+LMyAB6rrSw0L8=
> > --> >>>=kl90
> > --> >>>-----END PGP SIGNATURE-----
> > --> >>>_______________________________________________
> > --> >>>rbridge mailing list
> > --> >>>[email-masked]
> > --> >>>http://mailman.postel.org/mailman/listinfo/rbridge
> > --> >>>
> > --> >>>
> > --> >>>
> > --> >>_______________________________________________
> > --> >>rbridge mailing list
> > --> >>[email-masked]
> > --> >>http://mailman.postel.org/mailman/listinfo/rbridge
> > --> >>
> > --> >>
> > --> >>
> > --> _______________________________________________
> > --> rbridge mailing list
> > --> [email-masked]
> > --> http://mailman.postel.org/mailman/listinfo/rbridge
> > -->
> >
>

Date: Fri, 14 Jul 2006 19:14:30 +0200
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[email-masked]>
To: "Gray, Eric" <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] How to deal with RBridge-Rbridge link metrics ?
Status: RO
Content-Length: 7775

I agree. It was only the asymmetry in costs issue that I exposed but it 
is acceptable provided the worst case cost is applied at both RBridges.
But it seems that the default link costs can not be applied to links 
directly but need previous crosscheck with the path cost received from 
neighbour RBridges (those separated by only  std bridges)and apply the 
maximum (?) of them. It can be seen like some kind of agreement phase 
between neighbours on costs to be applied prior to running the 
algorithm. Link failures may introduce transients due to the reagreement 
of costs.
Guillermo

Gray, Eric wrote:
> Guillermo,
> 
> 	Just to be clear, having a manual configuration capability
> does not prevent "zero-configuration" as long as a well understood
> default exists (either a set of specific values, or something that
> can be derived).
> 
> --
> Eric 
> 
> --> -----Original Message-----
> --> From: [email-masked] 
> --> [mailto:[email-masked]] On Behalf Of Guillermo Ib??ez
> --> Sent: Thursday, July 13, 2006 2:31 PM
> --> To: Pierre Francois
> --> Cc: [email-masked]; Radia Perlman
> --> Subject: Re: [rbridge] How to deal with RBridge-Rbridge 
> --> link metrics ?
> --> 
> --> It seems that choosing worst case metric would be the 
> --> logical decision.
> --> Manual configuration is against zero configuration 
> --> objectives stated on 
> --> RBridge origins.
> --> Universal metric regardless bandwidth seems irrational having 10**n 
> --> bandwidth range with Ethernet.
> --> 
> --> Pierre Francois wrote:
> --> 
> --> >Guillermo,
> --> >
> --> >Thinking top of my head there, but, in your particular 
> --> case, where there
> --> >is only one bridge in the middle, you could rely on what follows :
> --> >
> --> >RBridgeA has a link metric of x,
> --> >RBridgeB has a link metric of y < x.
> --> >
> --> >All the RBridges detect an asymetrical link metric, 
> --> consider the largest,
> --> >x, as the metric for RbridgeA->RBridgeB and 
> --> RbridgeB->RBridgeA so that
> --> >no one will consider that the link A->B is a 1Gbps link.
> --> >
> --> >Once you have two bridges in the middle, I don't see how
> --> >to make the metric be accurate without a manual configuration...
> --> >
> --> >Pierre.
> --> >
> --> >On Thu, 13 Jul 2006, Guillermo Ib??ez wrote:
> --> >
> --> >  
> --> >
> --> >>I did not follow the whole discussion. I apologize in advance.
> --> >>A suggestion and a doubt.
> --> >>For link metrics I would suggest to refer to 802.1D 
> --> default link costs
> --> >>for bridges. (20.000.000/Link speed in Mbps), but what happens if
> --> >>between two RBridges A and B there is standard bridge and 
> --> the link to
> --> >>one RBridge is 100 Mbps and the link to the other is 1 Gbps?
> --> >>Guillermo
> --> >>
> --> >>Russ White wrote:
> --> >>    
> --> >>
> --> >>>-----BEGIN PGP SIGNED MESSAGE-----
> --> >>>Hash: SHA1
> --> >>>
> --> >>>
> --> >>>
> --> >>>      
> --> >>>
> --> >>>>When we said "zero configuration" we weren't intending 
> --> to preclude
> --> >>>>configuration for tuning. So perhaps we have
> --> >>>>to change the wording in the documents. VLANs almost 
> --> certainly require
> --> >>>>configuration, and there will always
> --> >>>>be tuning.
> --> >>>>
> --> >>>>Should we consider setting of link metrics, and what 
> --> the defaults are,
> --> >>>>to be an implementation issue? I agree
> --> >>>>with Pierre that it would be good, for instance, to 
> --> choose defaults in
> --> >>>>the base TRILL document, so that all
> --> >>>>implementations use the same logical defaults.
> --> >>>>        
> --> >>>>
> --> >>>The first question we actually need to answer is--wide metrics or
> --> >>>narrow? Since IS-IS has two metric types, if we do "zero 
> --> configuration,"
> --> >>>we need to worry about the type of metric chosen in the 
> --> default state.
> --> >>>IMHO, it would be better to specify wide metrics only.
> --> >>>
> --> >>>
> --> >>>      
> --> >>>
> --> >>>>Should we pick a single default for link cost for all 
> --> types of links? (I
> --> >>>>think not)
> --> >>>>Should we pick a default value for each link type? 
> --> (say, a link of this
> --> >>>>speed would have this default). I think I
> --> >>>>favor this, but I'd certainly prefer someone who has 
> --> been working with
> --> >>>>IS-IS recently decide.
> --> >>>>        
> --> >>>>
> --> >>>I would say that if we want to go this route, some type 
> --> of "x/bandwidth"
> --> >>>would work, but, we must be careful on two fronts:
> --> >>>
> --> >>>- -- We don't really want to specify x, unless we 
> --> specify it so close to
> --> >>>infinity that we'll never hit a link with greater than x 
> --> available
> --> >>>bandwidth. There have been many points in the past when 
> --> we've chosen
> --> >>>what we think x should be, and we're always wrong, in a 
> --> sense. In fact,
> --> >>>it's hard to know what x should be, since it's not 
> --> really derived from
> --> >>>the maximum link bandwidth in the network, but it's 
> --> rather a balance of
> --> >>>the min and max link bandwidths available.
> --> >>>
> --> >>>- -- We want to make certain that there is a way to 
> --> change x in the
> --> >>>network without undue downtime (none would be preferred).
> --> >>>
> --> >>>The first problem is something we, the trill community, 
> --> need to address.
> --> >>>Perhaps we could specify a default metric of "x/bandwidth," with
> --> >>>operators able to set what they want (tune), and 
> --> operators also setting
> --> >>>x, and the assumption that vendors may choose x for 
> --> their products. The
> --> >>>second problem is outside the scope of TRILL, so we can 
> --> ignore it, for now.
> --> >>>
> --> >>>Or, another option is, as Radia says, simply make up a 
> --> list. The problem
> --> >>>here is that no matter how you cut it, you're 
> --> essentially doing some
> --> >>>form of x/bandwidth anyway, and you always run into some problems
> --> >>>figuring out what x should be. (Remember, as well, that 
> --> x may not be a
> --> >>>single value, it may be a formula containing the 
> --> bandwidth, as well).
> --> >>>
> --> >>>
> --> >>>      
> --> >>>
> --> >>>>The easiest thing would be to ignore this issue and 
> --> claim that the IS-IS
> --> >>>>specification deals with it, but I think
> --> >>>>it would be nice to suggest defaults.
> --> >>>>        
> --> >>>>
> --> >>>It doesn't, really--in IS-IS today, you must tune if you 
> --> want tuning,
> --> >>>the default metric is set such that we don't fall over 
> --> the maximum with
> --> >>>narrow metrics in fairly large networks. I don't think 
> --> that's really a
> --> >>>"good idea" for TRILL, if we can avoid it, since we want 
> --> this to be
> --> >>>configuration less, if possible (?).
> --> >>>
> --> >>>:-)
> --> >>>
> --> >>>Russ
> --> >>>
> --> >>>
> --> >>>-----BEGIN PGP SIGNATURE-----
> --> >>>Version: GnuPG v1.4.1 (Darwin)
> --> >>>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> --> >>>
> --> >>>iD8DBQFEtNqsER27sUhU9OQRAkAHAKDC2ud3T7cooyQK7YMpEKd91ZuPyACaA9rR
> --> >>>FhZQutTJj+LMyAB6rrSw0L8=
> --> >>>=kl90
> --> >>>-----END PGP SIGNATURE-----
> --> >>>_______________________________________________
> --> >>>rbridge mailing list
> --> >>>[email-masked]
> --> >>>http://mailman.postel.org/mailman/listinfo/rbridge
> --> >>>
> --> >>>      
> --> >>>
> --> >>_______________________________________________
> --> >>rbridge mailing list
> --> >>[email-masked]
> --> >>http://mailman.postel.org/mailman/listinfo/rbridge
> --> >>
> --> >>    
> --> >>
> --> _______________________________________________
> --> rbridge mailing list
> --> [email-masked]
> --> http://mailman.postel.org/mailman/listinfo/rbridge
> --> 
> 

Date: Fri, 14 Jul 2006 07:58:03 -0700
From: [email-masked]
To: [email-masked]
Priority: normal
Subject: [rbridge] Need help sorting out IP multicast with RBridges
Status: RO
Content-Length: 6072

IP multicast is really hairy. I'd like some opinions on what RBridges should do with multicast, since it was
pointed out to me that what's in the current spec is not optimal. I have 4 orthogonal questions below, numbered
Question 0 through question 3. If you don't understand what I'm saying, ask me to explain.

The current spec says:

a) RBridges discover whether they have IP routers on their own link. Actually what's in the spec for this won't quite
work since I asked what messages IP multicast routers send, and was pointed to a lovely spec (IP multicast router
discovery) but was told at this meeting that it isn't actually implemented. So I'll have to change it to something else.
currently I think the "something else" is "listen to PIM messages". This is ugly, since in theory there could be other
IP multicast protocols.

Question 0: How should RBridges discover which links have IP multicast routers on them?

b) RBridges inform (in the core instance LSP) the other RBridges that they have an attached IP multicast router
c) When an RBridge sees an IGMP report, it sends it to all the links (and only the links) that have IP multicast routers, and
also puts information about the requested groups in its (not sure if it should be per-VLAN instance or core instance) LSP
d) an IP multicast data packet for group G, tagged with VLAN A, will be sent to all the links in VLAN A that have an
IGMP-reported join from a listener, and also to links in VLAN A that have multicast routers.

Question 1) Should the group membership for VLAN A be reported in the core instance or the per-VLAN instance? The
reason for putting it in the core instance is so that core RBridges can filter sooner, for branches of the ingress-RBridge tree
that have no receivers downstream. The reason to put it in the per-VLAN instance is that this is potentially a large
and volatile information, especially if an obnoxious endnode decides to join and unjoin zillions of groups...why annoy
the core bridges in that case.

I'd argue for putting it in the per-VLAN instance, and I suspect most installations that are heavily depending on
high volume IP multicast applications won't be also using VLANs.

***********
Question 2: IGMPv2 suppresses a host report if an endnode E hears someone else has joined G.  RBridges are making
E think the whole campus is a single link, but RBridges are trying to optimize IP multicast and only send G to links
that requested G. I was worried about the case where an endnode E and an IP router R were sharing a link...if the IGMP
report was sent to R, then E would see the report and not join. But I was told that all IP multicast would be sent to all
links with IP multicast routers, so it's OK not to see E's join...the data would be sent on that link anyway. So what's
in the spec now works, but as I'll explain in question 3, if we try to optimize IP multicast delivery so that it isn't sent to
*all* IP multicast routers, then we don't want to suppress E's IGMP report.

We could solve the problem of suppressing E's IGMP report (if we do what I'll describe in question 3) in several ways:
a) assume that nobody is using IGMPv2 anymore and don't worry about that case
b) Have the Designated RBridge notice that the IGMP report it is about to
forward to the link is version 2, and in that case, rather than multicasting the report on
the link to the multicast MAC address derived from the IP multicast address (which is what version 2 does), unicasting
to the multicast router. I suspect this might confuse the IP multicast router, since it's receiving it unicast rather htan
what the spec says, but I also suspect that implementations might not check for this, so it might work.

My inclination is to not stand on our head for version 2, and furthermore not to bother with what I'll explain in question 3,
since I don't want supporting IP multicast to get so complicated that RBridges become prohibitive.

*********
Question 3: Should we optimize delivery of IP multicast data to only get sent to the "right" multicast router?

Not all IP multicast routers will be "interested" in data for G. I believe in "dense mode", they all will be. But in "sparse mode"
I believe only one IP multicast router needs tor receive G. Which IP multicast router should receive G is the following:
PIM has a Designated Multicast Router election (similar to IS-IS), electing DR. The default is that all groups go to DR.
However, sometimes it is discovered (through PIM sparse mode magic) that R2 should receive G, and not the DR. In
that case RBridges should deliver G to R2 and not to DR. This could be done by having R2 explicitly ask for G, just like
an endnode would.

Various potential solutions

a) RBridges send all IP mutlicasts to all IP multicast routers. Too bad if it's not completely optimized.
b) RBridges listen to the PIM election to decide which IP multicast router is the DR, 
and also listen to PIM asserts (or whatever it is that tells which IP multicast router other than DR should get G), to know
which groups to send to which IP multicast routers.
c) RBridges send G only to the DR. If an IP multicast router R2 that is not DR wants to receive G, it joins G, just like
an endnode would do, so that RBridges will deliver G to R2, in addition to sending it to DR.
d) as default, RBridges send all IP multicast traffic to all IP multicast routers, but define a message to be
sent between an IP multicast router R2 and its RBridge, that says "send me only these groups". Without receipt of
that message, the RBridges send all IP multicast traffic to R2.

I personally prefer a, since the others seem to be getting real comlicated.
b) seems way too PIM specific, and RBridges would have to change when PIM changed
c) won't work with IP multicast routers today that don't explicitly join the groups, since they wouldn't join G explicitly
d) at least has correct behavior without expecting the IP multicast routers to change. The extra message to be
defined is only an optimization beyond a).

So I prefer a) as simplest. My second choice is d).

Radia

From: "Gray, Eric" <[email-masked]>
To: =?iso-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[email-masked]>, Pierre Francois <[email-masked]>
Date: Fri, 14 Jul 2006 10:12:22 -0400
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] How to deal with RBridge-Rbridge link metrics ?
Status: RO
Content-Length: 6757

Guillermo,

	Just to be clear, having a manual configuration capability
does not prevent "zero-configuration" as long as a well understood
default exists (either a set of specific values, or something that
can be derived).

--
Eric 

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]] On Behalf Of Guillermo Ib??ez
--> Sent: Thursday, July 13, 2006 2:31 PM
--> To: Pierre Francois
--> Cc: [email-masked]; Radia Perlman
--> Subject: Re: [rbridge] How to deal with RBridge-Rbridge 
--> link metrics ?
--> 
--> It seems that choosing worst case metric would be the 
--> logical decision.
--> Manual configuration is against zero configuration 
--> objectives stated on 
--> RBridge origins.
--> Universal metric regardless bandwidth seems irrational having 10**n 
--> bandwidth range with Ethernet.
--> 
--> Pierre Francois wrote:
--> 
--> >Guillermo,
--> >
--> >Thinking top of my head there, but, in your particular 
--> case, where there
--> >is only one bridge in the middle, you could rely on what follows :
--> >
--> >RBridgeA has a link metric of x,
--> >RBridgeB has a link metric of y < x.
--> >
--> >All the RBridges detect an asymetrical link metric, 
--> consider the largest,
--> >x, as the metric for RbridgeA->RBridgeB and 
--> RbridgeB->RBridgeA so that
--> >no one will consider that the link A->B is a 1Gbps link.
--> >
--> >Once you have two bridges in the middle, I don't see how
--> >to make the metric be accurate without a manual configuration...
--> >
--> >Pierre.
--> >
--> >On Thu, 13 Jul 2006, Guillermo Ib??ez wrote:
--> >
--> >  
--> >
--> >>I did not follow the whole discussion. I apologize in advance.
--> >>A suggestion and a doubt.
--> >>For link metrics I would suggest to refer to 802.1D 
--> default link costs
--> >>for bridges. (20.000.000/Link speed in Mbps), but what happens if
--> >>between two RBridges A and B there is standard bridge and 
--> the link to
--> >>one RBridge is 100 Mbps and the link to the other is 1 Gbps?
--> >>Guillermo
--> >>
--> >>Russ White wrote:
--> >>    
--> >>
--> >>>-----BEGIN PGP SIGNED MESSAGE-----
--> >>>Hash: SHA1
--> >>>
--> >>>
--> >>>
--> >>>      
--> >>>
--> >>>>When we said "zero configuration" we weren't intending 
--> to preclude
--> >>>>configuration for tuning. So perhaps we have
--> >>>>to change the wording in the documents. VLANs almost 
--> certainly require
--> >>>>configuration, and there will always
--> >>>>be tuning.
--> >>>>
--> >>>>Should we consider setting of link metrics, and what 
--> the defaults are,
--> >>>>to be an implementation issue? I agree
--> >>>>with Pierre that it would be good, for instance, to 
--> choose defaults in
--> >>>>the base TRILL document, so that all
--> >>>>implementations use the same logical defaults.
--> >>>>        
--> >>>>
--> >>>The first question we actually need to answer is--wide metrics or
--> >>>narrow? Since IS-IS has two metric types, if we do "zero 
--> configuration,"
--> >>>we need to worry about the type of metric chosen in the 
--> default state.
--> >>>IMHO, it would be better to specify wide metrics only.
--> >>>
--> >>>
--> >>>      
--> >>>
--> >>>>Should we pick a single default for link cost for all 
--> types of links? (I
--> >>>>think not)
--> >>>>Should we pick a default value for each link type? 
--> (say, a link of this
--> >>>>speed would have this default). I think I
--> >>>>favor this, but I'd certainly prefer someone who has 
--> been working with
--> >>>>IS-IS recently decide.
--> >>>>        
--> >>>>
--> >>>I would say that if we want to go this route, some type 
--> of "x/bandwidth"
--> >>>would work, but, we must be careful on two fronts:
--> >>>
--> >>>- -- We don't really want to specify x, unless we 
--> specify it so close to
--> >>>infinity that we'll never hit a link with greater than x 
--> available
--> >>>bandwidth. There have been many points in the past when 
--> we've chosen
--> >>>what we think x should be, and we're always wrong, in a 
--> sense. In fact,
--> >>>it's hard to know what x should be, since it's not 
--> really derived from
--> >>>the maximum link bandwidth in the network, but it's 
--> rather a balance of
--> >>>the min and max link bandwidths available.
--> >>>
--> >>>- -- We want to make certain that there is a way to 
--> change x in the
--> >>>network without undue downtime (none would be preferred).
--> >>>
--> >>>The first problem is something we, the trill community, 
--> need to address.
--> >>>Perhaps we could specify a default metric of "x/bandwidth," with
--> >>>operators able to set what they want (tune), and 
--> operators also setting
--> >>>x, and the assumption that vendors may choose x for 
--> their products. The
--> >>>second problem is outside the scope of TRILL, so we can 
--> ignore it, for now.
--> >>>
--> >>>Or, another option is, as Radia says, simply make up a 
--> list. The problem
--> >>>here is that no matter how you cut it, you're 
--> essentially doing some
--> >>>form of x/bandwidth anyway, and you always run into some problems
--> >>>figuring out what x should be. (Remember, as well, that 
--> x may not be a
--> >>>single value, it may be a formula containing the 
--> bandwidth, as well).
--> >>>
--> >>>
--> >>>      
--> >>>
--> >>>>The easiest thing would be to ignore this issue and 
--> claim that the IS-IS
--> >>>>specification deals with it, but I think
--> >>>>it would be nice to suggest defaults.
--> >>>>        
--> >>>>
--> >>>It doesn't, really--in IS-IS today, you must tune if you 
--> want tuning,
--> >>>the default metric is set such that we don't fall over 
--> the maximum with
--> >>>narrow metrics in fairly large networks. I don't think 
--> that's really a
--> >>>"good idea" for TRILL, if we can avoid it, since we want 
--> this to be
--> >>>configuration less, if possible (?).
--> >>>
--> >>>:-)
--> >>>
--> >>>Russ
--> >>>
--> >>>
--> >>>-----BEGIN PGP SIGNATURE-----
--> >>>Version: GnuPG v1.4.1 (Darwin)
--> >>>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
--> >>>
--> >>>iD8DBQFEtNqsER27sUhU9OQRAkAHAKDC2ud3T7cooyQK7YMpEKd91ZuPyACaA9rR
--> >>>FhZQutTJj+LMyAB6rrSw0L8=
--> >>>=kl90
--> >>>-----END PGP SIGNATURE-----
--> >>>_______________________________________________
--> >>>rbridge mailing list
--> >>>[email-masked]
--> >>>http://mailman.postel.org/mailman/listinfo/rbridge
--> >>>
--> >>>      
--> >>>
--> >>_______________________________________________
--> >>rbridge mailing list
--> >>[email-masked]
--> >>http://mailman.postel.org/mailman/listinfo/rbridge
--> >>
--> >>    
--> >>
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://mailman.postel.org/mailman/listinfo/rbridge
--> 

From: "Gray, Eric" <[email-masked]>
To: Pierre Francois <[email-masked]>, =?iso-8859-1?Q?Guillermo_Ib=E1?= =?iso-8859-1?Q?=F1ez?= <[email-masked]>
Date: Fri, 14 Jul 2006 10:12:21 -0400
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] How to deal with RBridge-Rbridge link metrics ?
Status: RO
Content-Length: 5752

It does not appear to me that there is disagreement here.

Yes, we should use Ethernet default link costs.  
Yes, we should allow configuration of link costs.

--
Eric 

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]] On Behalf Of Pierre Francois
--> Sent: Thursday, July 13, 2006 1:41 PM
--> To: Guillermo Ib??ez
--> Cc: [email-masked]; Radia Perlman
--> Subject: Re: [rbridge] How to deal with RBridge-Rbridge 
--> link metrics ?
--> 
--> 
--> Guillermo,
--> 
--> This is a typical scenario where, imo, link metric 
--> configuration should
--> be made doable by the operator.
--> 
--> Pierre.
--> 
--> On Thu, 13 Jul 2006, Guillermo Ib??ez wrote:
--> 
--> > I did not follow the whole discussion. I apologize in advance.
--> > A suggestion and a doubt.
--> > For link metrics I would suggest to refer to 802.1D 
--> default link costs
--> > for bridges. (20.000.000/Link speed in Mbps), but what happens if
--> > between two RBridges A and B there is standard bridge and 
--> the link to
--> > one RBridge is 100 Mbps and the link to the other is 1 Gbps?
--> > Guillermo
--> >
--> > Russ White wrote:
--> > > -----BEGIN PGP SIGNED MESSAGE-----
--> > > Hash: SHA1
--> > >
--> > >
--> > >
--> > >>When we said "zero configuration" we weren't intending 
--> to preclude
--> > >>configuration for tuning. So perhaps we have
--> > >>to change the wording in the documents. VLANs almost 
--> certainly require
--> > >>configuration, and there will always
--> > >>be tuning.
--> > >>
--> > >>Should we consider setting of link metrics, and what 
--> the defaults are,
--> > >>to be an implementation issue? I agree
--> > >>with Pierre that it would be good, for instance, to 
--> choose defaults in
--> > >>the base TRILL document, so that all
--> > >>implementations use the same logical defaults.
--> > >
--> > >
--> > > The first question we actually need to answer is--wide 
--> metrics or
--> > > narrow? Since IS-IS has two metric types, if we do 
--> "zero configuration,"
--> > > we need to worry about the type of metric chosen in the 
--> default state.
--> > > IMHO, it would be better to specify wide metrics only.
--> > >
--> > >
--> > >>Should we pick a single default for link cost for all 
--> types of links? (I
--> > >>think not)
--> > >>Should we pick a default value for each link type? 
--> (say, a link of this
--> > >>speed would have this default). I think I
--> > >>favor this, but I'd certainly prefer someone who has 
--> been working with
--> > >>IS-IS recently decide.
--> > >
--> > >
--> > > I would say that if we want to go this route, some type 
--> of "x/bandwidth"
--> > > would work, but, we must be careful on two fronts:
--> > >
--> > > - -- We don't really want to specify x, unless we 
--> specify it so close to
--> > > infinity that we'll never hit a link with greater than 
--> x available
--> > > bandwidth. There have been many points in the past when 
--> we've chosen
--> > > what we think x should be, and we're always wrong, in a 
--> sense. In fact,
--> > > it's hard to know what x should be, since it's not 
--> really derived from
--> > > the maximum link bandwidth in the network, but it's 
--> rather a balance of
--> > > the min and max link bandwidths available.
--> > >
--> > > - -- We want to make certain that there is a way to 
--> change x in the
--> > > network without undue downtime (none would be preferred).
--> > >
--> > > The first problem is something we, the trill community, 
--> need to address.
--> > > Perhaps we could specify a default metric of "x/bandwidth," with
--> > > operators able to set what they want (tune), and 
--> operators also setting
--> > > x, and the assumption that vendors may choose x for 
--> their products. The
--> > > second problem is outside the scope of TRILL, so we can 
--> ignore it, for now.
--> > >
--> > > Or, another option is, as Radia says, simply make up a 
--> list. The problem
--> > > here is that no matter how you cut it, you're 
--> essentially doing some
--> > > form of x/bandwidth anyway, and you always run into 
--> some problems
--> > > figuring out what x should be. (Remember, as well, that 
--> x may not be a
--> > > single value, it may be a formula containing the 
--> bandwidth, as well).
--> > >
--> > >
--> > >>The easiest thing would be to ignore this issue and 
--> claim that the IS-IS
--> > >>specification deals with it, but I think
--> > >>it would be nice to suggest defaults.
--> > >
--> > >
--> > > It doesn't, really--in IS-IS today, you must tune if 
--> you want tuning,
--> > > the default metric is set such that we don't fall over 
--> the maximum with
--> > > narrow metrics in fairly large networks. I don't think 
--> that's really a
--> > > "good idea" for TRILL, if we can avoid it, since we 
--> want this to be
--> > > configuration less, if possible (?).
--> > >
--> > > :-)
--> > >
--> > > Russ
--> > >
--> > >
--> > > -----BEGIN PGP SIGNATURE-----
--> > > Version: GnuPG v1.4.1 (Darwin)
--> > > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
--> > >
--> > > iD8DBQFEtNqsER27sUhU9OQRAkAHAKDC2ud3T7cooyQK7YMpEKd91ZuPyACaA9rR
--> > > FhZQutTJj+LMyAB6rrSw0L8=
--> > > =kl90
--> > > -----END PGP SIGNATURE-----
--> > > _______________________________________________
--> > > rbridge mailing list
--> > > [email-masked]
--> > > http://mailman.postel.org/mailman/listinfo/rbridge
--> > >
--> > _______________________________________________
--> > rbridge mailing list
--> > [email-masked]
--> > http://mailman.postel.org/mailman/listinfo/rbridge
--> >
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://mailman.postel.org/mailman/listinfo/rbridge
--> 

Date: Fri, 14 Jul 2006 07:35:07 +0200
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[email-masked]>
To: Caitlin Bestler <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] How to deal with RBridge-Rbridge link metrics ?
Status: RO
Content-Length: 1237

Caitlin,
        My understanding for manual configuration consist in that costs 
are configured my management. Once a cost is configured, defaul cost 
(zero configuration cost) is overriden. Zero configuration does not 
react to cost changes. Only the protocol will react to cost changes if 
shortest paths are different.
Guillermo

Caitlin Bestler wrote:

>[email-masked] wrote:
>  
>
>>Guillermo,
>>
>>Thinking top of my head there, but, in your particular case,
>>where there is only one bridge in the middle, you could rely on what
>>follows : 
>>
>>RBridgeA has a link metric of x,
>>RBridgeB has a link metric of y < x.
>>
>>All the RBridges detect an asymetrical link metric, consider
>>the largest, x, as the metric for RbridgeA->RBridgeB and
>>RbridgeB->RBridgeA so that no one will consider that the link A->B is
>>a 1Gbps link. 
>>
>>Once you have two bridges in the middle, I don't see how to
>>make the metric be accurate without a manual configuration...
>>
>>    
>>
>
>I think the more relevant question is how to support manual
>configuration *and* zero-configuration. More precisely, how 
>do you know that a given manual configuration is still relevant
>after zero-configuration detects a change?
>
>  
>

Content-class: urn:content-classes:message
Date: Thu, 13 Jul 2006 12:49:48 -0700
From: "Caitlin Bestler" <[email-masked]>
To: "Pierre Francois" <[email-masked]>, "=?iso-8859-1?Q?Guillermo_Ib=E1=F1ez?=" <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] How to deal with RBridge-Rbridge link metrics ?
Status: RO
Content-Length: 850

[email-masked] wrote:
> Guillermo,
> 
> Thinking top of my head there, but, in your particular case,
> where there is only one bridge in the middle, you could rely on what
> follows : 
> 
> RBridgeA has a link metric of x,
> RBridgeB has a link metric of y < x.
> 
> All the RBridges detect an asymetrical link metric, consider
> the largest, x, as the metric for RbridgeA->RBridgeB and
> RbridgeB->RBridgeA so that no one will consider that the link A->B is
> a 1Gbps link. 
> 
> Once you have two bridges in the middle, I don't see how to
> make the metric be accurate without a manual configuration...
> 

I think the more relevant question is how to support manual
configuration *and* zero-configuration. More precisely, how 
do you know that a given manual configuration is still relevant
after zero-configuration detects a change?

Date: Thu, 13 Jul 2006 20:39:11 +0200 (CEST)
From: Pierre Francois <[email-masked]>
To: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] How to deal with RBridge-Rbridge link metrics ?
Status: RO
Content-Length: 5690

Guillermo,

As far as I understand, RBridges MUST work with zero-configuration. Now, I
don't see why we should make it non-tunable.

Pierre.

On Thu, 13 Jul 2006, Guillermo Ib??ez wrote:

> It seems that choosing worst case metric would be the logical decision.
> Manual configuration is against zero configuration objectives stated on
> RBridge origins.
> Universal metric regardless bandwidth seems irrational having 10**n
> bandwidth range with Ethernet.
>
> Pierre Francois wrote:
>
> >Guillermo,
> >
> >Thinking top of my head there, but, in your particular case, where there
> >is only one bridge in the middle, you could rely on what follows :
> >
> >RBridgeA has a link metric of x,
> >RBridgeB has a link metric of y < x.
> >
> >All the RBridges detect an asymetrical link metric, consider the largest,
> >x, as the metric for RbridgeA->RBridgeB and RbridgeB->RBridgeA so that
> >no one will consider that the link A->B is a 1Gbps link.
> >
> >Once you have two bridges in the middle, I don't see how
> >to make the metric be accurate without a manual configuration...
> >
> >Pierre.
> >
> >On Thu, 13 Jul 2006, Guillermo Ib??ez wrote:
> >
> >
> >
> >>I did not follow the whole discussion. I apologize in advance.
> >>A suggestion and a doubt.
> >>For link metrics I would suggest to refer to 802.1D default link costs
> >>for bridges. (20.000.000/Link speed in Mbps), but what happens if
> >>between two RBridges A and B there is standard bridge and the link to
> >>one RBridge is 100 Mbps and the link to the other is 1 Gbps?
> >>Guillermo
> >>
> >>Russ White wrote:
> >>
> >>
> >>>-----BEGIN PGP SIGNED MESSAGE-----
> >>>Hash: SHA1
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>>When we said "zero configuration" we weren't intending to preclude
> >>>>configuration for tuning. So perhaps we have
> >>>>to change the wording in the documents. VLANs almost certainly require
> >>>>configuration, and there will always
> >>>>be tuning.
> >>>>
> >>>>Should we consider setting of link metrics, and what the defaults are,
> >>>>to be an implementation issue? I agree
> >>>>with Pierre that it would be good, for instance, to choose defaults in
> >>>>the base TRILL document, so that all
> >>>>implementations use the same logical defaults.
> >>>>
> >>>>
> >>>The first question we actually need to answer is--wide metrics or
> >>>narrow? Since IS-IS has two metric types, if we do "zero configuration,"
> >>>we need to worry about the type of metric chosen in the default state.
> >>>IMHO, it would be better to specify wide metrics only.
> >>>
> >>>
> >>>
> >>>
> >>>>Should we pick a single default for link cost for all types of links? (I
> >>>>think not)
> >>>>Should we pick a default value for each link type? (say, a link of this
> >>>>speed would have this default). I think I
> >>>>favor this, but I'd certainly prefer someone who has been working with
> >>>>IS-IS recently decide.
> >>>>
> >>>>
> >>>I would say that if we want to go this route, some type of "x/bandwidth"
> >>>would work, but, we must be careful on two fronts:
> >>>
> >>>- -- We don't really want to specify x, unless we specify it so close to
> >>>infinity that we'll never hit a link with greater than x available
> >>>bandwidth. There have been many points in the past when we've chosen
> >>>what we think x should be, and we're always wrong, in a sense. In fact,
> >>>it's hard to know what x should be, since it's not really derived from
> >>>the maximum link bandwidth in the network, but it's rather a balance of
> >>>the min and max link bandwidths available.
> >>>
> >>>- -- We want to make certain that there is a way to change x in the
> >>>network without undue downtime (none would be preferred).
> >>>
> >>>The first problem is something we, the trill community, need to address.
> >>>Perhaps we could specify a default metric of "x/bandwidth," with
> >>>operators able to set what they want (tune), and operators also setting
> >>>x, and the assumption that vendors may choose x for their products. The
> >>>second problem is outside the scope of TRILL, so we can ignore it, for now.
> >>>
> >>>Or, another option is, as Radia says, simply make up a list. The problem
> >>>here is that no matter how you cut it, you're essentially doing some
> >>>form of x/bandwidth anyway, and you always run into some problems
> >>>figuring out what x should be. (Remember, as well, that x may not be a
> >>>single value, it may be a formula containing the bandwidth, as well).
> >>>
> >>>
> >>>
> >>>
> >>>>The easiest thing would be to ignore this issue and claim that the IS-IS
> >>>>specification deals with it, but I think
> >>>>it would be nice to suggest defaults.
> >>>>
> >>>>
> >>>It doesn't, really--in IS-IS today, you must tune if you want tuning,
> >>>the default metric is set such that we don't fall over the maximum with
> >>>narrow metrics in fairly large networks. I don't think that's really a
> >>>"good idea" for TRILL, if we can avoid it, since we want this to be
> >>>configuration less, if possible (?).
> >>>
> >>>:-)
> >>>
> >>>Russ
> >>>
> >>>
> >>>-----BEGIN PGP SIGNATURE-----
> >>>Version: GnuPG v1.4.1 (Darwin)
> >>>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> >>>
> >>>iD8DBQFEtNqsER27sUhU9OQRAkAHAKDC2ud3T7cooyQK7YMpEKd91ZuPyACaA9rR
> >>>FhZQutTJj+LMyAB6rrSw0L8=
> >>>=kl90
> >>>-----END PGP SIGNATURE-----
> >>>_______________________________________________
> >>>rbridge mailing list
> >>>[email-masked]
> >>>http://mailman.postel.org/mailman/listinfo/rbridge
> >>>
> >>>
> >>>
> >>_______________________________________________
> >>rbridge mailing list
> >>[email-masked]
> >>http://mailman.postel.org/mailman/listinfo/rbridge
> >>
> >>
> >>
>

Date: Thu, 13 Jul 2006 20:31:23 +0200
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[email-masked]>
To: Pierre Francois <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] How to deal with RBridge-Rbridge link metrics ?
Status: RO
Content-Length: 5274

It seems that choosing worst case metric would be the logical decision.
Manual configuration is against zero configuration objectives stated on 
RBridge origins.
Universal metric regardless bandwidth seems irrational having 10**n 
bandwidth range with Ethernet.

Pierre Francois wrote:

>Guillermo,
>
>Thinking top of my head there, but, in your particular case, where there
>is only one bridge in the middle, you could rely on what follows :
>
>RBridgeA has a link metric of x,
>RBridgeB has a link metric of y < x.
>
>All the RBridges detect an asymetrical link metric, consider the largest,
>x, as the metric for RbridgeA->RBridgeB and RbridgeB->RBridgeA so that
>no one will consider that the link A->B is a 1Gbps link.
>
>Once you have two bridges in the middle, I don't see how
>to make the metric be accurate without a manual configuration...
>
>Pierre.
>
>On Thu, 13 Jul 2006, Guillermo Ib??ez wrote:
>
>  
>
>>I did not follow the whole discussion. I apologize in advance.
>>A suggestion and a doubt.
>>For link metrics I would suggest to refer to 802.1D default link costs
>>for bridges. (20.000.000/Link speed in Mbps), but what happens if
>>between two RBridges A and B there is standard bridge and the link to
>>one RBridge is 100 Mbps and the link to the other is 1 Gbps?
>>Guillermo
>>
>>Russ White wrote:
>>    
>>
>>>-----BEGIN PGP SIGNED MESSAGE-----
>>>Hash: SHA1
>>>
>>>
>>>
>>>      
>>>
>>>>When we said "zero configuration" we weren't intending to preclude
>>>>configuration for tuning. So perhaps we have
>>>>to change the wording in the documents. VLANs almost certainly require
>>>>configuration, and there will always
>>>>be tuning.
>>>>
>>>>Should we consider setting of link metrics, and what the defaults are,
>>>>to be an implementation issue? I agree
>>>>with Pierre that it would be good, for instance, to choose defaults in
>>>>the base TRILL document, so that all
>>>>implementations use the same logical defaults.
>>>>        
>>>>
>>>The first question we actually need to answer is--wide metrics or
>>>narrow? Since IS-IS has two metric types, if we do "zero configuration,"
>>>we need to worry about the type of metric chosen in the default state.
>>>IMHO, it would be better to specify wide metrics only.
>>>
>>>
>>>      
>>>
>>>>Should we pick a single default for link cost for all types of links? (I
>>>>think not)
>>>>Should we pick a default value for each link type? (say, a link of this
>>>>speed would have this default). I think I
>>>>favor this, but I'd certainly prefer someone who has been working with
>>>>IS-IS recently decide.
>>>>        
>>>>
>>>I would say that if we want to go this route, some type of "x/bandwidth"
>>>would work, but, we must be careful on two fronts:
>>>
>>>- -- We don't really want to specify x, unless we specify it so close to
>>>infinity that we'll never hit a link with greater than x available
>>>bandwidth. There have been many points in the past when we've chosen
>>>what we think x should be, and we're always wrong, in a sense. In fact,
>>>it's hard to know what x should be, since it's not really derived from
>>>the maximum link bandwidth in the network, but it's rather a balance of
>>>the min and max link bandwidths available.
>>>
>>>- -- We want to make certain that there is a way to change x in the
>>>network without undue downtime (none would be preferred).
>>>
>>>The first problem is something we, the trill community, need to address.
>>>Perhaps we could specify a default metric of "x/bandwidth," with
>>>operators able to set what they want (tune), and operators also setting
>>>x, and the assumption that vendors may choose x for their products. The
>>>second problem is outside the scope of TRILL, so we can ignore it, for now.
>>>
>>>Or, another option is, as Radia says, simply make up a list. The problem
>>>here is that no matter how you cut it, you're essentially doing some
>>>form of x/bandwidth anyway, and you always run into some problems
>>>figuring out what x should be. (Remember, as well, that x may not be a
>>>single value, it may be a formula containing the bandwidth, as well).
>>>
>>>
>>>      
>>>
>>>>The easiest thing would be to ignore this issue and claim that the IS-IS
>>>>specification deals with it, but I think
>>>>it would be nice to suggest defaults.
>>>>        
>>>>
>>>It doesn't, really--in IS-IS today, you must tune if you want tuning,
>>>the default metric is set such that we don't fall over the maximum with
>>>narrow metrics in fairly large networks. I don't think that's really a
>>>"good idea" for TRILL, if we can avoid it, since we want this to be
>>>configuration less, if possible (?).
>>>
>>>:-)
>>>
>>>Russ
>>>
>>>
>>>-----BEGIN PGP SIGNATURE-----
>>>Version: GnuPG v1.4.1 (Darwin)
>>>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>>>
>>>iD8DBQFEtNqsER27sUhU9OQRAkAHAKDC2ud3T7cooyQK7YMpEKd91ZuPyACaA9rR
>>>FhZQutTJj+LMyAB6rrSw0L8=
>>>=kl90
>>>-----END PGP SIGNATURE-----
>>>_______________________________________________
>>>rbridge mailing list
>>>[email-masked]
>>>http://mailman.postel.org/mailman/listinfo/rbridge
>>>
>>>      
>>>
>>_______________________________________________
>>rbridge mailing list
>>[email-masked]
>>http://mailman.postel.org/mailman/listinfo/rbridge
>>
>>    
>>

Date: Thu, 13 Jul 2006 20:29:36 +0200 (CEST)
From: Pierre Francois <[email-masked]>
To: Radia Perlman <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] How to deal with RBridge-Rbridge link metrics ?
Status: RO
Content-Length: 987

Radia,

On Thu, 13 Jul 2006, Radia Perlman wrote:

> I don't think it's a problem to have two RBridges, R1, and R2, have
> different costs for
> the two directions of the R1-R2 link.

I agree it's not a problem, in general, to have asym. link metrics.
However, in our case here, we give a link A->B a default metric
for a 1Gbps link, although a "part a the link" is a 100Mbps one.

> I think what we're all agreeing on is that link costs should be tunable,
> but that there should be
> reasonable defaults.

Agreed, but if we say we refer to 802.1D defaults, we must remember that
it will not always match the link speed in TRILL, as illustrated
by Guillermo's case.

Pierre.

> Then the question is, should we specify the defaults for different types
> of links, and if so, in
> which document?
>
> One potential answer to "which document" is "not in TRILL", since we
> might be able to assume
> that any metrics used by IS-IS for layer 3 will work just fine for layer
> 2 TRILL.

Date: Thu, 13 Jul 2006 19:57:08 +0200 (CEST)
From: Pierre Francois <[email-masked]>
To: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] How to deal with RBridge-Rbridge link metrics ?
Status: RO
Content-Length: 4900

Guillermo,

Thinking top of my head there, but, in your particular case, where there
is only one bridge in the middle, you could rely on what follows :

RBridgeA has a link metric of x,
RBridgeB has a link metric of y < x.

All the RBridges detect an asymetrical link metric, consider the largest,
x, as the metric for RbridgeA->RBridgeB and RbridgeB->RBridgeA so that
no one will consider that the link A->B is a 1Gbps link.

Once you have two bridges in the middle, I don't see how
to make the metric be accurate without a manual configuration...

Pierre.

On Thu, 13 Jul 2006, Guillermo Ib??ez wrote:

> I did not follow the whole discussion. I apologize in advance.
> A suggestion and a doubt.
> For link metrics I would suggest to refer to 802.1D default link costs
> for bridges. (20.000.000/Link speed in Mbps), but what happens if
> between two RBridges A and B there is standard bridge and the link to
> one RBridge is 100 Mbps and the link to the other is 1 Gbps?
> Guillermo
>
> Russ White wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> >
> >
> >>When we said "zero configuration" we weren't intending to preclude
> >>configuration for tuning. So perhaps we have
> >>to change the wording in the documents. VLANs almost certainly require
> >>configuration, and there will always
> >>be tuning.
> >>
> >>Should we consider setting of link metrics, and what the defaults are,
> >>to be an implementation issue? I agree
> >>with Pierre that it would be good, for instance, to choose defaults in
> >>the base TRILL document, so that all
> >>implementations use the same logical defaults.
> >
> >
> > The first question we actually need to answer is--wide metrics or
> > narrow? Since IS-IS has two metric types, if we do "zero configuration,"
> > we need to worry about the type of metric chosen in the default state.
> > IMHO, it would be better to specify wide metrics only.
> >
> >
> >>Should we pick a single default for link cost for all types of links? (I
> >>think not)
> >>Should we pick a default value for each link type? (say, a link of this
> >>speed would have this default). I think I
> >>favor this, but I'd certainly prefer someone who has been working with
> >>IS-IS recently decide.
> >
> >
> > I would say that if we want to go this route, some type of "x/bandwidth"
> > would work, but, we must be careful on two fronts:
> >
> > - -- We don't really want to specify x, unless we specify it so close to
> > infinity that we'll never hit a link with greater than x available
> > bandwidth. There have been many points in the past when we've chosen
> > what we think x should be, and we're always wrong, in a sense. In fact,
> > it's hard to know what x should be, since it's not really derived from
> > the maximum link bandwidth in the network, but it's rather a balance of
> > the min and max link bandwidths available.
> >
> > - -- We want to make certain that there is a way to change x in the
> > network without undue downtime (none would be preferred).
> >
> > The first problem is something we, the trill community, need to address.
> > Perhaps we could specify a default metric of "x/bandwidth," with
> > operators able to set what they want (tune), and operators also setting
> > x, and the assumption that vendors may choose x for their products. The
> > second problem is outside the scope of TRILL, so we can ignore it, for now.
> >
> > Or, another option is, as Radia says, simply make up a list. The problem
> > here is that no matter how you cut it, you're essentially doing some
> > form of x/bandwidth anyway, and you always run into some problems
> > figuring out what x should be. (Remember, as well, that x may not be a
> > single value, it may be a formula containing the bandwidth, as well).
> >
> >
> >>The easiest thing would be to ignore this issue and claim that the IS-IS
> >>specification deals with it, but I think
> >>it would be nice to suggest defaults.
> >
> >
> > It doesn't, really--in IS-IS today, you must tune if you want tuning,
> > the default metric is set such that we don't fall over the maximum with
> > narrow metrics in fairly large networks. I don't think that's really a
> > "good idea" for TRILL, if we can avoid it, since we want this to be
> > configuration less, if possible (?).
> >
> > :-)
> >
> > Russ
> >
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.1 (Darwin)
> > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> >
> > iD8DBQFEtNqsER27sUhU9OQRAkAHAKDC2ud3T7cooyQK7YMpEKd91ZuPyACaA9rR
> > FhZQutTJj+LMyAB6rrSw0L8=
> > =kl90
> > -----END PGP SIGNATURE-----
> > _______________________________________________
> > rbridge mailing list
> > [email-masked]
> > http://mailman.postel.org/mailman/listinfo/rbridge
> >
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge
>

Date: Thu, 13 Jul 2006 19:41:06 +0200 (CEST)
From: Pierre Francois <[email-masked]>
To: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] How to deal with RBridge-Rbridge link metrics ?
Status: RO
Content-Length: 4467

Guillermo,

This is a typical scenario where, imo, link metric configuration should
be made doable by the operator.

Pierre.

On Thu, 13 Jul 2006, Guillermo Ib??ez wrote:

> I did not follow the whole discussion. I apologize in advance.
> A suggestion and a doubt.
> For link metrics I would suggest to refer to 802.1D default link costs
> for bridges. (20.000.000/Link speed in Mbps), but what happens if
> between two RBridges A and B there is standard bridge and the link to
> one RBridge is 100 Mbps and the link to the other is 1 Gbps?
> Guillermo
>
> Russ White wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> >
> >
> >>When we said "zero configuration" we weren't intending to preclude
> >>configuration for tuning. So perhaps we have
> >>to change the wording in the documents. VLANs almost certainly require
> >>configuration, and there will always
> >>be tuning.
> >>
> >>Should we consider setting of link metrics, and what the defaults are,
> >>to be an implementation issue? I agree
> >>with Pierre that it would be good, for instance, to choose defaults in
> >>the base TRILL document, so that all
> >>implementations use the same logical defaults.
> >
> >
> > The first question we actually need to answer is--wide metrics or
> > narrow? Since IS-IS has two metric types, if we do "zero configuration,"
> > we need to worry about the type of metric chosen in the default state.
> > IMHO, it would be better to specify wide metrics only.
> >
> >
> >>Should we pick a single default for link cost for all types of links? (I
> >>think not)
> >>Should we pick a default value for each link type? (say, a link of this
> >>speed would have this default). I think I
> >>favor this, but I'd certainly prefer someone who has been working with
> >>IS-IS recently decide.
> >
> >
> > I would say that if we want to go this route, some type of "x/bandwidth"
> > would work, but, we must be careful on two fronts:
> >
> > - -- We don't really want to specify x, unless we specify it so close to
> > infinity that we'll never hit a link with greater than x available
> > bandwidth. There have been many points in the past when we've chosen
> > what we think x should be, and we're always wrong, in a sense. In fact,
> > it's hard to know what x should be, since it's not really derived from
> > the maximum link bandwidth in the network, but it's rather a balance of
> > the min and max link bandwidths available.
> >
> > - -- We want to make certain that there is a way to change x in the
> > network without undue downtime (none would be preferred).
> >
> > The first problem is something we, the trill community, need to address.
> > Perhaps we could specify a default metric of "x/bandwidth," with
> > operators able to set what they want (tune), and operators also setting
> > x, and the assumption that vendors may choose x for their products. The
> > second problem is outside the scope of TRILL, so we can ignore it, for now.
> >
> > Or, another option is, as Radia says, simply make up a list. The problem
> > here is that no matter how you cut it, you're essentially doing some
> > form of x/bandwidth anyway, and you always run into some problems
> > figuring out what x should be. (Remember, as well, that x may not be a
> > single value, it may be a formula containing the bandwidth, as well).
> >
> >
> >>The easiest thing would be to ignore this issue and claim that the IS-IS
> >>specification deals with it, but I think
> >>it would be nice to suggest defaults.
> >
> >
> > It doesn't, really--in IS-IS today, you must tune if you want tuning,
> > the default metric is set such that we don't fall over the maximum with
> > narrow metrics in fairly large networks. I don't think that's really a
> > "good idea" for TRILL, if we can avoid it, since we want this to be
> > configuration less, if possible (?).
> >
> > :-)
> >
> > Russ
> >
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.1 (Darwin)
> > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> >
> > iD8DBQFEtNqsER27sUhU9OQRAkAHAKDC2ud3T7cooyQK7YMpEKd91ZuPyACaA9rR
> > FhZQutTJj+LMyAB6rrSw0L8=
> > =kl90
> > -----END PGP SIGNATURE-----
> > _______________________________________________
> > rbridge mailing list
> > [email-masked]
> > http://mailman.postel.org/mailman/listinfo/rbridge
> >
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge
>

Date: Thu, 13 Jul 2006 19:25:11 +0200
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[email-masked]>
To: Russ White <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] How to deal with RBridge-Rbridge link metrics ?
Status: RO
Content-Length: 3986

I did not follow the whole discussion. I apologize in advance.
A suggestion and a doubt.
For link metrics I would suggest to refer to 802.1D default link costs 
for bridges. (20.000.000/Link speed in Mbps), but what happens if 
between two RBridges A and B there is standard bridge and the link to 
one RBridge is 100 Mbps and the link to the other is 1 Gbps?
Guillermo

Russ White wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> 
>>When we said "zero configuration" we weren't intending to preclude 
>>configuration for tuning. So perhaps we have
>>to change the wording in the documents. VLANs almost certainly require 
>>configuration, and there will always
>>be tuning.
>>
>>Should we consider setting of link metrics, and what the defaults are, 
>>to be an implementation issue? I agree
>>with Pierre that it would be good, for instance, to choose defaults in 
>>the base TRILL document, so that all
>>implementations use the same logical defaults.
> 
> 
> The first question we actually need to answer is--wide metrics or
> narrow? Since IS-IS has two metric types, if we do "zero configuration,"
> we need to worry about the type of metric chosen in the default state.
> IMHO, it would be better to specify wide metrics only.
> 
> 
>>Should we pick a single default for link cost for all types of links? (I 
>>think not)
>>Should we pick a default value for each link type? (say, a link of this 
>>speed would have this default). I think I
>>favor this, but I'd certainly prefer someone who has been working with 
>>IS-IS recently decide.
> 
> 
> I would say that if we want to go this route, some type of "x/bandwidth"
> would work, but, we must be careful on two fronts:
> 
> - -- We don't really want to specify x, unless we specify it so close to
> infinity that we'll never hit a link with greater than x available
> bandwidth. There have been many points in the past when we've chosen
> what we think x should be, and we're always wrong, in a sense. In fact,
> it's hard to know what x should be, since it's not really derived from
> the maximum link bandwidth in the network, but it's rather a balance of
> the min and max link bandwidths available.
> 
> - -- We want to make certain that there is a way to change x in the
> network without undue downtime (none would be preferred).
> 
> The first problem is something we, the trill community, need to address.
> Perhaps we could specify a default metric of "x/bandwidth," with
> operators able to set what they want (tune), and operators also setting
> x, and the assumption that vendors may choose x for their products. The
> second problem is outside the scope of TRILL, so we can ignore it, for now.
> 
> Or, another option is, as Radia says, simply make up a list. The problem
> here is that no matter how you cut it, you're essentially doing some
> form of x/bandwidth anyway, and you always run into some problems
> figuring out what x should be. (Remember, as well, that x may not be a
> single value, it may be a formula containing the bandwidth, as well).
> 
> 
>>The easiest thing would be to ignore this issue and claim that the IS-IS 
>>specification deals with it, but I think
>>it would be nice to suggest defaults.
> 
> 
> It doesn't, really--in IS-IS today, you must tune if you want tuning,
> the default metric is set such that we don't fall over the maximum with
> narrow metrics in fairly large networks. I don't think that's really a
> "good idea" for TRILL, if we can avoid it, since we want this to be
> configuration less, if possible (?).
> 
> :-)
> 
> Russ
> 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iD8DBQFEtNqsER27sUhU9OQRAkAHAKDC2ud3T7cooyQK7YMpEKd91ZuPyACaA9rR
> FhZQutTJj+LMyAB6rrSw0L8=
> =kl90
> -----END PGP SIGNATURE-----
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 

Date: Wed, 12 Jul 2006 07:19:08 -0400
From: Russ White <[email-masked]>
To: Radia Perlman <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] How to deal with RBridge-Rbridge link metrics ?
Status: RO
Content-Length: 3315

> When we said "zero configuration" we weren't intending to preclude 
> configuration for tuning. So perhaps we have
> to change the wording in the documents. VLANs almost certainly require 
> configuration, and there will always
> be tuning.
> 
> Should we consider setting of link metrics, and what the defaults are, 
> to be an implementation issue? I agree
> with Pierre that it would be good, for instance, to choose defaults in 
> the base TRILL document, so that all
> implementations use the same logical defaults.

The first question we actually need to answer is--wide metrics or
narrow? Since IS-IS has two metric types, if we do "zero configuration,"
we need to worry about the type of metric chosen in the default state.
IMHO, it would be better to specify wide metrics only.

> Should we pick a single default for link cost for all types of links? (I 
> think not)
> Should we pick a default value for each link type? (say, a link of this 
> speed would have this default). I think I
> favor this, but I'd certainly prefer someone who has been working with 
> IS-IS recently decide.

I would say that if we want to go this route, some type of "x/bandwidth"
would work, but, we must be careful on two fronts:

- -- We don't really want to specify x, unless we specify it so close to
infinity that we'll never hit a link with greater than x available
bandwidth. There have been many points in the past when we've chosen
what we think x should be, and we're always wrong, in a sense. In fact,
it's hard to know what x should be, since it's not really derived from
the maximum link bandwidth in the network, but it's rather a balance of
the min and max link bandwidths available.

- -- We want to make certain that there is a way to change x in the
network without undue downtime (none would be preferred).

The first problem is something we, the trill community, need to address.
Perhaps we could specify a default metric of "x/bandwidth," with
operators able to set what they want (tune), and operators also setting
x, and the assumption that vendors may choose x for their products. The
second problem is outside the scope of TRILL, so we can ignore it, for now.

Or, another option is, as Radia says, simply make up a list. The problem
here is that no matter how you cut it, you're essentially doing some
form of x/bandwidth anyway, and you always run into some problems
figuring out what x should be. (Remember, as well, that x may not be a
single value, it may be a formula containing the bandwidth, as well).

> The easiest thing would be to ignore this issue and claim that the IS-IS 
> specification deals with it, but I think
> it would be nice to suggest defaults.

It doesn't, really--in IS-IS today, you must tune if you want tuning,
the default metric is set such that we don't fall over the maximum with
narrow metrics in fairly large networks. I don't think that's really a
"good idea" for TRILL, if we can avoid it, since we want this to be
configuration less, if possible (?).

:-)

Russ

From: "Saikat Ray" <[email-masked]>
To: "'Sanjay Sane \(sanjays\)'" <[email-masked]>, <[email-masked]>
Date: Tue, 11 Jul 2006 21:35:33 -0400
Organization: University of Pennsylvania
Subject: Re: [rbridge] Core Rbridge instance PDU packet encapsulation
Reply-To: [email-masked]
Status: RO
Content-Length: 1597

This was discussed before and, if I remember right, the conclusion was that
it is a VLAN configuration issue: i.e., it is assumed that VLANs are
configured correctly on all bridges so that there is no weird/unexpected
behavior.

The issue you pointed out actually holds for any encapsulated packet: what
VLAN ID should the outer headers use ...

________________________________________
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Sanjay Sane (sanjays)
Sent: Tuesday, July 11, 2006 9:22 PM
To: [email-masked]
Subject: [rbridge] Core Rbridge instance PDU packet encapsulation

Hi,
?
It seems PDUs of core Rbridge instance are supposed to go without VLAN Tag,
i.e. no .1Q tag. typically, when a classical bridge gets an untagged packet
(either on an access port or trunk port), it treats the packet as if its
coming on the default port-vlan. It will forward the packet only within that
vlan. 
?
Consider the the case where 2 Rbridges are connected through a classical
bridge. Lets say the 2 ports of this classical bridge, on which the 2
Rbridges are connected, are configured as trunk ports. Both these ports also
have a default port-vlan. 
Now,?untagged packets coming from one Rbridge will reach the other Rbridge
*only* if the default port-vlans are the same. 
?
If the 2 Rbridges were connected through a network of classical bridges
(instead of a single classical bridge), are we relying on the assumption
that default port-vlans are the same. Why not use a VLAN tag (.1Q) for the
PDU packets of the core Rbridge instance as well ? 
?
Thanks.
Sanjay

Content-class: urn:content-classes:message
Date: Tue, 11 Jul 2006 18:22:11 -0700
From: "Sanjay Sane \(sanjays\)" <[email-masked]>
To: <[email-masked]>
Subject: [rbridge] Core Rbridge instance PDU packet encapsulation
Status: RO
Content-Length: 3781

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6A551.99E446B1
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,
=20
It seems PDUs of core Rbridge instance are supposed to go without VLAN
Tag, i.e. no .1Q tag. typically, when a classical bridge gets an
untagged packet (either on an access port or trunk port), it treats the
packet as if its coming on the default port-vlan. It will forward the
packet only within that vlan.=20
=20
Consider the the case where 2 Rbridges are connected through a classical
bridge. Lets say the 2 ports of this classical bridge, on which the 2
Rbridges are connected, are configured as trunk ports. Both these ports
also have a default port-vlan.=20
Now, untagged packets coming from one Rbridge will reach the other
Rbridge *only* if the default port-vlans are the same.=20
=20
If the 2 Rbridges were connected through a network of classical bridges
(instead of a single classical bridge), are we relying on the assumption
that default port-vlans are the same. Why not use a VLAN tag (.1Q) for
the PDU packets of the core Rbridge instance as well ?=20
=20
Thanks.
Sanjay

------_=_NextPart_001_01C6A551.99E446B1
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1543" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D849373720-11072006><FONT face=3DArial=20
size=3D2>Hi,</FONT></SPAN></DIV>
<DIV><SPAN class=3D849373720-11072006><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D849373720-11072006><FONT face=3DArial size=3D2>It =
seems PDUs of=20
core Rbridge instance are supposed to go without VLAN Tag, i.e. no .1Q =
tag.=20
typically, when a classical bridge gets an untagged packet (either on an =
access=20
port or trunk port), it treats the packet as if its coming on the =
default=20
port-vlan. It will forward the packet only within that vlan.=20
</FONT></SPAN></DIV>
<DIV><SPAN class=3D849373720-11072006><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D849373720-11072006><FONT face=3DArial =
size=3D2>Consider the the=20
case where 2 Rbridges are connected through a classical bridge. Lets say =

t</FONT></SPAN><SPAN class=3D849373720-11072006><FONT face=3DArial =
size=3D2>he 2 ports=20
of this classical bridge, on which the 2 Rbridges are connected, are =
configured=20
as trunk ports. Both these ports also have a default port-vlan.=20
</FONT></SPAN></DIV>
<DIV><SPAN class=3D849373720-11072006><FONT face=3DArial=20
size=3D2>Now,&nbsp;</FONT></SPAN><SPAN class=3D849373720-11072006><FONT =
face=3DArial=20
size=3D2>untagged packets coming from one Rbridge will reach the other =
Rbridge=20
*only* if the default port-vlans are the same. </FONT></SPAN></DIV>
<DIV><SPAN class=3D849373720-11072006><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D849373720-11072006><FONT face=3DArial size=3D2>If the =
2 Rbridges=20
were connected through a network of classical bridges (instead of a =
single=20
classical bridge), are we relying on the assumption that default =
port-vlans are=20
the same. Why not use a VLAN tag (.1Q) for the PDU packets of the core =
Rbridge=20
instance as well ? </FONT></SPAN></DIV>
<DIV><SPAN class=3D849373720-11072006><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D849373720-11072006><FONT face=3DArial=20
size=3D2>Thanks.</FONT></SPAN></DIV>
<DIV><SPAN class=3D849373720-11072006><FONT face=3DArial=20
size=3D2>Sanjay</FONT></SPAN></DIV></BODY></HTML>

------_=_NextPart_001_01C6A551.99E446B1--

From: "Gray, Eric" <[email-masked]>
To: Radia Perlman <[email-masked]>, Eastlake III Donald-LDE008 <[email-masked]>
Date: Tue, 11 Jul 2006 17:29:41 -0400
Cc: [email-masked], Yang Yang <[email-masked]>
Subject: Re: [rbridge] Some comments on RBridge
Status: RO
Content-Length: 6008

Radia,

	Some comments in line below...

--
Eric

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]] On Behalf Of Radia Perlman
--> Sent: Tuesday, July 11, 2006 10:16 AM
--> To: Eastlake III Donald-LDE008
--> Cc: [email-masked]; Yang Yang
--> Subject: Re: [rbridge] Some comments on RBridge
--> 
--> It seemed like at the meeting some people were saying if we don't use 
--> the same Ethertype to specify "MPLSencoding", that there isn't any 
--> advantage to using this format, and others were saying that using the 
--> same Ethertype is asking for trouble because the label space would be 
--> overlapping. I suspect this is very implementation dependent, and there 
--> might be some implementations that would benefit from this encodings, 
--> and others it wouldn't help.

This is not quite in alignment with what I thought I heard in the
discussion.

There did not seem to be any argument that using a 32-bit shim 
might not be useful if it is not 100% consistent/compatible with 
MPLS labels.

What I thought some people were saying was that there might not
be any point in preserving the details of the format if we were
going to "break" compatibility by using a dfferent Ethertype.

One _interpretation_ of this - I believe was being argued - was
that we might re-use the BoS bit for some other purpose.  For a
few reasons, I personally don't think this is a good idea.  If
you follow this reasoning, for instance, you could equally well
argue that we could go with a 22-bit "nick-name" rather than to
reserve the EXP-bits space in the MPLS label format.

Clearly, these kind of arguments open up a can of worms that we
have seen the contents of before.  For this (and other) reason(s)
we should avoid re-hashing the format - given that the existing
format is "good enough."

I believe we may find that there are reasons why we might need
the BoS-bit down the road - just as there is likely to be good
reasons to use the EXP-bits.  I don't think we need to do this
in the RBridge protocol specification at this time, but the 
possibility that we may need to someday means we should think
about the consequences of needlessly churning an existing 
format.

Even if changing the Ethertype means that _some_ hardware may
not be directly re-used without modification, does not mean we
could not use the existing hardware with minimal modification.

Minimal modification means at least some savings in hardware
re-definition, re-spin, and re-certification.

Plus, there is the fact that not all hardware combines the 
demultiplexing of Ether-types and interpretation of Labels in
the same component.  For these cases, a lot of hardware re-use
is directly possible if we stick with existing MPLS label format 
details.

--> 
--> So the advantages of the MPLS-like format (with new Ethertype) is:
--> 
--> a) shorter (less overhead) than 8 bytes (which is probably what we'd use

--> for an RBridge ID, a hop count, and perhaps a priority field)

Assuming we use the same paradigm, but with the IS-IS system ID 
rather than a 19 bit nick-name, we would need:

Known Unicast/Other (Multicast/Broadcast/Flooded) De-mux Flag
Ingress/Egress System ID (at least the system unique portion)
TTL/Hop Count (by the way, this does work like TTL, right?)
Potentially a priority bit-field

I agree that this should fit in 8 bytes, but it may be close.

An often missed advantage of the shorter (19-bit) nickname is 
that - with a 19 bit name - it is possible to orient hardware 
around a litteral table look-up.

--> b) perhaps it would make some implementations easier
--> c) as long as we have to come up with a shim format, might as well use 
--> this encoding, since it has everything we want
--> 
--> The disadvantages are:
--> a) more complicated (because of the nickname acquisition protocol)...
-->    I don't think the nickname acquisition protocol is all that 
-->    complicated, but admittedly, with enough "let's do this one extra 
-->    thing because it's not that hard" can add up
--> 

IMO, we're going to absorb this complexity, either in the 
hardware or in the protocol.  My preference would be in the
protocol, but other people's mileage may vary.

-->
--> I can't think of any other disadvantages. People can feel free to add to

--> either list. But at any rate I don't think it matters a lot, and we 
--> should just pick one and not waste much time on this.
--> 
--> Radia
--> 
--> Eastlake III Donald-LDE008 wrote:
--> 
--> > Yes, RBridge forwarding is completely different from MPLS 
--> forwarding. 
--> > But the argument has been that a lot of effort has been 
--> invested in 
--> > hardware to efficiently process the MPLS header at high speed. 
--> > Therefore, it will be helpful to more rapid deployment 
--> and the more 
--> > widespread attainment of the prospective advantages of 
--> TRILL to re-use 
--> > the MPLS header format.
--> >  
--> > Donald
--> >
--> > 
--> ------------------------------------------------------------
--> ------------
--> > *From:* [email-masked] 
--> [mailto:[email-masked]] 
--> > *On Behalf Of *Yang Yang
--> > *Sent:* Monday, July 10, 2006 8:15 PM
--> > *To:* [email-masked]
--> > *Subject:* [rbridge] Some comments on RBridge
--> >
--> > Hello,
--> >    RBridge tries to adopt MPLS header. Are there any 
--> benefit to do so? 
--> > IMO, the forwarding behavior of RBridge is totally different from 
--> > MPLS. It's not possible to use the same forwarding componments.
--> >  
--> >    Best Regards!
--> >        Yang
--> >
--> >-----------------------------------------------------------
--> -------------
--> >
--> >_______________________________________________
--> >rbridge mailing list
--> >[email-masked]
--> >http://mailman.postel.org/mailman/listinfo/rbridge
--> >  
--> >
--> 
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://mailman.postel.org/mailman/listinfo/rbridge
--> 

Content-class: urn:content-classes:message
Date: Tue, 11 Jul 2006 12:34:14 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: <[email-masked]>
Subject: [rbridge] TRILL meeting presentations available
Status: RO
Content-Length: 279

Hi,

All of the presentations at the TRILL meeting are available linked off
the
https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=66
web page. Search for TRILL.

After I have received and edited the minutes, they will also be
available
there.

Thanks,
Donald

Date: Tue, 11 Jul 2006 07:27:23 -0700
From: Radia Perlman <[email-masked]>
To: Pierre Francois <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] How to deal with RBridge-Rbridge link metrics ?
Status: RO
Content-Length: 2364

When we said "zero configuration" we weren't intending to preclude 
configuration for tuning. So perhaps we have
to change the wording in the documents. VLANs almost certainly require 
configuration, and there will always
be tuning.

Should we consider setting of link metrics, and what the defaults are, 
to be an implementation issue? I agree
with Pierre that it would be good, for instance, to choose defaults in 
the base TRILL document, so that all
implementations use the same logical defaults.

Should we pick a single default for link cost for all types of links? (I 
think not)
Should we pick a default value for each link type? (say, a link of this 
speed would have this default). I think I
favor this, but I'd certainly prefer someone who has been working with 
IS-IS recently decide.

The easiest thing would be to ignore this issue and claim that the IS-IS 
specification deals with it, but I think
it would be nice to suggest defaults.

Radia

Pierre Francois wrote:

>
>Hi,
>
>I have questions regarding "IS-IS like" link metrics that would be used in
>trill.
>
>Shouldn't the requirements specify that if zero configuration must be made
>possible, it should also be made possible to configure RBridge->RBridge
>link metrics in order to allow smarter than smallest hopcount path
>forwarding...
>
>In the zero configuration case, what would be the default metric ?
>
>Also, what would be the behaviour of a RBridge if not all the links have a
>configured metric ?
>
>Consider all links have default metrics or configured links have their
>configured metrics and the other the default ?
>
>Wouldn't the last solution lead to a forwarding mess during a migration
>from an unconfigured link metrics architecture to a configured one ? For
>example if the default metric is 1, traffic will be concentrated on
>unconfigured links during the transition as they will provide the shortest
>paths...
>
>If this solution is used, shouldn't the default metric be made
>configurable in order to solve (at least try to solve) this problem ?
>
>Also, if link metric config is possible, shouldn't there be a requirement
>stating that a metric re-configuration should not lead to packet
>loops/loss ?
>
>
>
>Pierre.
>_______________________________________________
>rbridge mailing list
>[email-masked]
>http://mailman.postel.org/mailman/listinfo/rbridge
>  
>

Date: Tue, 11 Jul 2006 07:16:15 -0700
From: Radia Perlman <[email-masked]>
To: Eastlake III Donald-LDE008 <[email-masked]>
Cc: [email-masked], Yang Yang <[email-masked]>
Subject: Re: [rbridge] Some comments on RBridge
Status: RO
Content-Length: 2509

It seemed like at the meeting some people were saying if we don't use 
the same Ethertype to specify "MPLS
encoding", that there isn't any advantage to using this format, and 
others were saying that using the same Ethertype
is asking for trouble because the label space would be overlapping. I 
suspect this is very implementation
dependent, and there might be some implementations that would benefit 
from this encodings, and others it wouldn't
help.

So the advantages of the MPLS-like format (with new Ethertype) is:

a) shorter (less overhead) than 8 bytes (which is probably what we'd use 
for an RBridge ID, a hop count, and
perhaps a priority field)
b) perhaps it would make some implementations easier
c) as long as we have to come up with a shim format, might as well use 
this encoding, since it has everything we want

The disadvantages are:
a) more complicated (because of the nickname acquisition protocol)...I 
don't think the nickname acquisition
protocol is all that complicated, but admittedly, with enough "let's do 
this one extra thing because it's not that hard"
can add up

I can't think of any other disadvantages. People can feel free to add to 
either list. But at any rate I don't think
it matters a lot, and we should just pick one and not waste much time on 
this.

Radia

Eastlake III Donald-LDE008 wrote:

> Yes, RBridge forwarding is completely different from MPLS forwarding. 
> But the argument has been that a lot of effort has been invested in 
> hardware to efficiently process the MPLS header at high speed. 
> Therefore, it will be helpful to more rapid deployment and the more 
> widespread attainment of the prospective advantages of TRILL to re-use 
> the MPLS header format.
>  
> Donald
>
> ------------------------------------------------------------------------
> *From:* [email-masked] [mailto:[email-masked]] 
> *On Behalf Of *Yang Yang
> *Sent:* Monday, July 10, 2006 8:15 PM
> *To:* [email-masked]
> *Subject:* [rbridge] Some comments on RBridge
>
> Hello,
>    RBridge tries to adopt MPLS header. Are there any benefit to do so? 
> IMO, the forwarding behavior of RBridge is totally different from 
> MPLS. It's not possible to use the same forwarding componments.
>  
>    Best Regards!
>        Yang
>
>------------------------------------------------------------------------
>
>_______________________________________________
>rbridge mailing list
>[email-masked]
>http://mailman.postel.org/mailman/listinfo/rbridge
>  
>

Content-class: urn:content-classes:message
Date: Tue, 11 Jul 2006 09:23:05 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: <[email-masked]>
Cc: Yang Yang <[email-masked]>
Subject: Re: [rbridge] Some comments on RBridge
Status: RO
Content-Length: 3004

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6A4ED.2550B73C
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Yes, RBridge forwarding is completely different from MPLS forwarding.
But the argument has been that a lot of effort has been invested in
hardware to efficiently process the MPLS header at high speed.
Therefore, it will be helpful to more rapid deployment and the more
widespread attainment of the prospective advantages of TRILL to re-use
the MPLS header format.
=20
Donald

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Yang Yang
Sent: Monday, July 10, 2006 8:15 PM
To: [email-masked]
Subject: [rbridge] Some comments on RBridge

Hello,
   RBridge tries to adopt MPLS header. Are there any benefit to do so?
IMO, the forwarding behavior of RBridge is totally different from MPLS.
It's not possible to use the same forwarding componments.=20
=20
   Best Regards!
       Yang

------_=_NextPart_001_01C6A4ED.2550B73C
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1555" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D867201313-11072006>Yes, RBridge forwarding is completely =
different from=20
MPLS forwarding. But the argument has been that a lot of effort has been =

invested in hardware to efficiently process the MPLS header at high =
speed.=20
Therefore, it will be helpful to more rapid deployment and the more =
widespread=20
attainment of the prospective advantages of TRILL to re-use the MPLS =
header=20
format.</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D867201313-11072006></SPAN></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D867201313-11072006>Donald</SPAN></FONT></DIV><BR>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> [email-masked]=20
[mailto:[email-masked]] <B>On Behalf Of </B>Yang=20
Yang<BR><B>Sent:</B> Monday, July 10, 2006 8:15 PM<BR><B>To:</B>=20
[email-masked]<BR><B>Subject:</B> [rbridge] Some comments on=20
RBridge<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV>Hello,</DIV>
<DIV>&nbsp;&nbsp; RBridge tries to adopt MPLS header. Are there any =
benefit to=20
do so? IMO, the forwarding behavior of RBridge is totally =
different&nbsp;from=20
MPLS. It's not possible to use the same forwarding componments. </DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;&nbsp; Best Regards!</DIV>
<DIV>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Yang</DIV></BODY></HTML>

------_=_NextPart_001_01C6A4ED.2550B73C--

Date: Tue, 11 Jul 2006 15:19:13 +0200 (CEST)
From: Pierre Francois <[email-masked]>
To: [email-masked]
Subject: [rbridge] How to deal with RBridge-Rbridge link metrics ?
Status: RO
Content-Length: 1198

Hi,

I have questions regarding "IS-IS like" link metrics that would be used in
trill.

Shouldn't the requirements specify that if zero configuration must be made
possible, it should also be made possible to configure RBridge->RBridge
link metrics in order to allow smarter than smallest hopcount path
forwarding...

In the zero configuration case, what would be the default metric ?

Also, what would be the behaviour of a RBridge if not all the links have a
configured metric ?

Consider all links have default metrics or configured links have their
configured metrics and the other the default ?

Wouldn't the last solution lead to a forwarding mess during a migration
from an unconfigured link metrics architecture to a configured one ? For
example if the default metric is 1, traffic will be concentrated on
unconfigured links during the transition as they will provide the shortest
paths...

If this solution is used, shouldn't the default metric be made
configurable in order to solve (at least try to solve) this problem ?

Also, if link metric config is possible, shouldn't there be a requirement
stating that a metric re-configuration should not lead to packet
loops/loss ?

Pierre.

Date: Tue, 11 Jul 2006 08:14:59 +0800
From: "Yang Yang" <[email-masked]>
Sender: [email-masked]
To: [email-masked]
Subject: [rbridge] Some comments on RBridge
Status: RO
Content-Length: 949

------=_Part_19216_27198664.1152576899599
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hello,
   RBridge tries to adopt MPLS header. Are there any benefit to do so? IMO,
the forwarding behavior of RBridge is totally different from MPLS. It's not
possible to use the same forwarding componments.

   Best Regards!
       Yang

------=_Part_19216_27198664.1152576899599
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

<div>Hello,</div>
<div>&nbsp;&nbsp; RBridge tries to adopt MPLS header. Are there any benefit to do so? IMO, the forwarding behavior of RBridge is totally different&nbsp;from MPLS. It's not possible to use the same forwarding componments. </div>
<div>&nbsp;</div>
<div>&nbsp;&nbsp; Best Regards!</div>
<div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Yang</div>

------=_Part_19216_27198664.1152576899599--