Bill Fenner | 3 Apr 23:00 2007
Picon

Re: issues in draft-ietf-mboned-routingarch-07


>  2) Document Obsoletes and reclassifies Historic 5 RFCs *).
>...
>*) ...  Multicast OSPF (MOSPF)

At the OSPF WG meeting in Prague, Acee said that he wanted to
get rid of MOSPF for OSPFv3 in draft-ietf-ospf-ospfv3-update
but he got pushback.  I didn't catch exactly where the pushback
was from, but you might want to check with the OSPF WG before
moving forward with this part.

  Bill

_______________________________________________
MBONED mailing list
MBONED <at> ietf.org
https://www1.ietf.org/mailman/listinfo/mboned

Jayanth Chennamangalam | 12 Apr 15:26 2007
Picon

IGMP/MLD Proxy Upstream Interface Learning

Hi!

IGMP/MLD Proxy Upstream Interface Learning ( draft-vijay-magma-igmpproxy-upstream-intf-learning-00) specifies a mechanism for the dynamic determination of the upstream interface of a device running IGMP/MLD Proxy, as opposed to manual configuration. The learning of the upstream interface is achieved by listening for IGMP/MLD General Query messages on the interfaces of the proxy device.

This document is actually intended for Multicast and Anycast Group Membership (MAGMA) Working Group. Since MBONED is also involved in multicast mechanisms, I thought it would be a good idea to request the WG members to review the document. I would greatly appreciate it if the WG members could review the draft and send me comments.

The draft is available at: http://www.ietf.org/internet-drafts/draft-vijay-magma-igmpproxy-upstream-intf-learning-00.txt

Thanks and regards,

Jayanth

_______________________________________________
MBONED mailing list
MBONED <at> ietf.org
https://www1.ietf.org/mailman/listinfo/mboned
Marshall Eubanks | 12 Apr 20:14 2007

Re: IGMP/MLD Proxy Upstream Interface Learning


On Apr 12, 2007, at 9:26 AM, Jayanth Chennamangalam wrote:

> Hi!
>
> IGMP/MLD Proxy Upstream Interface Learning ( draft-vijay-magma- 
> igmpproxy-upstream-intf-learning-00) specifies a mechanism for the  
> dynamic determination of the upstream interface of a device running  
> IGMP/MLD Proxy, as opposed to manual configuration. The learning of  
> the upstream interface is achieved by listening for IGMP/MLD  
> General Query messages on the interfaces of the proxy device.
>
> This document is actually intended for Multicast and Anycast Group  
> Membership (MAGMA) Working Group. Since MBONED is also involved in  
> multicast mechanisms, I thought it would be a good idea to request  
> the WG members to review the document. I would greatly appreciate  
> it if the WG members could review the draft and send me comments.
>
> The draft is available at: http://www.ietf.org/internet-drafts/ 
> draft-vijay-magma-igmpproxy-upstream-intf-learning-00.txt
>

Have you gotten approval to the MAGMA chairs for this ?  My  
understanding was that that WG was shutting down.

Regards
Marshall

> Thanks and regards,
>
> Jayanth
> _______________________________________________
> MBONED mailing list
> MBONED <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/mboned

_______________________________________________
MBONED mailing list
MBONED <at> ietf.org
https://www1.ietf.org/mailman/listinfo/mboned

Hiroshi Ohta | 17 Apr 11:49 2007
Picon

Adopting <draft-venaas-mboned-ssmping-00.txt> as a WG doc

Working group,

In the last session of mboned during IETF-68 in Prague, a good 
number of supports were shown for adopting 
<draft-koch-mboned-mcast-arpa-00.txt> as a WG document.  I 
would like to confirm it on the list.

If you have any comments or objections, please post them on the 
ML by the end of next week (i.e., April 27, 17:00 EST).

Thank you.
Hiroshi and Marshall

_______________________________________________
MBONED mailing list
MBONED <at> ietf.org
https://www1.ietf.org/mailman/listinfo/mboned

