Hi Alvaro, On Jul 10, 2012, at 3:36 PM, Retana, Alvaro wrote:
> Acee: > > Your point is that because the V6-bit only stops IPv6 traffic, and it doesn't > make the whole router a stub, then we shouldn't mention it here. Sure, that > sounds reasonable. That and, more importantly, one would want an OSPF stub router's local interfaces (especially loopbacks) to be reachable for I-BGP and targeted LDP. Thanks, Acee > > Alvaro. > >> -----Original Message----- >> From: Acee Lindem [mailto:[email protected]] >> Sent: Tuesday, July 10, 2012 2:31 PM >> To: Retana, Alvaro >> Cc: Shishio Tsuchiya; [email protected] >> Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-rfc3137bis-01.txt >> >> Hi Alvaro, >> I agree with the scope of the changes but I wouldn't mention the V6-bit >> since it really doesn't satisfy the stub router requirements. Actually, >> the only use case I can imagine for the V6-bit is to snoop the OSPFv3 >> topology but not be reachable throughout the OSPFv3 routing domain. I'm >> not sure what the original authors envisioned but I suspect they >> thought it might help in supporting other address families. Anyway, If >> you only consider the R-bit, it both satisfies the stub router >> requirements and simplifies the text: >> >> OSPFv3 [RFC5340] introduced additional options to provide similar, if >> not better, control of the forwarding topology; the R-bit provides >> a more granular indication of whether an OSPFv3 router should be >> used for transit traffic. >> >> On the other hand, clearing the R-bit will consistently result >> in the router not being used for IPv6 transit traffic. >> >> Do you agree? Any opinions from others? >> >> Thanks, >> Acee >> >> On Jul 10, 2012, at 10:48 AM, Retana, Alvaro wrote: >> >>> Hi! >>> >>> Before I publish an update I want to make sure that we're covering >> what you want covered. >>> >>> I pasted below the relevant sections. Note that the new sections are >> 3.1 and the second paragraph in Section 5. >>> >>> Thanks! >>> >>> Alvaro. >>> >>> >>> ... >>> 3. Solutions >>> >>> The solution introduced in this document solves two challenges >>> associated with the outlined problem. In the description below, >>> router X is the router announcing itself as a stub. >>> >>> 1) Making other routers prefer routes around router X while >>> performing the Dijkstra calculation. >>> >>> 2) Allowing other routers to reach IP prefixes directly connected >> to >>> router X. >>> >>> Note that it would be easy to address issue 1) alone by just >> flushing >>> router X's router-LSA from the domain. However, it does not solve >>> problem 2), since other routers will not be able to use links to >>> router X in Dijkstra (no back link), and because router X will not >>> have links to its neighbors. >>> >>> To address both problems, router X announces its router-LSA to the >>> neighbors with the costs of all non-stub links (links of the types >>> other than 3) set to MaxLinkMetric. >>> >>> The solution above applies to both OSPFv2 [RFC2328] and OSPFv3 >>> [RFC5340]. >>> >>> 3.1. OSPFv3-only Solution >>> >>> OSPFv3 [RFC5340] introduced additional options to provide similar, >> if >>> not better, control of the forwarding topology; the R-bit and the >> V6- >>> bit provide a more granular indication of whether a router is >> active >>> and/or whether it should be used specifically for IPv6 traffic, >>> respectively. >>> >>> It is left to network operators to decide which technique to use in >>> their network. >>> >>> >>> 4. Maximum Link Metric >>> >>> ... >>> >>> 5. Deployment Considerations >>> >>> When using MaxLinkMetric, some inconsistency may be seen if the >>> network is constructed of routers that perform intra-area Dijkstra >>> calculation as specified in [RFC1247] (discarding link records in >>> router-LSAs that have a MaxLinkMetric cost value) and routers that >>> perform it as specified in [RFC1583] and higher (do not treat links >>> with MaxLinkMetric cost as unreachable). Note that this >>> inconsistency will not lead to routing loops, because if there are >>> some alternate paths in the network, both types of routers will >> agree >>> on using them rather than the path through the stub router. If the >>> path through the stub router is the only one, the routers of the >>> first type will not use the stub router for transit (which is the >>> desired behavior), while the routers of the second type will still >>> use this path. >>> >>> On the other hand, clearing the R-bit/V6-bit will consistently >> result >>> in the router not being used as transit and/or specifically for >> IPv6 >>> traffic, respectively. >>> >>> >>>> -----Original Message----- >>>> From: Retana, Alvaro >>>> Sent: Monday, July 02, 2012 12:23 PM >>>> To: 'Acee Lindem' >>>> Cc: Shishio Tsuchiya; [email protected] >>>> Subject: RE: [OSPF] I-D Action: draft-ietf-ospf-rfc3137bis-01.txt >>>> >>>>> -----Original Message----- >>>>> From: Acee Lindem [mailto:[email protected]] >>>>> Sent: Monday, July 02, 2012 11:29 AM >>>> ... >>>>>> Besides from the reference (see below), what else do you think we >>>>> should include? >>>>>> >>>>>> The point I'm trying to make is: rfc5340 already defines and >>>>> documents the R-bit functionality (and it is the standard!). IMHO, >>>>> there is no need to rehash here what is already defined and >> explained >>>>> somewhere else...which is why I think the reference is enough. >>>>> >>>>> I don't think you have to describe the mechanism. However, I agree >> R- >>>>> bit should be on equal ground as the max-metric links. Also, it >> would >>>>> be good to point out the difference in behavior. With max-metric >>>> links, >>>>> transit traffic is discouraged while with the R-bit, transit >> traffic >>>> is >>>>> completely suppressed. >>>> >>>> Ok, I'll work on that. >>>> >>>> Alvaro. >>> >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
