Re: OSPF sham link

[Acee Lindem <[e-mail]>]

Hi Quaizar,

Quaizar Vohra wrote:

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

>Though option 1 itslf is hacky. My point is that not allowing
>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

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