Subject: Re: LDP MIB last call

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 09 Mar 2000 14:11:44 -0500

I still have two major objections to the current
state of the LDP MIB. There are two tables: the LIB
and the FEC tables, which I and the authors of the
TE/LSR MIBs would like removed. Rob Schmitt also
requested that these tables be removed prior to
version -05 of the MIB. These tables are at least in
part, redundant to that which is present in the LSR
MIB. I have posted several messages to the mailing list
requesting discussion on this issue, and both times
I have not received any responses from the authors, nor
have they replied to the mailing list.  I will ask again for
this discussion to commence.

         --Tom

>We would like to commence the last call for:
>
>Definitions of Managed Objects for the Multiprotocol Label Switching, 
>Label Distribution Protocol (LDP)
>draft-ietf-mpls-ldp-mib-05.txt
>
>Last call will end on Friday, March 17.  Please send your comments to the 
>list.
>
>Regards,
>- Vijay

---

From: Piers Finlayson <[email-masked]>
Date: Fri, 10 Mar 2000 10:19:54 -0000

Tom,
 
There is some common information stored in both the LIB and FEC tables in
the LDP MIB and in the LSR MIB.  However, there is no way in the LSR MIB to
associate FECs with labels.
 
You mentioned in reply to an email from Adrian Farrel that you were working
on a Packet Classifier MIB.  I suspect there is some concern on the mailing
list in removing the LIB and FEC tables from the LDP MIB before seeing the
Packet Classifier MIB - we certainly have this concern.  Is the Packet
Classifier MIB nearing completion?  If not, could you go into some more
detail on exactly what this MIB will contain?
 
Thanks,
Piers
--------------------------------------------------------- 
Piers Finlayson 

ATM, MPLS and Telecoms Group 
Data Connection Ltd. 

Tel:   +44 20 8366 1177     Fax: +44 20 8363 4478 
Email: [email-masked]     Web: http://www.datcon.co.uk
<http://www.datcon.co.uk/>  
--------------------------------------------------------- 

