Subject: RE: LSR MIB WG Last Call

From: Joan Cucchiara <[email-masked]>
Date: Wed, 15 Mar 2000 10:55:39 -0500

George,

I do raise an objection.  It has been pointed
out to me that the rev 02 of the LSR MIB
now states that it intends to support LDP.

When the (TE-MIB which contained the LSR-MIB) was
proposed as a working group document in Minneapolis,
Jim Luciani asked if there would be overlap with the
LDP MIB, he (and the rest of the working group) were
told, "no, not much".

Now, they intend (apparently) to support LDP.
As a working group, we do NOT need two mibs to
support the same protocol.  So I object on this
basis.  It does not seem fair to me that
3 revisions into the LSR MIB, the LSR MIB can expand 
its scope to support another protocol, namely LDP, especially 
when there is already an active LDP MIB.  

There has been NO working group consensus about including LDP in
scope of the LSR MIB.   

Why does the working group need two MIBs for LDP?

Thank you, Joan

> -----Original Message-----
> From: George Swallow [mailto:[email-masked]]
> Sent: Wednesday, March 15, 2000 10:28 AM
> To: Joan Cucchiara
> Cc: 'Thomas D. Nadeau'; Adrian Farrel; [email-masked]; 
> [email-masked]';
> [email-masked]'; [email-masked]
> Subject: Re: LSR MIB WG Last Call 
> 
> 
> Joan -
> 
> I believe that Tom merely meant to suggest that the LSR mib was now
> ready for last call.  Unless I hear objections I'll issue one before
> the day is out.  
> 
> ...George
> 
> ==================================================================
> George Swallow       Cisco Systems                   (978) 244-8143
>                      250 Apollo Drive
>                      Chelmsford, Ma 01824
>

---

From: Arun Viswanathan <[email-masked]>
Date: Wed, 15 Mar 2000 11:11:08 -0800

Joan,

> From: [email-masked] [mailto:[email-masked]]On Behalf Of Joan
> Cucchiara
> Sent: Wednesday, March 15, 2000 7:56 AM
> To: 'George Swallow'; Joan Cucchiara
> [email-masked]'
> Subject: RE: LSR MIB WG Last Call 
> 
> 
> 
> George,
> 

The LSR MIB supported LDP from day one. It is a mere
cross-connect and is absolutely agnostic about which
entity created the cross-connect. We introduced the
owner field in this rev, based on some feedback, to enable
tracking which entity actually created a cross-connect
entry.

> LDP MIB, he (and the rest of the working group) were

I don't recall anybody say "none". And at the same meeting
it was decided by the WG to split the then TE document into
two documents one for the TE alone and another as LSR MIB
applicable to ALL MPLS protocols.

> Now, they intend (apparently) to support LDP.

Can you explain how the LSR MIB didn't support LDP in
the previous rev? 
The data model hasn't changed a bit since inception.
A single LSR that provides connection capability
with several clients (protocols) using the resources.

> support the same protocol.

LDP doesn't constitute an LSR. The label and connection
resources are common to every MPLS protocol and hence the
LSR MIB. It is just seems absurd to me that LDP requires
to manage its own label space and connections instead
of a single entity that manages label and connection resources
for ALL MPLS protocols.

> So I object on this

Let me state this one more time. LSR MIB supported LDP (and
every other MPLS protocol) from the day of its inception.

> There has been NO working group consensus about including LDP in

The very reason the WG split the intial TE doc into
two separate doc was to have a seperate LSR MIB common
to all MPLS protocols.

> 
> Why does the working group need two MIBs for LDP

Because LDP is not LSR! Please see the above comments.

-arun

---

From: Adrian Farrel <[email-masked]>
Date: Thu, 16 Mar 2000 04:51:02 -0000

Good catch Tim,
I raised this with Tom some months ago in the context of the TE MIB.

Tom, I think this is really important.  As the MPLS Diff-Serv draft gets
much more stable, more people will be implementing it and wanting to
configure E-LSP and L-LSP tunnels.

We need to
- configure E-LSP and L-LSP tunnels
- record the Diff-Serv information passing through an LSR
- make information available for packet classification?

Adrian

--
Adrian Farrel  mailto:[email-masked]
Network Convergence Group
Data Connection Ltd., Chester, UK
http://www.datcon.co.uk/
Tel: +44 (0) 1244 313440  Fax: +44 (0) 1244 312422
>From: Tim Mancour [mailto:[email-masked]]
>Sent: Wednesday, March 15, 2000 10:46 PM
>To: Arun Viswanathan; 'Thomas D. Nadeau'; [email-masked];
>[email-masked]; 'Vijay Srinivasan'
>Cc: 'Cheenu Srinivasan'
>Arun,
>I don't see anyway to manually configure an E-LSP or L-LSP
>using the LSR MIB. Without knowing the LSP style, the incoming 
>EXP bits cannot be properly interpreted and therefore cannot be
>processed.

---

From: Arun Viswanathan <[email-masked]>
Date: Wed, 15 Mar 2000 23:10:30 -0800

George and Vijay,

Here are the diffs between the last four versions of this draft.
This should help in identifying what exactly changed in the LSR
MIB through the revs. I have listed the diffs starting with
the March 6, 2000 draft to Feb 16, 1999 draft. If anybody cared
to notice we haven't made any substantial or structural changes
since Feb 99.

Almost all changes in the rev-02 are made based on comments from
the list. I see no reason why we should not make last call on this
draft. 