Tim Chown | 17 Apr 12:30 2007
Picon

Re: Adopting <draft-venaas-mboned-ssmping-00.txt> as a WG doc

On Tue, Apr 17, 2007 at 06:49:15PM +0900, Hiroshi Ohta wrote:
> Working group,
> 
> In the last session of mboned during IETF-68 in Prague, a good 
> number of supports were shown for adopting 
> <draft-koch-mboned-mcast-arpa-00.txt> as a WG document.  I 
> would like to confirm it on the list.
> 
> If you have any comments or objections, please post them on the 
> ML by the end of next week (i.e., April 27, 17:00 EST).

I agree the WG should adopt the item.    The tool is already in quite
widespread use and work on standardising the specification of the tool
will only help improve it and allow others (maybe router vendors) to
support the ssmping(d) functions in an interoperable way.

--

-- 
Tim

_______________________________________________
MBONED mailing list
MBONED <at> ietf.org
https://www1.ietf.org/mailman/listinfo/mboned

Hiroshi Ohta | 17 Apr 15:00 2007
Picon

Re: Adopting <draft-venaas-mboned-ssmping-00.txt> as a WG doc

Working Group,

At 18:49 07/04/17 +0900, Hiroshi Ohta wrote:
>Working group,
>
>In the last session of mboned during IETF-68 in Prague, a good 
>number of supports were shown for adopting 
><draft-koch-mboned-mcast-arpa-00.txt> as a WG document.  I 
>would like to confirm it on the list.

Sorry for confusion.  Of course, I wanted to say:

In the last session of mboned during IETF-68 in Prague, a good 
number of supports were shown for adopting 
<draft-venaas-mboned-ssmping-00.txt> as a WG document.  I 
would like to confirm it on the list.

Regards,
Hiroshi

>If you have any comments or objections, please post them on the 
>ML by the end of next week (i.e., April 27, 17:00 EST).
>
>Thank you.
>Hiroshi and Marshall
>
>
>
>_______________________________________________
>MBONED mailing list
>MBONED <at> ietf.org
>https://www1.ietf.org/mailman/listinfo/mboned

_______________________________________________
MBONED mailing list
MBONED <at> ietf.org
https://www1.ietf.org/mailman/listinfo/mboned

Marshall Eubanks | 17 Apr 20:17 2007

Re: IGMP/MLD Proxy Upstream Interface Learning

Dear Jayanth;

Based on a discussion with Isidor, I think that we will need to  
consider this in Mboned.

Could the WG please take a look at this draft so that we can consider  
it for adoption.

Also, I will forward 4 relevant messages from MAGMA.

Regards
Marshall

On Apr 12, 2007, at 9:26 AM, Jayanth Chennamangalam wrote:

> Hi!
>
> IGMP/MLD Proxy Upstream Interface Learning ( draft-vijay-magma- 
> igmpproxy-upstream-intf-learning-00) specifies a mechanism for the  
> dynamic determination of the upstream interface of a device running  
> IGMP/MLD Proxy, as opposed to manual configuration. The learning of  
> the upstream interface is achieved by listening for IGMP/MLD  
> General Query messages on the interfaces of the proxy device.
>
> This document is actually intended for Multicast and Anycast Group  
> Membership (MAGMA) Working Group. Since MBONED is also involved in  
> multicast mechanisms, I thought it would be a good idea to request  
> the WG members to review the document. I would greatly appreciate  
> it if the WG members could review the draft and send me comments.
>
> The draft is available at: http://www.ietf.org/internet-drafts/ 
> draft-vijay-magma-igmpproxy-upstream-intf-learning-00.txt
>
> Thanks and regards,
>
> Jayanth
> _______________________________________________
> MBONED mailing list
> MBONED <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/mboned

_______________________________________________
MBONED mailing list
MBONED <at> ietf.org
https://www1.ietf.org/mailman/listinfo/mboned

Marshall Eubanks | 17 Apr 20:19 2007
Picon

Fwd: [magma] IGMP/MLD Proxy Upstream Interface Learning

