Subject: Second WG last call on LSR MIB

From: George Swallow <[email-masked]>
Date: Thu, 04 May 2000 17:09:11 -0400

Folks -

The previous last call resulted in enough changes that a second WG
last call is in order.  The purpose of this last call is not to raise
new issues, but to insure that the issues raised in the previous last
call have been satisfactorily addressed.  As always, things that are
just plain broken are always fair game.

The last call will end Thurday, May 11, 5 pm edt.

The draft is:

MPLS Label Switch Router Management Information Base Using SMIv2
                                  
                   draft-ietf-mpls-lsr-mib-04.txt

...George

======================================================================
George Swallow       Cisco Systems                   (978) 244-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824

---

From: Arun Viswanathan <[email-masked]>
Date: Mon, 8 May 2000 17:21:44 -0700

Based on a few comments we would like to make the following
changes to the draft in the next rev (at the close of this call).

1. Removing mplsInSegmentAdminStatus, mplsInSegmentOperStatus,
   mplsOutSegmentAdminStatus, and mplsOutSegmentOperStatus from
   MplsInSegmentEntry and MplsOutSegmentEntry respectively. They
   seem to serve no purpose. Similar objects in MplsXCEntry subsumes
   their functionality.

2. Removing mplsInterfaceInPackets, mplsInterfaceInDiscards,
   mplsInterfaceOutPackets, and mplsInterfaceOutDiscards from
   the MplsInterfacePerfEntry.

If you have any objection to these changes please speak up now.

-arun

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of George
> Swallow
> Sent: Thursday, May 04, 2000 2:09 PM
> To: [email-masked]
> Subject: Second WG last call on LSR MIB
> 
> 
> Folks -
>

---

From: "Kullberg, Alan" <[email-masked]>
Date: Wed, 10 May 2000 14:53:55 -0400

The MplsLSPID is described as "This value is piggybacked
by the signaling protocol when the LSP is signaled within
the network."  However, this is only true for CR-LDP and
RSVP, since LDP does not have any TLV containing the LSPID
to pass along.

The question is what value should we have for the mplsXCLspId
object for a LDP LSP ?

Alan

---

From: "Cucchiara, Joan" <[email-masked]>
Date: Mon, 15 May 2000 10:37:13 -0400

Hi Alan,

You make a good point here.  Probably the
right thing to do would be to make this
object optional such that if the LSP is created
as a result of LDP or management then the 
object is not supported (because it cannot be).  
Otherwise, if it is created by a protocol which
support LSPIds (such as crldp, or rsvp) 
then this object has meaning.  A description could
be tied to the description of the Owner object
in the row.

I don't understand why the LSP ID currently varies
in size from 0..31 octets.   Could an LSP ID be
1 or 2 octets?

         -Joan

> From: Kullberg, Alan [mailto:[email-masked]]
> Sent: Wednesday, May 10, 2000 2:54 PM
> To: [email-masked]'
> Subject: RE: Second WG last call on LSR MIB
> 
>

---

From: Arun Viswanathan <[email-masked]>
Date: Wed, 17 May 2000 11:56:30 -0700

> From: Cucchiara, Joan [mailto:[email-masked]]
> Sent: Monday, May 15, 2000 7:37 AM
> To: 'Kullberg, Alan'; [email-masked]'

We agree that this is something that needs to be addressed.
We will creaste a new group in the manadatory group
section, and make group not part of the madatory
group section. If we hear no objection for this change,
we will add this in the next rev.
-arun