Re: OSPF sham link

[Peter Psenak <[e-mail]>]

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.
>  > >  > >
>  > >  > >  
>  > >  > >
>  > > 
>