Subject: LDP MIB, version 9 outstanding issue

From: [email-masked]
Date: Sun, 13 Apr 2003 17:53:15 -0400

Hello Everyone,

From the Atlanta MPLS MIB meeting there was an outstanding issue
as described by the "MPLS MIB review meeting minutes" posted
to the mpls working group on Dec 03, 2002.  This issue
had to do with the change from version 8 of the MIB to
version 9.

Version 8 of the MIB had 3 Mapping tables, from an LDP LSP
to either an InSegment/OutSegment/XCSegment in the LSR-MIB.

Version 9 reduces this to 1 table and uses RowPointers.

The motivation for doing this was to reduce the number of
objects.  However, it turns out that this table is lacking
because the indexing will not be unique under certain
circumstances.  This was very well documented in email 
by Neil Jerram on Nov 15, 2002 "RE: Questions on LDP MIB v9".
This is repeated here for your convenience:

  "Here is a concrete example of the problem.  LSR A and LSR B each
   distribute a label to each other, and by chance they use the same
   label value, 67.  So in LSR A's mplsLdpLspTable, the label that A
   distributed to B has index:

     mplsLdpEntityLdpId      AA AA AA AA 00 01
     mplsLdpEntityIndex      1
     mplsLdpPeerLdpId        BB BB BB BB 00 01
     mplsLdpLspIfIndex       1
     mplsLdpLspLabel         67

   The label that A received from B has index:

     mplsLdpEntityLdpId      AA AA AA AA 00 01
     mplsLdpEntityIndex      1
     mplsLdpPeerLdpId        BB BB BB BB 00 01
     mplsLdpLspIfIndex       1
     mplsLdpLspLabel         67

   Which is exactly the same.  So the mplsLdpLspTable can't hold
   represent both of these labels at once."

Please note, the next version of the MIB will 
not have the mplsLdpLspTable.  Neil has proposed a solution
which is very detailed in that email (and repeated
at the end of this email).  I would like to incorporate his
these tables (or revised versions of these tables) 
into the next version of the MIB.

Does anyone have any objections with this change?

   Thanks, Joan

Quoting from Neil's email dated Nov 15th to the [email-masked]:

"Key points of my proposal are as follows.

- The new tables are:

  - mplsLdpUpLabelTable, describing labels distributed to upstream peers

  - mplsLdpDownLabelTable, describing labels received from downstream
    peers, including liberally retained and null labels.

- Like the tables that they replace in LDP MIB v9, these tables use
  RowPointers to point to LIB information in the LSR MIB.  They don't
  unnecessarily duplicate any information that can be obtained from
  the LSR MIB.

- Advantages in comparison with LDB MIB v9 are that:

  - mplsLdpDownLabelTable can show both established and liberally
    retained labels, and has a flag to indicate which labels are which

  - mplsLdpDownLabelTable can show multiple label mappings received
    from the same peer, for the same FEC, and with the same label
    value (this is most relevant for implicit and explicit null
    labels, but can also occur in some networks with non-null label
    values)

  - mplsLdpUpLabelTable and mplsLdpDownLabelTable can show a
    distributed label and a received label that share the same
    session, FEC and label value.

- mplsLdpUpLabelTable has a RowPointer to an mplsLdpDownLabelTable
  entry that can be used to show how upstream and downstream mappings
  are connected.

The full ASN.1 and a note on indexing are appended below.  Thank you
very much for your time.

     Neil

Indexing
========

The tables are indexed by (LDP session, FEC index, LSP index), where:

- LDP session is the usual (entity ldp id, entity index, peer ldp id)
- FEC index is a non-predictable index into the mplsFecTable
- LSP index is a non-predictable tie-breaker index for non-merging
  LSPs for the same FEC. 

The key benefit of this indexing is that it permits the
representation, for non-merging FECs, of the labels established by
multiple Label Request - Label Mapping exchanges through an LSR, even
when the labels distributed for different Label Requests are the same
(usually implicit and explicit nulls).

