Re: OSPF sham link

[Quaizar Vohra <[e-mail]>]

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