Subject: RE: changes to unnumbered and link bundling

From: "Abarbanel, Benjamin" <[email-masked]>
Date: Wed, 7 Nov 2001 11:07:29 -0500

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:[email-masked]]
Sent: Tuesday, November 06, 2001 6:51 PM
To: Abarbanel, Benjamin
Cc: [email-masked]
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:[email-masked]]
> Sent: Tuesday, November 06, 2001 12:41 PM
> To: Nabil Seddigh; Yakov Rekhter
> Cc: [email-masked]
> 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 <[email-masked]>
> To: Nabil Seddigh <[email-masked]>
> Cc: <[email-masked]>
> 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.
> >

---

From: Bora Akyol <[email-masked]>
Date: Wed, 07 Nov 2001 10:35:22 -0800

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