ASN.1
=====

     --
     --  The MPLS LDP Upstream Label Table
     --

     mplsLdpUpLabelTable OBJECT-TYPE
         SYNTAX      SEQUENCE OF MplsLdpUpLabelEntry
         MAX-ACCESS  not-accessible
         STATUS      current
         DESCRIPTION
             "A table mapping LDP sessions and FECs to the upstream
             labels distributed for those sessions and FECs, and to
             the corresponding LIB entries in the LSR MIB."
         ::= { mplsLdpSessionObjects 6 }

     mplsLdpUpLabelEntry OBJECT-TYPE
         SYNTAX      MplsLdpUpLabelEntry
         MAX-ACCESS  not-accessible
         STATUS      current
         DESCRIPTION
             "An entry in this table represents a label that has been
             distributed upstream for a particular session and FEC
             combination.  It is indexed by the session's index triple
             (mplsLdpEntityLdpId, mplsLdpEntityIndex,
             mplsLdpPeerLdpId), the FEC index (mplsFecIndex) and an
             LSP index (mplsLdpLspIndex) that distinguishes between
             non-merging LSPs for the same FEC. 

             The information contained in a row is read-only."
         INDEX       { mplsLdpEntityLdpId,
                       mplsLdpEntityIndex,
                       mplsLdpPeerLdpId,
                       mplsFecIndex,
                       mplsLdpLspIndex
                     }
         ::= { mplsLdpUpLabelTable 1 }

     MplsLdpUpLabelEntry ::= SEQUENCE {
         mplsLdpUpLabel                  MplsLabel,
         mplsLdpUpLabelType              MplsLdpLabelType,
         mplsLdpUpLspType                MplsLspType,
         mplsLdpUpDownLabelPointer       RowPointer,
         mplsLdpUpLsrInSegmentPointer    RowPointer,
         mplsLdpUpLsrXCPointer           RowPointer
     }

     mplsLdpLspIndex OBJECT-TYPE
         SYNTAX       Unsigned32
         MAX-ACCESS   not-accessible
         STATUS       current
         DESCRIPTION
             "A tie-breaker index that distinguishes between multiple
              non-merging LSPs for the same FEC.

              Where an LSR merges all LSPs for the same FEC, this
              field is not needed and should always be zero.

              Where an LSR does not merge LSPs for the same FEC, it is
              possible for the LSR to distribute (or receive) multiple
              label mappings for the same FEC to (or from) the same
              session, and for some of these labels to be equal (in
              particular where implicit and explicit null labels are
              in use).  In this case, the entries that describe the
              labels are distinguished from each other by using a
              different, non-zero value for this index field."
         ::= { mplsLdpUpLabelEntry 1 }

     mplsLdpUpLabel OBJECT-TYPE
         SYNTAX        MplsLabel
         MAX-ACCESS    not-accessible
         STATUS        current
         DESCRIPTION
             "The upstream label value."
         ::= { mplsLdpUpLabelEntry 2 }

     mplsLdpUpLabelType  OBJECT-TYPE
         SYNTAX        MplsLdpLabelType
         MAX-ACCESS    read-only
         STATUS        current
         DESCRIPTION
             "The Layer 2 upstream label type."
         ::= { mplsLdpUpLabelEntry 3 }

     mplsLdpUpLspType OBJECT-TYPE
         SYNTAX        MplsLspType
         MAX-ACCESS    read-only
         STATUS        current
         DESCRIPTION
             "The type of LSP connection for which this label is in
             use.  The possible values are:

                unknown(1)         --  if the LSP is not known
                                       to be one of the following.

               terminatingLsp(2)   -- if the LSP terminates
                                      on the LSR, then this
                                      is an ingressing LSP
                                      which ends on the LSR,

               originatingLsp(3)   -- if the LSP originates
                                      from the LSR, then this
                                      is an egressing LSP which is
                                      the head-end of the LSP,

             crossConnectingLsp(4) -- if the LSP ingresses
                                      and egresses on the LSR,
                                      then it is cross-connecting
                                      on that LSR."
         ::= { mplsLdpUpLabelEntry 4 }

     mplsLdpUpDownLabelPointer OBJECT-TYPE
         SYNTAX      RowPointer
         MAX-ACCESS  read-only
         STATUS      current
         DESCRIPTION
             "If this label is cross-connected to a received LDP
             downstream label mapping, this RowPointer should point to
             the entry in the mplsLdpDownLabelTable that describes the
             downstream label.

             Otherwise this field's value is zeroDotzero."
         ::= { mplsLdpUpLabelEntry 5 }

     mplsLdpUpLsrInSegmentPointer OBJECT-TYPE
         SYNTAX      RowPointer
         MAX-ACCESS  read-only
         STATUS      current
         DESCRIPTION
             "If this label has a corresponding entry in the LSR MIB
             mplsInSegmentTable, this RowPointer should point to that
             entry.

             Otherwise this field's value is zeroDotzero."
         ::= { mplsLdpUpLabelEntry 6 }

     mplsLdpUpLsrXCPointer OBJECT-TYPE
         SYNTAX      RowPointer
         MAX-ACCESS  read-only
         STATUS      current
         DESCRIPTION
             "If this label is cross-connected to a received LDP
             downstream label mapping and there is an entry
             describing this cross-connect in the LSR MIB mplsXCTable,
             this RowPointer should point to that entry.

             Otherwise this field's value is zeroDotzero."
         ::= { mplsLdpUpLabelEntry 7 }

     --
     --  The MPLS LDP Downstream Label Table
     --

     mplsLdpDownLabelTable OBJECT-TYPE
         SYNTAX      SEQUENCE OF MplsLdpDownLabelEntry
         MAX-ACCESS  not-accessible
         STATUS      current
         DESCRIPTION
             "A table mapping LDP sessions and FECs to the downstream
             labels received for those sessions and FECs, and to the
             corresponding LIB entries in the LSR MIB."
         ::= { mplsLdpSessionObjects 6 }

     mplsLdpDownLabelEntry OBJECT-TYPE
         SYNTAX      MplsLdpDownLabelEntry
         MAX-ACCESS  not-accessible
         STATUS      current
         DESCRIPTION
             "An entry in this table represents a label that has been
             received from a downstream peer for a particular session
             and FEC combination.  It is indexed by the session's
             index triple (mplsLdpEntityLdpId, mplsLdpEntityIndex,
             mplsLdpPeerLdpId), the FEC index (mplsFecIndex) and an
             LSP index (mplsLdpLspIndex) that distinguishes between
             non-merging LSPs for the same FEC.

             The information contained in a row is read-only."
         INDEX       { mplsLdpEntityLdpId,
                       mplsLdpEntityIndex,
                       mplsLdpPeerLdpId,
                       mplsFecIndex,
                       mplsLdpLspIndex
                     }
         ::= { mplsLdpDownLabelTable 1 }

     MplsLdpDownLabelEntry ::= SEQUENCE {
         mplsLdpDownLabel                  MplsLabel,
         mplsLdpDownLabelType              MplsLdpLabelType,
         mplsLdpDownLspType                MplsLspType,
         mplsLdpDownLiberal                TruthValue,
         mplsLdpDownLsrOutSegmentPointer   RowPointer,
         mplsLdpDownLsrXCPointer           RowPointer
     }

     mplsLdpDownLabel OBJECT-TYPE
         SYNTAX        MplsLabel
         MAX-ACCESS    not-accessible
         STATUS        current
         DESCRIPTION
             "The downstream label value."
         ::= { mplsLdpDownLabelEntry 1 }

     mplsLdpDownLabelType  OBJECT-TYPE
         SYNTAX        MplsLdpLabelType
         MAX-ACCESS    read-only
         STATUS        current
         DESCRIPTION
             "The Layer 2 downstream label type."
         ::= { mplsLdpDownLabelEntry 2 }

     mplsLdpDownLspType OBJECT-TYPE
         SYNTAX        MplsLspType
         MAX-ACCESS    read-only
         STATUS        current
         DESCRIPTION
             "The type of LSP connection for which this label is in
             use.  The possible values are:

                unknown(1)         --  if the LSP is not known
                                       to be one of the following.

               terminatingLsp(2)   -- if the LSP terminates
                                      on the LSR, then this
                                      is an ingressing LSP
                                      which ends on the LSR,

               originatingLsp(3)   -- if the LSP originates
                                      from the LSR, then this
                                      is an egressing LSP which is
                                      the head-end of the LSP,

             crossConnectingLsp(4) -- if the LSP ingresses
                                      and egresses on the LSR,
                                      then it is cross-connecting
                                      on that LSR."
         ::= { mplsLdpDownLabelEntry 3 }

     mplsLdpDownLiberal OBJECT-TYPE
         SYNTAX      TruthValue
         MAX-ACCESS  read-only
         STATUS      current
         DESCRIPTION
             "Whether this is a liberally retained downstream label."
         DEFVAL { false }
         ::= { mplsLdpDownLabelEntry 4 }

     mplsLdpDownLsrOutSegmentPointer OBJECT-TYPE
         SYNTAX      RowPointer
         MAX-ACCESS  read-only
         STATUS      current
         DESCRIPTION
             "If this label has a corresponding entry in the LSR MIB
             mplsOutSegmentTable, this RowPointer should point to that
             entry.

             Otherwise this field's value is zeroDotzero."
         ::= { mplsLdpDownLabelEntry 5 }

     mplsLdpDownLsrXCPointer OBJECT-TYPE
         SYNTAX      RowPointer
         MAX-ACCESS  read-only
         STATUS      current
         DESCRIPTION
             "If this label is cross-connected to a distributed LDP
             upstream label mapping and there is an entry describing
             this cross-connect in the LSR MIB mplsXCTable, this
             RowPointer should point to that entry.

             Otherwise this field's value is zeroDotzero."
         ::= { mplsLdpDownLabelEntry 6 }"

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Sun, 13 Apr 2003 23:47:24 -0400

