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