Re: [Isis-wg] draft-ginsberg-isis-l2bundles

"Acee Lindem (acee)" <acee@cisco.com> Thu, 06 August 2015 13:34 UTC

Return-Path: <acee@cisco.com>
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C36021B2F77 for <isis-wg@ietfa.amsl.com>; Thu, 6 Aug 2015 06:34:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VDioFXx7jgLu for <isis-wg@ietfa.amsl.com>; Thu, 6 Aug 2015 06:34:22 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68FA51B2F56 for <isis-wg@ietf.org>; Thu, 6 Aug 2015 06:34:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18446; q=dns/txt; s=iport; t=1438868061; x=1440077661; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=HcdkYmx0eIBtNHmiM6u/kIYCN+yCqRqMq4sFBXEx5dg=; b=nGSWNtowNJOlZzHCCBuDKzy/W/IdMkec623Mr0brU3EVBGltObEuI3DE h9abKY0dI5rJ0E1EV2MdYIzpV3KbQFNfDr9ML5S3Xg8VOZhwJKfj9ZCQt B6owvtGDR/rQ79+yKsQkHiTDKulY1TqDR4//mMyXPsYJP9MDvW0BW8iae U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0B/AwDfYcNV/49dJa1bgxtUaQaDHblwCYF6CoV5AhyBJTgUAQEBAQEBAYEKhCMBAQEEAQEBIBE3AgEXAgICAQgRBAEBAQICIwMCAgIZDAsUAQgIAgQBEogZAxINtxiQdQOFTAEBAQEBAQEBAQEBAQEBAQEBAQEBARcEgR6KLYQmCwUCATUWDAaCY4FDBZUBAYR+h1iBR0aDXZAhg2Qmg31vAQGBBEKBBAEBAQ
X-IronPort-AV: E=Sophos;i="5.15,622,1432598400"; d="scan'208";a="16372775"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-8.cisco.com with ESMTP; 06 Aug 2015 13:34:19 +0000
Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t76DYJT2026764 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 6 Aug 2015 13:34:19 GMT
Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 6 Aug 2015 08:34:19 -0500
Received: from xhc-aln-x13.cisco.com (173.36.12.87) by xch-aln-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Thu, 6 Aug 2015 08:34:19 -0500
Received: from xmb-aln-x06.cisco.com ([169.254.1.223]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0248.002; Thu, 6 Aug 2015 08:34:18 -0500
From: "Acee Lindem (acee)" <acee@cisco.com>
To: "stephane.litkowski@orange.com" <stephane.litkowski@orange.com>, Ebben Aries <exa@fb.com>, "isis-wg@ietf.org list (isis-wg@ietf.org)" <isis-wg@ietf.org>
Thread-Topic: [Isis-wg] draft-ginsberg-isis-l2bundles
Thread-Index: AdDN623Y8EVm+rlaS12GE2fzf9VY0wBTS0wAABH0tgAACt7LgAAnCN4AAAHJBIAACU6MAP//wR+A
Date: Thu, 06 Aug 2015 13:34:18 +0000
Message-ID: <D1E8D9DC.2A680%acee@cisco.com>
References: <26030_1438606960_55BF6670_26030_2637_1_9E32478DFA9976438E7A22F69B08FF92166BD55F@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <55C14D02.3040606@fb.com> <9343_1438762371_55C1C583_9343_425_1_9E32478DFA9976438E7A22F69B08FF92166BE011@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <D1E7BBD9.2A539%acee@cisco.com> <29791_1438848107_55C3146B_29791_2196_1_9E32478DFA9976438E7A22F69B08FF92166BE386@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <D1E8CF5E.2A64B%acee@cisco.com> <32556_1438867163_55C35EDB_32556_1906_1_9E32478DFA9976438E7A22F69B08FF92166BE558@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
In-Reply-To: <32556_1438867163_55C35EDB_32556_1906_1_9E32478DFA9976438E7A22F69B08FF92166BE558@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [173.36.7.28]
Content-Type: text/plain; charset="utf-8"
Content-ID: <EAC151B4E723E04FA7C4C9EAE6E4AE26@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/isis-wg/CBgpvNdkC2Q0l5JaMRYZU4aIfbE>
Subject: Re: [Isis-wg] draft-ginsberg-isis-l2bundles
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/isis-wg/>
List-Post: <mailto:isis-wg@ietf.org>
List-Help: <mailto:isis-wg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Aug 2015 13:34:25 -0000


On 8/6/15, 9:19 AM, "stephane.litkowski@orange.com"
<stephane.litkowski@orange.com> wrote:

>I think this may have implications beyond SR but it seems there are other
>areas where LAGs (aka, link-bundles) have permeated into L3 (e.g., BFD -
>RFC 7130). 
>
>[SLI] Fully agree, IMO, we must not let the doors wide open to this kind
>of permeation.

LAGs are ubiquitous and I think we are going to have to accommodate them
in L3 protocols even if it is a layer violation. But this is just my
opinion. 

Thanks,
Acee 



> 
>
>
>-----Original Message-----
>From: Acee Lindem (acee) [mailto:acee@cisco.com]
>Sent: Thursday, August 06, 2015 14:53
>To: LITKOWSKI Stephane SCE/IBNF; Ebben Aries; isis-wg@ietf.org list
>(isis-wg@ietf.org)
>Subject: Re: [Isis-wg] draft-ginsberg-isis-l2bundles
>
>Hi Stephane, 
>
>
>On 8/6/15, 4:01 AM, "stephane.litkowski@orange.com"
><stephane.litkowski@orange.com> wrote:
>
>>Hi Acee,
>>
>>Some comments inline
>>
>>-----Original Message-----
>>From: Acee Lindem (acee) [mailto:acee@cisco.com]
>>Sent: Wednesday, August 05, 2015 19:24
>>To: LITKOWSKI Stephane SCE/IBNF; Ebben Aries; isis-wg@ietf.org list
>>(isis-wg@ietf.org)
>>Subject: Re: [Isis-wg] draft-ginsberg-isis-l2bundles
>>
>>Hi Stephane,
>>I think the IS-IS advertisement is merely a consequence of the fact
>>that we are satisfying the requirement of incorporating these L2 links
>>in the segment routing path.
>>[SLI] Yes, and IMO, that's bad.
>
>
>
>>- I still have some doubt on the reason to split LAGs for TE and
>>keeping bundles for other protocols.
>>- Regarding TE, I don't really see how BW use cases can work with this,
>>as there may be some TE tunnels using the bundle and some using
>>specific link, so evaluating the remaining BW per link and for the
>>bundle is hard.
>>- This "breaks" layers, IGP exposes Layer 3 topology by design, not
>>layer
>>2 ... if we want to expose layer 2, that's not an issue, it's a kind of
>>multilayer TE approach and BGP-LS may so come in the picture and is a
>>good candidate to retrieve topological information. I do not want to
>>see IS-IS or OSPF becoming a topology discovery protocol for everything :
>>while it's related to the Layer 3 topology it's fine to me to keep it
>>in the IGP for other informations, may be we need to find another way.
>>
>>
>> If we limit advertisement to BGP-LS, it will have the following impact:
>>
>>     1. All routers in the IS-IS domain that use link-bundles will need
>>some form of BGP LS peering, either to the controller directly or
>>through some intermediary.
>>[SLI] Agree but I don't see this as a negative point, as I think most
>>networks running TE, already have a BGP controlplane that can be reused.
>
>If there is BGP-LS peering on all the routers, then I agree that this
>would work given the right local policy to specify what BGP-LS
>information each router advertises.
>
>Thanks,
>Acee 
>
>
>
>
>>
>>     2. Since the link-bundle itself is an IS-IS L3 link, one would
>>need to correlate the information with the corresponding IS-IS link
>>state information (assuming not every IS-IS router advertises the entire
>>LSDB).
>>[SLI] Agree there is a need of correlation, but correlation is required
>>in all cases (in the current proposal, we advertise some parent link
>>information).
>>
>>Additionally, any time the information is coming from multiple sources,
>>you are likely to trigger path computation more frequently.
>>[SLI] I would say that's implementation dependent.
>>
>>
>>I don’t think this added complexity warrants omitting them from the
>>IGPs if we do, in fact, accept link bundle adjacency steering as a
>>requirement.
>>
>>Thanks,
>>Acee
>>
>>
>>On 8/5/15, 4:12 AM, "Isis-wg on behalf of stephane.litkowski@orange.com"
>><isis-wg-bounces@ietf.org on behalf of stephane.litkowski@orange.com>
>>wrote:
>>
>>>Hi,
>>>
>>>Pls find some inline comments.
>>>
>>>-----Original Message-----
>>>From: Ebben Aries [mailto:exa@fb.com]
>>>Sent: Wednesday, August 05, 2015 01:39
>>>To: LITKOWSKI Stephane SCE/IBNF; isis-wg@ietf.org list
>>>(isis-wg@ietf.org)
>>>Subject: Re: [Isis-wg] draft-ginsberg-isis-l2bundles
>>>
>>>I see BGP-LS extensions complementing this, not necessarily as a
>>>replacement.
>>>[SLI] It's for sure an option, but my point is do we need to continue
>>>to add extensions to both IGP and BGP LS ?
>>>Moreover I still have an issue with propagating L2 informations into
>>>layer 3 routing protocol  (not technically ... more from a design
>>>perspective).
>>>Let's say that tomorrow, you would like to advertise some L1
>>>information under your layer 2 information ... ?? As we are breaking
>>>layers, if you want to advertise some underlay topology, I would be in
>>>favor to not doing it in IGP.
>>>
>>>For a use-case of a central entity learning these underlying l2
>>>attributes to then do whatever you wish (impose label stacks, etc..) -
>>>BGP-LS is a natural fit.
>>>[SLI] Nothing prevents to use BGP-LS in a distributed computation model.
>>>
>>>For this to remain in the IGP, a consideration could be the
>>>propagation of these L2 attributes to then be included in TEDs for
>>>additional logic from headend nodes (network elements within the IGP
>>>domain) - e.g.
>>>control packet per member from a remote endpoint overriding remote
>>>hashing either by some policy/SLA or dynamic based off of per member
>>>utilization, etc..
>>>
>>>[SLI] Even if TED was previously populated only by IGP (because there
>>>was nothing else), this is not the case anymore. TED is also populated
>>>by BGP-LS and we may be able to create also new processes to populate
>>>the TED. So you can imagine having your process managing LAGs to add
>>>those L2 TE information into the TED and then being able to export it
>>>through BGP-LS to other nodes through the BGP controlplane, so every
>>>one will have the same content in the TED.
>>>
>>>
>>>On 08/03/2015 07:02 AM, stephane.litkowski@orange.com wrote:
>>>> Hi,
>>>> 
>>>>  
>>>> 
>>>> Thinking again about this draft, I wondering why not using BGP-LS
>>>> for that purpose ?
>>>> 
>>>> I mean, the goal here is just to provide some topological
>>>> information that are not related to IGP, as you want to keep L2
>>>> bundles and so a single IP link. If you want to expose the
>>>> underlaying topology, you may be able to do it in BGP-LS rather than
>>>> adding this in the IGP as the information you want to expose is not
>>>>necessary for the IGP to run.
>>>> 
>>>>  
>>>> 
>>>> Thx
>>>> 
>>>>  
>>>> 
>>>> Orange logo
>>>> <https://urldefense.proofpoint.com/v1/url?u=http://www.orange.com/&k
>>>> =
>>>> Z
>>>> VNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=GJQFPrZyyh453ywaGV%2FvoQ%3D%3D%0A&m
>>>> =
>>>> x
>>>> DbMtpjPKPQ26eNh1Ka%2FhnXOqVfqYtZ9MjolqbbcT8U%3D%0A&s=75085ca9001f9c7
>>>> a
>>>> 2
>>>> 4e6f23efb57f50f5d79a97cbadcbfe1ce65082d335dba35>
>>>> 
>>>>  
>>>> 
>>>> *Stephane Litkowski *
>>>> Network Architect
>>>> Orange/SCE/EQUANT/IBNF/ENDD/NDE
>>>> 
>>>> Orange Expert Future Networks
>>>> 
>>>> phone: +33 2 23 28 49 83
>>>> <https://urldefense.proofpoint.com/v1/url?u=https://monsi.sso.france
>>>> t
>>>> e
>>>> lecom.fr/index.asp?target%3Dhttp%253A%252F%252Fclicvoice.sso.francet
>>>> e
>>>> l
>>>> ecom.fr%252FClicvoiceV2%252FToolBar.do%253Faction%253Ddefault%2526ro
>>>> o
>>>> t
>>>> service%253DSIGNATURE%2526to%253D%26%2343%3B33%25202%252023%252028%2
>>>> 5
>>>> 2
>>>> 049%252083%2520&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=GJQFPrZyyh453ywa
>>>> G
>>>> V
>>>> %2FvoQ%3D%3D%0A&m=xDbMtpjPKPQ26eNh1Ka%2FhnXOqVfqYtZ9MjolqbbcT8U%3D%0
>>>> A & 
>>>> s=4490d282c20720cdbe8d3350c17a191e1762a7ea211ff404be972fddea2f62f3>
>>>> mobile: +33 6 37 86 97 52
>>>> <https://urldefense.proofpoint.com/v1/url?u=https://monsi.sso.france
>>>> t
>>>> e
>>>> lecom.fr/index.asp?target%3Dhttp%253A%252F%252Fclicvoice.sso.francet
>>>> e
>>>> l
>>>> ecom.fr%252FClicvoiceV2%252FToolBar.do%253Faction%253Ddefault%2526ro
>>>> o
>>>> t
>>>> service%253DSIGNATURE%2526to%253D%26%2343%3B33%25206%252037%252086%2
>>>> 5
>>>> 2
>>>> 097%252052%2520&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=GJQFPrZyyh453ywa
>>>> G
>>>> V
>>>> %2FvoQ%3D%3D%0A&m=xDbMtpjPKPQ26eNh1Ka%2FhnXOqVfqYtZ9MjolqbbcT8U%3D%0
>>>> A & 
>>>> s=696fa2cd342bca61fdf5e849c8d3d76abe1075281d4218eaac873227641f9514>
>>>> stephane.litkowski@orange.com <mailto:stephane.litkowski@orange.com>
>>>> 
>>>>  
>>>> 
>>>>  
>>>> 
>>>> ____________________________________________________________________
>>>> _ _ ___________________________________________________
>>>> 
>>>> Ce message et ses pieces jointes peuvent contenir des informations
>>>>confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
>>>>exploites ou copies sans autorisation. Si vous avez recu ce message
>>>>par erreur, veuillez le signaler a l'expediteur et le detruire ainsi
>>>>que les pieces jointes. Les messages electroniques etant susceptibles
>>>>d'alteration, Orange decline toute responsabilite si ce message a ete
>>>>altere, deforme ou falsifie. Merci.
>>>> 
>>>> This message and its attachments may contain confidential or
>>>>privileged information that may be protected by law; they should not
>>>>be distributed, used or copied without authorisation.
>>>> If you have received this email in error, please notify the sender
>>>>and delete this message and its attachments.
>>>> As emails may be altered, Orange is not liable for messages that
>>>>have been modified, changed or falsified.
>>>> Thank you.
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Isis-wg mailing list
>>>> Isis-wg@ietf.org
>>>> https://urldefense.proofpoint.com/v1/url?u=https://www.ietf.org/mail
>>>> m
>>>> a
>>>> n/listinfo/isis-wg&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=GJQFPrZyyh453
>>>> y
>>>> w
>>>> aGV%2FvoQ%3D%3D%0A&m=xDbMtpjPKPQ26eNh1Ka%2FhnXOqVfqYtZ9MjolqbbcT8U%3
>>>> D
>>>> %
>>>> 0A&s=3211164dcbc94ec39a7390a5d1c8371f2c391ec0aeec8806884c6abfd441511
>>>> 0
>>>> 
>>>
>>>______________________________________________________________________
>>>_ ___ _______________________________________________
>>>
>>>Ce message et ses pieces jointes peuvent contenir des informations
>>>confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
>>>exploites ou copies sans autorisation. Si vous avez recu ce message
>>>par erreur, veuillez le signaler a l'expediteur et le detruire ainsi
>>>que les pieces jointes. Les messages electroniques etant susceptibles
>>>d'alteration, Orange decline toute responsabilite si ce message a ete
>>>altere, deforme ou falsifie. Merci.
>>>
>>>This message and its attachments may contain confidential or
>>>privileged information that may be protected by law; they should not
>>>be distributed, used or copied without authorisation.
>>>If you have received this email in error, please notify the sender and
>>>delete this message and its attachments.
>>>As emails may be altered, Orange is not liable for messages that have
>>>been modified, changed or falsified.
>>>Thank you.
>>>
>>>_______________________________________________
>>>Isis-wg mailing list
>>>Isis-wg@ietf.org
>>>https://www.ietf.org/mailman/listinfo/isis-wg
>>
>>
>>_______________________________________________________________________
>>___ _______________________________________________
>>
>>Ce message et ses pieces jointes peuvent contenir des informations
>>confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
>>exploites ou copies sans autorisation. Si vous avez recu ce message par
>>erreur, veuillez le signaler a l'expediteur et le detruire ainsi que
>>les pieces jointes. Les messages electroniques etant susceptibles
>>d'alteration, Orange decline toute responsabilite si ce message a ete
>>altere, deforme ou falsifie. Merci.
>>
>>This message and its attachments may contain confidential or privileged
>>information that may be protected by law; they should not be
>>distributed, used or copied without authorisation.
>>If you have received this email in error, please notify the sender and
>>delete this message and its attachments.
>>As emails may be altered, Orange is not liable for messages that have
>>been modified, changed or falsified.
>>Thank you.
>>
>
>
>__________________________________________________________________________
>_______________________________________________
>
>Ce message et ses pieces jointes peuvent contenir des informations
>confidentielles ou privilegiees et ne doivent donc
>pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
>recu ce message par erreur, veuillez le signaler
>a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
>electroniques etant susceptibles d'alteration,
>Orange decline toute responsabilite si ce message a ete altere, deforme
>ou falsifie. Merci.
>
>This message and its attachments may contain confidential or privileged
>information that may be protected by law;
>they should not be distributed, used or copied without authorisation.
>If you have received this email in error, please notify the sender and
>delete this message and its attachments.
>As emails may be altered, Orange is not liable for messages that have
>been modified, changed or falsified.
>Thank you.
>