The MPLS WG Archive

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



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

changes to unnumbered and link bundling

  • From: "Abarbanel, Benjamin" <Benjamin.Abarbanel@Marconi.com>
  • Date: Wed, 7 Nov 2001 14:50:25 -0500
  • Cc: mpls@UU.NET



 


>> MAC Address is 48 bits. You need a 32 bit identifer. I also don't think
that POS
interfaces have unique HW identifiers. >>

The interface identifier only has to be unique within the scope of the
router that the interface 
is defined. What we really need is a number that is static, so perhaps we
need to define another such field in the interface structure like
ifr_hwaddr. I personnally dont care which one we choose for this effort. I
just think Ifindex will not work for us in all applications.

BTW don't we have to support IP V6 which is 128 bits long? How are all the
protocols equipped
to handle the unnumbered interfaces defined with IPV6 router ID (128 bits)
and (16 bits)
Ifindex?
  

Bora


"Abarbanel, Benjamin" wrote:

> Bora:
>   I would agree that there needs to be a management knob to specify
> interface
> IDs that are static for TE purposes. I recommend we use the interface
> hardware
> address, in most cases this number is either configured statically by
> management
> system or is burnt into the adopter port card (e.g. ethernet MAC address).
>
> So I would say that an unnumbered interface could be defined by its "IP
> Router ID"
> and its "hardware interface address". In most IP interfaces there is
already
> a
> field assigned for the hardware interface address. Typically that field is
> reflected
> in the "ifr_hwaddr" field of the (struct ifreq) IP interface structure.
> Usually its a
> MAC address but it could be any interface type hardware address.
>
> Regards,
> Ben
>
> -----Original Message-----
> From: Bora Akyol [mailto:bora@cisco.com]
> Sent: Wednesday, November 07, 2001 1:35 PM
> To: Abarbanel, Benjamin
> Cc: mpls@UU.NET
> Subject: Re: changes to unnumbered and link bundling
>
> 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.
> > > >