Subject: [OSPF] FW: New Version Notification for draft-ietf-ospf-ospfv3-lsa-extend-02.txt

From: Acee Lindem <[email-masked]>
Date: Fri, 18 Apr 2014 15:58:53 +0000

All,
This version has been reorganized to separate the definitions of the TLVs
and sub-TLVs from the Extended LSAs (Alan Davey's suggestion).
It also includes the changes to the compatibility section discussed during
the OSPF WG meeting in London (David Lamparter's input).
Thanks,
Acee 

On 4/18/14 8:36 AM, "[email-masked]" <[email-masked]>
wrote:

>
>A new version of I-D, draft-ietf-ospf-ospfv3-lsa-extend-02.txt
>has been successfully submitted by Acee Lindem and posted to the
>IETF repository.
>
>Name:		draft-ietf-ospf-ospfv3-lsa-extend
>Revision:	02
>Title:		OSPFv3 LSA Extendibility
>Document date:	2014-04-18
>Group:		ospf
>Pages:		35
>URL:            
>http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-lsa-extend-02.t
>xt
>Status:         
>https://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv3-lsa-extend/
>Htmlized:       
>http://tools.ietf.org/html/draft-ietf-ospf-ospfv3-lsa-extend-02
>Diff:           
>http://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-ospfv3-lsa-extend-02
>
>Abstract:
>   OSPFv3 requires functional extension beyond what can readily be done
>   with the fixed-format Link State Advertisement (LSA) as described in
>   RFC 5340.  Without LSA extension, attributes associated with OSPFv3
>   links and advertised IPv6 prefixes must be advertised in separate
>   LSAs and correlated to the fixed-format LSAs.  This document extends
>   the LSA format by encoding the existing OSPFv3 LSA information in
>   Type-Length-Value (TLV) tuples and allowing advertisement of
>   additional information with additional TLVs.  Backward compatibility
>   mechanisms are also described.
>
>                  
>        
>
>
>Please note that it may take a couple of minutes from the time of
>submission
>until the htmlized version and diff are available at tools.ietf.org.
>
>The IETF Secretariat
>

---

From: Peter Psenak <[email-masked]>
Date: Fri, 18 Apr 2014 18:18:00 +0200

Hi Acee,

quote From section (5):

    "In this manner, OSPFv3 routers using new encodings can be
    completely isolated from those OSPFv3 routers depending on the RFC
    5340 encoding and not setting their options field EL-bits since the
    default setting indicates no support for extended LSAs."

Even though you prevent adjacency to be formed between routers with 
certain compatibility modes, it still does not prevent all modes to 
coexist in the area/network.

Let's imagine you have a chain of routers with following modes:

Full---MixedModeOriginateSPF----MixedModeOriginateOnly-----None

thanks,
Peter

On 4/18/14 17:58 , Acee Lindem wrote:
> _______________________________________________
> OSPF mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ospf
>

---

From: Acee Lindem <[email-masked]>
Date: Fri, 18 Apr 2014 16:22:36 +0000

Hi Peter, 
You are correct - I’d thought about these situations myself but didn’t strike this statement. I’m thinking I will remove this and discuss the options of separate routing domains in more detail. 
Thanks,
Acee
On Apr 18, 2014, at 12:18 PM, Peter Psenak <[email-masked]> wrote:

> Even though you prevent adjacency to be formed between routers with certain compatibility modes, it still does not prevent all modes to coexist in the area/network.
>

---

From: Peter Psenak <[email-masked]>
Date: Fri, 18 Apr 2014 18:57:28 +0200

Hi Acee,

I do not see any problem with routers with various compatibility modes 
living in area/network together. With all the modes we have, we provide 
the possibility of graceful migration from old to new LSA types. I don't 
think we need to restrict any combination. Sure, if someone mix "full" 
and "none", then it can not expect the full reachability between them, 
but that does not mean we have to prohibit it.

Separate routing is the possibility, but probably not the easiest one. I 
would certainly not enforce it as the only possibility.

thanks,
Peter

On 4/18/14 18:22 , Acee Lindem wrote:
> .

---

From: Acee Lindem <[email-masked]>
Date: Fri, 18 Apr 2014 20:41:13 +0000

Hi Peter, 

On Apr 18, 2014, at 12:57 PM, Peter Psenak <[email-masked]> wrote:

> Hi Acee,
> 
> I do not see any problem with routers with various compatibility modes living in area/network together. With all the modes we have, we provide the possibility of graceful migration from old to new LSA types. I don't think we need to restrict any combination. Sure, if someone mix "full" and "none", then it can not expect the full reachability between them, but that does not mean we have to prohibit it.

I agree. 

> 
> Separate routing is the possibility, but probably not the easiest one. I would certainly not enforce it as the only possibility.

We started with this as the only migration mechanism. It is still one option and I will attempt to assure both migration paths are clear. 

Thanks,
Acee

---

From: Acee Lindem <[email-masked]>
Date: Fri, 18 Apr 2014 22:39:04 +0000

Hi Tony,

On Apr 18, 2014, at 6:28 PM, prz <[email-masked]> wrote:

> On Fri, 18 Apr 2014 20:41:13 +0000, Acee Lindem <[email-masked]> wrote:
>> Hi Peter,
>> 
> Zipped through the diffs on the new one. See most work went into migration. Two observations:
> 
> . nitpick: WILL is _not_ any kind of normative language. Use MUST

Ok - I’ll search these out. 

> . the only reason the migration holds together without stable loops is that there is an implicit assumption in the draft (I didn't see it spelled out but then again I skimmed over it only) that the metric advertised in TLVs and old style is always absolutely the same. I suggest to spell that out strongly.

It is implicit but it seems rather obvious that if one originates the non-extended and extended versions of the same LSA, the content MUST be the same. However, I can state this explicitly. 

Thanks,
Acee 

> --- tony

---

From: Acee Lindem <[email-masked]>
Date: Sat, 19 Apr 2014 02:08:31 +0000

Ok - Agreed. 

Thanks,
Acee 

On 4/18/14 6:44 PM, "prz" <[email-masked]> wrote:

>
>>> . the only reason the migration holds together without stable loops
>>> is that there is an implicit assumption in the draft (I didn't see it
>>> spelled out but then again I skimmed over it only) that the metric
>>> advertised in TLVs and old style is always absolutely the same. I
>>> suggest to spell that out strongly.
>>
>> It is implicit but it seems rather obvious that if one originates the
>> non-extended and extended versions of the same LSA, the content MUST
>> be the same. However, I can state this explicitly.
>>
>
> agreed but then again, there are so many metrics floating in those
> protocols now that if you couple them implicitly (which you do with this
> draft) I don't think spelling it out cleanly and strongly hurts (given
> that the whole migration in the draft only holds together under this
> very assumption).
>
> And I never seize to be amazed what kind of stuff people build based on
> RFCs and how I come to completely wrong conclusion as what they mean
> when I read them (but that can be just feeble old age of mine or
> intentional by authors ;-)
>
> --- tony
>
>