Acee (2012/07/11 23:01), Acee Lindem wrote: > 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?
Yes,I think it is better. > > >> -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. Um.Thank you for comments. I think we need more time and customer experience of RFC5838 to discuss this topic. Therefore it should not describe about RFC5838 in the draft. Thank you for correction. Regards, -Shishio > > 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:acee.lin...@ericsson.com] >>>>> Sent: Tuesday, July 10, 2012 2:31 PM >>>>> To: Retana, Alvaro >>>>> Cc: Shishio Tsuchiya; ospf@ietf.org >>>>> 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; ospf@ietf.org >>>>>>> Subject: RE: [OSPF] I-D Action: draft-ietf-ospf-rfc3137bis-01.txt >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Acee Lindem [mailto:acee.lin...@ericsson.com] >>>>>>>> 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 OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf
