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