Diff between draft-ietf-mpls-lsr-mib-02.txt (Mar 6 '00)
	and draft-ietf-mpls-lsr-mib-01.txt (Feb 16, '00):

	1. Add new MPLS ifType 166.
      2. Removed mplsTSpecDirection from the MplsTSpecTable.
	3. Changed MplsBitRate definition.
	4. Added mplsInterfaceIsLocalLabelSpace to the
MplsInterfaceConfEntry.
	5. Changed 'crldp' to 'ldp' in mplsInSegmentOwner and
mplsOutSegmentOwner.
	6. mplsXCOwner object added to the MplsXCEntry.
	7. Added notifications mplsInterfaceTrapEnable,
mplsInSegmentTrapEnable, 
	   mplsOutSegmentTrapEnable, and mplsXCTrapEnable.
	8. Changes to SYNTAX field of several objects.
	9. Added text into description field of various objects for better
clarity.
     10. Some editorial changes in the 'Unit of Conformance' section.

Diff between draft-ietf-mpls-lsr-mib-01.txt (Feb 16 '00) and 
	draft-ietf-mpls-lsr-mib-00.txt (Jul 16 '99):

	1. Changed formatting from right aligned to unaligned.
	2. Added section 8.1. 'Support of the MPLS Layer by ifTable'.
	3. Added MplsLSPId support.
	4. Added textual conventions for BitRate, BurstSize, and BufferSize.
	5. Added BW information in MplsInterfaceConfEntry.
	6. Added mplsInterfaceIsGlobalLabelSpace object in
mplsInterfaceConfEntry.
	7. Removed few objects from the mplsInterfacePerfTable.
	8. Added ownership object in MplsInSegmentTable and
MplsOutSegmentTable.
      9. Added ...IndexNext objects to various tables.
     10. Added scaler mplsMaxLabelStackDepth.
     11. Removed ifIndex from the TSpec table.

Diff between draft-ietf-mpls-lsr-mib-00.txt (Jul 16 '99) and 
	draft-ietf-mpls-te-mib-00.txt (Feb 16 '99):

	1. Split LSR MIB into a seperate WG document from TE MIB
         on WG's recommendation.
      2. No changes were made otherwise.

-arun

> From: [email-masked] [mailto:[email-masked]]On Behalf Of George
> Swallow
> Sent: Wednesday, March 15, 2000 7:28 AM
> To: Joan Cucchiara

---

From: Joan Cucchiara <[email-masked]>
Date: Thu, 16 Mar 2000 11:13:20 -0500

Arun,

It was not clear to me from reading the MIB.  No where does
it say, "for LPD this means ...." or "this object/table does
not apply to LDP".  For example, the XC table goes to
great length to discuss p-to-mp and mp-to-p types of Cross Connects
and I don't understand what this has to do with LDP which
is next-hop peer.  Especially, p-to-mp which seems to me to
imply some sort of multicast when thinking about LDP, but
maybe that's just me.

Secondly, I thought configuration of LDP was a new addition because to the
change under Feature Checklist:

"The MIB should be able to support both manually configured LSPs
as well as those configured via LDP and/or RSVP signalling".

The prior rev said "CR-LDP and/or RSVP signalling".  

> of a single entity that manages label and connection resources

Arun, again I am concerned about these statements.  It is 
not absurd if you consider that there was not an alternative,
nor is there an existing alternative.  Separating these
tables from the LDP MIB may or may not be adequate for
all 3 MPLS protocols.  I don't know at this point.

If the LSR MIB would like to configure label ranges, then
certainly the work for this in the LDP MIB could be used
as a starting point.  Feel free to copy it into the LSR MIB
as a starting point. However, it is not appropriate for
the LDP MIB to be held up waiting for the LSR MIB. 

MIBs often copy in Textual Conventional at the same time
so they can advance without being held up by one another.
It is just not accepted practice to hold up one MIB 
for another, especially when the other one is NOT necessary
to support the first.  The LSR MIB is not needed for the LDP MIB.

If the LSR MIB intends to support configuring label ranges
then I would like to raise a couple of issue:

* I think that separate MIBs which for LDP, CR-LDP and RSVP-MPLS
should be developed for the very simple reason that an LSR may
only want to run one protocol.  Thus, supporting the LSR MIB
is not needed until there are two or more MPLS protocols on the
same LSR.

Certainly, if all 3 of these MIBs could point to some label range
config tables in the LSR MIB (or elsewhere), then that is an alternative.  
Today this is NOT the case.

* A few weeks ago there was quite a bit of discussion on
what it meant to modify a label range for LDP.  Modifying a
Label Range could have potential ripple effects throughout most 
of the tables in the LDP MIB.
Is the LSR MIB going to maintain state for all the different
protocols?  I would disagree for the reasons stated above: specifically,
an LSR should be able to run only one MPLS protocol without the LSR MIB.  
It is not clear to me where the LSR MIB is drawing the lines, 
and I would like to understand this prior to the LSR MIB going to
last call.

I also would like to understand if this configuring of label ranges
is going to be part of the LSR MIB, or yet another draft? 

In a way, I think that it is "too soon" for the LSR MIB.  If all
3 protocols already had existing MIBs, then it would be much clearer
to me where the likenesses were and what could be separated out
into an LSR MIB.  I am concerned that the LSR MIB is actually trying
to support CR-LDP and MPLS-RSVP specific objects and is not 
maintaining the abstraction level which was the original goal.  

-Joan

---

From: Arun Viswanathan <[email-masked]>
Date: Thu, 16 Mar 2000 11:59:56 -0800

Joan,

> imply some sort of multicast when thinking about LDP, but

LSR MIB is modelling nothing but the LSR as described in the
MPLS Arch. The goal has always been to provide a common entity
that modelled an LSR for use by all MPLS protocols (LDP included).
Therefore, the LSR MIB is agnostic about MPLS protocols.
LSR is nothing but labels and connections, that is, models LSPs.

> change under Feature Checklist:

It is not a new addition. I am glad you pointed this out.
See what it says in Rev 00.

> The prior rev said "CR-LDP and/or RSVP signalling".  

In Rev 00 it said:
   -  The MIB should be able to support both manually configured LSPs
      as well as via LDP and/or RSVP signaling.
In Rev 01 it said:
   -  The MIB should be able to support both manually configured LSPs
      as well as those configured via CR-LDP and/or RSVP signaling.
In Rev 02 it says:
   -  The MIB should be able to support both manually configured LSPs
      as well as those configured via LDP and/or RSVP signaling.
I think it should read:
   -  The MIB should be able to support both manually configured LSPs
      as well as those configured via any MPLS signaling protocol.

It got inadvertently changed by one of the author while editing for
rev 01 and it got corrected in rev 02. I think it should be changed to
the last suggestion.

> all 3 MPLS protocols.  I don't know at this point.

I don't know what you mean by 'these tables'. I was only
referring to the LIB table in LDP MIB. Instead of the LIB
table use the XC table in LSR MIB which provides the same
capability (and more). That is, have the FEC table in
LDP MIB have a row pointer to the XC table in the LSR MIB.
This is the ONLY change that I am suggesting we make in
the LDP MIB.

The basic idea behind the LSR MIB is not to have every
protocol model its own LSP. The way the LIB table is
defined in the LDP MIB is under powered even by LDP
requirements. For example:
    - there is no notion of a label stack
    - label performance objects
    - finding the next-hop for a outgoing label
    - being able to manipulate the EXP bits

> the LDP MIB to be held up waiting for the LSR MIB. 

There's no need for the LSR MIB to support several ranges
to support LDP MIB. The LDP MIB continues to have its own
label ranges table.

> to support the first.  The LSR MIB is not needed for the LDP MIB.

No the LDP MIB requires LSR MIB for modelling the LSPs.
This precisely the reason why the WG choose to spin off the
LSR MIB as a separate document.

Besides, we are already requesting for a last call on the LSR MIB.
I have seen objections from only two people (one of them being
yourself) and either of them haven't quantified their objection yet.
I have posted the diffs of all the versions for your reference.

> Today this is NOT the case.

Wrong. See TE MIB. And again, there is no need for the LSR MIB
to support multiple label ranges. If the protocol MIBs such as
LDP MIB have such requirement then they maintain their own
ranges.

> an LSR should be able to run only one MPLS protocol without 

What if there is no protocol and LSPs need to be provisioned?

> and I would like to understand this prior to the LSR MIB going to

See the feature check (section 4) for the LSR MIB.
Its been there ALL ALONG. Please don't make it look like
a surprise expansion of scope for actually not having read it.

> is going to be part of the LSR MIB, or yet another draft? 

No. It is not required. See above.

> 
> In a way, I think that it is "too soon" for the LSR MIB.

Did you see the dates on the rev diffs I posted? What do you mean
"too soon"? Would you care to share your rule of thumb in
accessing this? Be specific.

> If all
> into an LSR MIB.

We need the MIB today. And it serves the purpose of all
existing protocols.

>
> I am concerned that the LSR MIB is actually trying

Can you explin to me how? Once again for your benefit, though
LDP has multiple label ranges requirement, it fits in this model
with the minimal change I suggested above.

-arun

---

From: Cheenu Srinivasan <[email-masked]>
Date: Thu, 16 Mar 2000 19:59:25 -0500

Joan,

Reading your email below I think there is a serious misunderstanding
here about the scope and purpose of the LSR MIB. I suggest a careful
comparative reading of the current and previous versions of the LSR
MIB to see for yourself that we have made no great or sudden changes in
the scope or implementation of this MIB. Please alse see my comments
below. 

> now states that it intends to support LDP.

It was always the intention of the MIB and the consensus of the WG from
over a year back that the LSR MIB not be specific to a particular MPLS
protocol. All protocol specific objects are to be supported by respective
RSVP/LDP/... MIBs. The purpose of the LSR MIB was to provide a common
model of the LSR/LSP for _all_ protocols. This also means that the
individual
protocol specific MIBs should not be reinventing an LSR/LSP model of their
own. If you go back to the Orlando presentation on the LSR MIB you
will see that the particular LSR model proposed (with nice powerpoint
pictures, no less :-) and agreed upon is identical to the one in the
the current as well as all preceding versions of the MIB.

> LDP MIB, he (and the rest of the working group) were

From that very time and in Minneapolis we said that the LDP MIB should
be pointing to the XC table of the LSR MIB. We have not introduced any
new objects that change the original model we proposed or the fact
that the FEC table of the LDP MIB should have a reference to the XC entry
in the LSR MIB. Rather than continue talking in generalities, I think it
will help all of us if you could please go through the diffs that Arun
posted and point out which objects you think we have suddenly sneaked into
the latest version of the MIB to precipidate this uproar.

> Now, they intend (apparently) to support LDP.

The agreement was always to make it as general as possible and no this
was not some change that was introduced in the current version.

> when there is already an active LDP MIB.

The LSR MIB does not do protocol specific things.
As I said before could you please point out these offending objects
which you claim have suddenly cropped up to change the very structure
of the MIB in this latest revision which were not there before?
  
> There has been NO working group consensus about including LDP in

Please see above.

> Why does the working group need two MIBs for LDP?

There is only one LDP MIB as far as I know. At the same time
there should not be two MIBs modelling an LSR. The LSR MIB should be
the only one doing that and that has been the agreed upon consensus all
along.

Thanks,
Cheenu