From owner-bgmp@catarina.usc.edu Thu Apr 5 07:14:15 2001 Received: from catarina.usc.edu ([128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA27632 for ; Thu, 5 Apr 2001 07:14:14 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id DAA85887 for bgmp-list; Thu, 5 Apr 2001 03:42:22 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-bgmp@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136] (may be forged)) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id DAA85882 for ; Thu, 5 Apr 2001 03:42:20 -0700 (PDT) Received: from plmta00.chello.pl (plmta00.chello.pl [213.46.248.62]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id DAA03573 for ; Thu, 5 Apr 2001 03:42:18 -0700 (PDT) Message-Id: <200104051042.DAA03573@usc.edu> Received: from hetnet.nl ([213.93.48.181]) by plmta00.chello.pl (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with SMTP id pl for ; Thu, 5 Apr 2001 08:00:35 -0100 From: "Rita de Groot" To: Subject: huidziekte Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Date: Thu, 5 Apr 2001 10:58:06 +0200 Content-Transfer-Encoding: 8bit Sender: owner-bgmp@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 8bit Vijf jaar voordat deze foto's werden genomen werd bij mij diagnose reumatische artritis gesteld en als zodanig ook behandeld. Niets hielp. Toen de ziekte zich zo manifesteerde zoals u hieronder kunt zien.......... http://www.naardedokter.com/testimonials/sys_lup_eryth.htm From owner-bgmp@catarina.usc.edu Mon Apr 9 19:29:04 2001 Received: from catarina.usc.edu ([128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA19124 for ; Mon, 9 Apr 2001 19:29:03 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id PAA12608 for bgmp-list; Mon, 9 Apr 2001 15:51:07 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-bgmp@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136] (may be forged)) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id PAA12586; Mon, 9 Apr 2001 15:50:24 -0700 (PDT) From: James_Huang@Mitel.COM Received: from Mitel.COM (newgate.mitel.com [198.53.180.100]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id PAA12088; Mon, 9 Apr 2001 15:50:22 -0700 (PDT) Received: from kanmta01.software.mitel.com (kanmta01 [134.199.37.58]) by Mitel.COM (V8/MAIL-RELAY-2.1) with SMTP id SAA25307; Mon, 9 Apr 2001 18:46:12 -0400 (EDT) Received: by kanmta01.software.mitel.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 85256A29.007D11CE ; Mon, 9 Apr 2001 18:46:05 -0400 X-Lotus-FromDomain: MITEL To: pim@catarina.usc.edu, bgmp@catarina.usc.edu cc: mjh@aciri.org, dthaler@MICROSOFT.com, estrin@usc.edu, dmm@cisco.com Message-ID: <85256A29.007D104E.00@kanmta01.software.mitel.com> Date: Mon, 9 Apr 2001 15:46:01 -0700 Subject: PIM-SM <--> BGMP interaction Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-bgmp@catarina.usc.edu Precedence: bulk Hi all, I have some questions on the PIM-SM behavior of a RP router in the following scenario: (1) BGMP/MASC is used as the inter-domain multicast routing protocol (2) group g is is rooted at domain G (3) The RP router is in domain D running PIM-SM and is the shared-domain tree ingress border router for group g (4) receivers for (*, g) traffic exists in domain D (5) (s,g) traffic is active and is sourced in a domain S and is delivered to domain D through domain G. +--- G ---+ | | | | S D | | In this situation, (a) Will RP ever have register/regiser-stop interaction for (s,g) traffic? (b) Will RP ever send PIM-SM (s,g) join toward s? If so, how does it get triggered? Is KeepAliveTImer(s,g) running? (c) Is the "Data Packet Forwarding Rules" in the PIM-SM spec still vaild? According to the PIM-SM spec, RPF_interface(RP) at the RP is the virtual interface on which register packets are received. So I assume RPF_interface(RP) != interface connected to domain G. If RPF_interface(s) != (interface connected to domain G) either, then (s,g) traffics will be dropped according to the PIM-SM forwarding rules. Thanks for answering these questions. -- James C. Huang From owner-bgmp@catarina.usc.edu Mon Apr 9 19:59:20 2001 Received: from catarina.usc.edu ([128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA19865 for ; Mon, 9 Apr 2001 19:59:17 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id QAA12901 for bgmp-list; Mon, 9 Apr 2001 16:14:24 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-bgmp@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id QAA12896; Mon, 9 Apr 2001 16:14:22 -0700 (PDT) Received: from df-inet1.exchange.microsoft.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id QAA02739; Mon, 9 Apr 2001 16:14:20 -0700 (PDT) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by df-inet1.exchange.microsoft.com with Microsoft SMTPSVC(5.0.2195.2831); Mon, 9 Apr 2001 16:12:04 -0700 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 09 Apr 2001 16:11:13 -0700 (Pacific Daylight Time) Received: from df-max.platinum.corp.microsoft.com ([172.30.236.100]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2905); Mon, 9 Apr 2001 16:11:13 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4683.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: PIM-SM <--> BGMP interaction Date: Mon, 9 Apr 2001 16:11:10 -0700 Message-ID: <5B90AD65A9E8934987DB0C8C0762657405266FB6@DF-BOWWOW.platinum.corp.microsoft.com> Thread-Topic: PIM-SM <--> BGMP interaction Thread-Index: AcDBR6cDO073pTEYSlW/EdYAkPRIfQAAizxQ From: "Dave Thaler" To: , , Cc: , , X-OriginalArrivalTime: 09 Apr 2001 23:11:13.0216 (UTC) FILETIME=[5F033400:01C0C14A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by catarina.usc.edu id QAB12897 Sender: owner-bgmp@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 8bit James Huang wrotes: > I have some questions on the PIM-SM behavior of a RP > router in the > following scenario: > > (1) BGMP/MASC is used as the inter-domain multicast routing protocol > (2) group g is is rooted at domain G > (3) The RP router is in domain D running PIM-SM and is the > shared-domain tree > ingress border router for group g > (4) receivers for (*, g) traffic exists in domain D > (5) (s,g) traffic is active and is sourced in a domain S and > is delivered to > domain D through domain G. > > +--- G ---+ > | | > | | > S D > | | > > > In this situation, > (a) Will RP ever have register/regiser-stop interaction for > (s,g) traffic? No. > (b) Will RP ever send PIM-SM (s,g) join toward s? If so, how > does it get triggered? Is KeepAliveTImer(s,g) running? No, it's similar to when the source is directly connected to the RP. > (c) Is the "Data Packet Forwarding Rules" in the PIM-SM spec > still vaild? > According to the PIM-SM spec, RPF_interface(RP) at the RP is > the virtual > interface on which register packets are received. So I > assume RPF_interface(RP) > != interface connected to domain G. If RPF_interface(s) != > (interface connected > to domain G) either, then (s,g) traffics will be dropped > according to the PIM-SM > forwarding rules. Per RFC 2715, the iif for (*,G) is the interface towards domain G, and PIM only applies an RPF check if the iif is owned by PIM, which is not the case here. -Dave From owner-bgmp@catarina.usc.edu Wed Apr 11 15:37:38 2001 Received: from catarina.usc.edu ([128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA01724 for ; Wed, 11 Apr 2001 15:37:37 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id LAA30196 for bgmp-list; Wed, 11 Apr 2001 11:51:53 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-bgmp@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136] (may be forged)) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id LAA30176; Wed, 11 Apr 2001 11:51:31 -0700 (PDT) From: James_Huang@Mitel.COM Received: from Mitel.COM (newgate.mitel.com [198.53.180.100]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id LAA00786; Wed, 11 Apr 2001 11:51:31 -0700 (PDT) Received: from kanmta01.software.mitel.com (kanmta01 [134.199.37.58]) by Mitel.COM (V8/MAIL-RELAY-2.1) with SMTP id OAA02655; Wed, 11 Apr 2001 14:47:51 -0400 (EDT) Received: by kanmta01.software.mitel.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 85256A2B.00673EEA ; Wed, 11 Apr 2001 14:47:43 -0400 X-Lotus-FromDomain: MITEL To: "Dave Thaler" cc: mjh@aciri.org, estrin@usc.edu, dmm@cisco.com, pim@catarina.usc.edu, bgmp@catarina.usc.edu Message-ID: <85256A2B.00673D41.00@kanmta01.software.mitel.com> Date: Wed, 11 Apr 2001 11:47:38 -0700 Subject: RE: PIM-SM <--> BGMP interaction Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-bgmp@catarina.usc.edu Precedence: bulk From: James Huang@MITEL on 04/11/2001 11:47 AM PDT >James Huang wrotes: >> I have some questions on the PIM-SM behavior of a RP >> router in the following scenario: >> >> (1) BGMP/MASC is used as the inter-domain multicast routing protocol >> (2) group g is is rooted at domain G >> (3) The RP router is in domain D running PIM-SM and is the >> shared-domain tree ingress border router for group g >> (4) receivers for (*, g) traffic exists in domain D >> (5) (s,g) traffic is active and is sourced in a domain S and >> is delivered to domain D through domain G. >> >> +--- G ---+ >> | | >> | | >> S D >> | | >> >> >> Is the "Data Packet Forwarding Rules" in sec 4.2 of the latest PIM-SM draft >> still vaild? >> According to the PIM-SM draft, RPF_interface(RP) at the RP is >> the virtual interface on which register packets are received. So I >> assume RPF_interface(RP) != interface connected to domain G. >> If RPF_interface(s) != (interface connected to domain G) either, >> then (s,g) traffics will be dropped according to the PIM-SM >> forwarding rules. > >Per RFC 2715, the iif for (*,G) is the interface towards domain G, >and PIM only applies an RPF check if the iif is owned by PIM, >which is not the case here. > >-Dave Sec 4.2 of the latest PIM-SM draft (draft-ietf-pim-sm-v2-new-02.txt) has the following section of code: On receipt on a data from S to G on interface iif: if( DirectlyConnected(S) == TRUE ) { set KeepaliveTimer(S,G) to Keepalive_Period # Note: register state transition may happen as a result # of restarting KeepaliveTimer, and must be dealt with here. } Update_SPTbit(S,G,iif) if( iif == RPF_interface(S) AND UpstreamJPState(S,G) == Joined ) { oiflist = inherited_olist(S,G) if( oiflist != NULL ) { restart KeepaliveTimer(S,G) } } else if( iif == RPF_interface(RP) AND SPTbit(S,G) == FALSE) { oiflist = inherited_olist(S,G,rpt) } else { # Note: RPF check failed if ( SPTbit(S,G) == TRUE AND iif is in inherited_olist(S,G) ) { send Assert(S,G) on iif } else if ( SPTbit(S,G) == FALSE AND iif is in inherited_olist(S,G,rpt) { send Assert(*,G) on iif } } oiflist = oiflist (-) iif forward packet on all interfaces in oiflist This code does not differentiate packets recieived from a iif owned by PIM from packets received from a iif owned by BGMP. So unless this code is changed accordingly, it is likely that packets will be dropped by PIM-SM component of a PMBR if BGMP is used as the inter-domain routing protocol. -- James Huang From owner-bgmp@catarina.usc.edu Wed Apr 11 18:26:05 2001 Received: from catarina.usc.edu ([128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA04325 for ; Wed, 11 Apr 2001 18:26:04 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id OAA31460 for bgmp-list; Wed, 11 Apr 2001 14:46:57 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-bgmp@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136] (may be forged)) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id OAA31455; Wed, 11 Apr 2001 14:46:55 -0700 (PDT) Received: from df-inet1.exchange.microsoft.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id OAA22428; Wed, 11 Apr 2001 14:46:50 -0700 (PDT) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by df-inet1.exchange.microsoft.com with Microsoft SMTPSVC(5.0.2195.2831); Wed, 11 Apr 2001 14:46:19 -0700 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 11 Apr 2001 14:45:28 -0700 (Pacific Daylight Time) Received: from df-max.platinum.corp.microsoft.com ([172.30.236.100]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2905); Wed, 11 Apr 2001 14:45:28 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4683.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: PIM-SM <--> BGMP interaction Date: Wed, 11 Apr 2001 14:45:27 -0700 Message-ID: <5B90AD65A9E8934987DB0C8C0762657405266FDE@DF-BOWWOW.platinum.corp.microsoft.com> Thread-Topic: PIM-SM <--> BGMP interaction Thread-Index: AcDCuPJ5y5UUVgubSNqYiCvo+xuTMwAF1UaA From: "Dave Thaler" To: , "Dave Thaler" Cc: , , , , X-OriginalArrivalTime: 11 Apr 2001 21:45:28.0399 (UTC) FILETIME=[B949EDF0:01C0C2D0] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by catarina.usc.edu id OAB31456 Sender: owner-bgmp@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 8bit > Sec 4.2 of the latest PIM-SM draft > (draft-ietf-pim-sm-v2-new-02.txt) has the > following section of code: [...] > This code does not differentiate packets recieived from a iif > owned by PIM from > packets received from a iif owned by BGMP. So unless this > code is changed > accordingly, it is likely that packets will be dropped by > PIM-SM component of a > PMBR if BGMP is used as the inter-domain routing protocol. The code you quote assumes that all interfaces are owned by PIM-SM. (Hence, it's not just BGMP, it's *any* other protocol using other interfaces, that the quoted code would have a problem with.) The PIM-SM spec only specifies the behavior of a PIM-SM router, not of a PIM-SM border router. Hence, RFC 2715 overrides what's in the PIM-SM spec. -Dave From owner-bgmp@catarina.usc.edu Wed Apr 11 19:21:53 2001 Received: from catarina.usc.edu ([128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA04892 for ; Wed, 11 Apr 2001 19:21:51 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id PAA31943 for bgmp-list; Wed, 11 Apr 2001 15:42:33 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-bgmp@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136] (may be forged)) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id PAA31927; Wed, 11 Apr 2001 15:42:16 -0700 (PDT) From: James_Huang@Mitel.COM Received: from Mitel.COM (newgate.mitel.com [198.53.180.100]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id PAA17731; Wed, 11 Apr 2001 15:42:14 -0700 (PDT) Received: from kanmta01.software.mitel.com (kanmta01 [134.199.37.58]) by Mitel.COM (V8/MAIL-RELAY-2.1) with SMTP id SAA25245; Wed, 11 Apr 2001 18:38:10 -0400 (EDT) Received: by kanmta01.software.mitel.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 85256A2B.007C5627 ; Wed, 11 Apr 2001 18:38:05 -0400 X-Lotus-FromDomain: MITEL To: "Dave Thaler" cc: mjh@aciri.org, estrin@usc.edu, dmm@cisco.com, pim@catarina.usc.edu, bgmp@catarina.usc.edu Message-ID: <85256A2B.007C55BD.00@kanmta01.software.mitel.com> Date: Wed, 11 Apr 2001 15:38:03 -0700 Subject: RE: PIM-SM <--> BGMP interaction Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-bgmp@catarina.usc.edu Precedence: bulk From: James Huang@MITEL on 04/11/2001 03:38 PM PDT Dave: Here is the quote of Rule 2 of RFC 2715 (section 2), Rule 2: The component owning an interface specifies the criteria for which packets received on that interface are to be accepted or dropped (e.g., whether to perform an RPF check, and what scoped boundaries exist on that interface). Once a packet is accepted, however, it is processed according to the forwarding rules of all components. According to this rule, when a multicast packet is received by the BGMP component, the following will happen (1) BGMP component will check if the packet should be accepted or dropped. (2) If the packet is accepted, BGMP component will forward it to all targets (other than the iif) (3) If PIM-SM is one of the target, then PIM-SM will forward it according to PIM-SM's Data packet forwarding rules (which may include some RPF check.) Now, if the PIM-SM data packet forwarding rules for a border router is exactly the same as specified in section 4.2 of draft-ietf-pim-sm-v2-new-02.txt, packets will likely be dropped by the PIM-SM component. Section 4.4 of RFC 2715 does not specify any change for PIM-SM forwarding rules on a border router. -- James Huang "Dave Thaler" on 04/11/2001 02:45:27 PM To: James Huang/USA/Mitel@Mitel, "Dave Thaler" cc: mjh@aciri.org, estrin@usc.edu, dmm@cisco.com, pim@catarina.usc.edu, bgmp@catarina.usc.edu Subject: RE: PIM-SM <--> BGMP interaction > Sec 4.2 of the latest PIM-SM draft > (draft-ietf-pim-sm-v2-new-02.txt) has the > following section of code: [...] > This code does not differentiate packets recieived from a iif > owned by PIM from > packets received from a iif owned by BGMP. So unless this > code is changed > accordingly, it is likely that packets will be dropped by > PIM-SM component of a > PMBR if BGMP is used as the inter-domain routing protocol. The code you quote assumes that all interfaces are owned by PIM-SM. (Hence, it's not just BGMP, it's *any* other protocol using other interfaces, that the quoted code would have a problem with.) The PIM-SM spec only specifies the behavior of a PIM-SM router, not of a PIM-SM border router. Hence, RFC 2715 overrides what's in the PIM-SM spec. -Dave From owner-bgmp@catarina.usc.edu Wed Apr 11 19:34:32 2001 Received: from catarina.usc.edu ([128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA05014 for ; Wed, 11 Apr 2001 19:34:31 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id PAA32173 for bgmp-list; Wed, 11 Apr 2001 15:57:02 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-bgmp@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id PAA32158; Wed, 11 Apr 2001 15:56:16 -0700 (PDT) Received: from aardvark.aciri.org (aardvark.aciri.org [192.150.187.20]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id PAA01423; Wed, 11 Apr 2001 15:56:15 -0700 (PDT) Received: from aardvark.aciri.org (localhost [127.0.0.1]) by aardvark.aciri.org (8.11.1/8.11.1) with ESMTP id f3BMs2137046; Wed, 11 Apr 2001 15:54:02 -0700 (PDT) (envelope-from mjh@aardvark.aciri.org) From: Mark Handley X-Organisation: ACIRI To: James_Huang@Mitel.COM cc: "Dave Thaler" , estrin@usc.edu, dmm@cisco.com, pim@catarina.usc.edu, bgmp@catarina.usc.edu Subject: Re: PIM-SM <--> BGMP interaction In-reply-to: Your message of "Wed, 11 Apr 2001 15:38:03 PDT." <85256A2B.007C55BD.00@kanmta01.software.mitel.com> Date: Wed, 11 Apr 2001 15:54:02 -0700 Message-ID: <37044.987029642@aardvark.aciri.org> Sender: owner-bgmp@catarina.usc.edu Precedence: bulk > According to this rule, when a multicast packet is received by the BGMP >component, the following will happen > (1) BGMP component will check if the packet should be accepted or dropped >. > (2) If the packet is accepted, BGMP component will forward it to all >targets (other than the iif) > (3) If PIM-SM is one of the target, then PIM-SM will forward it according >to PIM-SM's Data packet forwarding rules (which may include some RPF check.) > > Now, if the PIM-SM data packet forwarding rules for a border router is >exactly the same as specified in section 4.2 of draft-ietf-pim-sm-v2-new-02.tx >t, >packets will likely be dropped by the PIM-SM component. Section 4.4 of RFC 27 >15 >does not specify any change for PIM-SM forwarding rules on a border router. Currently this seems to have fallen down the cracks between specs. I think a PMBR needs to function like a DR for all packets arriving from inter-domain routing protocols, and treat them as if they arrived from a directly connected source. We'll look into what's involved in adding this to the PIM-SM spec. Cheers, Mark From owner-bgmp@catarina.usc.edu Wed Apr 11 20:10:57 2001 Received: from catarina.usc.edu ([128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA05363 for ; Wed, 11 Apr 2001 20:10:55 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id QAA32636 for bgmp-list; Wed, 11 Apr 2001 16:35:05 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-bgmp@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id QAA32631; Wed, 11 Apr 2001 16:35:04 -0700 (PDT) Received: from df-inet1.exchange.microsoft.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id QAA05970; Wed, 11 Apr 2001 16:35:03 -0700 (PDT) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by df-inet1.exchange.microsoft.com with Microsoft SMTPSVC(5.0.2195.2831); Wed, 11 Apr 2001 16:34:32 -0700 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 11 Apr 2001 16:33:41 -0700 (Pacific Daylight Time) Received: from df-max.platinum.corp.microsoft.com ([172.30.236.100]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2905); Wed, 11 Apr 2001 16:33:41 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4683.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: PIM-SM <--> BGMP interaction Date: Wed, 11 Apr 2001 16:33:40 -0700 Message-ID: <5B90AD65A9E8934987DB0C8C0762657405266FE5@DF-BOWWOW.platinum.corp.microsoft.com> Thread-Topic: PIM-SM <--> BGMP interaction Thread-Index: AcDC3R9KxiiG2KVyRVi0PGSOaW4YZQAAnDmA From: "Dave Thaler" To: , "Dave Thaler" Cc: , , , , X-OriginalArrivalTime: 11 Apr 2001 23:33:41.0638 (UTC) FILETIME=[D78F9260:01C0C2DF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by catarina.usc.edu id QAB32632 Sender: owner-bgmp@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 8bit James Huang writes: > Here is the quote of Rule 2 of RFC 2715 (section 2), > > Rule 2: The component owning an interface specifies the > criteria for > which packets received on that interface are to be accepted > or dropped (e.g., whether to perform an RPF check, and what > scoped boundaries exist on that interface). Once > a packet is > accepted, however, it is processed according to the > forwarding rules of all components. > > According to this rule, when a multicast packet is > received by the BGMP > component, the following will happen > (1) BGMP component will check if the packet should be > accepted or dropped. > (2) If the packet is accepted, BGMP component will > forward it to all > targets (other than the iif) > (3) If PIM-SM is one of the target, then PIM-SM will > forward it according > to PIM-SM's Data packet forwarding rules (which may include > some RPF check.) No, it definitely shouldn't include some RPF check. The RPF check is applied when (and only when) determining whether to accept a packet. Once the determination to accept has been made, the packet will go out whatever interfaces are in the oiflist (and PIM controls whether its interfaces appear in the oiflist). > Now, if the PIM-SM data packet forwarding rules for a > border router is > exactly the same as specified in section 4.2 of > draft-ietf-pim-sm-v2-new-02.txt, > packets will likely be dropped by the PIM-SM component. > Section 4.4 of RFC 2715 > does not specify any change for PIM-SM forwarding rules on a > border router. That would be a broken implementation. -Dave From owner-bgmp@catarina.usc.edu Thu Apr 12 11:02:36 2001 Received: from catarina.usc.edu ([128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02229 for ; Thu, 12 Apr 2001 11:02:36 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id HAA36777 for bgmp-list; Thu, 12 Apr 2001 07:24:34 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-bgmp@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id HAA36772 for ; Thu, 12 Apr 2001 07:24:32 -0700 (PDT) Received: from sky.irisa.fr (sky.irisa.fr [131.254.60.147]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id HAA25653 for ; Thu, 12 Apr 2001 07:24:30 -0700 (PDT) Received: from irisa.fr (rocha.irisa.fr [131.254.13.52]) by sky.irisa.fr (8.9.3/8.9.3) with ESMTP id QAA19463 for ; Thu, 12 Apr 2001 16:20:43 +0200 (MET DST) Message-ID: <3AD5B9CA.40F56ECB@irisa.fr> Date: Thu, 12 Apr 2001 16:20:58 +0200 From: Ali Boudani Organization: INRIA - RENNES X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en, fr MIME-Version: 1.0 To: bgmp@catarina.usc.edu Subject: MBGP and BGMP Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-bgmp@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hello, Is there any relation between MBGP and BGMP. in the draft you mentionned some relations between MBGP and BGMP but it is not so clear. Thanx Ali From owner-bgmp@catarina.usc.edu Thu Apr 12 22:41:08 2001 Received: from catarina.usc.edu ([128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA17168 for ; Thu, 12 Apr 2001 22:41:07 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id TAA40883 for bgmp-list; Thu, 12 Apr 2001 19:03:28 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-bgmp@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136] (may be forged)) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id TAA40878 for ; Thu, 12 Apr 2001 19:03:26 -0700 (PDT) Received: from df-inet1.exchange.microsoft.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id TAB27849 for ; Thu, 12 Apr 2001 19:03:26 -0700 (PDT) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by df-inet1.exchange.microsoft.com with Microsoft SMTPSVC(5.0.2195.2831); Thu, 12 Apr 2001 19:02:56 -0700 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 12 Apr 2001 19:02:05 -0700 (Pacific Daylight Time) Received: from DINO.platinum.corp.microsoft.com ([172.30.236.101]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2905); Thu, 12 Apr 2001 19:02:05 -0700 content-class: urn:content-classes:message Subject: RE: Accepting packets on a multi-access interface owned by BGMP Date: Thu, 12 Apr 2001 19:02:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <5B90AD65A9E8934987DB0C8C0762657405267003@DF-BOWWOW.platinum.corp.microsoft.com> X-MimeOLE: Produced By Microsoft Exchange V6.0.4683.0 Thread-Topic: Accepting packets on a multi-access interface owned by BGMP Thread-Index: AcDDvOeUx82TO/sRSRe7wwck/OPiIwAAKKgw From: "Dave Thaler" To: Cc: , , X-OriginalArrivalTime: 13 Apr 2001 02:02:05.0439 (UTC) FILETIME=[BD0D88F0:01C0C3BD] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by catarina.usc.edu id TAA40879 Sender: owner-bgmp@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 8bit I think you're right in that the text needs to be changed to cover the downstream case. Thanks, -Dave > -----Original Message----- > From: James_Huang@Mitel.COM [mailto:James_Huang@Mitel.COM] > Sent: Thursday, April 12, 2001 6:37 PM > To: Dave Thaler; estrin@usc.edu; dmm@cisco.com; bgmp@catarina.usc.edu > Subject: Accepting packets on a multi-access interface owned by BGMP > > > Hi all, > > Section 5.2 of the latest BGMP spec > (draft-ietf-bgmp--spec-02.txt) > specifies the following rules on accepting packets arrived on > an interface owned > by BGMP: > > (1) If the packet was received over a point-to-point > interface owned by BGMP, > the packet is accepted. > > (2) If the packet arrived on a multiaccess network interface > owned by BGMP, the > packet is accepted if it is receiving data on a > source-specific branch, if it is > the designated forwarder for the longest matching route for > S, or for the > longest matching route for the nominal root of G. > > The second rule is for multiaccess network. But it seems to > me that this rule > will only work for packets being forwarded upstream toward > the root of the tree. > For packets being forwarded down the tree, the downstream > border router will not > be the designated forwarder. So packets travelling downstream > will not be > accepted. Am I missing something here?? > > > Thanks, > James Huang > > > > > From owner-bgmp@catarina.usc.edu Thu Apr 12 23:07:46 2001 Received: from catarina.usc.edu ([128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA17364 for ; Thu, 12 Apr 2001 23:07:45 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id SAA40731 for bgmp-list; Thu, 12 Apr 2001 18:41:05 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-bgmp@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id SAA40726 for ; Thu, 12 Apr 2001 18:41:04 -0700 (PDT) From: James_Huang@Mitel.COM Received: from Mitel.COM (newgate.mitel.com [198.53.180.100]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id SAA13769 for ; Thu, 12 Apr 2001 18:41:03 -0700 (PDT) Received: from kanmta01.software.mitel.com (kanmta01 [134.199.37.58]) by Mitel.COM (V8/MAIL-RELAY-2.1) with SMTP id VAA14681; Thu, 12 Apr 2001 21:37:13 -0400 (EDT) Received: by kanmta01.software.mitel.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 85256A2D.0008E3BA ; Thu, 12 Apr 2001 21:37:05 -0400 X-Lotus-FromDomain: MITEL To: "Dave Thaler" , estrin@usc.edu, dmm@cisco.com, bgmp@catarina.usc.edu Message-ID: <85256A2D.0008E263.00@kanmta01.software.mitel.com> Date: Thu, 12 Apr 2001 18:37:02 -0700 Subject: Accepting packets on a multi-access interface owned by BGMP Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-bgmp@catarina.usc.edu Precedence: bulk Hi all, Section 5.2 of the latest BGMP spec (draft-ietf-bgmp--spec-02.txt) specifies the following rules on accepting packets arrived on an interface owned by BGMP: (1) If the packet was received over a point-to-point interface owned by BGMP, the packet is accepted. (2) If the packet arrived on a multiaccess network interface owned by BGMP, the packet is accepted if it is receiving data on a source-specific branch, if it is the designated forwarder for the longest matching route for S, or for the longest matching route for the nominal root of G. The second rule is for multiaccess network. But it seems to me that this rule will only work for packets being forwarded upstream toward the root of the tree. For packets being forwarded down the tree, the downstream border router will not be the designated forwarder. So packets travelling downstream will not be accepted. Am I missing something here?? Thanks, James Huang From owner-bgmp@catarina.usc.edu Mon Apr 16 20:46:14 2001 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA15737 for ; Mon, 16 Apr 2001 20:46:12 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id QAA63555 for bgmp-list; Mon, 16 Apr 2001 16:37:21 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-bgmp@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136] (may be forged)) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id QAA63550 for ; Mon, 16 Apr 2001 16:37:20 -0700 (PDT) From: James_Huang@Mitel.COM Received: from Mitel.COM (newgate.mitel.com [198.53.180.100]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id QAA09814 for ; Mon, 16 Apr 2001 16:37:18 -0700 (PDT) Received: from kanmta01.software.mitel.com (kanmta01 [134.199.37.58]) by Mitel.COM (V8/MAIL-RELAY-2.1) with SMTP id TAA09311; Mon, 16 Apr 2001 19:30:41 -0400 (EDT) Received: by kanmta01.software.mitel.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 85256A30.0081263C ; Mon, 16 Apr 2001 19:30:39 -0400 X-Lotus-FromDomain: MITEL To: "Dave Thaler" cc: estrin@usc.edu, dmm@cisco.com, bgmp@catarina.usc.edu Message-ID: <85256A30.008125FC.00@kanmta01.software.mitel.com> Date: Mon, 16 Apr 2001 16:30:37 -0700 Subject: PR-bit in the BGMP protocol Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-bgmp@catarina.usc.edu Precedence: bulk From: James Huang@MITEL on 04/16/2001 04:30 PM PDT Dave: Could you explain the purpose of the PR-bit (poison-reverse) in the BGMP protocol? When is it set or reset? How does it affect the protocol? I will appreciate it if you could give some examples. Thanks, -- James Huang "Dave Thaler" on 04/12/2001 07:02:04 PM To: James Huang/USA/Mitel@Mitel cc: estrin@usc.edu, dmm@cisco.com, bgmp@catarina.usc.edu Subject: RE: Accepting packets on a multi-access interface owned by BGMP I think you're right in that the text needs to be changed to cover the downstream case. Thanks, -Dave > -----Original Message----- > From: James_Huang@Mitel.COM [mailto:James_Huang@Mitel.COM] > Sent: Thursday, April 12, 2001 6:37 PM > To: Dave Thaler; estrin@usc.edu; dmm@cisco.com; bgmp@catarina.usc.edu > Subject: Accepting packets on a multi-access interface owned by BGMP > > > Hi all, > > Section 5.2 of the latest BGMP spec > (draft-ietf-bgmp--spec-02.txt) > specifies the following rules on accepting packets arrived on > an interface owned > by BGMP: > > (1) If the packet was received over a point-to-point > interface owned by BGMP, > the packet is accepted. > > (2) If the packet arrived on a multiaccess network interface > owned by BGMP, the > packet is accepted if it is receiving data on a > source-specific branch, if it is > the designated forwarder for the longest matching route for > S, or for the > longest matching route for the nominal root of G. > > The second rule is for multiaccess network. But it seems to > me that this rule > will only work for packets being forwarded upstream toward > the root of the tree. > For packets being forwarded down the tree, the downstream > border router will not > be the designated forwarder. So packets travelling downstream > will not be > accepted. Am I missing something here?? > > > Thanks, > James Huang > > > > > From owner-bgmp@catarina.usc.edu Tue Apr 17 15:17:29 2001 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13934 for ; Tue, 17 Apr 2001 15:17:28 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id LAA68705 for bgmp-list; Tue, 17 Apr 2001 11:42:36 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-bgmp@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136] (may be forged)) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id LAA68700 for ; Tue, 17 Apr 2001 11:42:35 -0700 (PDT) Received: from df-inet1.exchange.microsoft.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id LAA18733 for ; Tue, 17 Apr 2001 11:42:32 -0700 (PDT) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by df-inet1.exchange.microsoft.com with Microsoft SMTPSVC(5.0.2195.2831); Tue, 17 Apr 2001 11:42:01 -0700 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 17 Apr 2001 11:41:11 -0700 (Pacific Daylight Time) Received: from DF-MAX.platinum.corp.microsoft.com ([172.30.236.100]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2905); Tue, 17 Apr 2001 11:41:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4688.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: PR-bit in the BGMP protocol Date: Tue, 17 Apr 2001 11:40:14 -0700 Message-ID: <5B90AD65A9E8934987DB0C8C076265740878F564@DF-BOWWOW.platinum.corp.microsoft.com> Thread-Topic: PR-bit in the BGMP protocol Thread-Index: AcDGzW0oyWIN7eKTT8ytyN96QKkNgwAkuanA From: "Dave Thaler" To: , "Dave Thaler" Cc: , , X-OriginalArrivalTime: 17 Apr 2001 18:41:10.0737 (UTC) FILETIME=[F8E31C10:01C0C76D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by catarina.usc.edu id LAA68701 Sender: owner-bgmp@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 8bit I have a set of powerpoint slides somewhere that give examples (starting from an example topology Isidor raised), and I haven't tracked down where the slides are. The PR-bit is discussed in the BGMP spec, which does describe exactly when it's set or reset. Its basic purpose is to indicate to BGMP nodes whether they need to forward packets up towards the root domain. For example, in a case where an (S,G) branch exists, a transit domain may get packets along the (S,G) branch, and needs to know whether to (also) forward them up towards the root domain. If the domain in question is on the path between S and the root domain, then the answer is yes (and the PR bit will be set on the S,G state). If the domain in question is not on the path between S and the root domain, then the answer is no (and the PR bit will be clear on the S,G state). Hope this helps. -Dave > -----Original Message----- > From: James_Huang@Mitel.COM [mailto:James_Huang@Mitel.COM] > Sent: Monday, April 16, 2001 4:31 PM > To: Dave Thaler > Cc: estrin@usc.edu; dmm@cisco.com; bgmp@catarina.usc.edu > Subject: PR-bit in the BGMP protocol > > > > > From: James Huang@MITEL on 04/16/2001 04:30 PM PDT > Dave: > > Could you explain the purpose of the PR-bit > (poison-reverse) in the BGMP > protocol? When is it set or reset? How does it affect the > protocol? I will > appreciate it if you could give some examples. > > Thanks, > -- James Huang > > > > > > "Dave Thaler" on 04/12/2001 > 07:02:04 PM > > To: James Huang/USA/Mitel@Mitel > cc: estrin@usc.edu, dmm@cisco.com, bgmp@catarina.usc.edu > > Subject: RE: Accepting packets on a multi-access interface > owned by BGMP > > > > I think you're right in that the text needs to be changed to > cover the downstream case. > > Thanks, > -Dave > > > -----Original Message----- > > From: James_Huang@Mitel.COM [mailto:James_Huang@Mitel.COM] > > Sent: Thursday, April 12, 2001 6:37 PM > > To: Dave Thaler; estrin@usc.edu; dmm@cisco.com; > bgmp@catarina.usc.edu > > Subject: Accepting packets on a multi-access interface owned by BGMP > > > > > > Hi all, > > > > Section 5.2 of the latest BGMP spec > > (draft-ietf-bgmp--spec-02.txt) > > specifies the following rules on accepting packets arrived on > > an interface owned > > by BGMP: > > > > (1) If the packet was received over a point-to-point > > interface owned by BGMP, > > the packet is accepted. > > > > (2) If the packet arrived on a multiaccess network interface > > owned by BGMP, the > > packet is accepted if it is receiving data on a > > source-specific branch, if it is > > the designated forwarder for the longest matching route for > > S, or for the > > longest matching route for the nominal root of G. > > > > The second rule is for multiaccess network. But it seems to > > me that this rule > > will only work for packets being forwarded upstream toward > > the root of the tree. > > For packets being forwarded down the tree, the downstream > > border router will not > > be the designated forwarder. So packets travelling downstream > > will not be > > accepted. Am I missing something here?? > > > > > > Thanks, > > James Huang > > > > > > > > > > > > > > > From owner-bgmp@catarina.usc.edu Tue Apr 17 17:48:53 2001 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17022 for ; Tue, 17 Apr 2001 17:48:51 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id OAA70683 for bgmp-list; Tue, 17 Apr 2001 14:12:42 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-bgmp@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id OAA70678 for ; Tue, 17 Apr 2001 14:12:41 -0700 (PDT) From: James_Huang@Mitel.COM Received: from Mitel.COM (newgate.mitel.com [198.53.180.100]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id OAA01152 for ; Tue, 17 Apr 2001 14:12:36 -0700 (PDT) Received: from kanmta01.software.mitel.com (kanmta01 [134.199.37.58]) by Mitel.COM (V8/MAIL-RELAY-2.1) with SMTP id RAA11978; Tue, 17 Apr 2001 17:08:51 -0400 (EDT) Received: by kanmta01.software.mitel.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 85256A31.00742610 ; Tue, 17 Apr 2001 17:08:39 -0400 X-Lotus-FromDomain: MITEL To: "Dave Thaler" cc: estrin@usc.edu, dmm@cisco.com, bgmp@catarina.usc.edu Message-ID: <85256A31.007424DF.00@kanmta01.software.mitel.com> Date: Tue, 17 Apr 2001 14:08:35 -0700 Subject: RE: PR-bit in the BGMP protocol Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-bgmp@catarina.usc.edu Precedence: bulk From: James Huang@MITEL on 04/17/2001 02:08 PM PDT Dave: Thanks for your reply. From your email, it seems to imply that PR-bit in a (S,G) state will affect how data packet is forwarded. But I can not find any rules regarding PR bit in section 5.2 (Multicast Data Packet Processing). Do I miss understand something? Also if you are able to track down the powerpoint slides, could you post it in the bgmp mailing distribution? Thanks, -- James Huang "Dave Thaler" on 04/17/2001 11:40:14 AM To: James Huang/USA/Mitel@Mitel, "Dave Thaler" cc: estrin@usc.edu, dmm@cisco.com, bgmp@catarina.usc.edu Subject: RE: PR-bit in the BGMP protocol I have a set of powerpoint slides somewhere that give examples (starting from an example topology Isidor raised), and I haven't tracked down where the slides are. The PR-bit is discussed in the BGMP spec, which does describe exactly when it's set or reset. Its basic purpose is to indicate to BGMP nodes whether they need to forward packets up towards the root domain. For example, in a case where an (S,G) branch exists, a transit domain may get packets along the (S,G) branch, and needs to know whether to (also) forward them up towards the root domain. If the domain in question is on the path between S and the root domain, then the answer is yes (and the PR bit will be set on the S,G state). If the domain in question is not on the path between S and the root domain, then the answer is no (and the PR bit will be clear on the S,G state). Hope this helps. -Dave > -----Original Message----- > From: James_Huang@Mitel.COM [mailto:James_Huang@Mitel.COM] > Sent: Monday, April 16, 2001 4:31 PM > To: Dave Thaler > Cc: estrin@usc.edu; dmm@cisco.com; bgmp@catarina.usc.edu > Subject: PR-bit in the BGMP protocol > > > > > From: James Huang@MITEL on 04/16/2001 04:30 PM PDT > Dave: > > Could you explain the purpose of the PR-bit > (poison-reverse) in the BGMP > protocol? When is it set or reset? How does it affect the > protocol? I will > appreciate it if you could give some examples. > > Thanks, > -- James Huang > > > > > > "Dave Thaler" on 04/12/2001 > 07:02:04 PM > > To: James Huang/USA/Mitel@Mitel > cc: estrin@usc.edu, dmm@cisco.com, bgmp@catarina.usc.edu > > Subject: RE: Accepting packets on a multi-access interface > owned by BGMP > > > > I think you're right in that the text needs to be changed to > cover the downstream case. > > Thanks, > -Dave > > > -----Original Message----- > > From: James_Huang@Mitel.COM [mailto:James_Huang@Mitel.COM] > > Sent: Thursday, April 12, 2001 6:37 PM > > To: Dave Thaler; estrin@usc.edu; dmm@cisco.com; > bgmp@catarina.usc.edu > > Subject: Accepting packets on a multi-access interface owned by BGMP > > > > > > Hi all, > > > > Section 5.2 of the latest BGMP spec > > (draft-ietf-bgmp--spec-02.txt) > > specifies the following rules on accepting packets arrived on > > an interface owned > > by BGMP: > > > > (1) If the packet was received over a point-to-point > > interface owned by BGMP, > > the packet is accepted. > > > > (2) If the packet arrived on a multiaccess network interface > > owned by BGMP, the > > packet is accepted if it is receiving data on a > > source-specific branch, if it is > > the designated forwarder for the longest matching route for > > S, or for the > > longest matching route for the nominal root of G. > > > > The second rule is for multiaccess network. But it seems to > > me that this rule > > will only work for packets being forwarded upstream toward > > the root of the tree. > > For packets being forwarded down the tree, the downstream > > border router will not > > be the designated forwarder. So packets travelling downstream > > will not be > > accepted. Am I missing something here?? > > > > > > Thanks, > > James Huang > > > > > > > > > > > > > > > From owner-bgmp@catarina.usc.edu Tue Apr 17 22:44:42 2001 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA21980 for ; Tue, 17 Apr 2001 22:44:42 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id TAA73128 for bgmp-list; Tue, 17 Apr 2001 19:07:29 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-bgmp@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id TAA73123 for ; Tue, 17 Apr 2001 19:07:28 -0700 (PDT) Received: from df-inet1.exchange.microsoft.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id TAA07476 for ; Tue, 17 Apr 2001 19:07:28 -0700 (PDT) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by df-inet1.exchange.microsoft.com with Microsoft SMTPSVC(5.0.2195.2831); Tue, 17 Apr 2001 19:06:57 -0700 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 17 Apr 2001 19:06:06 -0700 (Pacific Daylight Time) Received: from DF-BOWWOW.platinum.corp.microsoft.com ([172.30.236.100]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2905); Tue, 17 Apr 2001 19:06:05 -0700 content-class: urn:content-classes:message Subject: RE: PR-bit in the BGMP protocol MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 17 Apr 2001 19:06:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4688.0 Message-ID: <5B90AD65A9E8934987DB0C8C076265740526705C@DF-BOWWOW.platinum.corp.microsoft.com> Thread-Topic: PR-bit in the BGMP protocol Thread-Index: AcDHkFpze0LQtxOoR5yPIw3eNtRZHwAG5ETg From: "Dave Thaler" To: Cc: , , X-OriginalArrivalTime: 18 Apr 2001 02:06:05.0158 (UTC) FILETIME=[20008060:01C0C7AC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by catarina.usc.edu id TAA73124 Sender: owner-bgmp@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 8bit There's nothing in the data packet processing since the other places in the spec talk about using the PR bit to add/remove the target towards the root domain in the target list. For example: "After the border router sends a BGMP (S,G) Join, if its (S,G) state has the PR-bit clear, a (S,G) Poison-Reverse message (with the PR-bit clear) is sent to the ingress router for G. The ingress router then creates (S,G) if it does not already exist, and removes the next hop towards the nominal root of G from the target list." Since the forwarding is done using the target list, the forwarding rules implicitly take the PR-bit into account. -Dave > -----Original Message----- > From: James_Huang@Mitel.COM [mailto:James_Huang@Mitel.COM] > Sent: Tuesday, April 17, 2001 2:09 PM > To: Dave Thaler > Cc: estrin@usc.edu; dmm@cisco.com; bgmp@catarina.usc.edu > Subject: RE: PR-bit in the BGMP protocol > > > > > From: James Huang@MITEL on 04/17/2001 02:08 PM PDT > Dave: > > Thanks for your reply. From your email, it seems to > imply that PR-bit in a > (S,G) state will affect how data packet is forwarded. But I > can not find any > rules regarding PR bit in section 5.2 (Multicast Data Packet > Processing). Do I > miss understand something? > > Also if you are able to track down the powerpoint > slides, could you post it > in the bgmp mailing distribution? > > Thanks, > -- James Huang > > > > > > "Dave Thaler" on 04/17/2001 > 11:40:14 AM > > To: James Huang/USA/Mitel@Mitel, "Dave Thaler" > > cc: estrin@usc.edu, dmm@cisco.com, bgmp@catarina.usc.edu > > Subject: RE: PR-bit in the BGMP protocol > > > > I have a set of powerpoint slides somewhere that give > examples (starting from an example topology Isidor raised), > and I haven't tracked down where the slides are. > > The PR-bit is discussed in the BGMP spec, which does > describe exactly when it's set or reset. > > Its basic purpose is to indicate to BGMP nodes whether > they need to forward packets up towards the root domain. > For example, in a case where an (S,G) branch exists, > a transit domain may get packets along the (S,G) branch, > and needs to know whether to (also) forward them up > towards the root domain. If the domain in question > is on the path between S and the root domain, then > the answer is yes (and the PR bit will be set on the > S,G state). If the domain in question is not on the > path between S and the root domain, then the answer > is no (and the PR bit will be clear on the S,G state). > > Hope this helps. > > -Dave > > > -----Original Message----- > > From: James_Huang@Mitel.COM [mailto:James_Huang@Mitel.COM] > > Sent: Monday, April 16, 2001 4:31 PM > > To: Dave Thaler > > Cc: estrin@usc.edu; dmm@cisco.com; bgmp@catarina.usc.edu > > Subject: PR-bit in the BGMP protocol > > > > > > > > > > From: James Huang@MITEL on 04/16/2001 04:30 PM PDT > > Dave: > > > > Could you explain the purpose of the PR-bit > > (poison-reverse) in the BGMP > > protocol? When is it set or reset? How does it affect the > > protocol? I will > > appreciate it if you could give some examples. > > > > Thanks, > > -- James Huang > > > > > > > > > > > > "Dave Thaler" on 04/12/2001 > > 07:02:04 PM > > > > To: James Huang/USA/Mitel@Mitel > > cc: estrin@usc.edu, dmm@cisco.com, bgmp@catarina.usc.edu > > > > Subject: RE: Accepting packets on a multi-access interface > > owned by BGMP > > > > > > > > I think you're right in that the text needs to be changed to > > cover the downstream case. > > > > Thanks, > > -Dave > > > > > -----Original Message----- > > > From: James_Huang@Mitel.COM [mailto:James_Huang@Mitel.COM] > > > Sent: Thursday, April 12, 2001 6:37 PM > > > To: Dave Thaler; estrin@usc.edu; dmm@cisco.com; > > bgmp@catarina.usc.edu > > > Subject: Accepting packets on a multi-access interface > owned by BGMP > > > > > > > > > Hi all, > > > > > > Section 5.2 of the latest BGMP spec > > > (draft-ietf-bgmp--spec-02.txt) > > > specifies the following rules on accepting packets arrived on > > > an interface owned > > > by BGMP: > > > > > > (1) If the packet was received over a point-to-point > > > interface owned by BGMP, > > > the packet is accepted. > > > > > > (2) If the packet arrived on a multiaccess network interface > > > owned by BGMP, the > > > packet is accepted if it is receiving data on a > > > source-specific branch, if it is > > > the designated forwarder for the longest matching route for > > > S, or for the > > > longest matching route for the nominal root of G. > > > > > > The second rule is for multiaccess network. But it seems to > > > me that this rule > > > will only work for packets being forwarded upstream toward > > > the root of the tree. > > > For packets being forwarded down the tree, the downstream > > > border router will not > > > be the designated forwarder. So packets travelling downstream > > > will not be > > > accepted. Am I missing something here?? > > > > > > > > > Thanks, > > > James Huang > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From owner-bgmp@catarina.usc.edu Wed Apr 18 15:00:33 2001 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16028 for ; Wed, 18 Apr 2001 15:00:32 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id LAA77148 for bgmp-list; Wed, 18 Apr 2001 11:20:27 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-bgmp@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id LAA77143 for ; Wed, 18 Apr 2001 11:20:26 -0700 (PDT) From: James_Huang@Mitel.COM Received: from Mitel.COM (newgate.mitel.com [198.53.180.100]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id LAA04936 for ; Wed, 18 Apr 2001 11:20:26 -0700 (PDT) Received: from kanmta01.software.mitel.com (kanmta01 [134.199.37.58]) by Mitel.COM (V8/MAIL-RELAY-2.1) with SMTP id OAA15271; Wed, 18 Apr 2001 14:16:55 -0400 (EDT) Received: by kanmta01.software.mitel.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 85256A32.00646A3B ; Wed, 18 Apr 2001 14:16:47 -0400 X-Lotus-FromDomain: MITEL To: "Dave Thaler" cc: estrin@usc.edu, dmm@cisco.com, bgmp@catarina.usc.edu Message-ID: <85256A32.00646912.00@kanmta01.software.mitel.com> Date: Wed, 18 Apr 2001 11:16:41 -0700 Subject: RE: PR-bit in the BGMP protocol Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-bgmp@catarina.usc.edu Precedence: bulk From: James Huang@MITEL on 04/18/2001 11:16 AM PDT Dave: The two rules regarding add/remove the target towards the root domain to/from the target list of a BGMP (S,G) state are specified in the section for PIM-SM (sec 5.4.2). What is the reason they do not also apply to the other intra-domain protocols?? Also I have the following question with regarding to BGMP <-> PIM-SM interaction. Given a domain X which is on the best path from S to G and a border router R which is the best exit for G in domain X. How does the PIM-SM component of router R knows that it should forward (S,G) traffic it receives internally from the domain to its BGMP component? This is required so that the BGMP component will forward the (S,G) traffic upstream towards G. Thanks, - James C. Huang "Dave Thaler" on 04/17/2001 07:06:02 PM To: James Huang/USA/Mitel@Mitel cc: estrin@usc.edu, dmm@cisco.com, bgmp@catarina.usc.edu Subject: RE: PR-bit in the BGMP protocol There's nothing in the data packet processing since the other places in the spec talk about using the PR bit to add/remove the target towards the root domain in the target list. For example: "After the border router sends a BGMP (S,G) Join, if its (S,G) state has the PR-bit clear, a (S,G) Poison-Reverse message (with the PR-bit clear) is sent to the ingress router for G. The ingress router then creates (S,G) if it does not already exist, and removes the next hop towards the nominal root of G from the target list." Since the forwarding is done using the target list, the forwarding rules implicitly take the PR-bit into account. -Dave > -----Original Message----- > From: James_Huang@Mitel.COM [mailto:James_Huang@Mitel.COM] > Sent: Tuesday, April 17, 2001 2:09 PM > To: Dave Thaler > Cc: estrin@usc.edu; dmm@cisco.com; bgmp@catarina.usc.edu > Subject: RE: PR-bit in the BGMP protocol > > > > > From: James Huang@MITEL on 04/17/2001 02:08 PM PDT > Dave: > > Thanks for your reply. From your email, it seems to > imply that PR-bit in a > (S,G) state will affect how data packet is forwarded. But I > can not find any > rules regarding PR bit in section 5.2 (Multicast Data Packet > Processing). Do I > miss understand something? > > Also if you are able to track down the powerpoint > slides, could you post it > in the bgmp mailing distribution? > > Thanks, > -- James Huang > > > > > > "Dave Thaler" on 04/17/2001 > 11:40:14 AM > > To: James Huang/USA/Mitel@Mitel, "Dave Thaler" > > cc: estrin@usc.edu, dmm@cisco.com, bgmp@catarina.usc.edu > > Subject: RE: PR-bit in the BGMP protocol > > > > I have a set of powerpoint slides somewhere that give > examples (starting from an example topology Isidor raised), > and I haven't tracked down where the slides are. > > The PR-bit is discussed in the BGMP spec, which does > describe exactly when it's set or reset. > > Its basic purpose is to indicate to BGMP nodes whether > they need to forward packets up towards the root domain. > For example, in a case where an (S,G) branch exists, > a transit domain may get packets along the (S,G) branch, > and needs to know whether to (also) forward them up > towards the root domain. If the domain in question > is on the path between S and the root domain, then > the answer is yes (and the PR bit will be set on the > S,G state). If the domain in question is not on the > path between S and the root domain, then the answer > is no (and the PR bit will be clear on the S,G state). > > Hope this helps. > > -Dave > > > -----Original Message----- > > From: James_Huang@Mitel.COM [mailto:James_Huang@Mitel.COM] > > Sent: Monday, April 16, 2001 4:31 PM > > To: Dave Thaler > > Cc: estrin@usc.edu; dmm@cisco.com; bgmp@catarina.usc.edu > > Subject: PR-bit in the BGMP protocol > > > > > > > > > > From: James Huang@MITEL on 04/16/2001 04:30 PM PDT > > Dave: > > > > Could you explain the purpose of the PR-bit > > (poison-reverse) in the BGMP > > protocol? When is it set or reset? How does it affect the > > protocol? I will > > appreciate it if you could give some examples. > > > > Thanks, > > -- James Huang > > > > > > > > > > > > "Dave Thaler" on 04/12/2001 > > 07:02:04 PM > > > > To: James Huang/USA/Mitel@Mitel > > cc: estrin@usc.edu, dmm@cisco.com, bgmp@catarina.usc.edu > > > > Subject: RE: Accepting packets on a multi-access interface > > owned by BGMP > > > > > > > > I think you're right in that the text needs to be changed to > > cover the downstream case. > > > > Thanks, > > -Dave > > > > > -----Original Message----- > > > From: James_Huang@Mitel.COM [mailto:James_Huang@Mitel.COM] > > > Sent: Thursday, April 12, 2001 6:37 PM > > > To: Dave Thaler; estrin@usc.edu; dmm@cisco.com; > > bgmp@catarina.usc.edu > > > Subject: Accepting packets on a multi-access interface > owned by BGMP > > > > > > > > > Hi all, > > > > > > Section 5.2 of the latest BGMP spec > > > (draft-ietf-bgmp--spec-02.txt) > > > specifies the following rules on accepting packets arrived on > > > an interface owned > > > by BGMP: > > > > > > (1) If the packet was received over a point-to-point > > > interface owned by BGMP, > > > the packet is accepted. > > > > > > (2) If the packet arrived on a multiaccess network interface > > > owned by BGMP, the > > > packet is accepted if it is receiving data on a > > > source-specific branch, if it is > > > the designated forwarder for the longest matching route for > > > S, or for the > > > longest matching route for the nominal root of G. > > > > > > The second rule is for multiaccess network. But it seems to > > > me that this rule > > > will only work for packets being forwarded upstream toward > > > the root of the tree. > > > For packets being forwarded down the tree, the downstream > > > border router will not > > > be the designated forwarder. So packets travelling downstream > > > will not be > > > accepted. Am I missing something here?? > > > > > > > > > Thanks, > > > James Huang > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From owner-bgmp@catarina.usc.edu Wed Apr 18 18:11:37 2001 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18875 for ; Wed, 18 Apr 2001 18:11:36 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id OAA78651 for bgmp-list; Wed, 18 Apr 2001 14:31:28 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-bgmp@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id OAA78646 for ; Wed, 18 Apr 2001 14:31:27 -0700 (PDT) From: James_Huang@Mitel.COM Received: from Mitel.COM (newgate.mitel.com [198.53.180.100]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id OAA07693 for ; Wed, 18 Apr 2001 14:31:27 -0700 (PDT) Received: from kanmta01.software.mitel.com (kanmta01 [134.199.37.58]) by Mitel.COM (V8/MAIL-RELAY-2.1) with SMTP id RAA08549; Wed, 18 Apr 2001 17:26:53 -0400 (EDT) Received: by kanmta01.software.mitel.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 85256A32.0075CD8B ; Wed, 18 Apr 2001 17:26:43 -0400 X-Lotus-FromDomain: MITEL To: bgmp@catarina.usc.edu cc: dthaler@Exchange.Microsoft.com, estrin@usc.edu, dmm@cisco.com Message-ID: <85256A32.0075CC4F.00@kanmta01.software.mitel.com> Date: Wed, 18 Apr 2001 14:26:39 -0700 Subject: BGMP join/prune message beween BGMP internal peers?? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-bgmp@catarina.usc.edu Precedence: bulk Hi all, Will BGMP internal peers send BGMP join/prune messages to each other?? I thought the answer is NO, i.e. BGMP join/prune message will only be sent between BGMP external peers. But the following quote from the second to the last paragraph in section 5.3.1 of the BGMP spec really baffles me: "Finally, if an (S,G) Join is received from an internal peer, the peer should be stored with the M-IGP component target. If (S,G) state exists with the PR-bit set, and the next-hop towards the nominal root for G is through the M-IGP component, an (S,G) Poison-Reverse message is immediately sent to the internal peer." Thanks for your clarification -- James C. Huang From owner-bgmp@catarina.usc.edu Thu Apr 19 18:06:26 2001 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA19057 for ; Thu, 19 Apr 2001 18:06:25 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id OAA84186 for bgmp-list; Thu, 19 Apr 2001 14:04:17 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-bgmp@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id OAA84181 for ; Thu, 19 Apr 2001 14:04:16 -0700 (PDT) From: James_Huang@Mitel.COM Received: from Mitel.COM (newgate.mitel.com [198.53.180.100]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id OAA13106 for ; Thu, 19 Apr 2001 14:04:16 -0700 (PDT) Received: from kanmta01.software.mitel.com (kanmta01 [134.199.37.58]) by Mitel.COM (V8/MAIL-RELAY-2.1) with SMTP id RAA08333; Thu, 19 Apr 2001 17:00:09 -0400 (EDT) Received: by kanmta01.software.mitel.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 85256A33.00735A55 ; Thu, 19 Apr 2001 16:59:57 -0400 X-Lotus-FromDomain: MITEL To: "Dave Thaler" cc: estrin@usc.edu, dmm@cisco.com, bgmp@catarina.usc.edu Message-ID: <85256A33.0073586D.00@kanmta01.software.mitel.com> Date: Thu, 19 Apr 2001 13:59:53 -0700 Subject: RE: PR-bit in the BGMP protocol Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-bgmp@catarina.usc.edu Precedence: bulk From: James Huang@MITEL on 04/19/2001 01:59 PM PDT Dave: The two rules regarding add/remove the target towards the root domain to/from the target list of a BGMP (S,G) state are specified in the section for PIM-SM (sec 5.4.2). What is the reason they do not also apply to the other intra-domain protocols?? Also I have the following question with regarding to BGMP <-> PIM-SM interaction. Given a domain X which is on the best path from S to G and a border router R which is the best exit for G in domain X. How does the PIM-SM component of router R knows that it should forward (S,G) traffic it receives internally from the domain to its BGMP component? This is required so that the BGMP component will forward the (S,G) traffic upstream towards G. Thanks, - James C. Huang "Dave Thaler" on 04/17/2001 07:06:02 PM To: James Huang/USA/Mitel@Mitel cc: estrin@usc.edu, dmm@cisco.com, bgmp@catarina.usc.edu Subject: RE: PR-bit in the BGMP protocol There's nothing in the data packet processing since the other places in the spec talk about using the PR bit to add/remove the target towards the root domain in the target list. For example: "After the border router sends a BGMP (S,G) Join, if its (S,G) state has the PR-bit clear, a (S,G) Poison-Reverse message (with the PR-bit clear) is sent to the ingress router for G. The ingress router then creates (S,G) if it does not already exist, and removes the next hop towards the nominal root of G from the target list." Since the forwarding is done using the target list, the forwarding rules implicitly take the PR-bit into account. -Dave > -----Original Message----- > From: James_Huang@Mitel.COM [mailto:James_Huang@Mitel.COM] > Sent: Tuesday, April 17, 2001 2:09 PM > To: Dave Thaler > Cc: estrin@usc.edu; dmm@cisco.com; bgmp@catarina.usc.edu > Subject: RE: PR-bit in the BGMP protocol > > > > > From: James Huang@MITEL on 04/17/2001 02:08 PM PDT > Dave: > > Thanks for your reply. From your email, it seems to > imply that PR-bit in a > (S,G) state will affect how data packet is forwarded. But I > can not find any > rules regarding PR bit in section 5.2 (Multicast Data Packet > Processing). Do I > miss understand something? > > Also if you are able to track down the powerpoint > slides, could you post it > in the bgmp mailing distribution? > > Thanks, > -- James Huang > > > > > > "Dave Thaler" on 04/17/2001 > 11:40:14 AM > > To: James Huang/USA/Mitel@Mitel, "Dave Thaler" > > cc: estrin@usc.edu, dmm@cisco.com, bgmp@catarina.usc.edu > > Subject: RE: PR-bit in the BGMP protocol > > > > I have a set of powerpoint slides somewhere that give > examples (starting from an example topology Isidor raised), > and I haven't tracked down where the slides are. > > The PR-bit is discussed in the BGMP spec, which does > describe exactly when it's set or reset. > > Its basic purpose is to indicate to BGMP nodes whether > they need to forward packets up towards the root domain. > For example, in a case where an (S,G) branch exists, > a transit domain may get packets along the (S,G) branch, > and needs to know whether to (also) forward them up > towards the root domain. If the domain in question > is on the path between S and the root domain, then > the answer is yes (and the PR bit will be set on the > S,G state). If the domain in question is not on the > path between S and the root domain, then the answer > is no (and the PR bit will be clear on the S,G state). > > Hope this helps. > > -Dave > > > -----Original Message----- > > From: James_Huang@Mitel.COM [mailto:James_Huang@Mitel.COM] > > Sent: Monday, April 16, 2001 4:31 PM > > To: Dave Thaler > > Cc: estrin@usc.edu; dmm@cisco.com; bgmp@catarina.usc.edu > > Subject: PR-bit in the BGMP protocol > > > > > > > > > > From: James Huang@MITEL on 04/16/2001 04:30 PM PDT > > Dave: > > > > Could you explain the purpose of the PR-bit > > (poison-reverse) in the BGMP > > protocol? When is it set or reset? How does it affect the > > protocol? I will > > appreciate it if you could give some examples. > > > > Thanks, > > -- James Huang > > > > > > > > > > > > "Dave Thaler" on 04/12/2001 > > 07:02:04 PM > > > > To: James Huang/USA/Mitel@Mitel > > cc: estrin@usc.edu, dmm@cisco.com, bgmp@catarina.usc.edu > > > > Subject: RE: Accepting packets on a multi-access interface > > owned by BGMP > > > > > > > > I think you're right in that the text needs to be changed to > > cover the downstream case. > > > > Thanks, > > -Dave > > > > > -----Original Message----- > > > From: James_Huang@Mitel.COM [mailto:James_Huang@Mitel.COM] > > > Sent: Thursday, April 12, 2001 6:37 PM > > > To: Dave Thaler; estrin@usc.edu; dmm@cisco.com; > > bgmp@catarina.usc.edu > > > Subject: Accepting packets on a multi-access interface > owned by BGMP > > > > > > > > > Hi all, > > > > > > Section 5.2 of the latest BGMP spec > > > (draft-ietf-bgmp--spec-02.txt) > > > specifies the following rules on accepting packets arrived on > > > an interface owned > > > by BGMP: > > > > > > (1) If the packet was received over a point-to-point > > > interface owned by BGMP, > > > the packet is accepted. > > > > > > (2) If the packet arrived on a multiaccess network interface > > > owned by BGMP, the > > > packet is accepted if it is receiving data on a > > > source-specific branch, if it is > > > the designated forwarder for the longest matching route for > > > S, or for the > > > longest matching route for the nominal root of G. > > > > > > The second rule is for multiaccess network. But it seems to > > > me that this rule > > > will only work for packets being forwarded upstream toward > > > the root of the tree. > > > For packets being forwarded down the tree, the downstream > > > border router will not > > > be the designated forwarder. So packets travelling downstream > > > will not be > > > accepted. Am I missing something here?? > > > > > > > > > Thanks, > > > James Huang > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From owner-bgmp@catarina.usc.edu Thu Apr 26 09:42:18 2001 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA03416 for ; Thu, 26 Apr 2001 09:42:18 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id GAA17531 for bgmp-list; Thu, 26 Apr 2001 06:01:01 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-bgmp@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136] (may be forged)) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id GAA17526 for ; Thu, 26 Apr 2001 06:00:59 -0700 (PDT) Received: from mel.alcatel.fr (mel.alcatel.fr [212.208.74.132]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id GAA25854 for ; Thu, 26 Apr 2001 06:00:58 -0700 (PDT) Received: from aifhs2.alcatel.fr (mailhub.alcatel.fr [155.132.180.80]) by mel.alcatel.fr (ALCANET/SMTP) with ESMTP id NAA14802 for ; Thu, 26 Apr 2001 13:44:29 +0200 Received: from bsf.alcatel.fr (mail.dit.sxb.bsf.alcatel.fr [155.132.20.1]) by aifhs2.alcatel.fr (ALCANET/SMTP2) with ESMTP id OAA19818 for ; Thu, 26 Apr 2001 14:53:00 +0200 (MET DST) Received: from cabsimp1 (cabsimp1 [155.132.46.160]) by bsf.alcatel.fr (8.8.8+Sun/8.9.3) with SMTP id OAA22981 for ; Thu, 26 Apr 2001 14:58:43 +0200 (MET DST) Received: from col000018698b by cabsimp1 (SMI-8.6/SMI-4.1) id PAA19880; Thu, 26 Apr 2001 15:00:38 +0200 From: =?iso-8859-1?B?RnLpZOlyaWMgTGFyYnJl?= To: Subject: Handling of JOIN messages Date: Thu, 26 Apr 2001 14:59:21 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-bgmp@catarina.usc.edu Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by catarina.usc.edu id GAA17531 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA03416 Hi all, I am trying to understand how the JOIN messages are handled by BGMP. The Internet draft is sometimes not clear enough to me, so I tried to resume the section 5.3.1 into an algorithm that is described below. I am wondering if I am on the good way, and I'd like to get some comments about my understanding... Thanks, -- Frederic Larbre //////////////////////////////////////////////////////////////////////////// //////////////////////// // when the local BGMP component receives a JOIN message, it searches the tree // state table for a matching entry entry_found, entry = lookupEntry(tree_state_table, join_request); if(entry_found) // there is a matching entry in the tree state table if((SOURCE_OF(join_request) == ALL_SOURCES) and SOURCE_OF(entry) == ALL_SOURCES) { // the JOIN request is for a (*,G) state and there is already an // entry in the tree state table for the (*,G) state with the same G if(!isInTargetList(entry, join_initiator)) { // the join initiator is not listed in the target list. The // target from which the JOIN request was received is then // added to the target list of the matching entry addToTargetList(entry, join_initiator); } end. } elseif((SOURCE_OF(join_request) == ALL_SOURCES) and (SOURCE_OF(entry) != ALL_SOURCES)) { // the JOIN request is for a (*,G) state and there is already an // entry in the tree state table for the (S,G) state with the same G S = SOURCE_OF(entry); G = GROUP_OF(entry); NRG = NOMINAL_ROOT_OF_G(entry); next_hop_towards_S = lookupNextHop(S); next_hop_towards_nr_G = lookupNextHop(NRG); if(next_hop_towards_S != next_hop_towards_nr_G) { // the next hop peers toward S and the nominal root of G are // different // send a (S,G) PRUNE message towards the source S sendPRUNE(next_hop_towards_S, S, G); // clear the SPT bit on the (S,G) entry clearSPT(tree_state_table, entry); } } } else { // no entry was found, one must be created if(SOURCE_OF(join_request) == ALL_SOURCES) { // the JOIN request is not source-specific, an (*,G) entry must be // created entry = createGroupForwardingStateEntry(ALL_SOURCES, GROUP_OF(join_request)); // the local BGMP component retrieves the next hop towards the // nominal root of G according to the Multicast RIB of the EGP next_hop = lookupNextHop(NOMINAL_ROOT_OF_G(join_request)); if(isInternalPeer(next_hop)) { // the next hop towards the nominal root of G is an // internal peer. The target list of the newly created // entry must be initialized to contain the MIGP // component owning the next hop interface migp_component_interface = getMIGPComponentInterface(next_hop); addToTargetList(entry, migp_component_interface); } else { // the next hop towards the nominal root of G is an external // peer or the next hop component. The target list of the // entry – created above – must be initialized to contain it. addToTargetList(entry, next_hop); } // the target from which the JOIN request was received is then added // to the target list of the newly created entry addToTargetList(entry, join_initiator); } else { // the JOIN request is source-specific, an (S,G) entry must be // created S = SOURCE_OF(join_request); G = GROUP_OF(join_request); NRG = NOMINAL_ROOT_OF_G(join_request); entry = createSourceForwardingStateEntry(S, G); if(isAnInternalSource(S)) { // the source is internal to the BGMP speaker’s domain. The // “Poison Reverse” (PR-bit) must be set. setPR(entry); } // the target from which the JOIN request was received is then added // to the target list of the newly created entry addToTargetList(entry, join_initiator); if(isInternalPeer(join_initiator) { // the join initiator is an internal peer // The target list of the newly created entry must be contain // the MIGP component interface towards the peer that initiates // the JOIN. migp_component_interface = getMIGPComponentInterface(join_initiator); addToTargetList(entry, migp_component_interface); entry_found, e = lookupEntry(tree_state_table, <(S,G)>); if(entry_found and isPR(e)) { // a (S,G) state exists with the PR-bit set next_hop, isPeer = lookupNextHop(NRG); if(isThroughMIGPComponent(next_hop)) { // the next hop is through the MIGP component // interface // send a POISON_REVERSE message sendPOISON_REVERSE(join_initiator, S, G); } } } else { // the join initiator is an external peer entry_found, e = lookupEntry(tree_state_table, <(S,G)>); if(entry_found and then (isPR(e) and isBestExit(NRG))) { // a (S,G) state exists with the PR-bit set. The local // BGMP speaker is the best exit for the nominal root of G next_hop = lookupNextHop(NRG); if(getComponentInterface(next_hop) == getComponentInterface(join_initiator)) { // the next hop towards the nominal root of G is // through the interface towards the external peer // send a POISON_REVERSE message sendPOISON_REVERSE(join_initiator, S, G); } } } } // the entry can now be added to the tree state table addEntry(tree_state_table, entry); } S = SOURCE_OF(entry); G = GROUP_OF(entry); NRG = NOMINAL_ROOT_OF_G(entry); if(S == ALL_SOURCES) { // the entry is not source-specific, it’s an (*,G) entry // find the next hop EGP peer towards the nominal root of G in the // Multicast RIB next_hop, isPeer = lookupNextHop(NRG); } else { // the entry is source-specific, it’s an (S,G) entry // find the next hop EGP peer towards S in the Multicast RIB next_hop, isPeer = lookupNextHop(S); } if(!isNull(getTargetListWithoutNextHop(entry, next_hop)) { // the target list is not inclluding the next hop is non-null if(isPeer) { // the next hop peer exists if(!isInternalPeer(next_hop)) { // the next hop peer towards the nominal root of G is an // external peer // send a (*,G) or (S,G) JOIN message towards the next hop if(S == ALL_SOURCES) { sendJOIN(next_hop, S, G); } else { entry_found, e = lookupEntry(tree_state_table, <(*,G)>); if(!entry_found) { // the router does not have any (*,G) state // matching the entry // send a (S,G) JOIN message unicast to the // external peer sendJOIN(next_hop, S, G); } } } else { // the next hop peer towards the nominal root of G is an // internal peer // retrieves the MIGP component owning the next hop interface migp_component_interface = getMIGPComponentInterface(next_hop); // send a (S,G) or (*,G) JOIN message unicast to the interface sendJOIN(migp_component_interface, S, G); } } else { // the next hop peer does not exist // retrieves the MIGP component owning the next hop interface migp_component_interface = getMIGPComponentInterface(next_hop); // send a (S,G) or (*,G) JOIN message unicast to the interface sendJOIN(migp_component_interface, S, G); } } //////////////////////////////////////////////////////////////////////////// ////////////////////////