Message 4

---------- Forwarded message ----------
From: Jayanth Chennamangalam <jayanthc <at> gmail.com>
Date: Apr 5, 2007 9:35 AM
Subject: Re: [magma] IGMP/MLD Proxy Upstream Interface Learning
To: Gorry Fairhurst <gorry <at> erg.abdn.ac.uk>, magma <at> ietf.org
Cc: Krishna Agarwal <kagarwal <at> infinera.com>

Hi Gorry,

Quoting from RFC 4605:

>    1.2.  Applicability Statement
>
>       The IGMP/MLD-based forwarding only works in a simple tree topology.
>       The tree must be manually configured by designating upstream and
>       downstream interfaces on each proxy device.  In addition, the IP
>       addressing scheme applied to the proxying tree topology SHOULD be
>       configured to ensure that a proxy device can win the IGMP/MLD Querier
>       election to be able to forward multicast traffic.  There are no other
>       multicast routers except the proxy devices within the tree, and the
>       root of the tree is expected to be connected to a wider multicast
>       infrastructure.  This protocol is limited to a single administrative
>       domain.
>
>       In more complicated scenarios where the topology is not a tree, a
>       more robust failover mechanism is desired, or more than one
>       administrative domain is involved, a multicast routing protocol
>       should be used.
>

RFC 4605 states that "there are no other multicast routers except the proxy
devices within the tree". STP will ensure that there is only one upstream
interface, which eventually connects to the multicast router.

If your question was regarding the case where there would be more than one
multicast router on the upstream, this is the solution that we see:

Connect the proxy device to both the routers. In this case, Querier Election
will not take place, as the proxy device will not forward the Queries from
one interface to the other. Here, the IGMP/MLD Proxy Upstream Interface
Learning algorithm will kick in, and try to converge on to one interface.
Since this configuration is intentional, the alarm that would be raised due
to non-convergence of the upstream interface can be ignored by the network
administrator. (Maybe we can have an option for administrative disabling of
the alarm in updates to the draft.) In any case, the proxy device will
continue to send the aggregated subscription messages to both the routers,
irrespective of whether convergence happened or not.

 +--+          +--+
  |R1|          |R2|
 ++-+          ++-+
   |             |
   |   +--+---+  |
   +---+Proxy +--+
       |Device|
       +--+---+
          |

Quoting from your mail:

"It can be the case that only one is configured to run IGMP-Querier (this
simplifies things sometimes)"

If you are referring to the case where only R1 is running IGMP, as far as we
understand it, this does not seem to simplify the scenario. Since R2 is not
IGMP-enabled, it will not process any multicast subscription requests and
thus multicast protocols might not be able to spawn trees (RPT/SPT). So why
would the proxy device need to send those messages to R2?

An alternative - and probably not ideal - solution would be to connect
the proxy device through a
switch to the multicast routers. Here, Querier Election will take place
between R1 and R2 and only the elected router will subsequently send
Queries. Since the device which is upstream with respect to the proxy device
is a switch, it will send multicast subscription requests to both the
routers.

 +--+          +--+
 |R1|          |R2|
  ++-+          ++-+
  |             |
   |   +------+  |
   +---+Switch+--+
       +--+---+
          |
       +--+---+
       |Proxy |
       |Device|
       +--+---+
          |

Thanks and regards,

Jayanth

