Re: [OSPF] FW: New Version Notification for draft-ietf-ospf-prefix-link-attr-00.txt

Hi Peter, Tony, 

On Sep 2, 2014, at 3:25 AM, Peter Psenak <ppsenak@cisco.com> wrote:

> Hi Tony,
> 
> please see inline:
> 
> On 9/1/14 23:34 , A. Przygienda wrote:
>> Comments:
>> 
>> a)   section 1. introduction last line
>> 
>> > the existing LSAs will be replaced _BY_ TLV-based extended LSAs.
> 
> ok,
> 
>> 
>> b) section 2.
>> 
>> It may be well writing a sentence or two what should happen if an OSPFv2
>> Extended Prefix Opaque LSA changes its flooding scope (i.e. 9-11
>> changes) and what should happen if the same prefix appears in two
>> different flooding scopes with different information (ignore prefix in
>> both, prefer local scope info ? [i.e. ignore wider scope]). Leaving it
>> open may lead to different treatement per router and surprising effects
> 
> as far as the information in the two LSAs are the same, having the prefix in two LSAs with different flooding scopes is not a problem - happens today with regular LSAs.) The problem would be if the content of TLVs associated with the prefix is controversial, in which case it would be a defect on the originator side.

This is another case where the segment routing mapping server requirement makes this more complicated. I think the guidance for the case should be to give preference to the information in the LSA with area flooding scope. 

> 
>> 
>> It may be also helpful to add that if an opaque extended is present but
>> the prefix (of the according type) is not in the standard LSAs, such
>> information must be disregarded.
> 
> no, that is a valid case. One may want to advertise some extended prefix attributes without advertising the prefix's reachability.
> 
>> 
>> c) section 2.1
>> 
>> > Multiple OSPF Extended Prefix
>> > TLVs MAY be advertised in each OSPFv2 Extended Prefix Opaque LSA but
>> > all prefixes included in a single OSPFv2 Extended Prefix Opaque LSA
>> > MUST have the same flooding scope.
>> 
>> may be misleading. Since they are in a opaque, the flooding scope is
>> controlled by opaque. If  the type-5 vs. type-3 is meant than 'flooding
>> scope' must be disassociated between 'opaque flooidng scope' and
>> 'route-type flooding scope [as in we don't flood type-1 across ABRs]'  ?
> 
> LSA can only have single flooding scope, so all information inside LSA is limited to that flooding scope. That is what was meant by the above texts.

Actually, I had considered removing this statement when I separated the generic protocol extensions from the SR specific draft. 

> 
>> 
>> 
>> d)
>> I think it may be a valid suggestion to implementors that (for every
>> version) the  according  LSA  SHOULD be flooded _before_ the opaque LSA
>> is flooded (which can be tad tricky [but doable] if the opaque carries a
>> bunch of those]).  Yes, with reordering of flooding etc. it's not a
>> guarantee for anything but a good practice to give the protocol a chance
>> to distribute the referent (LSA) before distributing any references
>> (opaques) and additionally, will make sure that  LSAs which are far more
>> important normally get out the box before opaques.
> 
> as I said, not flooding regular LSA, only extended LSA is a valid case.

In any case, an application using extended attributes will need to be triggered by the extended prefix/link attribute LSAs.  The advertising router may originate one or both of them independently. I will try to capture this disjointness in a paragraph. 

Thanks,
Acee 

> 
> thanks,
> Peter
>> 
>> 
>> --- tony
>> 
>> 
>> On 08/13/2014 06:12 AM, Acee Lindem (acee) wrote:
>>> Hi,
>>> 
>>> This new draft describes the generic prefix/link attribute opaque LSAs
>>> that were previously included in the OSPFv2 Segment Routing draft.  The
>>> opaque LSAs described in this draft can be used by other OSPF WG candidate
>>> drafts. There are already two implementations of the draft as part of
>>> segment routing interoperability testing. Please read and comment.
>>> Thanks,
>>> Acee
>>> 
>> 
>> 
>> 
>> _______________________________________________
>> OSPF mailing list
>> OSPF@ietf.org
>> https://www.ietf.org/mailman/listinfo/ospf
>> 
> 
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org
> https://www.ietf.org/mailman/listinfo/ospf