>Does anyone have any objections with this change?

         I think the only other point made during the
meeting was to make these tables optional in the
conformance.

         --Tom

>(usually implicit and explicit nulls).

http://www.elsevier-international.com/catalogue/title.cfm?ISBN=155860751X

---

From: Ravi Malhotra <[email-masked]>
Date: Tue, 15 Apr 2003 14:23:53 +0200

Hi Joan,

We have discussed the proposal of Neil internally in our group and have
the following comments.

1. mplsLdpUpLspType : The value of originatingLsp(3) would be invalid in
this case as an upstream label would never be at the head-end of an LSP.
The same also applies to mplsLdpDownLspType where the value of
terminatingLsp(2) would be invalid.

2. mplsLdpUpLsrXCPointer : in case of point-to-multipoint connections,
we can have the same upstream label connected to multiple downstream
labels. In that case, this object would no longer be unique. 
Suggestion - use mplsXCIndex i.s.o row-pointer; the other indices of the
mplsXCTable can be derived from other objects in this table.

3. mplsLdpDownLiberal : This object is redundant and its value can
instead be determined from the mplsLdpDownLsrOutSegmentPointer. If the
label is liberally-retained and not-in-use, then it would not have an
out-segment and correspondingly no entry in the mplsOutSegmentTable.
Thus, if the value of mplsLdpDownLsrOutSegmentPointer is 0.0, then the
label is liberally-retained.

