Re: [Bier] WG LC on https://datatracker.ietf.org/doc/draft-ietf-bier-pim-signaling/
Greg Shepherd <gjshep@gmail.com> Mon, 14 September 2020 20:29 UTC
Return-Path: <gjshep@gmail.com>
X-Original-To: bier@ietfa.amsl.com
Delivered-To: bier@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD4533A0EEB; Mon, 14 Sep 2020 13:29:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 hd_QEIM4pKZO; Mon, 14 Sep 2020 13:29:31 -0700 (PDT)
Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEACB3A0D44; Mon, 14 Sep 2020 13:29:30 -0700 (PDT)
Received: by mail-ej1-x62f.google.com with SMTP id gr14so1870732ejb.1; Mon, 14 Sep 2020 13:29:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=UkAZaoEQLCzjafjCFIhKNCJLbwQr1ZTJfr5HNcNQs9c=; b=kPzPx8A4oR/kjLDaYYhJzITugb4orAn147DV900m9gvVi1w8sOK3dVVJs/jktbcIEp sXSy1ZP2KOYPACMBiwM+apctm+UNuwx1p0tVnY1GhZKefZ76HT4uYTCXTisXgNkUHCWT rNx11RFJYGDBrsYZh5Uw5CEc+DykFwEIH33f8bZ7BXxqChO/PKxRi9kJ/QkNrqyVJaT/ viBmFKpWKwetPUIJ2lJfldPSjNl/ldoTfgTM3VZrJUlkP1JDFVfqNVLxVYLDeYwsjwrR 9icOun5hUaBxmwlZqNX8+vdmR6pkbzMnyfgXN0ZdCYZssK+q7oqizcGKdqYwqoR0BcQh d8aw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=UkAZaoEQLCzjafjCFIhKNCJLbwQr1ZTJfr5HNcNQs9c=; b=EmZKBYMxwj/0HBj13H/EgVLD48SFZWQaIpDHLEelKzyQcSaJze2ttD12BL56WzNvuL khYWy0JzvX1cWS4KCJNlnxAkZdsr4iqzz5CrVn6qZtKI4mhzFtdtaiGqJOmSvifeqRNf Mo+z7qsmW7VNkOYIuwOZtcBqmmSpGqimc3X3oeDQHuMu54eJZikNXXkxtFyIrJw8VSqz nIV3ACXk2uHU1oZEqoiy84sgTqAxihRJ/82WPKIK1NP8wOKjPSphiT8fLntDamY9UFMG x9/kz34NSrqhV5BZMH4O4rycKyPOouFL8UzYdIGVxo6FN/efOR6QlnzFrBcexBx+kn9w yL9g==
X-Gm-Message-State: AOAM533QBU23iY755ol70R2viJWb/CdMgzfG8kruVE/rGi2PVLVlgz8R Yj8qHanJRMVZmcJ79GNhHpPLEivfhWW/kkY3Q5b6FPGp
X-Google-Smtp-Source: ABdhPJwFuSUQwPAxbIAy/ygPhCxMMWYI1qJGhtQdMhg10XGIf2nechKGD8N1YmiYbLEomNArrTZTmOqgP+2+0sEUf+k=
X-Received: by 2002:a17:906:2a17:: with SMTP id j23mr16203620eje.146.1600115369121; Mon, 14 Sep 2020 13:29:29 -0700 (PDT)
MIME-Version: 1.0
References: <CABFReBpUv871vDqmOwZ4q6xcN8GsHn_y5BpB6gJ8t2mnna37Kg@mail.gmail.com> <F5F12874-D276-4D13-A4FF-A45B8030029B@cisco.com> <CAHANBtL2VuEKo4xXFnifPhJQpN83mhgr7H5re6b_43oeEQ_+9w@mail.gmail.com> <CAHANBtJQiNHh2E6KuFqYx-arcCVexFq_Qj_DmcXH2=C=4bywKA@mail.gmail.com> <DM6PR08MB3978481BDAF67B364760B0C091730@DM6PR08MB3978.namprd08.prod.outlook.com>
In-Reply-To: <DM6PR08MB3978481BDAF67B364760B0C091730@DM6PR08MB3978.namprd08.prod.outlook.com>
Reply-To: gjshep@gmail.com
From: Greg Shepherd <gjshep@gmail.com>
Date: Mon, 14 Sep 2020 13:29:54 -0700
Message-ID: <CABFReBrcPe0Lry4VRZv34qH9fHuZhcvbkvB8MO7Onm0eT0B3dA@mail.gmail.com>
To: "Bidgoli, Hooman (Nokia - CA/Ottawa)" <hooman.bidgoli@nokia.com>
Cc: Stig Venaas <stig@venaas.com>, "Mankamana Mishra (mankamis)" <mankamis@cisco.com>, BIER WG <bier@ietf.org>, Ijsbrand Wijnands <ice@cisco.com>, "bier-chairs@ietf.org" <bier-chairs@ietf.org>, "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>, Antoni Przygienda <prz@juniper.net>
Content-Type: multipart/alternative; boundary="0000000000002d1b4905af4be4f1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/gi80lwi2va71Rq6AMxa6N8S1l9c>
Subject: Re: [Bier] WG LC on https://datatracker.ietf.org/doc/draft-ietf-bier-pim-signaling/
X-BeenThere: bier@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "\"Bit Indexed Explicit Replication discussion list\"" <bier.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bier>, <mailto:bier-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bier/>
List-Post: <mailto:bier@ietf.org>
List-Help: <mailto:bier-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bier>, <mailto:bier-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Sep 2020 20:29:34 -0000
It appears that issues have been addressed as per the list discussion of July 28th. The latest rev was posted July 29th, I assume with the agreed changes, correct? Let's do a quick 1 week WGLC to confirm the latest rev. Please respond to this thread by Sept 27th. Thanks, Shep (chairs) On Tue, Jul 28, 2020 at 2:35 PM Bidgoli, Hooman (Nokia - CA/Ottawa) < hooman.bidgoli@nokia.com> wrote: > Thanks Stig! > > Inline HB> > > Regards > > Hooman > > -----Original Message----- > From: Stig Venaas <stig@venaas.com> > Sent: Tuesday, July 28, 2020 4:56 PM > To: Mankamana Mishra (mankamis) <mankamis@cisco.com> > Cc: gjshep@gmail.com; Bidgoli, Hooman (Nokia - CA/Ottawa) < > hooman.bidgoli@nokia.com>; BIER WG <bier@ietf.org>; Ijsbrand Wijnands < > ice@cisco.com>; bier-chairs@ietf.org; Jeffrey (Zhaohui) Zhang < > zzhang@juniper.net>; Antoni Przygienda <prz@juniper.net> > Subject: Re: [Bier] WG LC on > https://datatracker.ietf.org/doc/draft-ietf-bier-pim-signaling/ > > Hi > > It looks like most of the issues I found have been resolved now. But most > importantly, the IANA Considerations still say that there are none. This > needs to be fixed! > > HB> Done, Add it for the join attribute TLV that you got away from in the > other draft ;) > > I see a couple of places where it says PIM signaling message or PIM > signaling packet. I think it should say PIM join/prune message, or PIM > join/prune packet., > > HB> > Changed to PIM join/prune in section 3 because this was the PIM domain > join/prune. "it will generate a PIM join/prune packet toward its attached > PIM domain." > Any where else that the pim signaling is left is actually the BIER > signaling the join/prune through the bier network as such I wanted it to be > clear that these are signalling packet and not extending the PIM over the > BIER domain. > > : > > > Regards, > Stig > > On Tue, Sep 24, 2019 at 10:51 AM Stig Venaas <stig@venaas.com> wrote: > > > > Hi > > > > This is good work and I generally support the document. There are > > however some issues that need to be addressed. I also think it would > > be good to get this reviewed in the pim WG, perhaps you can ask for > > reviews on the pim list. > > > > I mostly have editorial comments that are easy to address. But at a > > high level I think some more text about pim is needed. > > > > PIM relies on hello messages to know what capabilities a router has, > > e.g. whether it support Join attributes, whether it support BIDIR etc. > > I think you need to point out what capabilities are assumed to be > > present. Obviously it is assumed that Join attributes are supported. > > It may also be good to point out that there is no J/P suppression as > > the J/P is only sent to the target, and not to other routers. Also > > point out that only J/P messages are used, and that there is no assert > > processing. > > > > > > Below are the editorial comments. Please also check the "nits" > > tool. It complains about missing references, and it cannot find the > > "Authors' Addresses" section. The heading is missing. > > > > Also Section 7 must be updated. There is an IANA action, but it says > > there are none! > > > > The abstract is rather long. Suggest removing some of the text that > > explains the general operation of BIER. > > > > Some of the references might need some work. In section 2 it says "RFC > > 2119 [RFC2119]". Should it be just "[RFC2119]"? Also the reference is > > missing. In 2.1 it says "[I-D. rfc8279]" which also needs to be > > fixed. Most of the other references look fine. > > In 3.1 there seems to be a reference to 8279 without brackets though. > > > > In 2.1, BFR definition. Missing space after ".". > > > > BFIR definition: It says "insert the BM into the packet", but I think > > it might be better to say that it performs BIER encapsulation. The > > term BM is not defined. It says "plain" instead of "plane". > > > > BFER defintion: Do we have to say that BFER is a BFR? In that case, we > > should also say that BFIR is a BFR. It says "plain" instead of "plane". > > > > IBBR and EBBR, might it be good to include "signaling" in the name, > > like Ingress Signaling BIER Router and Egress Signaling BIER Router? I > > want it to be very clear that ingress and egress are not related to data. > > > > In "Figure 1" I think "bfir" and "bfer" should be upper case. > > > > In 3.1: > > "weather" should be "whether". > > "located on" should probably be "located in". > > > > In 3.1 there is this paragraph that I think need some changes. > > > > After discovering the EBBR and its BFR-ID (flooded via IGP BIER > > extension), the IBBR will construct a PIM Join Attribute encoded as > > > > It says that BFR-ID is flooded via IGP BIER extension. That isn't > > necessarily true, do we need to explain how the BFR-ID is discovered? > > > > TLVs into the Source Address field of the PIM Join Message as per > > > > Isn't it just one TLV? I think you can skip saying that it is a TLV in > > the source address field. Just say that it includes a new PIM Join > > Attribute in the Join/Prune message. Also note that we should really > > say Join/Prune, not just Join. > > > > [RFC5384] and include it in PIM signaling message. Two new "BIER > > > > I think it is better to be clear and say PIM Join/Prune message. > > > > IBBR" attributes are define and explained in upcoming section. The > > s/define/defined > > > > PIM Join Attribute is used on EBBR to obtain necessary bier > > s/bier/BIER > > information to build its multicast states. In addition the IBBR will > > change the PIM signaling packet source IP address to its BIER prefix > > address (standard PIM procedure). It will also keep the destination > > address as the well known multicast IP address. It then will > > construct the BIER header. The signaling packet, in this case the PIM > > join/prune packet, is encapsulated in the BIER header and transported > > through BIER domain to EBBR. > > > > The language at the end here makes it sound like the PIM J/P is being > > forwarded and that the J/P is being modified. But J/P messages are > > sent hop-by-hop. Each router originates a new J/P. For instance, a > > router may receive a J/P for multiple sources. These sources may have > > different RPF neighbors on the receiving router and hence be split > > into separate join messages. This could happen on the IBBR as well. > > > > The lasts paragraph in section 3 says: > > The IBBR will track all the PIM interfaces on the attached PIM domain > > which are interested in a certain (S,G). It creates multicast states > > for arriving (S,G)s from PIM domain, with incoming interface as BIER > > "tunnel" interface and outgoing interface as the PIM domain > > interface(s) on which PIM Join(s) were received on. > > > > The IBBR is a PIM router and what you are describing is standard PIM > > behavior, so I think this is a bit redundant. It might be goot to > > stress that OIFs are adding according to standard PIM behavior. The > > only special here is the RPF interface. > > > > Section 3.1.4: > > In heading Pim/PIM > > bier/BIER > > > > It says "PIM Join Attribute [RFC5384] is used." I think it might be > > good to say that "a new PIM Join Attribute is used". And then also > > this sentence "The PIM Join Attribute format is as follow:" should > > perhaps be The new PIM Join Attribute format is defined as follows:". > > > > s/Ipv4/IPv4 > > s/Ipv6/IPv6 > > > > In the format I think it might be good to not just show "BIER info", > > but show the formatting of prefix, SD and BFR-ID explicitly. Also, it > > should state clearly that these are the prefix, SD and BFR-id of the > IBBR. > > > > In 3.1.4.1 why not say PIM Join/Prune packet instead of PIM signaling? > > > > In 3.3.: > > After receiving the BIER packet and determining this packet is a > > signaling packet, EBBR will remove the BIER header from PIM packet. > > The Received PIM join/prune Signaling packet is processed as if it > > were received from neighbors on a virtual interface, (i.e. as if the > > pim adjacency was presents, regardless of the fact there is no > > adjacency) > > Wouldn't the router remove the BIER header simply because the BFR-id > > in the BIER header matches its own BFR-id? There are some grammar > > issues and a missing period in this paragraph. > > > > In this paragraph: > > With same token the EBBR creates a multicast state with incoming > > interface as same interface that PIM join packet was forwarded and > > outgoing interfaces of BIER tunnel to BFER identified with BFIR-id > > and its corresponding Sub-Domain obtained from the BIER header or via > > PIM Join Attributes added to the PIM signaling packet by the IBBR. > > > > I'm not sure what "With same token" means here. Also, it not should > > say that PIM join packet was forwarded. I would say that state is > > created according to the PIM specification, and just describe the BIER > OIF state. > > The specific OIF state may be implementation specific though. Perhaps > > this is sufficiently described in the paragraph that comes right > > after? It is also well described in 4.1. > > > > In section 5: s/LEAFs/leaves? Should it be EBBRs? > > > > In section 6: > > s/vrf/VRF > > "it is determine" should be "it is determined". > > Replace "PIM signaling message" with "PIM Join/Prune message"? > > > > Section 8: > > The 4601 reference should be to RFC 7761. > > > > Appendix A: > > The header seems to not be formatted correctly. > > "This section" should be "This appendix"? > > > > In A.1: "is consist" should be "consists". > > > > In Figure 2: s/bier/BIER > > Also in the text in A.2.2. > > > > IN A.3.1 > > s/Bier/BIER > > s/bier/BIER > > s/tlv/TLV > > > > Stig >
- [Bier] WG LC on https://datatracker.ietf.org/doc/… Antoni Przygienda
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Jeff Tantsura
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Mankamana Mishra (mankamis)
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Dolganow, Andrew (Nokia - SG/Singapore)
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Rabadan, Jorge (Nokia - US/Mountain View)
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Purkayastha, Debashish
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Nabeel Cocker
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Nagendra Kumar Nainar (naikumar)
- Re: [Bier] WG LC onhttps://datatracker.ietf.org/d… zhang.zheng
- [Bier] 答复: WG LC onhttps://datatracker.ietf.org/d… chen.ran
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Stig Venaas
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Bidgoli, Hooman (Nokia - CA/Ottawa)
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Jeffrey (Zhaohui) Zhang
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Stig Venaas
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Mankamana Mishra (mankamis)
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Eric Rosen
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Stig Venaas
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Bidgoli, Hooman (Nokia - CA/Ottawa)
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Bidgoli, Hooman (Nokia - CA/Ottawa)
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Stig Venaas
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Jeffrey (Zhaohui) Zhang
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Bidgoli, Hooman (Nokia - CA/Ottawa)
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Bidgoli, Hooman (Nokia - CA/Ottawa)
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Bidgoli, Hooman (Nokia - CA/Ottawa)
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Bidgoli, Hooman (Nokia - CA/Ottawa)
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Eric Rosen
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Bidgoli, Hooman (Nokia - CA/Ottawa)
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Stig Venaas
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Greg Shepherd
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Rabadan, Jorge (Nokia - US/Mountain View)
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Mankamana Mishra (mankamis)
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Stig Venaas
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Nabeel Cocker
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Jeffrey (Zhaohui) Zhang
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Toerless Eckert
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Stig Venaas
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Toerless Eckert
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Bidgoli, Hooman (Nokia - CA/Ottawa)
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Stig Venaas
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Robert Raszuk
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Jeff Tantsura
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Toerless Eckert
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Stig Venaas
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Mankamana Mishra (mankamis)
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Bidgoli, Hooman (Nokia - CA/Ottawa)
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Toerless Eckert
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Mankamana Mishra (mankamis)
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Stig Venaas
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Bidgoli, Hooman (Nokia - CA/Ottawa)
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Bidgoli, Hooman (Nokia - CA/Ottawa)
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Toerless Eckert
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Stig Venaas
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Bidgoli, Hooman (Nokia - CA/Ottawa)
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Stig Venaas
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Bidgoli, Hooman (Nokia - CA/Ottawa)
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Stig Venaas
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Bidgoli, Hooman (Nokia - CA/Ottawa)
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Stig Venaas
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Bidgoli, Hooman (Nokia - CA/Ottawa)
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Greg Shepherd
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Bidgoli, Hooman (Nokia - CA/Ottawa)
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Greg Shepherd
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Mankamana Mishra (mankamis)
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Nabeel Cocker
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Bidgoli, Hooman (Nokia - CA/Ottawa)