Subject: [rbridge] forwarding of IP packets to off-campus destiantions

From: marcelo at it.uc3m.es (marcelo bagnulo braun)
Date: Tue, 1 Mar 2005 17:25:53 +0100

Hi,

i have one question regarding the forwarding of IP packets to 
off-campus destiantions

AFAIU, the rbrdiges will forward differently packets addressed to off 
campus destiantions that those whose destiantion is on-campus.

My question is how do they know if a packet destination is on campus or 
off campus?

I guess this requires manual configuration of the on campus prefix, 
right?

But if this is the case, wouldn't this be contradicting the proposed 
charter requirement:

- zero configuration of the hybrid devices

Regards, marcelo

---

From: Radia.Perlman at Sun.COM (Radia Perlman)
Date: Tue, 01 Mar 2005 09:22:33 -0800

The devices that have zero configuration are the RBridges. RBridges do 
not know
anything about "on-campus" or "off-campus". It's the IP nodes attached
to the cloud that know the difference, but just in the way that IP nodes 
have
always acted. The IP nodes will decide if the target is "their 
neighbor", i.e.,
on-campus, the way they have always done.

It certainly wasn't the intention that RBridges know the on-campus IP 
prefix, but
it might have been discussed when discussing variations on the design. 
At any
rate, it isn't the intention now.

The design now is that RBridges will forward all data packets
based on the layer 2 destination.
IP nodes will fill in the layer 2 destination as the MAC address they 
receive in an
ARP/ND reply (if the target is deemed by the IP node as on-campus), or to
the layer 2 address of an IP router (if the IP source node deems that 
the target is
off-campus).

But RBridges won't know the difference as to whether the node they are 
delivering
the packet to is an IP router or the actual destination.

Hope that answered your question. I know I had written something about 
what would
happen if RBridges attempted to avoid encapsulation with IP packets, and 
why that
would be hard (because they'd have to forward based on the layer 2 
header when
the packet was off-campus), but that was intended only to explain why 
it's better if
they always forward based on the layer 2 destination. So, sorry for the 
confusion...

Radia

marcelo bagnulo braun wrote:

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

---

From: marcelo at it.uc3m.es (marcelo bagnulo braun)
Date: Tue, 1 Mar 2005 19:51:49 +0100

Hi Radia,

I am not understanding some point here..
please see below...

> based on the layer 2 destination.

this is not what i read on the draft

5. Handling on-campus IP Packets

    Here, RBridges forward based on the layer 3 header.

am i misunderstanding something?

> the packet to is an IP router or the actual destination.

I am afraid no.

Current draft states that IP packets are treated differently by 
rbridges dependeing their destiantion.

it is stated that:

5. Handling on-campus IP Packets

    Here, RBridges forward based on the layer 3 header.

and later on that:

6. Handling off-campus IP packets

    Here, RBridges must forward based on the destination in the original
    layer 2 header, because the endnode must be able to choose which
    router to send off-campus packets to.  In particular, an IP router
    must be able to forward to another IP router across the campus.

So, rbrdige needs to know if the IP destiantion address is on campus or 
off campus, in order to treat them differently, hence on campus prefix 
configuration is needed.

What am i missing?

thanks, marcelo

---

From: Radia.Perlman at Sun.COM (Radia Perlman)
Date: Tue, 01 Mar 2005 11:18:12 -0800

Yup. You're absolutely right. The current draft still says that RBridges 
forward
based on the IP header, which as you point out, would require
RBridges to know the campus prefix, and therefore not be
zero configuration (unless they autoconfigure it the same way IP
endnodes would, but I'm not advocating that).

That section in the draft was an attempt to both avoid the encapsulation
header (in the case of IP packets) and an attempt to avoid requiring
RBridges to learn locations in the forwarding path (in the case of IP 
packets).

I think after discussing it for awhile we realized it just made 
everything more
complicated, so that portion of the internet draft should change (by being
removed). It seems
a better design to just always forward based on the layer 2 header. I 
thought
we had removed it, but I guess we didn't.

So I think you and I are agreeing on what the design should be, and you're
pointing out that the draft doesn't reflect that design.

Radia