Subject: Comments on OSPF PC/CE Drafts

From: Acee Lindem <[email-masked]>
Date: Fri, 26 Jul 2002 12:49:36 -0400

I posted this on the PPVPN list. I'm posting here as well since some
of  you may not be aware of these drafts....

Here are my comments on draft-rosen-vpns-ospf-bgp-mpls-04.txt and
draft-rosen-ppvpn-ospf2547-area0-00.txt:

General:

              -  It would seem that these two drafts could be combined since
                 draft-rosen-ppvpn-ospf2547-area0-00.txt only contains a couple
                 paragraphs of unique information. This would also avoid all
                 references in draft-rosen-vpns-ospf-bgp-mpls-04.txt

            -   The PE router doesn't really have to be an ABR. It is already "faking"
                that VPN redistributed routes are inter-area routes. It can also
                set its router LSA B bit accordingly. Oh well, maybe this could be
                considered an implementation detail.

draft-rosen-vpns-ospf-bgp-mpls-04.txt:

           - Page 4, second list item. Since the VPN routes are advertised as type
             3 LSAs, I believe you should say "inter-area routes" rather than
             "intra-network routes".

           - Page 6, Again - A PE router doesn't necessarily have to be an area 0
             router. It just has to present itself as a border router advertise type 3
             LSAs.

           - Page  11 - This states that the sham link endpoint "must be advertised
             as VPN-IPv4 address and it may be distributed by OSPF". The extant
             implementation does not advertise the sham endpoint as an OSPF VPN
             route (one must redistribute the connected route corresponding
             to the loopback address of the sham link endpoint). Advertising
             the sham  link endpoint as an OSPF route is only needed for
             auto-configuration (unless I'm missing something).

          - Page 11 - Why is auto-configuration a "MUST"? It seems to me that the use
            of  sham-links will be limited and the use of a full mesh of sham links will
            be even rarer.

         - Page 12 -  State the default hello and dead time for the sham link. Experience
           has shown that the existing implementation uses 10 and 40 but this is non-obvious
           due to the fact that an OSPF virtual link defaults to 40 and 120.

        - Page 12, last paragraph - Don't you mean that the PE should not install the route
          into the VRF routing table (since there should already be a BGP route). This will
          insure it doesn't replace the route and that it is not redistributed.

         - Page 13 - I believe the bulleted conditions could be greatly simplified.

             - the VRF has a non-zero OSPF Domain Identifier, but the route does
               not have a non-zero OSPF Domain Identifier Extended Communities
                attribute, or

                 ((VRF-Domain-ID != 0) && !(Route-Domain-ID != 0))  ||

            - the route has an OSPF Domain Identifier Extended Communities
              attribute whose value is not the same as the OSPF Domain
              Identifier associated with the VRF

               (Route-Domain-ID != VRF-Domain-ID)

             Isn't the first condition unnecessary since it is a subset of the second?

draft-rosen-ppvpn-ospf2547-area0-00.txt

             No additional comments.

That's all for now...

Thanks,
---
Acee

---

From: Peter Psenak <[email-masked]>
Date: Mon, 29 Jul 2002 11:37:28 +0200

Acee,

please see inline:

>                 considered an implementation detail.

right, it does not need to be an ABR (being attached to multiple areas)
it should present itself as an ABR, so it can generate Type-3 LSAs.

>              3 LSAs, I believe you should say "inter-area routes" rather than

agree, will be changed.

>              router. It just has to present itself as a border router advertise type 3

agree, will be changed.

>              auto-configuration (unless I'm missing something).

I guess the original idea was that the sham-link control traffic can be
routed over the OSPF  'backdoor' area instead of the VPN backbone if
there is a reason to do it that way. Usually the sham-link control
traffic is routed over the VPN backbone.

>             of  sham-links will be limited and the use of a full mesh of sham links will

agree, autoconfiguration should be optional.

>            due to the fact that an OSPF virtual link defaults to 40 and 120.

we will add that. We chose the same defaults as used for any p2p link.
Sham-link should be operating as a DC, so no Hellos should be sent after
the adjacency is formed.

>           insure it doesn't replace the route and that it is not redistributed.

PE will install the OSPF route over the sham-link. It will show in the
RT as an OSPF route. As this route came from the remote PE and an
equivalent route was advertised as an BGP prefix on the remote PE,
receiving PE should not redistribute the route back to BGP.

>              Isn't the first condition unnecessary since it is a subset of the second?

right, I guess this was added for clarity. There has been some changes
in the Domain-ID part recently and this will be reflected in the next
version of the draft.

thanks,
Peter

---

From: Acee Lindem <[email-masked]>
Date: Mon, 29 Jul 2002 09:18:27 -0400

Peter,

I'm happy.

Thanks much,
Acee

--
Acee