Subject: RE: prequeal to WG lat call om the LSR mib module

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Wed, 11 Jun 2003 00:12:45 +0200

> > So if you have 3 application managing Label Space as
> > in the following example. 
> > > 
> > > 	Application		Incoming Labels Owned by Application
> > > 	LDP			{ 15, 29, 45 }
> > > 	VPN			{ 30, 31, 32 }
> > > 	TE  			{ 16, 17, 18 }
> > > 	
> > And then you have the object mplsInSegmentIndexNext
> > 
> > How does that IndexNext object provide me with a proper
> > new index value that I can use. Cause it does not know 
> > if I (as an application) want to create a new InSegment 
> > for LPD, VPN or TE... or does it? If it does, then I
> > do not understand how. Maybe I missed the explanation in
> > some text in the MIB document... if so, pls point me to it.
> 
> 	It knows because it knows which device it is
> provisioning and thus knows what the application ID
> values need to be (from its agent cap statement or
> other documentation).

Sorry... I cannot understand. Your "it knows" is your agent, right?
Your agent accoding to the above table supports 3 applications,
namely LDP, VPN, TE. 
So your agent should accept rowCreates for each of those 3 apps.
How does you agent know what application type label I want to
setup with my next create? Your mplsInSegmentIndexNext will have
to be a value that representes one of those 3 apps, right? 
What if I want to configure for the other app?

You told me yourself (If I remember correctly) that you implemented
this MIB module in read-only mode. In that case, this is not a
problem, but when you support it in read-write mode... I still see
the problem, not matter that you keep repeating that it is not
problem in your view.

Bert

> I don't see this as a problem since
> there is a whole slew of non-standard things that a
> provisioning system needs to know about devices it
> manages. In fact, I would bet that %100 of the implementations
> out there will require some bit of proprietary MIB support
> to facilitate provisioning of static LSPs via SNMP (if
> they even will allow this). IMHO the fact that we have %90 
> of what most people need is not too bad.
> 
> 	--Tom
> 
> 
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 12 Jun 2003 12:23:21 -0400

Talking with Tom about this off-line we arrived at the following (startling?)
conclusion.

> It would, however, appear that we have reached the nub of the matter. The
> problem with the unformatted octet string aproach is in providing write
access,
> and (I'm guessing) the reason why this has become a hot debate is that I have
> been looking to provide write access and you have not been very bothered by
> whether that function works or not.
>
>
> So, there's an easy answer...
> People who use complex formatting of the octet string don't care about write
> access.
> People who use write access don't care about complex formatting of the octet
> string.

The suggestion we have is to add text (somewhere) to highlight this point.
For example...

>      In systems that provide write access to the LSR MIB, the mplsIndexType
>      SHOULD be used as a simple multi-digit integer encoded as an octet
string.
>      No further overloading of the meaning of an index SHOULD be made. The
>      mplsGetNextInSegmentIndex and similar objects should provide a
>      monotonic increasing value of indexes.
>
>      In systems that do not offer write access to the LSR MIB, the
>      mplsIndexType may contain implicit formatting that is specific to the
>      implementation to convey additional information such as interface index,
>      physical card or device, or application id. The interpretation of this
>      additional formatting is implementation dependent and not covered in this
>      document. Such formatting MUST NOT impact the basic functionality of
>      read-only access to the LSR MIB by management applications that are
>      not aware of the formatting rules.

This would address all of the issues about formating of the "index string".

Adrian

---

From: Len Nieman <[email-masked]>
Date: Thu, 12 Jun 2003 14:50 -0400 (EDT)

Inline:

>Date: Thu, 12 Jun 2003 13:01 -0400 (EDT)
>From: Curtis Villamizar <[email-masked]>
>To: Len Nieman <[email-masked]>
>CC: Curtis Villamizar <[email-masked]>,
>    "Natale,    Robert C (Bob)" <[email-masked]>,
>    [email-masked],
>    Adrian Farrel <[email-masked]>,
>    'MPLS WG' <[email-masked]>
>Reply-to: [email-masked]
>Original-recipient: rfc822;[email-masked]
>Subject: Re: prequeal to WG lat call om the LSR mib module

<Major Snip>

>
>To be honest with you, I see by your signature that you're with MCI
>and there are other people in Worldcom that don't share your opinion
>on this.  That is for Worldcom/MCI/UUNET to resolve.

I'm very aware of that, and when I'm responding to a WG list I'm speaking
strictly for myself.

>We speak here in the IETF as individuals and your opinion counts as
>much as anyone's.

Thank you. Maybe I need to start including a "The opinions expressed
are my own" disclaimer.
 
>There seems to be two approaches to configuring ATM and FR service.
>One is to have an offline NMS set the low level switch mappings.  Many
>providers with legacy ATM and FR switches seem to have done this.  The
>preference among ISPs using MPLS has been to use dynamic routing and
>configure only the MPLS LSP requirements (constraints) at the ingress.
>Where we are now is providers want to offer ATM and FR service over
>MPLS and there are clearly two groups in many providers that are
>starting to do this.  One group wants to set inseg/outseg with the MIB
>arguing that it is what they've always done.  The other wants setup on
>the ingress and points out that ATM and FR will be a small minority of
>traffic and configuring the ingress has proven more reliable.

It may sound weird, but I actually agree with both sides on this.

At some point FR and ATM will become a small minority of traffic. But my
opinion is that right now, across the board, there is a lot of customer
and carrier capital money tied up in both. No one is going to just toss
that investment out the window, it will attrit away over time as it
becomes depreciated. Until then, there will still be a lot of FR and ATM
being used to access MPLS networks.

>Maybe you are right.

And maybe not, it's just my opinion.

>The IETF can't decide that internal argument for the providers.
>For now the MIB needs to be read-write.  Providers need to resolve
>this internally and tell their vendors whether they need read-write
>or read-only.

Agreed.

>This argument may go on as long as the cells vs packets argument
>that raged almost a decade ago.

I hope not!

>If it resolves as many of us think it will, we can go with read-only,
>but at this point it is not resolved.
>
>Curtis

Time will tell.

Len