Re: OSPF sham link

[Quaizar Vohra <[e-mail]>]

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


 > Quaizar,
 > 
 > Quaizar Vohra wrote:
 > > Here is part of the text in that section. I am talking of option 1
 > > below.
 > 
 > that is valid for numbered links... anyway, most of the implementations 
 > these days use Option 2 for numbered links.
 > 
 > thanks,
 > Peter
 > 
 > > 
 > > 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]
 > > 
 > > 
 > >  > Quaizar,
 > >  > 
 > >  > where do you think this contradicts 12.4.1.1. Sham-link is advertised as 
 > >  > unnumbered p2p link...
 > >  > 
 > >  > thanks,
 > >  > Peter
 > >  > 
 > >  > Quaizar Vohra wrote:
 > >  > > 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.
 > >  > >  > >
 > >  > >  > >  
 > >  > >  > >
 > >  > > 
 > >