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
