Re: [OSPF] Re: OSPFv3: Vlink Instance Id

[Acee Lindem <[e-mail]>]

Hi Paul,
Paul Wells wrote:

> Hi Acee,
>
> Acee Lindem wrote:
>
>> Hi Paul,
>>
>> Paul Wells wrote:
>>
>>> Hi Acee,
>>>
>>> Acee Lindem wrote:
>>>
>>>> Paul, Vivek,
>>>>
>>>> Here is the suggested text. Note that I also moved
>>>> the local source address checking under OSPF processing to match the
>>>> disucssion of support for multiple interfaces attached to the same 
>>>> link.
>>>>
>>>> Thanks,
>>>> Acee
>>>
>
> <snip>
>
>>>>
>>>>
>>>> o  The Area ID and Instance ID found in the OSPF header must be
>>>>      verified.  If both of the following cases fail, the packet should
>>>>      be discarded.  The Area ID and Instance ID specified in the  
>>>> header
>>>>      must either:
>>>>
>>>>
>>>>      1.  Match one of the Area ID(s) and Instance ID(s) for the
>>>>          receiving interface.  
>>>
>>>
>>>
>>> While I agree with the sentiment, can we really imply here that an 
>>> interface can have multiple Area IDs and/or Instance IDs? 
>>> Notwithstanding draft-ietf-ospf-multi-area-adj and 
>>> draft-ietf-ospf-af-alt there are a number of other places in the 
>>> existing RFCs that contradict this.
>>
>>
>> I think this was one (if not the primary) motivation for the OSPFv3
>> interface instance ID. I realize not all implementations support it 
>> but I
>> know of at least one that does. If I remember correctly, there is also
>> some additional code (I mean text) that needs to be added to the section
>> on intra-area prefix LSAs.
>
>
> Are we talking about "physical" interfaces or interfaces as defined by 
> an OSPF interface structure?  As it happens, I wrote the packet input 
> code for an implementation that allows multiple OSPFv3 instances to 
> share a physical interface, however in that case each OSPFv3 instance 
> has it's own interface structure with a single instance ID value.

Ok - I see your point but it is semantics rather than functionality.
 I mean physical interface. I think if I change the text to say
"receiving link" it should be clear.

Thanks,

>
> Thanks,
> Paul
>
>>
>> Thanks,
>> Acee
>>
>>
>>>
>>> Thanks,
>>> Paul
>>>
>>>>          Unlike IPv4, the IPv6 source address is
>>>>          not restricted to lie within the same IPv6 subnet as the
>>>>          receiving interface.  IPv6 OSPF runs per-link instead of per-
>>>>          IP-subnet.
>>>>
>>>>      2.  Match the backbone area and other criteria for a configured
>>>>          virtual link.  The receiving router must be an ABR (Area
>>>>          Border Router) and the Router ID specified in the packet (the
>>>>          source router) must be the other end of a configured virtual
>>>>          link.  Additionally, The receiving interface must attach to
>>>>          the virtual link's configured transit area and the  
>>>> Instance ID
>>>>          must match the virtual link's Instance ID.  If all of these
>>>>          checks succeed, the packet is accepted and is from now on
>>>>          associated with the virtual link (and the backbone area).
>>>>
>>>>   o  Locally originated packets SHOULD NOT be processed by OSPF except
>>>>      for support of multiple interfaces attached to the same link as
>>>>      described in Section 3.9.  Locally originated packets have a
>>>>      source address equal to one of the router's local addresses.
>>>>
>>>> Thanks,
>>>> Acee
>>>
>
> <snip>
>

_______________________________________________
OSPF mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ospf