Hi Shishio, On Jul 11, 2012, at 5:58 AM, Shishio Tsuchiya wrote:
> Alvaro,Acee > I think the change is very good. > And I have some comments. > I agree with Acee's point about applicability of max-mum metric. > 1.Max-metric applicability is very large. > -After RFC3137 was published,it used on RFC5443 and RFC6138.(LDP-SYNC) Are you asking for a reference to these RFCs for the LDP-IGP synchronization use case? > -Most of operator are using max-metric to wait for BGP startup. > -Some operators using max-metric for traffic control. > It might be better if the draft mentions the applicability. > > Of course I know the motivation is including these descriptions. > But it would be more clear. > > 2.R-bit > I thought R-bit and v6 bit are better than maximum-metric on RFC5838 > environment. > +-->eBGP(v4) > R1--RFC5838--R2---+ > +-->eBGP(v6) I would agree with respect to the R-bit but RFC 5838 essentially deprecates the V6-bit for address families other than base IPv6 unicast address family. It was retained in the default address family for backward compatibility. Thanks, Acee > > It is easy to control. > > I would appreciate any comments. > > Regards, > > > > > > > (2012/07/11 4:47), Acee Lindem wrote: >> 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