4. mplsLdpDownLsrXCPointer : in case of multipoint-to-point connections,
we can have the same downstream label connected to multiple upstream
labels. In that case, this object would no longer be unique.
Suggestion - use mplsXCIndex i.s.o row-pointer.

5. How can we represent label-stacking in LDP via this MIB. The
label-stacking could be either
- LDP LSPs over RSVP-TE tunnels.
- PWE-LDP (Martini) LSPs over core LDP/RSVP - LSPs.

Suggestion - Each core LSP (LDP/RSVP) can be represented by an if-index
in the IF-MIB. If we include the if-index in the above tables then we
can find out whether the LSP goes via a physical-interface or a
'tunnel-interface'.

6. Whether mplsLdpLspIndex is really required ? - it may happen in
non-merging MPLS networks that the downstream peer (the egress LSR)
might send the same label (implicit/explicit-NULL) for the same FEC to
the same peer for mutiple Label-Requests. However, from an operational
point of view - all these entries would be the same and the LSR would
indeed be 'merging'. As such, these entries would just be unneccessary
duplicates conveying no extra information.
Also, from a deployment point of view, MPLS networks where
implicit/explicit-NULL labels (i.e. generic labels) are used, generally
support merging. Only in case of legacy layer-2 networks like ATM/FR,
merging may not be supported. In these cases, one can never have the
duplicate label/FEC/Peer combination as it would force these LSRs to do
merging.

Suggestion: mplsLdpUpLabel & mplsLdpDownLabel are quite sufficient as
indices for mplsLdpUpLabelTable & mplsLdpDownLabelTable i.s.o
mplsLdpLspIndex.

7. In our implementation of the LDP-LIB tables, we use
mplsLdpLabelDirection as an additional index to determine whether the
label/FEC has been advertised or received. 
The addition of this object to the mplsLdpLspTable in LDP-MIB version 9,
would solve the problem with the uniqueness of the indexing as pointed
out by Neil. At the same time, we can avoid having multiple tables
and/or a large number of indices in the MIB.

Thanks for your time in going through these comments.

Warm regards,
Ravi 

----------------------------------------------------
Ravi Malhotra                          
WX-25, Alcatel-Bell,                   
Antwerpen-2016, Belgium.               
                                       
email: [email-masked]           
phone : +32-3240-9738                     
----------------------------------------------------

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 15 Apr 2003 12:42:48 -0400

>can find out whether the LSP goes via a physical-interface or a

         I don't understand how assigning an IfIndex to an LSP is going to
work.  This sounds like something that is implementation-specific.
The label stack is represented either in the LSR MIB as it is
defined today.  If you want to see the application-specific label,
then look in the PWE3 MIBs as a short-hand. The PPVPN-MPLS-VPN MIB is
also going to be modified to show the VPN label as well.  However,
in either case, the ingress labels should be available in the LSR MIB
as a point of reference.

         --Tom

---

From: [email-masked]
Date: Wed, 16 Apr 2003 09:38:18 +0200

> work.  This sounds like something that is implementation-specific.

MPLS-TE MIB (draft-ietf-mpls-te-mib-09.txt) allows for defining an MPLS tunnel
as an interface.
mplsTunnelIsIf object is set to true(1) for tunnels to be used as interface
and an entry is created in the ifTable with the ifIndex of the tunnel.

Below is the text from the MPLS-TE-MIB.

mplsTunnelEntry OBJECT-TYPE
   SYNTAX        MplsTunnelEntry
   MAX-ACCESS    not-accessible
   STATUS        current
   DESCRIPTION
        "An entry in this table represents an MPLS tunnel.
          An entry can be created by a network administrator
          or by an SNMP agent as instructed by an MPLS
          signalling protocol. Whenever a new entry is
          created with mplsTunnelIsIf set to true(1), then a
          corresponding entry is created in ifTable as well
          (see RFC 2863). The ifType of this entry is
          mplsTunnel(150)."

> in either case, the ingress labels should be available in the LSR MIB

How would you represent the tunneling LDP into RSVP-TE at the ingress LSR of
the RSVP-TE tunnel?
Where would you store the labels (LDP label and RSVP label) that need to be
pushed? In the label stack table of the LSR-MIB or higher layer.

Regards, Riza.

---

From: bhuvan laddha <[email-masked]>
Date: Tue, 15 Apr 2003 22:02:04 -0700 (PDT)

Hi,

I would appreciate clarification for the following
points in the
'draft-ietf-ccamp-gmpls-sonet-sdh-08.txt':

1. Last paragraph of section 2. 'SONET and SDH Traffic
Parameters' states as 

" The traffic parameters and label encoding defined in
[RFC3471]
   Section 3.2 MUST be used for fully transparent
STS-1/STM-0/STS-
   3*N/STM-N (N=1, 4, 16, 64, 256) signal requests. A
fully
   transparent signal is one for which all overhead is
left
   unmodified by intermediate nodes, i.e., when all
defined
   Transparency (T) bits would be set if the traffic
parameters
   defined in section 2.1 were used."

Whereas one of the paragraph of section 3. 'SONET and
SDH Labels' states as 

" The label format defined in this section, referred
to as SUKLM,
   MUST be used for any SONET/SDH signal requests that
are not
   transparent i.e. when all Transparency (T) bits
defined in section
   2.1 are set to zero. Any transparent
STS-1/STM-0/STS-3*N/STM-N
   (N=1, 4, 16, 64, 256) signal request MUST use a
label format as
   defined in [RFC3471]. "

I want to know - 
	whether Section 3.2 of RFC3471 is applicable for any
or fully transparent signal ?
  	If that so, section 3.2 of RFC3471 doesn't specific
any format for SONET/SDH label.
	So, Is it fine to use generalized label in this case?

Please correct me if I missed something...

__________________________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo
http://search.yahoo.com

---

From: [email-masked]
Date: Wed, 16 Apr 2003 12:46:51 +0200

hi,

 > or fully transparent signal ?

