Subject: RE: Static MPLS configuration

From: "Igor Achkinazi" <[email-masked]>
Date: Mon, 07 Jan 2002 19:52:55

Thanks, Steven

However MPLS UNI implies MPLS signaling that adds complexity. In LSP 
hierarchy case it does not help at all. I intentionally asked about static 
configuration, because it is simple and easy to control. And it is much, 
much easier to implement.
Sorry, I do not want to use UNI :)

Best regards,
Igor

>From: "Dekany, Steven" <[email-masked]>
>To: Igor Achkinazi <[email-masked]>, [email-masked]
>CC: [email-masked]
>Subject: RE: Static MPLS configuration
>Date: Mon, 7 Jan 2002 14:37:01 -0500
>
>MPLS UNI solves this from a different direction. You may want to take a 
>look
>at that.
>
>Best Regards,
>
>
>Steven
>
>-----Original Message-----
>From: Igor Achkinazi [mailto:[email-masked]]
>Sent: Monday, January 07, 2002 11:46 AM
>To: [email-masked]
>Cc: [email-masked]
>Subject: Re: Static MPLS configuration
>
>
>Sorry for confusion, I meant statically configured MPLS label, LSP, to be a
>logical interface. May be mplsTunnel (150) ifType is better for this kind 
>of
>
>interface. It is not MPLS capability configuration over an interface. It is
>new subinterface, like ATM PVC over ATM physical link. My suggestion was 
>not
>
>just gathering statistics, but use of such interface in a system as a
>regular layer 3 link.
>
>Thanks,
>Igor
>
>
> >From: "Thomas D. Nadeau" <[email-masked]>
> >To: "Igor Achkinazi" <[email-masked]>
> >CC: [email-masked]
> >Subject: Re: Static MPLS configuration
> >Date: Mon, 07 Jan 2002 12:31:19 -0500
> >
> >
> >>Does anybody use MPLS interface as a layer 3 logical interface, or
> >>subinterface (part of a physical interface), like ATM PVC or Frame Relay
> >>DLCI, with its own entry in ifTable (mpls(166) ifType from 
>IANAifType-MIB)
> >>and IP address associated with it?
> >
> >         I know of lots of vendors that support this, as it is the 
>standard
> >model for MPLS
> >interface stacking.
> >
> >>Of course, it makes sense for static MPLS configuration of bidirectional
> >>flows.
> >
> >         It makes sense from a configuration perspective because it 
>allows
> >a manager to determine if MPLS is configured on that interface, as well 
>as
> >allows them to configure MPLS on an existing interface. It also makes 
>sense
> >from a statistical gathering perspective because stacking an MPLS 
>interface
>
> >on
> >top of another physical interface such as Ethernet allows a manager to
> >count just
> >the MPLS traffic on that interface, as opposed to the (aggregate) enet
> >traffic,
> >or anything else (IP).
> >
> >         --Tom
> >
> >
> >>I think it can be useful for multiplexing of small traffic flows onto 
>big
> >>capacity MPLS trunk. Another possible application is eliminating of
> >>complexity of forwarding adjacencies in routing protocols (LSP hierarchy
> >>draft), where simple static MPLS path can be used as actual, not virtual
> >>interface. In latter case MPLS interface can be even unnumbered, without
> >>IP address.
> >>
> >>Thanks,
> >>Igor
> >>
> >>
> >>_________________________________________________________________
> >>Send and receive Hotmail on your mobile device: http://mobile.msn.com
> >
> >
> >
> >------------------------------------------------------------------------
> >Mathematics is the supreme nostalgia of our time.
> >
>
>
>_________________________________________________________________
>Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.

_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com

---

From: Tricci So <[email-masked]>
Date: Mon, 07 Jan 2002 15:22:33 -0800

Hi Der-Hwa and Ping,

After reviewing your draft in more details, I have the following questions
regarding the detour mechanism for FRR.  Hope you can help me to clarify a few
things.  Thanks....

1. According to the latest draft, section 3.2.1, your recommend the use of the
RSVP_HOP object to be included in the detour Path message.  Since the
SENDER_TEMPLATE, which contains the new sender's IP's address in the "IPv4
tunnel sender address", is also being used in the Path message, why the RSVP_HOP
object is needed to carry the same information (i.e. PLR's IP addrss)?

2. In section 3.2.2., you have a statement mentioned that the MP may receieve
the Path message from different interfaces with the identical SESSION and
SENDER_TEMPLATE objects.  I don't see this would be possible except for the case
of the software error.  It is because the SENDER_TEMPLATE should be coded with
different LSP_IDs for the Protected and Detour LSPs for the same tunnel over
different interfaces.  This the design intent of using different LSP_IDs to
differentiate different instances of the LSPs for the same tunnel.  Am I
misunderstood your statement?

3. Somebody sent a previous email to suggest that the detour Path message should
include the option to specify the requested LSP's bandwidth and administrative
group constraint that is same as the Protected LSP, instead of locally
configuring these two options at each FRR capable LSR to adopt the Protected LSP
requirements or not.  I happen to agree with his view.  What do think about his
suggestion?

Thanks in advance to your help......
Tricci