Re: [OSPF] OSPF WG review of draft-ietf-l3vpn-ospfv3-pece, 'OSPFv3 as a PE-CE routing protocol'

I also looked at the latest version and have a few comments. Nothing 
significant, so these can possibly be done in RFC Ed..

       OSPFv3 Options : 1 byte

       The Options field indicates if the route carries a type-1 or
       type-2 metric.  Setting the least significant bit in the field
       indicates that the route carries a External type-2 metric.

#### When talking of bit positions, it's always better to show the 
bitfield, and name the bit(s) being allocated. For e.g. see section A.2 
of rfc5340.
#### We also need an IANA registry for:
####  - Option bits (allocate the one's we need here)
####  - Route Type (only a few values are currently permitted)

4.5.1.  OSPFv3 Down Bit

    Section 1 and Section 3 of [rfc4576] describe the usage of the DN-bit
    for OSPFv2 and are applicable for OSPFv3 for inter-area-prefix LSAs,
    NSSA LSAs and External LSAs.  Similarly, the DN-bit must be set in
    inter-area-prefix-LSAs, NSSA-LSAs and AS-External-LSAs, when these
    are originated from a PE to a CE, to prevent those prefixes from
    being re-advertised into BGP.  As in [rfc4577], any LSA with the DN
    bit set must not be used for route calculations.

#### Can we capitalize MUST in - "the DN-bit must be set .."
#### The last sentence is confusing because it doesn't clarify this 
restriction to be only on PE routers. We could use similar language as 
in rfc4576:

    When a PE router receives, from a CE router, any LSA with the DN bit
    [OSPF-DN] set, the information from that LSA MUST NOT be used by the
    route calculation.

Regards,
-Abhay

On 1/22/10 12:16 PM, Ross Callon wrote:
>
> draft-ietf-l3vpn-ospfv3-pece was recently approved by the IESG for 
> publication, and is currently in the RFC editor's queue. While this 
> document passed WG last call in the L3VPN working group, and also 
> passed IETF last call, we forgot to either do an last call in the OSPF 
> working group, or to specifically flag the IETF last call to the OSPF 
> working group.
>
> With this in mind, we would like to solicit comments on this draft 
> from the OSPF working group. If there are minor comments we can fix 
> this during AUTH48. If there are major concerns then we will need to 
> figure out what to do (which in the most extreme situation might 
> require un-approving the document).
>
> Thus, please review this document and reply to the OSPF working group 
> email list by the end of next Friday, January 29th, if you have any 
> comments or concerns.
>
> Thanks, Ross
>
> (acting in my role as the AD who goofed in this case).
>
>
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org
> https://www.ietf.org/mailman/listinfo/ospf
>    