The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] Re:
SG,
You could think of every device as having a default forwarding
mechanism - 'see a packet, drop a packet'. If a device is not able
to process packets for XYZ protocol, it effectively has no choice
but to service it with this default forwarding mechanism. It could
also notify 'higher layers' that it saw such a packet.
I believe that most real network devices have defined formats
that they support and defined behaviors for all other formats. In
many ways, this question is similar to asking what will happen if
a frame relay packet is received on an ATM interface. Such things
only happen as a result of installation/configuration errors.
In the MPLS case, for example, how would a labeled packet get
to a non MPLS node since it surely didn't distribute a valid label?
You wrote:
> Hi,
> I see the "non-mpls router" definition from your point. I was just
> trying to lay out the possibilities and was not trying to defend
> or beat up on any one approach. I understand the problem about having
> a non-mpls island between two MPLS LSP's and the issues with loss
> of knowledge as far as the label linkages are concerned and I did
> mention that in my previous reply.
> Coming back to your definition of "mpls aware router", what would
> happen if the non-mpls complaint router detects an MPLS packet. I
> don't believe it has been defined any where, is that true?
>
> SG
>
>
> At Tuesday, 9 October 2001, "Arun M. Thomas" <AMammenT@yahoo.com> wrote:
>
> >Just a comment.... As Eric mentioned, it seems to be a matter of
> >definition. In order for the tunneling idea to work, the router,
> while it
> >may not have an MPLS daemon running to handle label exchange, still
> needs to
> >be capable of detecting MPLS labelled packets. As soon as that
> is true, I
> >don't really think it's valid to say the router is a non-mpls router.
> >(That's my definition.... If what was meant originally by "non-mpls
> router"
> >was simply that no handling of labels is ongoing, then all that's
> written
> >below continues to be valid.
> >
> >-AMT
> >
> >-----Original Message-----
> >From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Hongwei
> >Sent: Tuesday, October 09, 2001 8:58 AM
> >To: sganguly@opulentsystems.com
> >Cc: mpls@UU.NET
> >Subject: RE:
> >
> >THX for discussion :). Yes, tunnel may be another idea, but it
> will more
> >complicate. The mpls LERs should be policed to be aware of tunnels,
> and if
> >the LERs around the non-mpls island want to share mpls knowledge
> (such as
> >labels and TTLs), every LER has to know which LER across the island
> is the
> >next hop. The non-mpls router is a bottleneck if it has to be routed
> >through.
> >
> >--hongwei
> >
> >-----Original Message-----
> >From: Sukanta Ganguly [mailto:sganguly@opulentsystems.com]
> >Sent: 09 October 2001 15:57
> >To: Hongwei
> >Subject: RE:
> >
> >Depends on the vendor implemetation. The packet can either tunneled
> so that
> >it retains its MPLS tag via a non-MPLS network or the MPLS tag(s)
> can be
> >completely removed from the packet in which if the packet travels
> through a
> >MPLS island further then new tags have to be inserted and new LSP's
> have to
> >be used. In the latter case the sender's MPLS knowledge which as
> originally
> >present in the packet is lost.
> >
> >SG
> >
--
Eric Gray (mailto:eric.gray@sandburst.com)
http://www.mindspring.com/~ewgray
|
|