Subject: Re: OSPF sham link

From: Quaizar Vohra <[email-masked]>
Date: Mon, 3 Oct 2005 11:55:44 -0700

Acee,

What this draft proposes is in contradiction with rfc 2328, section
12.4.1.1. I am not sure if an ietf spec should be imposing unnecessary
restrictions.

Quaizar

 > Kalyan Bade wrote:
 > 
 > >Acee,
 > >
 > >  
 > >
 > >>I recently commented on that this should be clarified in the draft.
 > >>    
 > >>
 > >The
 > >  
 > >
 > >>reason the sham endpoint should
 > >>not be redistributed or advertised in OSPF is that sham link endpoint
 > >>reachability
 > >>is used to determine whether or not sham link is up. If the sham link
 > >>endpoint is advertised in OSPF
 > >>the sham link would provide a viable path and greatly complicate this
 > >>determination.
 > >>    
 > >>
 > >
 > >Thanks for the response. I understand what you are saying, but isn't a
 > >purely implementation thing? If we do this, we end up loosing
 > >connectivity to the loopback from other routers. This might be not
 > >desirable in some scenarios. Aren't we restricting something just
 > >because implementations cannot deal with it? Let me know your thoughts.
 > >  
 > >
 > <speaking as a WG member who has reviewed 
 > draft-ietf-l3vpn-ospf-2547-04.txt several times>
 > 
 > Hi Kalyan,
 > 
 > This draft broke new ground since it documented specific mechanisms for
 > both protocol redistribution and protocol interaction. Prior to the draft,
 > these topics were pretty much left to the implemenations (at least in 
 > the case of
 > OSPF). In order to ensure interoperability, these topics needed to be 
 > documented.
 > Like any problem, there are multiple ways in solve it and different 
 > tradeoffs that
 > can be made. Given the number of reviews and last calls on the draft, 
 > I'd say
 > there would need to be a pretty compelling reason in order to change 
 > this now.
 > 
 > Thanks,
 > Acee
 > 
 > >Thanks,
 > >Kalyan.
 > >
 > >  
 > >

---

From: Peter Psenak <[email-masked]>
Date: Mon, 3 Oct 2005 21:21:54 +0200

Quaizar,

where do you think this contradicts 12.4.1.1. Sham-link is advertised as 
unnumbered p2p link...

thanks,
Peter

---

From: Quaizar Vohra <[email-masked]>
Date: Mon, 3 Oct 2005 13:04:37 -0700

Here is part of the text in that section. I am talking of option 1
below.

Quaizar

		o   In addition, as long as the	state of the interface
		    is "Point-to-Point"	(and regardless	of the
		    neighboring	router state), a Type 3	link (stub
		    network) should be added. There are	two forms that
		    this stub link can take:

		    Option 1
			Assuming that the neighboring router's IP
			address	is known, set the Link ID of the Type 3
			link to	the neighbor's IP address, the Link Data
			to the mask 0xffffffff (indicating a host
			route),	and the	cost to	the interface's
			configured output cost.[15]

		    Option 2
			If a subnet has	been assigned to the point-to-
			point link, set	the Link ID of the Type	3 link
			to the subnet's	IP address, the	Link Data to the
			subnet's mask, and the cost to the interface's
			configured output cost.[16]

---

From: Peter Psenak <[email-masked]>
Date: Mon, 3 Oct 2005 22:34:20 +0200

Quaizar,

> Here is part of the text in that section. I am talking of option 1

that is valid for numbered links... anyway, most of the implementations 
these days use Option 2 for numbered links.

thanks,
Peter

---

From: Quaizar Vohra <[email-masked]>
Date: Mon, 3 Oct 2005 14:06:47 -0700

Peter,

I don't think option 1 applies to only numberred links. Also
option 2 is only valid for subnetted point-to-point links
and not to unnumberred or numberred (yet not subnetted) links.

Though option 1 itslf is hacky. My point is that not allowing
sham-link end-point to be advertised in OSPF seems gratuitous.

Quaizar

---

From: Acee Lindem <[email-masked]>
Date: Mon, 3 Oct 2005 22:46:30 -0400

Hi Quaizar,

>and not to unnumberred or numberred (yet not subnetted) links.
In every implementation I've worked on or written, the stub link has 
been omitted for
unnumbered point-to-point links. You'll note that in the example in 
12.4.1.5, RT3's
backbone LSA doesn't include a stub link for the unnumbered interface.. 
However,
this isn't the main point of this discussion.

>sham-link end-point to be advertised in OSPF seems gratuitous.
I checked to see when the handling of the sham link endpoint address was 
first
documented and it dates back to section 4.2.3 of 
draft-rosen-vpns-ospf-bgp-mpls-01.txt
(February 2001). What is the compelling reason to change it now after 
this many draft
iterations and after multiple WG last calls?

Thanks,
Acee