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

[Paul Wells <[e-mail]>]

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.

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