Subject: [rbridge] Re: IP and MPLS TTL

From: loa at pi.se (Loa Andersson)
Date: Wed May 12 02:00:40 2004

this one too

/Loa

Loa Andersson wrote:

> All,
> 
> on the TTL discussion - and I'm not sure if I want to
> decrement the TTL or not yet - there is one mpls aspect that
> needs to be considered.
> 
> On any given link in a MPLS enabled IP network ther might be
> a mix of "pure" IP-packets and packets encapsulated with a mpls
> shim header. Now, if there are any mpls shim header, and we want
> to decremetn the TLL the rbridge needs to understand to decrement
> the TTL in the shime header, but not in the IP header.
> 
> If the rbridge is the pen ultimate mpls node it should "pop" the
> mpls shim header and re-write the IP TLL based on a set of rules
> (RFC3443) - butif we go down this route the rbridge becomes very
> close to an LSR.
> 
> /Loa

-- 

Loa Andersson

mobile +46 739 81 21 64

---

From: touch at ISI.EDU (Joe Touch)
Date: Wed May 12 09:19:07 2004

>> (RFC3443) - butif we go down this route the rbridge becomes very

This goes to my note prior note about MPLS. I agree that this might not 
be what some consider a layer, though many do. The ways in which it 
modifies other layers violates those layers, and results in 
inconsistencies. This is perhaps one of them.

I.e., I put MPLS and NATs in the same "use at your own risk" bin in this 
regard. So long as an rbridge presents a consistent, strictly layer-2 
service (it presents L2 to the periphery, regardless of what it tunnels 
over internally), then it should be equivalent to other strictly-L2 
boxes, like l2 switches.

The catch is that many L2 switches aren't L2; they snoop IGMP, etc. I'm 
not sure if MPLS falls into that category...

Joe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/rbridge/attachments/20040512/5b5a86d1/signature.bin