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

From: "Retana, Alvaro" <[email-masked]>
Date: Mon, 2 Jul 2012 11:15:58 +0000

> -----Original Message-----
> From: Shishio Tsuchiya [mailto:[email-masked]]
> Sent: Saturday, June 30, 2012 12:54 AM

Shishio:

...
> http://tools.ietf.org/html/draft-ietf-ospf-rfc3137bis-01#section-4.1
> I think maximum both metric and R-bit should be equivalence in today
> and future.
> In order to avoid confusing for people,I recommend
> -remove the sentence from abstract.
> "However, OSPF does not specify a standard way to accomplish this."

I will remove that.

> -move R-bit to solution from Deployment Considerations
> ex.)
> 3.  Proposed Solution
> 3-1.maximum metric
> 3-2.R-bit
> 
> What do you think of my recommendation?

3173 is about documenting the MaxLinkMetric approach, which is why we chose to reference the R-bit as other solutions.  3137 is not about comparing or describing the full functionality of the different approaches.

Thanks!

Alvaro.

---

From: Acee Lindem <[email-masked]>
Date: Mon, 2 Jul 2012 09:56:07 -0400

Hi Alvaro, 

> 3173 is about documenting the MaxLinkMetric approach, which is why we chose to reference the R-bit as other solutions.  3137 is not about comparing or describing the full functionality of the diffe…

The main we respin RFCs is to incorporate changes and there is no reason not to document the R-bit mechanism to accomplish the OSPFv3 stub router function. 

Thanks,
Acee 

> 
> Thanks!
> 
> Alvaro.
> _______________________________________________
> OSPF mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ospf

---

From: "Retana, Alvaro" <[email-masked]>
Date: Mon, 2 Jul 2012 15:05:33 +0000

Acee:

> From: Acee Lindem [mailto:[email-masked]]
> Sent: Monday, July 02, 2012 9:56 AM
...
> > 3173 is about documenting the MaxLinkMetric approach, which is why we
> chose to reference the R-bit as other solutions.  3137 is not about
> comparing or describing the full functionality of the different
> approaches.
> 
> The main we respin RFCs is to incorporate changes and there is no
> reason not to document the R-bit mechanism to accomplish the OSPFv3
> stub router function.

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.

Thanks!

Alvaro.

4.1.  Other Solutions

   This document describes a technique that has been implemented and
   deployed in a wide variety of networks.  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.

---

From: Acee Lindem <[email-masked]>
Date: Mon, 2 Jul 2012 11:29:21 -0400

Alvaro,

> 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 explaine…

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. 

Thanks, 
Acee

---

From: "Retana, Alvaro" <[email-masked]>
Date: Mon, 2 Jul 2012 16:23:08 +0000

> Sent: Monday, July 02, 2012 11:29 AM
...
> > 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.

---

From: "Retana, Alvaro" <[email-masked]>
Date: Tue, 10 Jul 2012 14:48:40 +0000

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.

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.

> From: Retana, Alvaro
> Sent: Monday, July 02, 2012 12:23 PM
> To: 'Acee Lindem'
> Cc: Shishio Tsuchiya; [email-masked]
> Subject: RE: [OSPF] I-D Action: draft-ietf-ospf-rfc3137bis-01.txt
>

---

From: Acee Lindem <[email-masked]>
Date: Tue, 10 Jul 2012 14:30:33 -0400

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

---

From: "Retana, Alvaro" <[email-masked]>
Date: Tue, 10 Jul 2012 19:36:02 +0000

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.

> Sent: Tuesday, July 10, 2012 2:31 PM
> To: Retana, Alvaro
> 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:
> 
> > 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
> >
> >>> transit traffic is discouraged while with the R-bit, transit
> traffic
> >> is
> >>> completely suppressed.
> >>
> >> Ok, I'll work on that.
> >>
> >> Alvaro.
> >

---

From: Acee Lindem <[email-masked]>
Date: Tue, 10 Jul 2012 15:47:34 -0400

Hi Alvaro, 

> 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

---

From: Shishio Tsuchiya <[email-masked]>
Date: Wed, 11 Jul 2012 18:58:50 +0900

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,

---

From: Acee Lindem <[email-masked]>
Date: Wed, 11 Jul 2012 10:01:06 -0400

Hi Shishio,

> -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? 

> I thought R-bit and v6 bit are better than maximum-metric on RFC5838 environment.

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

---

From: Shishio Tsuchiya <[email-masked]>
Date: Sat, 14 Jul 2012 21:34:20 +0900

Acee
> Are you asking for a reference to these RFCs for the LDP-IGP synchronization use case?

Yes,I think it is better.

> 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 famil…

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

---

From: "Retana, Alvaro" <[email-masked]>
Date: Sat, 14 Jul 2012 15:17:39 +0000

> Sent: Saturday, July 14, 2012 8:34 AM
...
> Yes,I think it is better.

6138 points to 5443, which points to 3137

Any now 3137bis, which would be referenced by 3137 (as its successor) would point to 6138 and 5443...   I'm no expert, but isn't that a loop? ;-)

Seriously, I think all this pointing around is overkill.

Are you trying to propose that we write an applicability section?  I'm afraid that whatever we specifically (i.e. with references) mention will not be complete because potentially other applications may come up.  The "Motivation" section (which I pasted below) already mentions some of the use cases (at a high level).   For example, the LDP sync application fits under graceful introduction, as well as waiting for BGP.

If you have specific text you want to suggest adding to the motivation (that doesn't make the new RFC become outdated faster), then we would be very glad to consider it.

Thanks!

Alvaro.

1. Motivation

   In some situations, it may be advantageous to inform routers in a
   network not to use a specific router as a transit point, but still
   route to it.  Possible situations include the following:

   o  The router is in a critical condition (for example, has very high
      CPU load or does not have enough memory to store all LSAs or build
      the routing table).

   o  Graceful introduction and removal of the router to/from the
      network.

   o  Other (administrative or traffic engineering) reasons.

   Note that the proposed solution does not remove the router from the
   topology view of the network (as could be done by just flushing that
   router's router-LSA), but prevents other routers from using it for
   transit routing, while still routing packets to the router's own IP
   addresses, i.e., the router is announced as a stub.

   It must be emphasized that the proposed solution provides real
   benefits in networks designed with at least some level of redundancy
   so that traffic can be routed around the stub router.  Otherwise,
   traffic destined for the networks reachable through such a stub
   router will be still routed through it.

---

From: Shishio Tsuchiya <[email-masked]>
Date: Mon, 16 Jul 2012 00:41:26 +0900

Alvaro
> If you have specific text you want to suggest adding to the motivation (that doesn't make the new RFC become outdated faster), then we would be very glad to consider it.

Yes,I agree that it should not be redundant.
If one sentence adds to the Solution section which describes maximum link metric,how is it?

2.  Solution
2.1.  Maximum Link Metric

The solution is already well-using with other protocol, such as  "wait for BGP startup", "LDP-Sync [RFC6138] [RFC5443]".

or

The solution is already implemented in a lot of vendors, it also works together with other protocols, such as "wait for BGP startup", "LDP-Sync [RFC6138] [RFC5443]".

2.2 R-bit (or OSPFv3 only solution)
....

Regards,
-Shishio

> .