Re: OSPF sham link

[Acee Lindem <[e-mail]>]

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