Re: [OSPF] WG Adoption Poll for "OSPF LLS Extensions for Local Interface ID Advertisement"

prz <> Wed, 10 May 2017 15:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8533F129C3B for <>; Wed, 10 May 2017 08:57:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.801
X-Spam-Status: No, score=0.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pjl-tOkv-vg8 for <>; Wed, 10 May 2017 08:57:21 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5CB3D129C30 for <>; Wed, 10 May 2017 08:57:19 -0700 (PDT)
Received: from (localhost []) (Authenticated sender: prz) by (Postfix) with ESMTPA id CBA4625A65; Wed, 10 May 2017 17:57:09 +0200 (CEST)
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Date: Wed, 10 May 2017 08:57:09 -0700
From: prz <>
To: Peter Psenak <>
Cc: "Acee Lindem (acee)" <>, OSPF WG List <>
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <>
Message-ID: <>
User-Agent: Roundcube Webmail/0.4.2
X-MailScanner-ID: CBA4625A65.A1361
X-MailScanner: Found to be clean
X-MailScanner-SpamScore: s
Archived-At: <>
Subject: Re: [OSPF] WG Adoption Poll for "OSPF LLS Extensions for Local Interface ID Advertisement"
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 10 May 2017 15:57:24 -0000

 On Tue, 09 May 2017 12:54:08 +0200, Peter Psenak <> 
> Hi Tony,
> let me try to clarify.
> 1. This draft does not change, nor does it conflict with RFC3630 in 
> any way.

 Peter, my bad, I got confused forgetting that the Link ID in 3630 is a
 different beast from the 4203 link ID. Thanks for pointing that out.

> 2. This draft does not change anything in RFC4203 either. It provides
> an alternative and more generic way to exchange Link Local Identifier
> on the interface. Your are right that in our draft we need to specify
> the behavior in case the mechanism described in RFC4203 AND the new
> mechanism specified in our draft are both active at the same time. We
> will add a new section in a next version that covers this part. I
> don't believe it will be too difficult, given that the value of the
> Link Local Identifier is the same same in both cases, the only
> difference is the the mechanism how it is advertised.

 Discussion ongoing ... Your question about 4203 deployment is valid and
 needs answers and yes, we need a backward compatibility section 

 a) @ which OSPF hello states the new signaling is supposed to be 
 b) what happens if the value ever changes (tear down adjacency?) or 
    it's a violation
 c) what happens if flooded 4203 values (on LSAs) contradict signaling
    (e.g. you're holding to the flooded LSA with "old" value) while
    neighbor LLS'es a new value
 d) what happens if both signaling types show up on the link

 Per earlier mails, clarification WHEN the new signaling is supposed to 
 be used
 would be also helpful. 4203 Link ID signaling seems to be used only in
 case of unnumbered.

 So, overall I think we agree on scope of the problem that needs to be
 addressed so we get a coherent set of standards out


 --- tony