for fully transparent signal only (i.e. in the second
statement it clearly refers to "full" transparency)

 > 	So, Is it fine to use generalized label in this case?

in this case, the G_LABEL of section 3.2 applies.

thanks,
- dimitri.

-- 
Papadimitriou Dimitri
E-mail : [email-masked]
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 16 Apr 2003 11:47:08 -0400

>How would you represent the tunneling LDP into RSVP-TE at the ingress LSR of

         You would show the LSP in the LSR MIB being switched to
the TE label.

>pushed? In the label stack table of the LSR-MIB or higher layer.

         In the LSR MIB's XC table.  The question above asked how to do LDP/TE.
The forwarding/label stacking is different from the interface stacking
used to accomplish this. The ifStack looks like:

         Outgoing Interface:

         TE
         MPLS
         underlying layer (enet for instance)

         Incoming Interface:
         MPLS
         underlying layer (enet)

         The cross-connection on a switch to do this might be:

         Incoming LDP label, incoming interface -> NULL outgoing label

         NULL incoming label -> outgoing TE tunnel label, outgoing TE interface
                 XC defines a push with the incoming LDP label in the
                 label stack table.

         So the resulting outgoing label stack would be LDP label/TE label.
However, that would go out of the TE interface/MPLS interface.

         --tom

---

From: bhuvan laddha <[email-masked]>
Date: Thu, 17 Apr 2003 00:05:08 -0700 (PDT)

Hi,
Thanks for the your valuable information ...

Please correct me for the following points :

1.a.Are the following labels valid for GMPLS LSP of
STS1 LINE SECTION TRANSPARENCY flag ?
Labels : S > 0  U > 0 K = 0 L = 0 M = 0 
It means , the whole time slot ( label range ) from   
( s > 0 U > 0 K = 0 L = 0 M = 0 ) to 
( s > 0 U > 0 k = 0 L = 7 M = 9 ) get allocated .

1.b.Now Can I use the next GMPLS LSP with the fully
transparency STS1 signals for the same SONET Network
Element [NE] ?
( pl. tell me whether we can have fully transparent as
well as any transparency LSP on the same NE ... )

1.c.If yes,the G_LABEL will get used for fully
transparent LSP.
Then same label value can get used for G_LABEL and
SUKLM Label .
So Is their any intelligence in hardware of Network
Element [NE] to identify this?

2. If I required the contiguous Label ( time-slot )
for the SONET STS_3_SPE for NCC = 12 
( RCC flag Standard Contiguous Concatenation is set )
;
Then time slot will be between 
 S = i and  S = i + 12 ( i > 0 ) whereas others fields
are from 0 to max values .
label will be( S > 0 U = 0 K = 0 L = 0 M = 0 N = 0 )

3. How do I get the sections 7.3.7 to 7.3.13 of G.707 
( or SONET ANSI [T1.105] materials ) ?
Are these material freely avail on InterNet ?

Regards ,
--- bhuvan

--- [email-masked] wrote:
> Private:
> http://www.rc.bel.alcatel.be/~papadimd/index.html

---

From: [email-masked]
Date: Thu, 17 Apr 2003 11:51:12 +0200

>                  XC defines a push with the incoming LDP label in the

In this case, mplsLdpDownLabel object (defined in the mplsLdpDownLabelTable of
Neil's proposal) will be LDP label (inner label) while
mplsLdpDownLsrOutSegmentPointer object (of the same mplsLdpDownLabelTable entry)
points to an out-segment entry configured with the REVP-TE label. Would it not be
confusing?

---

From: [email-masked]
Date: Thu, 17 Apr 2003 12:17:56 +0200

hi, see in-line

> STS1 LINE SECTION TRANSPARENCY flag ?

see the paragraph just before section 4.
"Note: when a Section/RS or Line/MS transparent STS-1/STM-0/STS-
    3*N/STM-N (N=1, 4, 16, 64, 256) signal is requested, the SUKLM
    label format and encoding is not applicable and the label encoding
    MUST follow the rules defined in [RFC3471] Section 3.2."

in brief the rule is:
- fully transparent signal request -> G_LABEL_REQUEST and G_LABEL
   of rfc3471
- (non-fully) transparent signal request -> G_LABEL_REQUEST of sonet-sdh
   and G_LABEL of rfc3471
- sonet/sdh signal request -> sonet-sdh for both the G_LABEL_REQUEST
   and the G_LABEL

> well as any transparency LSP on the same NE ... )