On 4/4/07, Gorry Fairhurst <gorry <at> erg.abdn.ac.uk> wrote:
>
> Seems to make sense, except my doubt was about:
>
> " Besides, since there is only one router in the tree
> (which is the Querier), detecting it by relying on General Query messages is
> simpler than running MRD on the devices."
>
> - In the networks we use, there are often more than two multicast routers
> connected. It can be the case that only one is configured to run
> IGMP-Querier (this simplifies things sometimes), but both do need to see
> multicast traffic from the LAN (i.e. they are both part of the same L2
> tree).
>
> If I understand, the devices cited in the draft rely on IGMP only for this,
> and these devices will break the normal multicast behaviour.
>
> Best wishes,
>
> Gorry
>
>
> On 4/4/07 13:45, "Jayanth Chennamangalam" <jayanthc <at> gmail.com> wrote:
>
> > Hi Gorry,
> >
> > Thank you for your interest in the document.
> >
> > The detection of multicast router interfaces is a key issue in the case of
> > snooping switches, not devices which proxy IGMP/MLD group membership
> > information.
> >
> > For a snooping switch, as shown in the diagram below, there may be multiple
> > routers connected to its ports. One of them would become the Querier
> > (denoted by Q), while the others would be the Non-Queriers (NQ). In this
> > scenario, there has to be some method by which the snooping switch has to
> > determine which ports are connected to routers, and MRD is used to address
> > this problem.
> >
> >  Q             NQ           NQ
> > +--+          +--+         +--+
> > |R1|          |R2|         |R3|
> > ++-+          ++-+         ++-+
> >  |             |            |
> >  |             |            |
> >  |            +++           |
> >  +------------+S+-----------+
> >               +-+
> >
> > In the case of a proxy device (quoting from RFC 4605):
> >
> > 1. The topology that the device is part of "is limited to a tree".
> > 2. The proxy device "has a single upstream interface".
> >
> > The upstream interface ("host interface") is connected to an IGMP/MLD
> > router. If the proxy device is a switch, the Spanning Tree Protocol ensures
> > that there is only one upstream. If the proxy device is a router, this has
> > to be done administratively. In any case, there is no question of Querier
> > Election happening on the upstream interface and Queries getting suppressed
> > (for Non-Queriers), as the proxy device does not flood recieved Queries, but
> > rather, generates its own Queries to be sent on the downstream interfaces
> > ("router interfaces"). Besides, since there is only one router in the tree
> > (which is the Querier), detecting it by relying on General Query messages is
> > simpler than running MRD on the devices.
> >
> > The applicability of IGMP/MLD Proxy Upstream Interface Learning is mainly
> > when STP reconfigures the tree, so that the upstream interface changes.
> > Here, it is not the router which is discovered, but the upstream interface.
> >
> > Hope this clarifies your doubt.
> >
> > Thanks and regards,
> >
> > Jayanth
> >
> >
> > On 4/3/07, Gorry Fairhurst < gorry <at> erg.abdn.ac.uk> wrote:
> >>
> >> I'm not sure I understand this. I thought a key issue was the detection
> >> of multicast router interfaces (which may be PIM routers, but need not
> >> necessarily be queriers). Whereas this document only seems to talk about
> > the
> >> querier.
> >>
> >> So - how does this document relate to using MRD to configure the upstream
> >> interface (RFC4286)?
> >>
> >> Gorry
> >>
> >> On 3/4/07 15:23, "Jayanth Chennamangalam" <jayanthc <at> gmail.com> wrote:
> >>
> >>> Hi!
> >>>
> >>> IGMP/MLD Proxy Upstream Interface Learning (
> >>> draft-vijay-magma-igmpproxy-upstream-intf-learning-00<
> > http://www.ietf.org/inte
> >>> rnet-drafts/draft- vijay-magma-igmpproxy-upstream-intf-learning-00.txt>)
> >>> specifies a mechanism for the dynamic determination of the upstream
> >>> interface of a device running IGMP/MLD Proxy, as opposed to manual
> >>> configuration. The learning of the upstream interface is achieved by
> >>> listening for IGMP/MLD General Query messages on the interfaces of the
> > proxy
> >>> device.
> >>>
> >>> I would greatly appreciate it if the WG members could review the draft
> > and
> >>> send me comments.
> >>>
> >>> The draft is available at:
> >>>
> > http://www.ietf.org/internet-drafts/draft-vijay-magma-igmpproxy-upstream-intf-
> >>> learning-00.txt
> >>>
> >>> Thanks and regards,
> >>>
> >>> Jayanth
> >>> _______________________________________________
> >>> magma mailing list
> >>> magma <at> ietf.org
> >>> https://www1.ietf.org/mailman/listinfo/magma
> >>
> >>
> >>
> > _______________________________________________
> > magma mailing list
> > magma <at> ietf.org
> > https://www1.ietf.org/mailman/listinfo/magma
>
>
>

