The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2001-Nov> msg00046



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

changes to unnumbered and link bundling

  • From: Bora Akyol <bora@cisco.com>
  • Date: Wed, 07 Nov 2001 10:35:22 -0800
  • CC: mpls@UU.NET
  • Organization: Cisco Systems

If the operator does not have control over the interface identifiers be it IP
addr or a 32 bit identifier, then they should not be specifying it as part of
the constraints.

Ideally, there needs to be a management knob to specify interface identifiers
for TE purposes statically.

Bora


"Abarbanel, Benjamin" wrote:

> What I was refering to, is someone writes a script configuring constraints
> for ERO
> CSPF calculations, but is unable to predetermine the Interface identity
> ahead of time
> if it's defined by an Ifindex and router ID) as an unnumbered interface.
> Since Ifindex
> is dynamic in nature the script will fail if the router affected is
> rebooted.
>
> Ben
>
> of that router. Normally
> file containing
>
> -----Original Message-----
> From: Bora Akyol [mailto:bora@cisco.com]
> Sent: Tuesday, November 06, 2001 6:51 PM
> To: Abarbanel, Benjamin
> Cc: mpls@UU.NET
> Subject: Re: changes to unnumbered and link bundling
>
> CSPF computation is based on the routing database obtained from the IGPs, if
> interface identifiers change, the database will be updated.
>
> This is more of an imlementation specific question.
>
> Bora
>
> "Abarbanel, Benjamin" wrote:
>
> > Hi all:
> >   I have one concern regarding the use of EROs and Router ID/Ifindex to
> > define
> > specific unnumbered interfaces in the network. Constraint routing usually
> > defines certain constraints (for CSPF) calculation sake based on
> interfaces
> > identified via IP addresses the problem with identifying interfaces which
> > are
> > unnumberd with router ID and Ifindex is that the Ifindex is dynamic and
> > changes
> > within the scope of the router especially during a reconfig of the
> interface
> > or
> > reboot of the router. If someone, in another router wanted to write
> > a static CLI based script to specify certain Constraint policies on in
> > interface
> > that is unnumbered he/she could not do it based on a Ifindex, because he
> > would not
> > know its value or be able to predict it will have the same value through a
> > reboot
> > of the router.
> >
> > How do we solve this one folks?
> >
> > Ben
> >
> > -----Original Message-----
> > From: Bora Akyol [mailto:bora@cisco.com]
> > Sent: Tuesday, November 06, 2001 12:41 PM
> > To: Nabil Seddigh; Yakov Rekhter
> > Cc: mpls@UU.NET
> > Subject: Re: changes to unnumbered and link bundling
> >
> > This is similar to the discussion we had on the expanded ERO issue
> > (draft-akyol-mpls-expanded-ero-00.txt, now expired) a while ago. I concur
> > with Yakov that one has to identify unnumbered interfaces by the tuple
> > (Router ID, ifindex) where ifindex is some 32 bit quantity assigned by the
> > router that is advertising this interface in the IGP TE advertisements.
> >
> > If one does sit on a broadcast media where a router may have multiple
> > interfaces sitting on the same segment, then even the proposal below is
> not
> > sufficient to uniquely identify the full path specified by the ERO.
> >
> > As A1 uniquely identifies the egress interface out of A, but we can not
> > identify (assuming that this is happening on an Ethernet segment where B
> has
> > multiple interfaces connected) which ingress interface of B we want to
> use.
> >
> > Which is why I think, the best way to specify an ERO is to write
> > Router ID, Egress Interface, Router ID, Ingress Interface
> >
> > This leaves pretty much nothing to "interpretation" and results in a
> precise
> > definition.
> >
> > If there is interest, I may revive the expanded ERO draft.
> >
> > Bora
> >
> > ----- Original Message -----
> > From: Yakov Rekhter <yakov@juniper.net>
> > To: Nabil Seddigh <nseddigh@tropicnetworks.com>
> > Cc: <mpls@UU.NET>
> > Sent: Tuesday, November 06, 2001 8:03 AM
> > Subject: Re: changes to unnumbered and link bundling
> >
> > > Nabil,
> > >
> > > > The proposed change is not quite clearly stated. Can you please
> > > > restate in more precise language. Is it possible to put a diagram
> > > > in the draft? E.g if we have nodes A,B,C,D with unnumbered i/f
> > > > 1-6 (I have made them distict for ease of illustration):
> > > >
> > > >       1       2   3          4   5      6
> > > >     A --------- B ------------ C -------- D
> > > >
> > > > The language in Section 6 of the unnum-02 draft would appear to
> > > > mandate an unnumbered ERO as follows: A1,B3,C5
> > > >
> > > > What are you proposing to change it to?
> > > > Is it B1,C3,D5?
> > >
> > > Certainly not, as I am proposing that "The Interface ID is the interface
> > > identifier assigned to the interface by the LSR specified by the router
> > ID."
> > >
> > > With this in mind B1 is not a valid combination, as the interface
> > > identifier 1 is assigned by A, not by B. And with my proposal
> > > you can't put in the Unnumbered Interface subobject the
> > > interface identifier assigned to the interface by one LSR, and
> > > the router ID of some other LSR.
> > >
> > > Ditto for C3 and D5.
> > >
> > > Yakov.
> > >
> > > P.S. Just like a numbered interface on an LSR is identified by the
> > > IP address that the LSR assigns to that interface, I am suggesting
> > > that an unnumbered interface be identified by the identified
> > > (i/f index) that the LSR assigns to that interface and the Router-ID
> > > of the LSR itself.
> > >