Re: [OSPF] I-D Action: draft-ietf-ospf-rfc3137bis-01.txt

[Acee Lindem <[e-mail]>]

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:[e-mail]]
>>>> Sent: Tuesday, July 10, 2012 2:31 PM
>>>> To: Retana, Alvaro
>>>> Cc: Shishio Tsuchiya; [e-mail]
>>>> 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; [e-mail]
>>>>>> Subject: RE: [OSPF] I-D Action: draft-ietf-ospf-rfc3137bis-01.txt
>>>>>> 
>>>>>>> -----Original Message-----
>>>>>>> From: Acee Lindem [mailto:[e-mail]]
>>>>>>> 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.
>>>>> 
>>> 
>> 
> 
> 
>