_______________________________________________
magma mailing list
magma <at> ietf.org
https://www1.ietf.org/mailman/listinfo/magma

_______________________________________________
MBONED mailing list
MBONED <at> ietf.org
https://www1.ietf.org/mailman/listinfo/mboned

Marshall Eubanks | 17 Apr 20:19 2007
Picon

Fwd: [magma] IGMP/MLD Proxy Upstream Interface Learning

Message 3

---------- Forwarded message ----------
From: Gorry Fairhurst <gorry <at> erg.abdn.ac.uk>
Date: Apr 4, 2007 10:20 AM
Subject: Re: [magma] IGMP/MLD Proxy Upstream Interface Learning
To: Jayanth Chennamangalam <jayanthc <at> gmail.com>, magma <at> ietf.org
Cc: Krishna Agarwal <kagarwal <at> infinera.com>

Seems to make sense, except my doubt was about:

" Besides, since there is only one router in the tree
(which is the Querier), detecting it by relying on General Query messages is
simpler than running MRD on the devices."

- In the networks we use, there are often more than two multicast routers
connected. It can be the case that only one is configured to run
IGMP-Querier (this simplifies things sometimes), but both do need to see
multicast traffic from the LAN (i.e. they are both part of the same L2
tree).

If I understand, the devices cited in the draft rely on IGMP only for this,
and these devices will break the normal multicast behaviour.

Best wishes,

Gorry

On 4/4/07 13:45, "Jayanth Chennamangalam" <jayanthc <at> gmail.com> wrote:

> Hi Gorry,
>
> Thank you for your interest in the document.
>
> The detection of multicast router interfaces is a key issue in the case of
> snooping switches, not devices which proxy IGMP/MLD group membership
> information.
>
> For a snooping switch, as shown in the diagram below, there may be multiple
> routers connected to its ports. One of them would become the Querier
> (denoted by Q), while the others would be the Non-Queriers (NQ). In this
> scenario, there has to be some method by which the snooping switch has to
> determine which ports are connected to routers, and MRD is used to address
> this problem.
>
>  Q             NQ           NQ
> +--+          +--+         +--+
> |R1|          |R2|         |R3|
> ++-+          ++-+         ++-+
>  |             |            |
>  |             |            |
>  |            +++           |
>  +------------+S+-----------+
>               +-+
>
> In the case of a proxy device (quoting from RFC 4605):
>
> 1. The topology that the device is part of "is limited to a tree".
> 2. The proxy device "has a single upstream interface".
>
> The upstream interface ("host interface") is connected to an IGMP/MLD
> router. If the proxy device is a switch, the Spanning Tree Protocol ensures
> that there is only one upstream. If the proxy device is a router, this has
> to be done administratively. In any case, there is no question of Querier
> Election happening on the upstream interface and Queries getting suppressed
> (for Non-Queriers), as the proxy device does not flood recieved Queries, but
> rather, generates its own Queries to be sent on the downstream interfaces
> ("router interfaces"). Besides, since there is only one router in the tree
> (which is the Querier), detecting it by relying on General Query messages is
> simpler than running MRD on the devices.
>
> The applicability of IGMP/MLD Proxy Upstream Interface Learning is mainly
> when STP reconfigures the tree, so that the upstream interface changes.
> Here, it is not the router which is discovered, but the upstream interface.
>
> Hope this clarifies your doubt.
>
> Thanks and regards,
>
> Jayanth
>
>
> On 4/3/07, Gorry Fairhurst <gorry <at> erg.abdn.ac.uk> wrote:
>>
>> I'm not sure I understand this. I thought a key issue was the detection
>> of multicast router interfaces (which may be PIM routers, but need not
>> necessarily be queriers). Whereas this document only seems to talk about
> the
>> querier.
>>
>> So - how does this document relate to using MRD to configure the upstream
>> interface (RFC4286)?
>>
>> Gorry
>>
>> On 3/4/07 15:23, "Jayanth Chennamangalam" <jayanthc <at> gmail.com> wrote:
>>
>>> Hi!
>>>
>>> IGMP/MLD Proxy Upstream Interface Learning (
>>> draft-vijay-magma-igmpproxy-upstream-intf-learning-00<
> http://www.ietf.org/inte
>>> rnet-drafts/draft-vijay-magma-igmpproxy-upstream-intf-learning-00.txt>)
>>> specifies a mechanism for the dynamic determination of the upstream
>>> interface of a device running IGMP/MLD Proxy, as opposed to manual
>>> configuration. The learning of the upstream interface is achieved by
>>> listening for IGMP/MLD General Query messages on the interfaces of the
> proxy
>>> device.
>>>
>>> I would greatly appreciate it if the WG members could review the draft
> and
>>> send me comments.
>>>
>>> The draft is available at:
>>>
> http://www.ietf.org/internet-drafts/draft-vijay-magma-igmpproxy-upstream-intf-
>>> learning-00.txt
>>>
>>> Thanks and regards,
>>>
>>> Jayanth
>>> _______________________________________________
>>> magma mailing list
>>> magma <at> ietf.org
>>> https://www1.ietf.org/mailman/listinfo/magma
>>
>>
>>
> _______________________________________________
> magma mailing list
> magma <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/magma

