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

On 1/26/10 1:20 PM, Abhay Roy wrote:
> 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.
Only the least significant bit is set to indicate the presence of  a 
type-2 metric we felt this was sufficient. If you feel this would make 
things clearer, we can make the change.
> #### 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)
>
While I feel it is not needed for the Options bit,  an IANA registry for 
the route types could be added.  I will defer to the ADs on this matter.

> 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 .."
Agreed.
> #### 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.
Agree we can rephrase it.

Thanks for your review

Padma
> 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  <mailto:OSPF@ietf.org>
>> https://www.ietf.org/mailman/listinfo/ospf
>>    
>
>
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org
> https://www.ietf.org/mailman/listinfo/ospf
>