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