_______________________________________________
magma mailing list
magma <at> ietf.org
https://www1.ietf.org/mailman/listinfo/magma

_______________________________________________
MBONED mailing list
MBONED <at> ietf.org
https://www1.ietf.org/mailman/listinfo/mboned

Marshall Eubanks | 17 Apr 20:18 2007
Picon

Fwd: [magma] IGMP/MLD Proxy Upstream Interface Learning

Message 1

---------- Forwarded message ----------
From: Gorry Fairhurst <gorry <at> erg.abdn.ac.uk>
Date: Apr 3, 2007 11:52 AM
Subject: Re: [magma] IGMP/MLD Proxy Upstream Interface Learning
To: Jayanth Chennamangalam <jayanthc <at> gmail.com>, magma <at> ietf.org
Cc: vijayanandaj <at> huawei.com, kagarwal <at> infinera.com

I'm not sure I understand this. I thought a key issue was the detection
of multicast router interfaces (which may be PIM routers, but need not
necessarily be queriers). Whereas this document only seems to talk about the
querier.

So - how does this document relate to using MRD to configure the upstream
interface (RFC4286)?

Gorry

On 3/4/07 15:23, "Jayanth Chennamangalam" <jayanthc <at> gmail.com> wrote:

> Hi!
>
> IGMP/MLD Proxy Upstream Interface Learning (
> draft-vijay-magma-igmpproxy-upstream-intf-learning-00<http://www.ietf.org/inte
> rnet-drafts/draft-vijay-magma-igmpproxy-upstream-intf-learning-00.txt>)
> specifies a mechanism for the dynamic determination of the upstream
> interface of a device running IGMP/MLD Proxy, as opposed to manual
> configuration. The learning of the upstream interface is achieved by
> listening for IGMP/MLD General Query messages on the interfaces of the proxy
> device.
>
> I would greatly appreciate it if the WG members could review the draft and
> send me comments.
>
> The draft is available at:
> http://www.ietf.org/internet-drafts/draft-vijay-magma-igmpproxy-upstream-intf-
> learning-00.txt
>
> Thanks and regards,
>
> Jayanth
> _______________________________________________
> magma mailing list
> magma <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/magma

_______________________________________________
magma mailing list
magma <at> ietf.org
https://www1.ietf.org/mailman/listinfo/magma

_______________________________________________
MBONED mailing list
MBONED <at> ietf.org
https://www1.ietf.org/mailman/listinfo/mboned


Gmane