-----Original Message-----
From: Thomas D. Nadeau [mailto:[email-masked]]
Sent: Thursday, March 09, 2000 7:12 PM
To: Vijay Srinivasan; [email-masked]'
Cc: [email-masked]'; Cheenu Srinivasan; Arun Viswanathan (E-mail);
Thomas D. Nadeau (E-mail); [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: LDP MIB last call

        --Tom

Definitions of Managed Objects for the Multiprotocol Label Switching, Label
Distribution Protocol (LDP) 
draft-ietf-mpls-ldp-mib-05.txt 

Regards, 
- Vijay

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Fri, 10 Mar 2000 07:18:09 -0500

--Tom

---

From: Arun Viswanathan <[email-masked]>
Date: Tue, 14 Mar 2000 11:23:50 -0800

I think there are two separate issues here. First is the
self-contained LSR table in the LDP MIB. I believe this must
go. The LSR MIB has been around for a while and has been through
several rounds of scrutiny. The LDP MIB needs only to point to
a cross-connect entry in the LSR MIB and be done with.

The second issue here is that of the FEC in the LDP MIB. The proposed
packet-classifier MIB was primarily designed for redirecting
traffic into MPLS tunnels at the head-end. The FEC requirements
in the LDP MIB is more like extending the FIB MIB (rfc2096?)
with label information. The right way to address the LDP requirement
IMHO would be to extend the FIB MIB to include label information.
The packet-classifier does encompass this functionality in a way,
however, I can understand the debate over the second issue.

-arun

> From: David Wilder [mailto:[email-masked]]
> Sent: Tuesday, March 14, 2000 10:33 AM
> To: Cheenu Srinivasan
> Cc: [email-masked]; [email-masked]'; Arun Viswanathan (E-mail);
> [email-masked]; [email-masked];
> [email-masked]; [email-masked]; 'Thomas D.
> Nadeau'; Vijay Srinivasan
> Cheenu,
> Isn't it a little premature to remove those tables from the 
> LDP MIB when there
> has not been an acceptable alternative?  I'd rather a little 
> redundancy than
> the to use the new proposed MIB which hasn't had the scrutiny 
> that the LDP
> MIB has had.
> 
> Dave
> 
> 
> [Charset iso-8859-1 unsupported, filtering to ASCII...]
> > I have the same objections to the current LDP MIB as Tom. The LIB
> > and the FEC tables are not specific to LDP and do not belong here.
> > The first one is part of the LSR MIB already and the second one
> > should be in a seperate packet classifier MIB. They should 
> be removed
> > before the LDP MIB goes to last call. 
> > 
> > I have seen several messages on this topic but no response from the
> > authors thus far.
> > 
> > Thanks,
> > Cheenu Srinivasan
> > 
> > Sent: Friday, March 10, 2000 7:18 AM
> > To: Vijay Srinivasan; [email-masked]

---

From: Joan Cucchiara <[email-masked]>
Date: Tue, 21 Mar 2000 09:27:21 -0500

> From: Jhilmil Kochar [mailto:[email-masked]]
> Sent: Tuesday, March 21, 2000 2:46 AM
> To: Joan Cucchiara
> Cc: 'Hans Sjöstrand'; [email-masked]'
> Hi Joan,
> > > > 6. mplsLdpEntityPeerEntry: It is not clear why the entries
> > > in this table
> > > > should not be present in session table. As far as I can
> > > make out these
> > > > parameters and also the parameters in session table are
> > > passed in init
> > > > message between peers, hence the purpose for keeping them
> > > in separate
> > > > tables is not clear. One possible reasoning I could 
> come up with was
> > > > that one gives peer information that is non-negotiable and
> > > other gives
> > > > peer information that is negotiated. But then this rule
> > > does not hold
> > > > true for all entries. Please clarify.
> >
> > The split between the two tables were for values used in
> > an active Session, versus values which were ignored by the
> > session (although a session is still created).
> >
> > The objects in the EntityPeer Table are related
> > to PathVectorLimit and are used to generate a trap if a
> > mismatch occurs.  The Session uses the PathVector value which
> > is in the Entity Table if there is a mismatch between the
> > two values.
> >
> > We probably should add more text here then, if this is
> > not clear.

Hi Jhilmil,

> 
> More text would be helpful. Does this mean there there will 
> always be a
> one-one mapping beween a Peer entry and a session entry? ie 
> one LDP Peer can
> have only one session with the entity? The indexing for both 
> is the same,
> but the draft does not explicitly mention this.

The mplsEntityPeerEntry (above called Peer entry) is information
related to a session (i.e. information which is obtained during
the session initialization process) which is why the indexing is
the same as the session's.  This information is the Peer's
PathVector information which is exchanged during session init
time. The Entity's PathVector info is in the Entity Table.
The session will always use the Entity's PathVector Info.
The only reason to keep track of the Peer's PathVector Info
is to send a trap in the event that the PathVector Limit's
for a specific session is not the same as the Entity's (in other words, the
Peer has a different Limit than the Entity).  This is about
the only case where a session will still be established without
having to negotiate (i.e. change values).   

We will add more text and perhaps a name change to this
table as it seems to continues to be a point of confusion.

For your answer about the relationship to the mplsEntityPeer
entry and the Session Entry, they are one-to-one because
the information is related to a specific session establishment.
Perhaps an Augment's relationship would be more clear...

Thanks, Joan

> 
> 
> Thanks and regards
> Jhilmil
> 
> --
> 
> ------------------------------
> Jhilmil Kochar
> Ficon Technology
> E-mail:[email-masked]
> Web: www.ficon-tech.com
> 
> 
>

---

From: Rob Schmitt <[email-masked]>
Date: Tue, 21 Mar 2000 10:47:03 -0800

......
......

Hi Joan..
We could have seen the confusion coming..as I said before,
a peer is a peer is a peer, so making it 'entitypeer' says -WHAT-??
I have an idea, maybe we could call it 'mplsPeerEntry'.
:)
/rs

---

From: Vijay Srinivasan <[email-masked]>
Date: Wed, 22 Mar 2000 11:47:37 -0800

The last call for the LDP MIB has closed.  Could the authors please make
changes based on comments during the last call and issue a new version?

- Vijay

> From: 	Vijay Srinivasan  
> Sent:	Thursday, March 09, 2000 10:30 AM
> To:	[email-masked]'
> Cc:	[email-masked]'
> Subject:	LDP MIB last call
> 
> 
list.