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.
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 >> > _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
