Subject: RE: Questions on unnumbered links

From: "Naidu, Venkata" <[email-masked]>
Date: Wed, 24 Oct 2001 14:57:04 -0400

Bora:

-> What still seems to be the issue?

  Apart from what David mentioned, can you please tell me
  in a simple scenario where if a manual (strict/loose) ERO 
  is calculated along the unnumbered links path, how could
  a Network Management entity preserve *uniqueness* of  
  interface IDs (about some remote unnumbered links)?!
  I don't think, even IfIndexes are preserved after reboots.

--Venkata Naidu

-> Eric Gray wrote:
-> 
-> > David,
-> >
-> >     Maybe I missed something: I thought support for 
-> unnumbered links
-> > needed to be added for GMPLS because there are problems with these
-> > links in the general case.  I was not aware that there are 
-> problems with
-> > unnumbered links in the Ethernet, PPP, ATM and Frame Relay cases or
-> > in basic signaling of MPLS explicit routes.
-> >
-> >     What exactly are the problems with using unnumbered 
-> links in the
-> > specific cases defined for MPLS?
-> >
-> > You wrote:
-> >
-> > > Yakov Rekhter wrote:
-> > > >
-> > > >> 4: Is there any way for an ingress router to compute 
-> an ERO with
-> > > >>    unnumbered links in it if GMPLS is not 
-> implemented?  It appears
-> > > >>    that support for unnumbered links was deleted from the TE
-> > > >>    versions of OSPF and ISIS, and moved into the 
-> GMPLS versions of
-> > > >>    those protocols, making the necessary information for ERO
-> > > >>    computation unavailable in an MPLS environment.
-> > > >
-> > > > You certainly don't need to implement all the GMPLS routing and
-> > > > signaling extensions in order to support unnumbered interfaces.
-> > >
-> > > Understood.  But if an ERO is to be auto-generated, and 
-> not manually
-> > > entered, the box doing the computation needs to know the 
-> topology.
-> > > Without the unnumbered extensions in OSPF/ISIS, any 
-> topology derived
-> > > from routing will not distinguish multiple parallel 
-> unnumbered links.
-> > > This will make it impossible to compute an ERO that uses 
-> the new ERO
-> > > subobject to specify one such link.
-> > >
-> > > It wouldn't be very nice to require all of GMPLS in 
-> order to compute an
-> > > ERO that specifies unnumbered links.
-> > >
-> > > I hope my explanation of this problem is clear.
-> > >
-> > > -- David
-> >
-> > --
-> > Eric Gray (mailto:[email-masked])
-> > http://www.mindspring.com/~ewgray
->

---

From: "Naidu, Venkata" <[email-masked]>
Date: Wed, 24 Oct 2001 18:25:43 -0400

->  ]  Unnumbered Links doesn't make any sense to Ethernet 
-> (broadcast media).
-> 
-> Just a simple comment on this, unnumbered interface can also 
-> be applied
-> to broadcast media such as Ethernet if using the IGP extension of
-> p2p-over-lan. for detail please check out:
-> 
-> http://www.ietf.org/internet-drafts/draft-ietf-isis-igp-p2p-o
-> ver-lan-00.txt

  To clarify, what I meant is strictly w.r.t RFC 1812 section 2.2.7.
  This is nothing to do with extending the notion to broadcast
  nets. In any case, here is my lemma, if you are able to extend 
  the unnumbered concept to broadcast nets, then you are almost
  redefining IP addressing. The notion of nexthop and/or L2 address
  binding will completely change. Am I right?

--Venkata Naidu

---

From: "Naidu, Venkata" <[email-masked]>
Date: Thu, 25 Oct 2001 18:23:18 -0400

Naiming:

-> 	The ping to the unnumbered interface, the draft is talking about
-> network operation issues. It's very common for NOC engineers to ping
-> remote router's interface IP addresses to determine if a 
-> link is up or
-> down, while ping to a router's loopback cannot determine a specific
-> link status; a traceroute does not show which link it 
-> traverses through
-> if a unnumbered address is used; you can't put link's name 
-> in DNS record
-> if its unnumbered; if you have parallel links between two routers, if
-> one link is not being used, a good troubleshooting way will 
-> be to ping
-> the other side interface IP address of this link(this assumes showing
-> both sides line status up but it just does not work somehow); when a
-> snmp trap comes into operation center, wouldn't it be nice to see
-> "oc12-link2-core2-ny-dc.xyz.net just down" instead of
-> "core2-ny.xyz.net link 238 just down"? All being said above, 
-> unnumbered
-> interface is VERY useful.

  I agree...

--Venkata Naidu