Subject: Re: [pim] draft-ietf-pim-mtid-05 wglc

From: hou <[email-masked]>
Date: Thu, 06 Jan 2011 16:51:04 -0800

[H] Thanks for your review comments. Reply inline

On 12/16/10 8:58 PM, "Liuhui" <[email-masked]> wrote:

> A few comments on the draft:
> 
> The Introduction only mentions the multiple topology over "separate network
> paths". Is this the only case or can different multicast topologies be built
> over the same physical link? This should be clarified, as the referenced
> [5120] does. 
> 
> [H] As mentioned in the ³Introduction², the main purpose of this
       [H] draft is to prevent multicast traffic loss in case of  single
       [H] network segment failure. Building multicast topologies over
> [H] the same physical network will be against the purpose, but
> [H] can be done if an operator chooses to do so
> 
> Besides, it might be better to give some explanations for the mtid attribute's
> influence on forwarding plane, whether it changes the forwarding state/rule or
> not.
> 
> [H] At the end of Section 2, we mention that ³The draft does not introduce any
> [H] change to the RPF check procedure used to verify the incoming interface
> [H] when a packet is forwarded²
> 
> 
> Finally, not very clear on the using of two group address G1 and G2 (in
> Introduction section):
> - Since mtid is used to identify the different topology, why additional
> differentiation of group address is needed.
> 
> [H] mtid and group address servers different purposes: mtid is the path
> [H] identifier, while the group address defines the content that needs to be
> [H] delivered via the path.
> 
> - Using two addresses to identify the same multicast stream, is it easy to be
> deployed in IPTV network, where group address   often corresponds with a
> channel.
> 
> [H] In order to achieve multicast resilience as an end-to-end solution
> [H] for IPTV, or other applications,  there will be work from other aspects,
> [H] besides the transport/network layer approach, as this draft is focusing
> on.
> [H] The channel to group address mapping actually fits the draft very well,
> [H] however, the channel/group split/merge functionality is beyond the scope
> [H] of this draft.
> 
>     
> thanks
> - Heidi
> 
> 
> Thanks,
> Liu Hui
> 
>> > -----Original Message-----
>> > From: [email-masked] [mailto:[email-masked]] On Behalf Of Mike
>> > McBride (mmcbride)
>> > Sent: Tuesday, December 07, 2010 8:24 AM
>> > To: Yiqun Cai (ycai); [email-masked]
>> > Subject: [pim] draft-ietf-pim-mtid-05 wglc
>> > 
>>> > > Mike and Stig,  will we need another last call?
>> > 
>> > Yes, sorry for the delay. Today begins another 2 week wglc for
>> > http://www.ietf.org/id/draft-ietf-pim-mtid-05.txt
>> > 
>> > Please review the draft and let us know if you support sending it to the
>> > iesg.
>> > 
>> > thanks,
>> > mike
>> > 
>>> > > -----Original Message-----
>>> > > From: [email-masked] [mailto:[email-masked]] On Behalf Of
>>> > > Yiqun Cai (ycai)
>>> > > Sent: Wednesday, September 22, 2010 3:27 PM
>>> > > To: [email-masked]
>>> > > Subject: Re: [pim] I-D Action:draft-ietf-pim-mtid-05.txt
>>> > >
>>> > >
>>> > > Chairs, Dimitri,  and WG,
>>> > >
>>> > > The latest update incorporates the comment received from the
>> > discussion
>>> > > during the Last Call.
>>> > >
>>> > > Please review and comment.
>>> > >
>>> > > Mike and Stig,  will we need another last call?
>>> > >
>>> > > Thanks.
>>> > >
>>> > >
>>> > > On 9/22/10 3:00 PM, "[email-masked]" <Internet-
>>> > > [email-masked]>
>>> > > wrote:
>>> > >
>>>> > > > A New Internet-Draft is available from the on-line Internet-Drafts
>>>> > > > directories.
>>>> > > > This draft is a work item of the Protocol Independent Multicast
>>> > > Working Group
>>>> > > > of the IETF.
>>>> > > >
>>>> > > >
>>>> > > > Title           : PIM Multi-Topology ID (MT-ID) Join-Attribute
>>>> > > > Author(s)       : Y. Cai, H. Ou
>>>> > > > Filename        : draft-ietf-pim-mtid-05.txt
>>>> > > > Pages           : 11
>>>> > > > Date            : 2010-09-22
>>>> > > >
>>>> > > > This document introduces a new type of PIM Join Attribute that
>>>> > > > extends PIM signaling to identify a topology that should be used
>> > when
>>>> > > > constructing a particular multicast distribution tree.
>>>> > > >
>>>> > > > A URL for this Internet-Draft is:
>>>> > > > http://www.ietf.org/internet-drafts/draft-ietf-pim-mtid-05.txt
>>>> > > >
>>>> > > > Internet-Drafts are also available by anonymous FTP at:
>>>> > > > ftp://ftp.ietf.org/internet-drafts/
>>>> > > >
>>>> > > > Below is the data which will enable a MIME compliant mail reader
>>>> > > > implementation to automatically retrieve the ASCII version of the
>>>> > > > Internet-Draft.
>>>> > > > _______________________________________________
>>>> > > > pim mailing list
>>>> > > > [email-masked]
>>>> > > > https://www.ietf.org/mailman/listinfo/pim
>>> > >
>>> > >
>>> > > --
>>> > > Yiqun
>>> > >
>>> > > _______________________________________________
>>> > > pim mailing list
>>> > > [email-masked]
>>> > > https://www.ietf.org/mailman/listinfo/pim
>> > _______________________________________________
>> > pim mailing list
>> > [email-masked]
>> > https://www.ietf.org/mailman/listinfo/pim
> _______________________________________________
> pim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pim

