Hi Faraz, I agree that this is a viable use case for OSPFv3. However, I don't see it as one that can be handled with autoconfiguration. I will try and clarify this in example in the next revision. Thanks, Acee
On Sep 27, 2012, at 10:04 AM, Faraz Shamim (sshamim) wrote: > Acee, > > I am not sure why you think that the same instance can not be used for the > ISP link. The fact that you will enable OSPFv3 in a passive mode, instance > ID really won't matter here. > > Faraz > > On 9/24/12 11:42 AM, "Acee Lindem" <[email protected]> wrote: > >> Hi Faraz, >> >> On Sep 24, 2012, at 12:11 PM, Faraz Shamim (sshamim) wrote: >> >>> Hi Acee, >>> >>> In my point 2) below, I am not saying to enable OSPFv3 towards ISP for >>> the >>> purpose of forming OSPFv3 neighbor relationship with ISP. I am saying >>> that >>> in eBGP case, you do need to enable OSPFv3 on the link towards the >>> service >>> provider(in passive mode) because this ISP link is needed to be known as >>> an IGP because BGP will cary this next-hop "as is" in its iBGP updates >>> unless we do next-hop-self. This is one aspect of interaction between >>> BGP >>> and IGP where you need to carry the eBGP next-hop in your IGP. >> >> I understood. What I meant was that this would not be an autoconfigured >> instance of OSPFv3 and it would most likely not be the same instance as >> is running on non-ISP facing interfaces. >> >> Thanks, >> Acee >> >> >>> >>> Thanks, >>> >>> Faraz >>> >>> On 9/24/12 10:47 AM, "Acee Lindem" <[email protected]> wrote: >>> >>>> Hi Faraz, >>>> Thanks for review. >>>> >>>> On Sep 21, 2012, at 1:43 PM, Faraz Shamim (sshamim) wrote: >>>> >>>>> Hi Acee, >>>>> >>>>> Not opposing this idea but have 4 comments here: >>>>> >>>>> 1) >>>>> >>>>> In section 5.2.1: >>>>> >>>>> The OSPFv3 Auto-Configuration (AC) LSA has a function code of TBD and >>>>> the S1/S2 bits set to B'01' indicating Area Flooding Scope. >>>>> >>>>> I think it should say S2/S1 as mentioned in RFC 5340. Since S2 comes >>>>> before S1 in packet format so it make sense to use the same sequence >>>>> in >>>>> your text. >>>> >>>> Yes - will update. >>>> >>>> >>>>> >>>>> Also, not sure what you meant by letter 'B' next to '01'. >>>> >>>> I mean these are bits. I will see whether or not this is used >>>> elsewhere. >>>> >>>>> >>>>> 2) >>>>> >>>>> In section 2.2: >>>>> >>>>> >>>>> For example, if manual >>>>> configuration or an other condition indicates that an interface >>>>> is connected to an Internet Service Provider (ISP), there is >>>>> typically no need to employ OSPFv3. However, note that in many >>>>> environments it can be useful to test whether an OSPFv3 adjacency >>>>> can be established. In home networking environments, an >>>>> interface where no OSPFv3 neighbors are found but a DHCP prefix >>>>> can be acquired may be considered as an ISP interface. >>>>> >>>>> >>>>> >>>>> In a situation when you are running eBGP with an ISP and iBGP >>>>> internally, >>>>> it is required to enable OSPFv3 on the ISP link unless you are using >>>>> next-hop-self in BGP. So in that case excluding ISP link is a bad >>>>> idea. >>>>> Also in this case enabling OSPFv3 with passive-interface would make >>>>> sense. >>>> >>>> You certainly wouldn't run OSPFv3 in the same routing domain with the >>>> ISP >>>> box. >>>> This is really only an example but I could qualify OSPFv3 as >>>> "autoconfigured OSPFv3". >>>> >>>> >>>> >>>>> >>>>> 3) >>>>> >>>>> In section 2.4: >>>>> >>>>> OSPFv3 interfaces MUST auto-configure the default HelloInterval >>>>> and RouterDeadInterval as specified in [OSPFV3]. >>>>> >>>>> I think the "auto-configure" part is confusing here. We do not >>>>> "configure" >>>>> the default values when we enable OSPFv3 on an interface. A better >>>>> sentence in my opinion would be: >>>>> >>>>> OSPFv3 interfaces MUST use the default HelloInterval >>>>> and RouterDeadInterval as specified in [OSPFV3]. >>>> >>>> Ok. >>>> >>>>> >>>>> >>>>> 4) In section 5.2.1, wouldn't it be better to use the field >>>>> name/letter >>>>> instead of the actual value? >>>> >>>> These fields are referred to by the bit names in RFC 5340. >>>> >>>> >>>> >>>>> For example instead of mentioning 1 0 1 it >>>>> should say U S2 S1 and in the explanation section it should mention >>>>> the >>>>> default value for AC LSA. Same logic goes for using TBD instead of >>>>> "LSA >>>>> Function Code" >>>> >>>> This is pretty much standard text for adding an OSPFv3 LSA. The text >>>> excerpted below >>>> includes the name of the bits, value, and the designation. >>>> >>>> The OSPFv3 Auto-Configuration (AC) LSA has a function code of TBD and >>>> the S1/S2 bits set to B'01' indicating Area Flooding Scope. The U >>>> bit will be set indicating that the OSPFv3 AC LSA should be flooded >>>> even if it is not understood. >>>> >>>> Note that we want to specify these bits precisely rather than the >>>> defaults. >>>> >>>> Thanks, >>>> Acee >>>> >>>> >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Faraz >>>>> >>>>> On 9/17/12 1:58 PM, "Acee Lindem" <[email protected]> wrote: >>>>> >>>>>> We had some support of making >>>>>> http://www.ietf.org/id/draft-acee-ospf-ospfv3-autoconfig-03.txt an >>>>>> OSPFv3 >>>>>> WG document at IETF 84. The impetus is: >>>>>> >>>>>> 1. OSPFv3 being considered as homenet routing protocol and >>>>>> autoconfiguration is a requirement. >>>>>> 2. Work on OSPFv3 configuration has started in the past in other WGs >>>>>> but not finished. >>>>>> 3. Current proposal has gone through a couple revision cycles with >>>>>> incremental comments addressed. >>>>>> >>>>>> Is anyone opposed? >>>>>> >>>>>> Thanks, >>>>>> Acee _______________________________________________ >>>>>> OSPF mailing list >>>>>> [email protected] >>>>>> https://www.ietf.org/mailman/listinfo/ospf >>>>> >>>> >>> >> >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
