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