---

From: Liuhui <[email-masked]>
Date: Mon, 10 Jan 2011 10:05:49 +0000

Hi Heidi,

Thanks for your explanation. I suggest some of them be incorporated into the draft to provide more information and for better understanding, if possible.

Besides, the introduction part should give clearer illustration on whether this method could be used for protection, for load balancing, or for both.  E.g.,  duplicated streams on different topologies will be distributed to the same user group for protection, but to different user groups for load balancing.  I heard different opinions on this point, but no explicit answer could be found.

Thanks,
Liu Hui

From: hou [mailto:[email-masked]]
Sent: Friday, January 07, 2011 8:51 AM
To: Liuhui; Mike McBride (mmcbride); Yiqun Cai (ycai); [email-masked]
Subject: Re: [pim] draft-ietf-pim-mtid-05 wglc

The Introduction only mentions the multiple topology over "separate network paths". Is this the only case or can different multicast topologies be built over the same physical link? This should be clarified, as the referenced [5120] does.

[H] As mentioned in the "Introduction", the main purpose of this

Besides, it might be better to give some explanations for the mtid attribute's influence on forwarding plane, whether it changes the forwarding state/rule or not.

[H] At the end of Section 2, we mention that "The draft does not introduce any
[H] change to the RPF check procedure used to verify the incoming interface
[H] when a packet is forwarded"

Finally, not very clear on the using of two group address G1 and G2 (in Introduction section):
- Since mtid is used to identify the different topology, why additional differentiation of group address is needed.

- Using two addresses to identify the same multicast stream, is it easy to be deployed in IPTV network, where group address   often corresponds with a channel.

[H] besides the transport/network layer approach, as this draft is focusing on.

thanks
- Heidi

Thanks,
Liu Hui

---

From: hou <[email-masked]>
Date: Mon, 10 Jan 2011 11:29:31 -0800

Liu Hui,

On 1/10/11 2:05 AM, "Liuhui" <[email-masked]> wrote:

> Hi Heidi, 
>  
> Thanks for your explanation. I suggest some of them be incorporated into the
> draft to provide more information and for better understanding, if possible.
> 
> [H2]  Would you please supply some specific text and we will be happy to
> incorporate.
>  
> Besides, the introduction part should give clearer illustration on whether
> this method could be used for protection, for load balancing, or for both.
> E.g.,  duplicated streams on different topologies will be distributed to the
> same user group for protection, but to different user groups for load
> balancing.  I heard different opinions on this point, but no explicit answer
> could be found.
> 
> [H2]  The draft only mentioned protection as one of the possible use cases. On
> the other hand
> [H2]  the PIM protocols doesn¹t have the knowledge of applications, we intend
> to focus on 
> [H2]  the protocol specification, but vendors are free to implement whatever
> applications 
> [H2]  they see fit on top of the specification.
> 
> thanks
> - Heidi
>  
> Thanks,
> Liu Hui
>  
>

---

From: Liuhui <[email-masked]>
Date: Tue, 11 Jan 2011 03:30:53 +0000

According to the illustration below, two places of the draft could be improved:

1．Section 1 : append to the last paragraph
The draft does not introduce any change to the RPF check procedure used to verify the incoming interface when a packet is forwarded. “It uses multiple group addresses to identify a unique multicast stream, which requires address split and merge to facilitate the address-channel mapping when being applied. The detailed processing is beyond the scope of the document.”