that's a data plane capability and by same NE what
do you mean interface/shelf/node (?)

> Element [NE] to identify this?

the "labels" that we speak about here are processed
at the *control plane* level (internal or local mapping
rules are outside of the scope - see also rfc3471)

> label will be( S > 0 U = 0 K = 0 L = 0 M = 0 N = 0 )

here, just follow the rule only one label appears in the
label field which identifies the lowest time-slot
occupied by the contiguously concatenated signal

> Are these material freely avail on InterNet ?

www.t1.org

>>>1. Last paragraph of section 2. 'SONET and SDH
>>
>>Traffic
>>
>>>Parameters' states as 
>>>
>>>" The traffic parameters and label encoding
>>
>>defined in
>>
>>>[RFC3471]
>>>   3*N/STM-N (N=1, 4, 16, 64, 256) signal
>>
>>requests. A
>>
>>>fully
>>>   transparent signal is one for which all
>>
>>overhead is
>>
>>>left
>>>   unmodified by intermediate nodes, i.e., when
>>
>>all
>>
>>>defined
>>>   Transparency (T) bits would be set if the
>>
>>traffic
>>
>>>parameters
>>>Whereas one of the paragraph of section 3. 'SONET
>>
>>and
>>
>>>SDH Labels' states as 
>>>
>>>" The label format defined in this section,
>>
>>referred
>>
>>>to as SUKLM,
>>>   MUST be used for any SONET/SDH signal requests
>>
>>that
>>
>>>are not
>>>	whether Section 3.2 of RFC3471 is applicable for
>>
>>any
>>
>>>  	If that so, section 3.2 of RFC3471 doesn't
>>
>>specific
>>
>>>	So, Is it fine to use generalized label in this
>>
>>case?
>>
>>>

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 17 Apr 2003 08:45:08 -0400

>points to an out-segment entry configured with the REVP-TE label. Would it 

         That is how it works; the outgoing label is owned by the TE 
application.

         --tom

---

From: "Amit Singh" <[email-masked]>
Date: Thu, 17 Apr 2003 12:45:22 -0700

Is there a Draft that is gonna be standardized for Point to multipoint l2vpn
??? khandekar or koempella ??? Just like martini

Regards

---

From: "Xiaoning He" <[email-masked]>
Date: Mon, 21 Apr 2003 11:07:06 -0700

Dear All

I apology if I send this to the wrong list. 

I have a question regarding the advantages of MPLS network. Besides the
obvious advantages such as TE, has there anyone look at improvement of
the link utilization, end-to-end latency, etc comparing to the IP
routing based network? 

Please give me any kind of comments.

Thank you

Xiaoning

-----------------------------
 
Xiaoning He, Ph.D
Research Engineer
 
NTT-DoCoMo USA Labs
181 Metro Drive, Suite 300
San Jose, CA 95110
 
Email: [email-masked]
Phone: +1 (408) 451-4737
Fax:   +1 (408) 573-1090

---

From: [email-masked]
Date: Sat, 26 Apr 2003 12:57:48 -0400

Hi Ravi,

Thank you for the comments.  Please see responses inline.

>terminatingLsp(2) would be invalid.

This TC has been reworded in the TC MIB.  So think the definition is
better now.

>mplsXCTable can be derived from other objects in this table.

LDP does not support point-to-multipoint.  It is not a goal of the MIB
to support this, since the spec doesn't.  Having said that, consider
this suggestion.

>Suggestion - use mplsXCIndex i.s.o row-pointer.

Same comment as above for #2.

>can find out whether the LSP goes via a physical-interface or a

I believe this was answered in email discussion between Tom and Riza.

>indices for mplsLdpUpLabelTable & mplsLdpDownLabelTable i.s.o

As I mentioned, there will likely be revisions to the original tables
proposed by Neil.  This appears to be a simplification and 
so we will consider this.

>and/or a large number of indices in the MIB.

We will consider this also.  However, in my opinion, it is sometimes
better to use separate tables and have simpler indexing.  The number of
objects will remain the same even with 2 tables.

>Thanks for your time in going through these comments.

Thanks for the comments,
  -Joan