Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-extensions-04
Xiejingrong <xiejingrong@huawei.com> Wed, 14 February 2018 06:46 UTC
Return-Path: <xiejingrong@huawei.com>
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17BFE126579; Tue, 13 Feb 2018 22:46:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.105
X-Spam-Level:
X-Spam-Status: No, score=-3.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=1.125, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
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 ZuMhCDm_Qs7O; Tue, 13 Feb 2018 22:46:49 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58C03124B17; Tue, 13 Feb 2018 22:46:48 -0800 (PST)
Received: from lhreml709-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 572AD4E92F5EF; Wed, 14 Feb 2018 06:46:44 +0000 (GMT)
Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 14 Feb 2018 06:46:43 +0000
Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0361.001; Wed, 14 Feb 2018 14:46:35 +0800
From: Xiejingrong <xiejingrong@huawei.com>
To: Tony Przygienda <tonysietf@gmail.com>, "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
CC: "bier@ietf.org" <bier@ietf.org>, "isis-wg@ietf.org list" <isis-wg@ietf.org>, "IJsbrand Wijnands (iwijnand)" <ice@cisco.com>, "Acee Lindem (acee)" <acee@cisco.com>, Eric C Rosen <erosen@juniper.net>, "Peter Psenak (ppsenak)" <ppsenak@cisco.com>
Thread-Topic: [Bier] WGLC: draft-ietf-bier-isis-extensions-04
Thread-Index: AQHTm0a871s3IkGkGk2rTq5licQQ26OPJUoAgAhnDwCABFK8AIAAFE4AgAABsACAAAIZgIAAAYeAgARuoACAABDAgIAAFJQAgAAWmYCAABl6AIAAAlaAgAAMsgCAAAUWAIAACVmAgAAEpACAAJmSgIAAHesAgABFQQCAAC3/gIAAA9IAgAACL4CAAA3SgIAACHqAgAFh/ZA=
Date: Wed, 14 Feb 2018 06:46:34 +0000
Message-ID: <16253F7987E4F346823E305D08F9115A99A1778A@nkgeml514-mbx.china.huawei.com>
References: <20170721062741.GA3215@faui40p.informatik.uni-erlangen.de> <CAG4d1rcZnZmbfU3AnLgfCJmOz-dJ0uv8VUZE+BQ9Qq3B=7DgZg@mail.gmail.com> <CA+wi2hNrQV+gyQS_ts-38w2OWYOkTXUy-Q3b0FAGKaztE8D+QQ@mail.gmail.com> <CABFReBoWZeQxnOCERr9EVykE5dY8p04KQT=JsDqk2eN2Q9p_2g@mail.gmail.com> <CA+wi2hPtxa_Z7VS6Hnj5Y4iQG3RUx7GP6exkf9o4ZcQr2eU_ig@mail.gmail.com> <5A81ABAC.107@cisco.com> <69EEC1F9-3077-4260-BB7A-66F0AEB3357D@cisco.com> <CA+wi2hO0ZPS=3aNY_Et1ChRhzQVJvr1dPiB-ugiC6iGDNpfyfA@mail.gmail.com> <DC7DFF2A-C986-4EA3-A701-6C80C867560B@cisco.com> <CDCE115D-C3AD-47DA-9993-6AC0BD88ED2D@cisco.com> <771dbad8841b42ac8ea3012dc73ef33b@XCH-ALN-001.cisco.com> <CC1CC82E-E134-4931-9735-07A0D0E64997@cisco.com> <e1ce91bb9d28485fbaad63252e1e0e3c@XCH-ALN-001.cisco.com> <E35F158F-2F97-47FD-8272-497B68ABDD1B@cisco.com> <07df09dda97e4dad9450a4a9799ae8c7@XCH-ALN-001.cisco.com> <CA+wi2hNK1WRN89q0uUOF4FLkDHoBBtUZhLxqrceY-q_zu7=8zg@mail.gmail.com> <5A82A9D8.7050606@cisco.com> <5153704a-843f-10de-eb74-c9c3a3ad722e@juniper.net> <CA+wi2hON6E7rdhELLg14ZFKQxyoz_moknhdrbm50BH_Jnopsuw@mail.gmail.com> <0d900502826d41bbb656c343575222ba@XCH-ALN-001.cisco.com> <CA+wi2hPXdZP9RE87MhNmgG0veMO+Gt+qdmCdQQXEFEYeX=ufpw@mail.gmail.com> <198ac8de09334551978f6069714270ab@XCH-ALN-001.cisco.com> <CA+wi2hO_x3DyBn1vveg=KfiMGBqMQKRhiCwZ846UPwX2wZPEHw@mail.gmail.com>
In-Reply-To: <CA+wi2hO_x3DyBn1vveg=KfiMGBqMQKRhiCwZ846UPwX2wZPEHw@mail.gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.217.214]
Content-Type: multipart/alternative; boundary="_000_16253F7987E4F346823E305D08F9115A99A1778Ankgeml514mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/isis-wg/icfmEqG94HpFR_ONPFFE94iZJVY>
Subject: Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-extensions-04
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 14 Feb 2018 06:46:55 -0000
Hi, forks Really a long trip and thread since WG LC to IETF LC! Many great improvements have been made. The draft have been completely changed from version-04, and it looks good to me. I simply share my summary here: (1) Allow BIER info flood spanning multi areas/levels from version-05, thanks to Toerless catched the problem. (2) Allow the BAR field be back in ISIS message to support further other algorithms from version-06. (3) Allow 256 SIs Change Label Range Size to Max SI to from version-07, thanks to Senthil catched the problem. (4) Allow one <SD,BSL,SI> to have multi Encapsulations from version-07, thanks to you guys make it clear that there will be multi encapsulations on a link. (5) And a consensus to clarify this in BIER Architecture documents have been made. (6) And some clarification examples which allow a MT to support multi SDs have been added from version-07. Regards, XieJingrong From: BIER [mailto:bier-bounces@ietf.org] On Behalf Of Tony Przygienda Sent: Wednesday, February 14, 2018 1:37 AM To: Les Ginsberg (ginsberg) <ginsberg@cisco.com> Cc: bier@ietf.org; isis-wg@ietf.org list <isis-wg@ietf.org>; IJsbrand Wijnands (iwijnand) <ice@cisco.com>; Acee Lindem (acee) <acee@cisco.com>; Eric C Rosen <erosen@juniper.net>; Peter Psenak (ppsenak) <ppsenak@cisco.com> Subject: Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-04 As I said, if we think it's more complex than what we wrote for the ISIS draft then I'm fine with a simple "here be dragons" disclaimer on the drafts as long we don't leave it as an unmentioned minefield for the developers. And then we start a draft standardizing, I foresee a BIER, eeh beer session @ the bar in London ;-) --- tony On Tue, Feb 13, 2018 at 9:06 AM, Les Ginsberg (ginsberg) <ginsberg@cisco.com<mailto:ginsberg@cisco.com>> wrote: Tony – I think the issues around supporting multiple encap types and how one might map one encap to another if your outgoing neighbor did not support the incoming encap are much more complex than the simple statement we have in the IS-IS draft. I do think it would be better if we did not make a statement which suggests there is a way to support something – but the actual details of how to support are still TBD. Better to put that in a draft that has the context to completely define such a solution. What is currently in the IS-IS isn’t useful w/o the additional detail. The new text we have is better than the old text – but I do agree with others that it really doesn’t belong in the IGP drafts. Les From: Tony Przygienda [mailto:tonysietf@gmail.com<mailto:tonysietf@gmail.com>] Sent: Tuesday, February 13, 2018 8:17 AM To: Les Ginsberg (ginsberg) <ginsberg@cisco.com<mailto:ginsberg@cisco.com>> Cc: Eric C Rosen <erosen@juniper.net<mailto:erosen@juniper.net>>; Peter Psenak (ppsenak) <ppsenak@cisco.com<mailto:ppsenak@cisco.com>>; Acee Lindem (acee) <acee@cisco.com<mailto:acee@cisco.com>>; bier@ietf.org<mailto:bier@ietf.org>; IJsbrand Wijnands (iwijnand) <ice@cisco.com<mailto:ice@cisco.com>>; isis-wg@ietf.org<mailto:isis-wg@ietf.org> list <isis-wg@ietf.org<mailto:isis-wg@ietf.org>> Subject: Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-04 Yes, it's one possible interpretation ;-) albeit I would be more comfortable to deliver draft(s) that can be looked @ and implemented as they are written and published ;-) So let's say, if we can all agree that there is one correct interpretation (and I suggest of course what we both agreed on but have no vested stake) then I prefer to have the drafts put it in as part of IETF LC comments. If we cannot agree, be it, let us put in a sentence to the tune of "issue of multiple encapsulations on the same <MT,SD,BML> combination is undefined in this RFC" which basically reads "here be dragons" which is inifintely better than having looping implementations because no'one knew what the score was. And in such case I would recommend to immediately follow up with a draft about how multiple encapsulations are to be treated and discuss it out since we all know the issue will likely show up in the field. sounds fair? I'm sorry again I missed it writing the ISIS draft (or rather wrote a section that we realized only on last fine read seemed overly restrictive) ... -- tony On Tue, Feb 13, 2018 at 8:09 AM, Les Ginsberg (ginsberg) <ginsberg@cisco.com<mailto:ginsberg@cisco.com>> wrote: Tony – Can I interpret this as meaning you are OK with removing the text about multiple encapsulations from the IS-IS draft? Les From: Tony Przygienda [mailto:tonysietf@gmail.com<mailto:tonysietf@gmail.com>] Sent: Tuesday, February 13, 2018 7:56 AM To: Eric C Rosen <erosen@juniper.net<mailto:erosen@juniper.net>> Cc: Peter Psenak (ppsenak) <ppsenak@cisco.com<mailto:ppsenak@cisco.com>>; Les Ginsberg (ginsberg) <ginsberg@cisco.com<mailto:ginsberg@cisco.com>>; Acee Lindem (acee) <acee@cisco.com<mailto:acee@cisco.com>>; bier@ietf.org<mailto:bier@ietf.org>; IJsbrand Wijnands (iwijnand) <ice@cisco.com<mailto:ice@cisco.com>>; isis-wg@ietf.org<mailto:isis-wg@ietf.org> list <isis-wg@ietf.org<mailto:isis-wg@ietf.org>> Subject: Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-04 +1 Eric's take ... I don't see how we can interpret it/standardize it in many ways unless we want it to be overly restrictive but in any case I think a new draft is a good thing. And sigh, we didn't pay enough attention since the issue seemed "ephemeral" (and arguably, there were many things more worth aruging to be argued then ;-) but with ether it needs clarification. The way it slipped me was that while writing the ISIS draft originally and using the <MT,SD,BML> I thought briefly based on my UML that it's really <MT,SD,ENC,BML> but then I was thinking "gosh, this is getting deep and people will probably roll their eyes" ;-) Another principle slipped, another lesson learned albeit I think this one is pretty harmless. Question more being: are we ready with the OSPF draft if we leave that completely open. If I'd be an implementer (or maybe I am ;-) I would have no issue implementing the ISIS draft in a clear way when computing, without any ENC explanation I would say @ this point in computaiton "hmm, am I supposed ignore the TLV because I see encaps I don't understand/support on this link" or do I install in fast-path just any encapsulation we both agree on? (Or we could think about e.g. is MPLS preferred over anything else, i.e. have a predictable ordering which may play a role if someone wants to debug the network). Or otherwise, yes, we could sya, more than ONE encap on the link is illegal (but that's not what my UML based on architecture doc/discussion says ;-) yes, it's finely carved, yes, IGPs always are ... --- tony On Tue, Feb 13, 2018 at 5:11 AM, Eric C Rosen <erosen@juniper.net<mailto:erosen@juniper.net>> wrote: If some folks think that there needs to be a correction or addition to the architecture, the best thing to do would be to write a new draft and post it for discussion. This appears to be a substantive technical issue, which is not appropriate for an erratum. It also doesn't seem appropriate for the IGP drafts. On 2/13/2018 4:03 AM, Peter Psenak wrote: Hi Folks, can we add an errata to RFC 8279, instead of adding the text to both IGP drafts that does not really belong there. thanks, Peter On 13/02/18 08:16 , Tony Przygienda wrote: +1 what Les says as my understanding of the problem we're tackling here ... --- tony On Mon, Feb 12, 2018 at 2:06 PM, Les Ginsberg (ginsberg) <ginsberg@cisco.com<mailto:ginsberg@cisco.com> <mailto:ginsberg@cisco.com<mailto:ginsberg@cisco.com>>> wrote: Ice –____ __ __ MY understanding is that – in the future – there may be additional encaps defined for BIER. When that happens, a given BFR may support multiple encaps. In such a case, it is OK if other BFRs supporting the same <MT,SD> only support one of the set of encaps – so long as we have one encap in common we can successfully forward. I believe that is the case the text change is trying to address – not encap vs no encap. The original text would have required identical sets of encaps to be supported by all BFRs for a give <MT,SD> - which is unnecessarily restrictive.____ __ __ Make sense?____ __ __ Les____ __ __ __ __ *From:*IJsbrand Wijnands (iwijnand) *Sent:* Monday, February 12, 2018 1:50 PM *To:* Les Ginsberg (ginsberg) <ginsberg@cisco.com<mailto:ginsberg@cisco.com> <mailto:ginsberg@cisco.com<mailto:ginsberg@cisco.com>>> *Cc:* Acee Lindem (acee) <acee@cisco.com<mailto:acee@cisco.com> <mailto:acee@cisco.com<mailto:acee@cisco.com>>>; bier@ietf.org<mailto:bier@ietf.org> <mailto:bier@ietf.org<mailto:bier@ietf.org>>; Peter Psenak (ppsenak) <ppsenak@cisco.com<mailto:ppsenak@cisco.com> <mailto:ppsenak@cisco.com<mailto:ppsenak@cisco.com>>>; isis-wg@ietf.org<mailto:isis-wg@ietf.org> <mailto:isis-wg@ietf.org<mailto:isis-wg@ietf.org>> list <isis-wg@ietf.org<mailto:isis-wg@ietf.org> <mailto:isis-wg@ietf.org<mailto:isis-wg@ietf.org>>> *Subject:* Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-04____ __ __ Les,____ __ __ (If MPLS encapsulation (Section 2.1 of [MPLS_BIER_ENCAPS]) is being used, this means that every BFR that is advertising a label for sub-domain S is advertising a label for the combination of sub-domain S and Disposition BitStringLength L.)____ __ __ It says, if MPLS encapsulation is used, there is a Label for the {SD, BSL}. So, if there is non-MPLS (ether) only, there will not be a Label and the compatibility check will fail. Is that not the same a router that does not support MPLS BIER, and treated as a non-BIER router?____ __ __ [Les:] I don’t see how this text can be used to mean “multiple encap types can be supported on the same BFR for a given <MT,SD>”. ???____ __ __ Are these not like ships in the night? Like an Prefix can be reachable over MPLS and IP on the same interface? I do assume you want to stay with the encapsulation that you where provisioned in and not move from MPLS into non-MPLS. Why do you need to say you can support both?____ __ __ Thx,____ __ __ Ice.____ __ __ __ __ On 12 Feb 2018, at 22:16, Les Ginsberg (ginsberg) <ginsberg@cisco.com<mailto:ginsberg@cisco.com> <mailto:ginsberg@cisco.com<mailto:ginsberg@cisco.com>>> wrote: Ice - From: IJsbrand Wijnands (iwijnand) Sent: Monday, February 12, 2018 12:58 PM To: Les Ginsberg (ginsberg) <ginsberg@cisco.com<mailto:ginsberg@cisco.com> <mailto:ginsberg@cisco.com<mailto:ginsberg@cisco.com>>> Cc: Acee Lindem (acee) <acee@cisco.com<mailto:acee@cisco.com> <mailto:acee@cisco.com<mailto:acee@cisco.com>>>; bier@ietf.org<mailto:bier@ietf.org> <mailto:bier@ietf.org<mailto:bier@ietf.org>>; Peter Psenak (ppsenak) <ppsenak@cisco.com<mailto:ppsenak@cisco.com> <mailto:ppsenak@cisco.com<mailto:ppsenak@cisco.com>>>; isis-wg@ietf.org<mailto:isis-wg@ietf.org> <mailto:isis-wg@ietf.org<mailto:isis-wg@ietf.org>> list <isis-wg@ietf.org<mailto:isis-wg@ietf.org> <mailto:isis-wg@ietf.org<mailto:isis-wg@ietf.org>>> Subject: Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-04 Les, Perhaps the thread is too long and you have gotten confused. J Maybe :-), but... The point being discussed now is support for multiple encapsulation types (BSL conversion was mentioned in the thread – but it is NOT the subject being discussed at the moment). I got that, it was removed after a long debate sometime back. In latest IS-IS BIER draft we changed: > All routers in the flooding scope of the BIER TLVs MUST advertise the > same encapsulation for a given <MT,SD>. A router discovering > encapsulation advertised that is different from its own MUST report a > misconfiguration of a specific <MT,SD>. All received BIER > advertisements associated with the conflicting <MT, SD> pair MUST be > ignored. > > " > > to > > " > > Multiple encapsulations MAY be advertised/supported for a given > <MT,SD>. Clearly, however, there MUST be at least one encapsulation > type in common in order for a BIER encapsulated packet to be > successfully forwarded between two BFRs. > Point has been made that this really belongs in the architecture RFC, but since it isn’t there it may make sense for the IGP drafts to mention it. Below is taken from "6.10.1. BitStringLength Compatibility Check” RFC 8279, does this not cover it? **** The combination of sub-domain S and Imposition BitStringLength L passes the BitStringLength Compatibility Check if and only if the following condition holds: Every BFR that has advertised its membership in sub-domain S has also advertised that it is using Disposition BitStringLength L (and possibly other BitStringLengths as well) in that sub-domain. (If MPLS encapsulation (Section 2.1 of [MPLS_BIER_ENCAPS]) is being used, this means that every BFR that is advertising a label for sub-domain S is advertising a label for the combination of sub-domain S and Disposition BitStringLength L.) If a BFIR has been provisioned to use a particular Imposition BitStringLength and a particular sub-domain for some set of packets, and if that combination of Imposition BitStringLength and sub-domain does not pass the BitStringLength Compatibility Check, the BFIR SHOULD log this fact as an error. **** [Les:] I don’t see how this text can be used to mean “multiple encap types can be supported on the same BFR for a given <MT,SD>”. ??? Les Thx, Ice. In the case of IS-IS, because earlier versions of the draft had an explicit statement which we now consider too limiting, it made sense to make an explicit statement of the more flexible behavior. In the case of OSPF, the overly restrictive text was never present, so it is more debatable as to whether the clarifying statement is needed – but doing so keeps the drafts in sync. Still, the “right solution” would be to have the statement in RFC 8279 – but a bit late for that. Les From: IJsbrand Wijnands (iwijnand) Sent: Monday, February 12, 2018 12:05 PM To: Acee Lindem (acee) <acee@cisco.com<mailto:acee@cisco.com> <mailto:acee@cisco.com<mailto:acee@cisco.com>>> Cc: Tony Przygienda <tonysietf@gmail.com<mailto:tonysietf@gmail.com> <mailto:tonysietf@gmail.com<mailto:tonysietf@gmail.com>>>; Les Ginsberg (ginsberg) <ginsberg@cisco.com<mailto:ginsberg@cisco.com> <mailto:ginsberg@cisco.com<mailto:ginsberg@cisco.com>>>; bier@ietf.org<mailto:bier@ietf.org> <mailto:bier@ietf.org<mailto:bier@ietf.org>>; isis-wg@ietf.org<mailto:isis-wg@ietf.org> <mailto:isis-wg@ietf.org<mailto:isis-wg@ietf.org>> list <isis-wg@ietf.org<mailto:isis-wg@ietf.org> <mailto:isis-wg@ietf.org<mailto:isis-wg@ietf.org>>>; Peter Psenak (ppsenak) <ppsenak@cisco.com<mailto:ppsenak@cisco.com> <mailto:ppsenak@cisco.com<mailto:ppsenak@cisco.com>>> Subject: Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-04 Folks, I would say its wrong to try and fix the BIER architecture by adding this into the IGP drafts. The IGP is a pass-through for the BIER information, and adding this text seems to imply that the IGP now needs to become BIER aware in order to detect and trigger notifications of encapsulation incompatibilities. The BIER architecture RFC 8279 has section 6.10 "Use of Different BitStringLengths within a Domain”, what is missing in that section that would justify the IGP to become aware of BitStringLength differences? IMO everything is covered. Thx, Ice. On 12 Feb 2018, at 19:33, Acee Lindem (acee) <acee@cisco.com<mailto:acee@cisco.com> <mailto:acee@cisco.com<mailto:acee@cisco.com>>> wrote: Hi Tony, I agree that since architecture has been published, it would not hurt to add the 5.2 text to the IGP documents. Thanks, Acee From: Tony Przygienda <tonysietf@gmail.com<mailto:tonysietf@gmail.com> <mailto:tonysietf@gmail.com<mailto:tonysietf@gmail.com>>> Date: Monday, February 12, 2018 at 12:13 PM To: Acee Lindem <acee@cisco.com<mailto:acee@cisco.com> <mailto:acee@cisco.com<mailto:acee@cisco.com>>> Cc: "Peter Psenak (ppsenak)" <ppsenak@cisco.com<mailto:ppsenak@cisco.com> <mailto:ppsenak@cisco.com<mailto:ppsenak@cisco.com>>>, "Les Ginsberg (ginsberg)" <ginsberg@cisco.com<mailto:ginsberg@cisco.com> <mailto:ginsberg@cisco.com<mailto:ginsberg@cisco.com>>>, "bier@ietf.org<mailto:bier@ietf.org> <mailto:bier@ietf.org<mailto:bier@ietf.org>>" <bier@ietf.org<mailto:bier@ietf.org> <mailto:bier@ietf.org<mailto:bier@ietf.org>>>, "isis-wg@ietf.org<mailto:isis-wg@ietf.org> list <mailto:isis-wg@ietf.org<mailto:isis-wg@ietf.org>%20list>" <isis-wg@ietf.org<mailto:isis-wg@ietf.org> <mailto:isis-wg@ietf.org<mailto:isis-wg@ietf.org>>> Subject: Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-04 Peter, Acee, agree that this was missed in architecture and we should have talked about multiple encaps on a link there (just like we mentioned the BSL conversion). Alas, it was theoretical then and we missed. It was just a suggestion here to put it into IGP draft as we did in ISIS. I'm fine whichever way you guys feel it's better and a clarification draft can be always published later after more experience in the field albeit it seems that the issue is straight fwd' for most old hands, it's a link local decision so just use any matching encaps to transfer, however the computation has to agree to prevent blackholes ... Otherwise went through the important sections on -11 and looks good to me, no further comments. Thanks for the work --- tony On Mon, Feb 12, 2018 at 7:58 AM, Acee Lindem (acee) <acee@cisco.com<mailto:acee@cisco.com> <mailto:acee@cisco.com<mailto:acee@cisco.com>>> wrote: With respect to the text in section 5.2, I agree with Peter. Thanks Acee On 2/12/18, 9:59 AM, "BIER on behalf of Peter Psenak (ppsenak)" <bier-bounces@ietf.org<mailto:bier-bounces@ietf.org> on behalf of ppsenak@cisco.com<mailto:ppsenak@cisco.com> <mailto:bier-bounces@ietf.org<mailto:bier-bounces@ietf.org>%20on%20behalf%20of%C2%A0ppsenak@cisco.com<mailto:20on%2520behalf%2520of%25C2%25A0ppsenak@cisco.com>>> wrote: Hi Tony, OSPF does not have the original text, so it does not need the new one. IMHO, the text in section 5 of ISIS BIER draft suits better to the BIER architecture draft than to the IGP extension draft. thanks, Peter On 09/02/18 20:17 , Tony Przygienda wrote: > Sure ;-) let me ping Peter @ the bottom then ... I don't think any of > the stuff applies to OSPF (was ISIS nits) except we can consider an > encaps paragraph. We basically suggest both to replace in ISIS the > encaps section like this > > before: > > " > All routers in the flooding scope of the BIER TLVs MUST advertise the > same encapsulation for a given <MT,SD>. A router discovering > encapsulation advertised that is different from its own MUST report a > misconfiguration of a specific <MT,SD>. All received BIER > advertisements associated with the conflicting <MT, SD> pair MUST be > ignored. > > " > > now > > " > > Multiple encapsulations MAY be advertised/supported for a given > <MT,SD>. Clearly, however, there MUST be at least one encapsulation > type in common in order for a BIER encapsulated packet to be > successfully forwarded between two BFRs. > > " > > I do think that OSPF would benefit from adding this section to clarify > the issue which is not theoretical now that we have Ethernet. > > > So Peter, any ETA on outstanding OSPF nits now that we're tying up the > IETF LC? > > thanks > > --- tony > > > On Fri, Feb 9, 2018 at 11:12 AM, Greg Shepherd <gjshep@gmail.com<mailto:gjshep@gmail.com> <mailto:gjshep@gmail.com<mailto:gjshep@gmail.com>%0b%C2%A0%20>> <mailto:gjshep@gmail.com<mailto:gjshep@gmail.com>>> wrote: > > No I didn't. Why would I? These are the changes you and Les worked > out. I assumed you'd share them as needed. If for some reason you're > uncomfortable engaging with the OSPF draft thread and authors with > your proposed changes, let me know and I'll broker the conversation. > > Greg > > On Fri, Feb 9, 2018 at 11:04 AM, Tony Przygienda > <tonysietf@gmail.com<mailto:tonysietf@gmail.com> <mailto:tonysietf@gmail.com<mailto:tonysietf@gmail.com> <mailto:tonysietf@gmail.com<mailto:tonysietf@gmail.com>%20%3cmailto:tonysietf@gmail.com<mailto:20%253cmailto%3Atonysietf@gmail.com>>>> wrote: > > Les has the diff, I'd expect him to publish any minute to the > list ... The encaps was a real defect, the rest is just > tightening down the language/spec where it was too loose/too > strict. > > OSPF still needs update with conversion TLV removed, same > paragraph on encaps could be useful. I hope Greg pinged Peter ... > > thanks > > tony > > On Fri, Feb 9, 2018 at 10:58 AM, Alia Atlas <akatlas@gmail.com<mailto:akatlas@gmail.com> <mailto:akatlas@gmail.com<mailto:akatlas@gmail.com>%0b%C2%A0%20>> <mailto:akatlas@gmail.com<mailto:akatlas@gmail.com>>> wrote: > > On Fri, Feb 9, 2018 at 12:46 PM, Tony Przygienda > <tonysietf@gmail.com<mailto:tonysietf@gmail.com> <mailto:tonysietf@gmail.com<mailto:tonysietf@gmail.com> <mailto:tonysietf@gmail.com<mailto:tonysietf@gmail.com>%20%3cmailto:tonysietf@gmail.com<mailto:20%253cmailto%3Atonysietf@gmail.com>>>> wrote: > > Went last nits with Les, we found one issue (encaps > section was wrong, need to look @ OSPF as well) and > basically tightened language in few places. > > > K - please get that out with the details of changes to the > list. I did my AD review back in Oct and looked at the > differences before issuing > IETF Last Call. > > I look forward to reviewing the minor changes. > > Regards, > Alia > > tony > > On Tue, Feb 6, 2018 at 3:45 PM, Greg Shepherd > <gjshep@gmail.com<mailto:gjshep@gmail.com> <mailto:gjshep@gmail.com<mailto:gjshep@gmail.com> <mailto:gjshep@gmail.com<mailto:gjshep@gmail.com>%20%3cmailto:gjshep@gmail.com<mailto:20%253cmailto%3Agjshep@gmail.com>>>> wrote: > > Thanks Les. > > Any other feedback? Looks like the concerns have > been addressed. Speak now. > > Cheers, > Greg > > On Thu, Feb 1, 2018 at 7:26 AM, Les Ginsberg > (ginsberg) <ginsberg@cisco.com<mailto:ginsberg@cisco.com> <mailto:ginsberg@cisco.com<mailto:ginsberg@cisco.com>%0b%C2%A0%20>> <mailto:ginsberg@cisco.com<mailto:ginsberg@cisco.com>>> wrote: > > Greg –____ > > __ __ > > This thread is outdated.____ > > In V6 of the draft we removed the restriction to > limit IS-IS BIER support to area boundaries – so > Toerless’s comment (and my proposed text) are no > longer relevant.____ > > __ __ > > Specifically:____ > > __ __ > > Section 4.1:____ > > __ __ > > “At present, IS-IS support for a given BIER > domain/sub-domain is ____ > > limited to a single area - > or to the IS-IS L2 sub-domain.”____ > > __ __ > > The above text was removed.____ > > __ __ > > Section 4.2____ > > __ __ > > o BIER sub-TLVs MUST NOT be included when a > prefix reachability____ > > advertisement is leaked between levels.____ > > __ __ > > Was changed to____ > > __ __ > > o BIER sub-TLVs MUST be included when a prefix > reachability____ > > advertisement is leaked between levels.____ > > __ __ > > This aligns IS-IS and OSPF drafts in this > regard.____ > > __ __ > > Les____ > > __ __ > > *From:*Greg Shepherd [mailto:gjshep@gmail.com<mailto:gjshep@gmail.com> > <mailto:gjshep@gmail.com<mailto:gjshep@gmail.com>> <mailto:gjshep@gmail.com<mailto:gjshep@gmail.com>%0b%C2%A0%20%C2%A0%20%3e%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%3cmailto:gjshep@gmail.com<mailto:0b%25C2%25A0%2520%25C2%25A0%2520%253e%2520%25C2%25A0%2520%25C2%25A0%2520%25C2%25A0%2520%25C2%25A0%2520%25C2%25A0%2520%25C2%25A0%2520%25C2%25A0%2520%25C2%25A0%2520%25C2%25A0%2520%25C2%25A0%2520%25C2%25A0%2520%25C2%25A0%2520%253cmailto%3Agjshep@gmail.com>%3e>] > *Sent:* Thursday, February 01, 2018 2:23 AM > *To:* Toerless Eckert <tte@cs.fau.de<mailto:tte@cs.fau.de> <mailto:tte@cs.fau.de<mailto:tte@cs.fau.de>%0b%C2%A0%20>> <mailto:tte@cs.fau.de<mailto:tte@cs.fau.de>>> > *Cc:* Les Ginsberg (ginsberg) > <ginsberg@cisco.com<mailto:ginsberg@cisco.com> <mailto:ginsberg@cisco.com<mailto:ginsberg@cisco.com>%0b%C2%A0%20>> <mailto:ginsberg@cisco.com<mailto:ginsberg@cisco.com>>>; Tony Przygienda > <tonysietf@gmail.com<mailto:tonysietf@gmail.com> <mailto:tonysietf@gmail.com<mailto:tonysietf@gmail.com>%0b%C2%A0%20>> <mailto:tonysietf@gmail.com<mailto:tonysietf@gmail.com>>>; Hannes Gredler > (hannes@gredler.at<mailto:hannes@gredler.at> <mailto:hannes@gredler.at<mailto:hannes@gredler.at>> <mailto:hannes@gredler.at<mailto:hannes@gredler.at> <mailto:hannes@gredler.at<mailto:hannes@gredler.at>>>) > <hannes@gredler.at<mailto:hannes@gredler.at> <mailto:hannes@gredler.at<mailto:hannes@gredler.at> <mailto:hannes@gredler.at<mailto:hannes@gredler.at>%20%3cmailto:hannes@gredler.at<mailto:20%253cmailto%3Ahannes@gredler.at>>>>; > bier@ietf.org<mailto:bier@ietf.org> <mailto:bier@ietf.org<mailto:bier@ietf.org>> <mailto:bier@ietf.org<mailto:bier@ietf.org> <mailto:bier@ietf.org<mailto:bier@ietf.org>>>; > isis-wg@ietf.org<mailto:isis-wg@ietf.org> <mailto:isis-wg@ietf.org<mailto:isis-wg@ietf.org>> <mailto:isis-wg@ietf.org<mailto:isis-wg@ietf.org> <mailto:isis-wg@ietf.org<mailto:isis-wg@ietf.org>>> list > <isis-wg@ietf.org<mailto:isis-wg@ietf.org> <mailto:isis-wg@ietf.org<mailto:isis-wg@ietf.org> <mailto:isis-wg@ietf.org<mailto:isis-wg@ietf.org>%20%3cmailto:isis-wg@ietf.org<mailto:20%253cmailto%3Aisis-wg@ietf.org>>>>; > Christian Hopps <chopps@chopps.org<mailto:chopps@chopps.org> <mailto:chopps@chopps.org<mailto:chopps@chopps.org>%0b%C2%A0%20>> <mailto:chopps@chopps.org<mailto:chopps@chopps.org>>> > > > *Subject:* Re: [Bier] WGLC: > draft-ietf-bier-isis-extensions-04____ > > __ __ > > Have these changes been reflected in the draft? > We're in WGLC but this discussion needs to come > to a conclusion so we can progress. ____ > > __ __ > > Greg____ > > __ __ > > On Tue, Jul 25, 2017 at 12:52 PM, Toerless > Eckert <tte@cs.fau.de<mailto:tte@cs.fau.de> <mailto:tte@cs.fau.de<mailto:tte@cs.fau.de> <mailto:tte@cs.fau.de<mailto:tte@cs.fau.de>%20%3cmailto:tte@cs.fau.de<mailto:20%253cmailto%3Atte@cs.fau.de>>>> > wrote:____ > > Thanks, Less, that would be lovely! > > I didn't check the OSPF draft, if its > similar state, explanatory text wold equally > be appreciated.____ > > > On Sun, Jul 23, 2017 at 11:28:08PM +0000, > Les Ginsberg (ginsberg) wrote: > > Toerless - > > > > I am thinking to add a statement in > Section 4.1 - something like: > > > > "At present, IS-IS support for a given > BIER domain/sub-domain is limited to a > single area - or to the IS-IS L2 sub-domain." > > > > If you believe this would be helpful I > will spin a new version (subject to > review/agreement from my co-authors). > > > > Les > > > > > > > -----Original Message----- > > > From: Toerless Eckert > [mailto:tte@cs.fau.de<mailto:tte@cs.fau.de> <mailto:tte@cs.fau.de<mailto:tte@cs.fau.de>> <mailto:tte@cs.fau.de<mailto:tte@cs.fau.de>%20%3cmailto:tte@cs.fau.de<mailto:20%253cmailto%3Atte@cs.fau.de>%3e>] > > > Sent: Saturday, July 22, 2017 6:34 AM > > > To: Les Ginsberg (ginsberg) > > > Cc: Tony Przygienda; Hannes Gredler > (hannes@gredler.at<mailto:hannes@gredler.at> <mailto:hannes@gredler.at<mailto:hannes@gredler.at>> > <mailto:hannes@gredler.at<mailto:hannes@gredler.at>>); Greg Shepherd; > > > bier@ietf.org<mailto:bier@ietf.org> <mailto:bier@ietf.org<mailto:bier@ietf.org>> <mailto:bier@ietf.org<mailto:bier@ietf.org> <mailto:bier@ietf.org<mailto:bier@ietf.org>>>; > isis-wg@ietf.org<mailto:isis-wg@ietf.org> <mailto:isis-wg@ietf.org<mailto:isis-wg@ietf.org>> <mailto:isis-wg@ietf.org<mailto:isis-wg@ietf.org> <mailto:isis-wg@ietf.org<mailto:isis-wg@ietf.org>>> > list; Christian Hopps > > > Subject: Re: [Bier] WGLC: > draft-ietf-bier-isis-extensions-04 > > > > > > Thanks Les > > > > > > When searching various terms in the doc > to figure out what happens i am not > > > sure why i missed this one. > > > > > > But: IMHO, RFCs can not only be the > minimum number of words to get a > > > running implementation. It also needs > to specify what this implementation > > > intends to achieve. Otherwise its not > possible to do a useful review: > > > The reviewer can to verify whether the > spec will achieve what it claims to > > > achieve is there no definitionn of what > it claims to achieve. > > > > > > If i understand ISIS correctly, my > reverse engineering of the intent is: > > > > > > - BIER TLVs stay within single ISIS > areas. BFIR and BFER must therefore be > > > in the same ISIS area: There is no > inter-area BIER traffic possible > > > with this specification. This is also > true for ISIS area 0. > > > > > > - The same BIER sub-domain identifiers > can be re-used > > > across different ISIS areas without > any current impact. If these BFR-IDs > > > are non-overlapping, then this would > allow in the future to create a single > > > cross ISIS area BIER sub-domain by > leaking TLVs for such a BIER sub-domain > > > across ISIS levels. Leakage is > outside the scope of this specificication. > > > > > > I actually even would like to do the > following: > > > > > > - If BIER sub-domains are made to span > multiple ISIS areas and BFR-ids > > > assignemtns > > > are made such that all BFR-ids with > the same SI are in the same ISIS ara, > > > then it should be in the future > reasonably easy to create inter-area BIER > > > not by leaking of the BIER TLV but by > having BFIR MPLS unicastBIER packets > > > for different SIs to an appropriate > L2L1 BFIR that is part of the destination > > > area/SI. > > > (if you would use SI number that are > the same as ISIS area numbers then > > > you could probably do this without > any new signaling. Not quite sure if > > > you can today easily find L1L2 > border router for another area via existing > > > TLVs). > > > > > > Alas, this idea will probably be > killed because of the BIER architecture > > > intent not to engineer SI assignments > in geographical fashions to > > > minimize traffic duplication in the > presence of multiple SIs. > > > > > > Cheers > > > Toerless > > > > > > On Sat, Jul 22, 2017 at 06:03:53AM > +0000, Les Ginsberg (ginsberg) wrote: > > > > Tony/Toerless ??? > > > > > > > > There is an explicit statement as to > scope: > > > > > > > > <snip> > > > > Section 4.2 > > > > ??? > > > > o BIER sub-TLVs MUST NOT be > included when a prefix reachability ... [Message clipped]
- [Isis-wg] WGLC: draft-ietf-bier-isis-extensions-04 Greg Shepherd
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Toerless Eckert
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Tony Przygienda
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Les Ginsberg (ginsberg)
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Toerless Eckert
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Tony Przygienda
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Les Ginsberg (ginsberg)
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Toerless Eckert
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Greg Shepherd
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Les Ginsberg (ginsberg)
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Greg Shepherd
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Greg Shepherd
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… IJsbrand Wijnands (iwijnand)
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Tony Przygienda
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Greg Shepherd
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Tony Przygienda
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Alia Atlas
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Alia Atlas
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Tony Przygienda
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Greg Shepherd
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Tony Przygienda
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Tony Przygienda
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… IJsbrand Wijnands
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… IJsbrand Wijnands
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Peter Psenak
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Peter Psenak
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Acee Lindem (acee)
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Tony Przygienda
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Acee Lindem (acee)
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… IJsbrand Wijnands
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Les Ginsberg (ginsberg)
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Tony Przygienda
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… IJsbrand Wijnands
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Les Ginsberg (ginsberg)
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… IJsbrand Wijnands
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Les Ginsberg (ginsberg)
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Tony Przygienda
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Peter Psenak
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… IJsbrand Wijnands
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Acee Lindem (acee)
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Eric C Rosen
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Tony Przygienda
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Les Ginsberg (ginsberg)
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Tony Przygienda
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Les Ginsberg (ginsberg)
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Tony Przygienda
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Xiejingrong