Re: [Isis-wg] draft-ginsberg-isis-l2bundles
"Ahmed Bashandy (bashandy)" <bashandy@cisco.com> Tue, 11 August 2015 00:05 UTC
Return-Path: <bashandy@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 05CD21A1B6D for <isis-wg@ietfa.amsl.com>; Mon, 10 Aug 2015 17:05:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 450j0_3vIcJG for <isis-wg@ietfa.amsl.com>; Mon, 10 Aug 2015 17:05:31 -0700 (PDT)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4ADA1A1C03 for <isis-wg@ietf.org>; Mon, 10 Aug 2015 17:05:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=48643; q=dns/txt; s=iport; t=1439251528; x=1440461128; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=W8zvRnFBbxjKXlMZs19tp8kNCtg9W4u0jCcD6xX8S44=; b=m5Du66+EpJw8fj3RyvK45YROSrU+QyparH++PKLc23UHleNoXcP316Qk LWbn33/KNFWsD+NzgC5z2nV0hKJwXe3YndPFZ26cMi+v0GO6Wzp9dnZRV Aw8x8s0S8NVhLb7xl5WDk+ogqUtZnCo33oGcZFMbbdcRIvTuPyCnJ8AY1 U=;
X-IronPort-AV: E=Sophos;i="5.15,649,1432598400"; d="scan'208,217";a="176864042"
Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-2.cisco.com with ESMTP; 11 Aug 2015 00:05:28 +0000
Received: from [128.107.165.110] (dhcp-128-107-165-110.cisco.com [128.107.165.110]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t7B05RYq024427; Tue, 11 Aug 2015 00:05:27 GMT
Message-ID: <55C93C47.9070909@cisco.com>
Date: Mon, 10 Aug 2015 17:05:27 -0700
From: "Ahmed Bashandy (bashandy)" <bashandy@cisco.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: stephane.litkowski@orange.com, "Acee Lindem (acee)" <acee@cisco.com>, Ebben Aries <exa@fb.com>, "isis-wg@ietf.org list (isis-wg@ietf.org)" <isis-wg@ietf.org>
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> <D1E8D9DC.2A680%acee@cisco.com> <17887_1438871493_55C36FC4_17887_18571_1_9E32478DFA9976438E7A22F69B08FF92166BE5E4@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <D1E96BF1.2A765%acee@cisco.com> <26458_1438932511_55C45E1E_26458_1031_1_9E32478DFA9976438E7A22F69B08FF92166BE826@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
In-Reply-To: <26458_1438932511_55C45E1E_26458_1031_1_9E32478DFA9976438E7A22F69B08FF92166BE826@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
Content-Type: multipart/alternative; boundary="------------080201070903010807070809"
Archived-At: <http://mailarchive.ietf.org/arch/msg/isis-wg/q9s0iHXTwcw571-hgBbVlHsxdMg>
X-Mailman-Approved-At: Fri, 14 Aug 2015 06:57:46 -0700
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: Tue, 11 Aug 2015 00:05:38 -0000
Folks In attempt to provide a relatively quantitative measurement of the proposed solutions to the problem at hand, I thought I would prepared a small comparison table between ISIS for L2 bundles, BGP-LS for L2 bundles, and changing all L2 bundles members to L3 links as unnumbered interfaces. I put +1 for (IMHO) what looks like an advantage, -1 for (IMHO) what looks like a disdavantage, and (0) what looks like a minor disadvantage or advantage ISIS to advertise L2 bundles BGP-LS to advertise L2 bundle L2 bundles as unnumbered interfaces in ISIS Scalability Minimal scale overheard (+1) Minimal scale overhead (+1) Significant scale overhead (-1) Mandate the deployment of a protocol that was not deployed before No (+1) Yes (-1) No (+1) Impact on basic routing functionality Minimal (+1) Minimal (+1) Significant (-1) Works for both P2P and LAN Simple (+1) Simple (+1) Difficult (unnumbered not easy with LANs) (-1) Using 1 protocol for diverse functionilities Yes (+1) No (-1) Yes (+1) Exposing L2 info in L3 protocol Yes (-1) Yes (-1) No (+1) Protocol change Yes (-1) Yes (-1) No (+1) Risk Small (Minimal impact on baseline functionality and managements tools while not deploying any new protocol) (+1) Medium (Have to deploy BGP-LS everywhere) (0) Significant (Have to make sure that baseline functionality on all routers as well as management and monitoring tools are not impacted by the sharp scale increase) (-1) Sum 5 -1 -2 One Important point, I agree with Ebben that BGP-LS is not an alternative to using ISIS but rather a complementary solution to be used by networks that do not use ISIS and OSPF. If we assume that BGP-LS will be used by networks that already employ BGP, then using ISIS and BGP-LS will have almost the same score Thanks Ahmed On 8/7/2015 12:28 AM, stephane.litkowski@orange.com wrote: > The gain is that there is no need for a new ISIS extension, you can use TLV22 as usual. > IMO, maintaining a real adjacency is not a big deal moreover it allow for detection of MTU mismatch ... > And as the interface is an IP interface, there is no more "layer breakage". > > So to do this, no need of IETF standardization, just local behavior on the node. > > > -----Original Message----- > From: Acee Lindem (acee) [mailto:acee@cisco.com] > Sent: Friday, August 07, 2015 02:08 > 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, 10:31 AM, "stephane.litkowski@orange.com" > <stephane.litkowski@orange.com> wrote: > >> Acee, >> >> Another possibility to address the requirement of TE per link within a >> LAG bundle may be to create L3 adjacencies on each link in addition to >> an adjacency for the bundle. This does not work today but ... >> This would be a new way to manage LAGs, IMHO (as I'm not an >> implementor), I don't see a reason for this to not work theorically. >> Then each L3 protocol has the choice to use a bundle-view or a per-link >> view. You will create more IGP adjacencies but that's not a big deal >> (CPU are quite big now :) ). >> This behavior is more clear than the one proposed in the draft, as the >> target is to provide a kind of layer 3 forwarding on layer 2 links ... >> here this would be a true layer 3 forwarding on layer 3 links. >> >> Example : >> >> Interface Port-Channel1 >> Ip address 1.1.1.1/30 >> Ip router isis >> Isis metric 100 >> ! >> Interface Te10 >> Ip address 2.0.0.1/30 >> Channel-group 1 >> Ip router isis >> Isis metric max-metric >> ! >> Interface Te20 >> Ip address 3.0.0.1/30 >> Channel-group 1 >> Ip router isis >> Isis metric max-metric >> ! >> >> Thoughts ? > I don’t think you’d want to establish a separate adjacency over each of the LAG constituent links. I guess you may be inventing a lower overhead adjacency similar to a TE forwarding adjacency (RFC 4206) to represent the constituents. This would also work but I don’t see that much difference from the existing proposal other than the abstraction and that you have an anchor point for TE attributes (which could be a good thing if these proliferate). > > Thanks, > Acee > > >> >> >> >> -----Original Message----- >> From: Acee Lindem (acee) [mailto:acee@cisco.com] >> Sent: Thursday, August 06, 2015 15:34 >> To: LITKOWSKI Stephane SCE/IBNF; Ebben Aries; isis-wg@ietf.org list >> (isis-wg@ietf.org) >> Subject: Re: [Isis-wg] draft-ginsberg-isis-l2bundles >> >> >> >> 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=75085ca9001f9 >>>>>> c >>>>>> 7 >>>>>> 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.fran >>>>>> c >>>>>> e >>>>>> t >>>>>> e >>>>>> lecom.fr/index.asp?target%3Dhttp%253A%252F%252Fclicvoice.sso.franc >>>>>> e >>>>>> t >>>>>> e >>>>>> l >>>>>> ecom.fr%252FClicvoiceV2%252FToolBar.do%253Faction%253Ddefault%2526 >>>>>> r >>>>>> o >>>>>> o >>>>>> t >>>>>> service%253DSIGNATURE%2526to%253D%26%2343%3B33%25202%252023%252028 >>>>>> % >>>>>> 2 >>>>>> 5 >>>>>> 2 >>>>>> 049%252083%2520&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=GJQFPrZyyh453y >>>>>> w >>>>>> a >>>>>> 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.fran >>>>>> c >>>>>> e >>>>>> t >>>>>> e >>>>>> lecom.fr/index.asp?target%3Dhttp%253A%252F%252Fclicvoice.sso.franc >>>>>> e >>>>>> t >>>>>> e >>>>>> l >>>>>> ecom.fr%252FClicvoiceV2%252FToolBar.do%253Faction%253Ddefault%2526 >>>>>> r >>>>>> o >>>>>> o >>>>>> t >>>>>> service%253DSIGNATURE%2526to%253D%26%2343%3B33%25206%252037%252086 >>>>>> % >>>>>> 2 >>>>>> 5 >>>>>> 2 >>>>>> 097%252052%2520&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=GJQFPrZyyh453y >>>>>> w >>>>>> a >>>>>> 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/ma >>>>>> i >>>>>> l >>>>>> m >>>>>> a >>>>>> n/listinfo/isis-wg&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=GJQFPrZyyh4 >>>>>> 5 >>>>>> 3 >>>>>> y >>>>>> w >>>>>> aGV%2FvoQ%3D%3D%0A&m=xDbMtpjPKPQ26eNh1Ka%2FhnXOqVfqYtZ9MjolqbbcT8U >>>>>> % >>>>>> 3 >>>>>> D >>>>>> % >>>>>> 0A&s=3211164dcbc94ec39a7390a5d1c8371f2c391ec0aeec8806884c6abfd4415 >>>>>> 1 >>>>>> 1 >>>>>> 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. >>> >> >> _______________________________________________________________________ >> ___ _______________________________________________ >> >> 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. > > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www.ietf.org/mailman/listinfo/isis-wg
- [Isis-wg] draft-ginsberg-isis-l2bundles stephane.litkowski
- Re: [Isis-wg] draft-ginsberg-isis-l2bundles Ebben Aries
- Re: [Isis-wg] draft-ginsberg-isis-l2bundles stephane.litkowski
- Re: [Isis-wg] draft-ginsberg-isis-l2bundles Acee Lindem (acee)
- Re: [Isis-wg] draft-ginsberg-isis-l2bundles stephane.litkowski
- Re: [Isis-wg] draft-ginsberg-isis-l2bundles Acee Lindem (acee)
- Re: [Isis-wg] draft-ginsberg-isis-l2bundles stephane.litkowski
- Re: [Isis-wg] draft-ginsberg-isis-l2bundles Acee Lindem (acee)
- Re: [Isis-wg] draft-ginsberg-isis-l2bundles stephane.litkowski
- Re: [Isis-wg] draft-ginsberg-isis-l2bundles Acee Lindem (acee)
- Re: [Isis-wg] draft-ginsberg-isis-l2bundles stephane.litkowski
- Re: [Isis-wg] draft-ginsberg-isis-l2bundles Acee Lindem (acee)
- Re: [Isis-wg] draft-ginsberg-isis-l2bundles Hannes Gredler
- Re: [Isis-wg] draft-ginsberg-isis-l2bundles Ahmed Bashandy (bashandy)
- Re: [Isis-wg] draft-ginsberg-isis-l2bundles stephane.litkowski
- Re: [Isis-wg] draft-ginsberg-isis-l2bundles stephane.litkowski
- Re: [Isis-wg] draft-ginsberg-isis-l2bundles Les Ginsberg (ginsberg)
- Re: [Isis-wg] draft-ginsberg-isis-l2bundles stephane.litkowski
- Re: [Isis-wg] draft-ginsberg-isis-l2bundles Les Ginsberg (ginsberg)
- Re: [Isis-wg] draft-ginsberg-isis-l2bundles stephane.litkowski
- Re: [Isis-wg] draft-ginsberg-isis-l2bundles Hannes Gredler
- Re: [Isis-wg] draft-ginsberg-isis-l2bundles Ahmed Bashandy (bashandy)
- Re: [Isis-wg] draft-ginsberg-isis-l2bundles Ahmed Bashandy (bashandy)