2.   Section 3.2 : add before other properties
For each PIM RPF topology created, a unique numerical ID is assigned per PIM domain.  This ID is called PIM MT-ID. PIM MT-ID has the following property,
“- It is the path identifier that is used by PIM control plane, but does not function in the forwarding state for a specific topology.  The differentiation for topologies on forwarding plane is made by different group addresses instead.”

Thanks,
Liu Hui

From: hou [mailto:[email-masked]]
Sent: Tuesday, January 11, 2011 3:30 AM
To: Liuhui; Mike McBride (mmcbride); Yiqun Cai (ycai); [email-masked]
Subject: Re: [pim] draft-ietf-pim-mtid-05 wglc

Liu Hui,

[H2]  Would you please supply some specific text and we will be happy to incorporate.

[H2]  The draft only mentioned protection as one of the possible use cases. On the other hand
[H2]  the PIM protocols doesn’t have the knowledge of applications, we intend to focus on
[H2]  the protocol specification, but vendors are free to implement whatever applications
[H2]  they see fit on top of the specification.

thanks
- Heidi

Thanks,
Liu Hui

[H] As mentioned in the “Introduction”, the main purpose of this

[H] At the end of Section 2, we mention that “The draft does not introduce any
[H] change to the RPF check procedure used to verify the incoming interface
[H] when a packet is forwarded”

thanks
- Heidi

Thanks,
Liu Hui

---

From: hou <[email-masked]>
Date: Tue, 11 Jan 2011 00:06:44 -0800

On 1/10/11 7:30 PM, "Liuhui" <[email-masked]> wrote:

> The draft does not introduce any change to the RPF check procedure used to
> verify the incoming interface when a packet is forwarded. “It uses multiple
> group addresses to identify a unique multicast stream, which requires address
> split and merge to facilitate the address-channel mapping when being applied.
> The detailed processing is beyond the scope of the document.”
> 
> [H3] I think you mean Section 2. Introduction.
> [H3] With slight modification, we will add this:  “As an example to use the
> capability
> [H3] described by this draft, an application can choose to use group
> addresses, and/
> [H3] or source addresses, to identify an unique multicast steam. It might
> further
> [H3] need to perform the functions of splitting and merging. But the detailed
> [H3] processing is beyond the scope of the document”
> 
>  
> For each PIM RPF topology created, a unique numerical ID is assigned per PIM
> domain.  This ID is called PIM MT-ID. PIM MT-ID has the following property,
> “- It is the path identifier that is used by PIM control plane, but does not
> function in the forwarding state for a specific topology.  The differentiation
> for topologies on forwarding plane is made by different group addresses
> instead.”
> 
> [H3] How about the following
> [H3] “- it is the path identifier that is used by PIM control plane, but does
> not 
> [H3] function in the forwarding state for a specific topology.  The
> differentiation for
> [H3] topologies on forwarding plane is made by different group addresses,
> and/or
> [H3] sources addresses instead.”
> 
> [H3]  Thanks again for your comments.
> [H3]  - Heidi
> 
> 
> 
> 
> Thanks,
> Liu Hui
>  
>  
>

---

From: Liuhui <[email-masked]>
Date: Tue, 11 Jan 2011 08:47:30 +0000

Hi Heidi,

I think your revision is all right.

Thanks,
Liu Hui

From: hou [mailto:[email-masked]]
Sent: Tuesday, January 11, 2011 4:07 PM
To: Liuhui; Mike McBride (mmcbride); Yiqun Cai (ycai); [email-masked]
Subject: Re: [pim] draft-ietf-pim-mtid-05 wglc

[H3] I think you mean Section 2. Introduction.
[H3] With slight modification, we will add this:  “As an example to use the capability
[H3] described by this draft, an application can choose to use group addresses, and/
[H3] or source addresses, to identify an unique multicast steam. It might further
[H3] need to perform the functions of splitting and merging. But the detailed
[H3] processing is beyond the scope of the document”

[H3] How about the following
[H3] “- it is the path identifier that is used by PIM control plane, but does not
[H3] function in the forwarding state for a specific topology.  The differentiation for
[H3] topologies on forwarding plane is made by different group addresses, and/or
[H3] sources addresses instead.”

Thanks,
Liu Hui

Liu Hui,

thanks
- Heidi

Thanks,
Liu Hui

thanks
- Heidi

Thanks,
Liu Hui