The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2001-Jul> msg00514



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

Doubts about MPLS-TE Mib

  • From: "Thomas D. Nadeau" <tnadeau@cisco.com>
  • Date: Mon, 30 Jul 2001 10:18:25 -0400
  • Cc: "'mpls@UU.NET'" <mpls@UU.NET>

At 07:18 PM 7/30/2001 +0530, Apratim Mukherjee wrote:
>Hi Tom ,
>
>Thanks for the clarification .
>         >>But , this is also being used as extended tunnel id , in which
>case it COULD
>         >>be 0 ... then isn't there an indexing problem ?
>         >        Why? 0 is a perfectly valid index.
>What i meant here is that if extended tunnel id is 0 , then IngressLSRId is
>0 (If Extended Tunnel Id is ALWAYS same as IngressLSRId). If IngressLSRId is
>0 , then Sender Template ip address is 0.0.0.0  , if this is same as Ingress
>LSR Id  . This is wrong since information about the sender Ip address is
>absolutely essential . I  think there shoud be a separate field for Extended
>Tunnel Id as this has no necessary relation with IngressLSRId . ( They only
>MIGHT be same ) .

         This is an artifact of how the protocol works,
and the MIB models the protocols. I personally think
that the protocol should have made the Ingress
LSR Id mandatory for the reason you stated, but it
didn't. Fortunately, all of the implementations I know
of to insert the loopback address in this field, so
operationally there should not be any problem
(and have not been from what I have heard/seen).

         --Tom



>Hope this is more clear
>Thanks
>Apratim
>
>         ----------
>         From:   Thomas D. Nadeau[SMTP:tnadeau@cisco.com]
>         Sent:   Monday, July 30, 2001 7:08 PM
>         To:     Apratim Mukherjee; 'mpls@UU.NET'
>         Subject:        RE: Doubts about MPLS-TE Mib
>
>         At 07:41 PM 7/26/2001 +0530, Apratim Mukherjee wrote:
>         > > Hi ,
>         > >
>         > > Thanks for the clarifications . But a few doubts persist ...
>         > > >2. the object mplsTunnelIngressId is defined to be used as the
>         > > >ExtendedTunnelId .
>         > >
>         > >          Yes.
>         > >
>         > > >But then where will the SenderTemplate object's
>         > > >Sender IP address come from ?
>         > >
>         > >          EgressTunnelId.
>         >First , do you mean EgressLSRId by this ... but this could only be
>         >IngressLSRId if anything .
>         >
>         >But , this is also being used as extended tunnel id , in which case
>it COULD
>         >be 0 ... then isn't there an indexing problem ?
>
>                  Why? 0 is a perfectly valid index.
>
>         >I realise that this question has been asked before but i could not
>find any
>         >satisfactory conclusion to a thread that speaks about this .
>         >One of the promising threads ends on this note from David Charlap (
>from the
>         >archives :
>http://cell.onecall.net/mhonarc/mpls/2001-pr/msg00426.html)
>         > >Then there is potential for conflict between the TE MIB and
>RSVP-TE
>         > >itself. ...........
>         > >I can only assume that the TE MIB was based upon the features of
> >RSVP-TE
>         >that are commonly in use, and can not fully accomodate all of >its
>features.
>         >If someone build a router that supports multipoint-to-point >LSPs
>using
>         >RSVP-TE, the TE MIB will have to be updated, or that
> >implementation will be
>         >unable to properly represent these kinds of LSPs >using it.
>         >
>         >Is this then an unresolved problem ?
>
>                  I don't think that this is still a problem. The current
>indexing
>         comes right from the RSVP/CR-LDP specifications, so if there is
>         a problem, those protocols will be broken too.
>
>                  --Tom