Subject: [pim] I-D Action: draft-ietf-pim-hierarchicaljoinattr-00.txt

From: [email-masked]
Date: Tue, 08 Oct 2013 15:18:03 -0700

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           : Hierarchical Join/Prune Attributes
	Author(s)       : Stig Venaas
                          Isidor Kouvelas
                          Jesus Arango
	Filename        : draft-ietf-pim-hierarchicaljoinattr-00.txt
	Pages           : 7
	Date            : 2013-10-03

Abstract:
   This document defines a hierachical method of encoding Join
   attributes, providing a more efficient encoding when the same
   attribute values need to be specified for multiple sources in a PIM
   Join/Prune message.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-pim-hierarchicaljoinattr

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-pim-hierarchicaljoinattr-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Kollipara, Siva (Siva)" <[email-masked]>
Date: Thu, 10 Oct 2013 16:13:03 +0000

Offline discussions on this draft: (for the benefit of others)

---

On 10/9/2013 9:29 AM, Kollipara, Siva (Siva) wrote:
> Hi Stig,
>
> Thanks for the response. Your plan sounds good. I believe your plan is in line with the optional idea I mentioned. I thought about the following points with this idea:
>
> 1) If G specifies a "Don't-Inherit-Attrib", does that mean S can still inherit that attribute from UN or that UN attribute is totally invisible to S?

I think the meaning should simply be not to inherit the attribute, so it should be as if it was not specified higher up in the hierarchy. So if Don't Inherit is present in G specifying that attribute A should not be inherited, then if UN has attribute A, then that A should not apply to G and below. It is blocking A from being inherited down the tree to G and below.

Note that sources below G could have attribute A specified still if needed (but it's not inherited). Also attribute A could be present for G, but then there is no point in Don't Inherit since it would override the attribute A if present in UN.

> 2) if S specified a "Don't-inherit-attrib", does that apply to not inheriting from G or from UN or both?

If attribute A is specified in G, then that A is inherited for the sources S (independent of whether A is present (or not) with some value in UN). If A is present only in UN, then it is inherited down. It does not matter how it is inherited by S, if Don't Inherit is specified for attribute A, then it is simply not inherited.

> A bitmask specifying the following:
> - don't inherit from G
> - don't inherit from UN
> This allows the S to not inherit from both or one of them specifically 
> (the case of bypass G and inherit from UN being the useful case). The 
> same mask can also be used at G level to prevent it from inheriting 
> from UN (although the G bit is don't-care)
>
> I see the flexibility in saying that "once G un-inherits an attribute, S doesn't see that attribute at all", but I also flexibility in allowing that to happen.
>
> Thoughts?

I think this is too complicated. I think all we need is to basically clear the attribute for an S or G. Attributes specified for G apply to all sources for G, so if you clear it for G, then I think it should also be cleared for all sources. If no sources under G should have it, just clear it for G (by using Don't Inherit for G). If most of the sources should have the attribute, then you can clear it for the few sources that should not have it. If most of the sources should not have the attribute, you can clear it for G, and then set the attribute again for the few sources that should have it.

Don't you think this is sufficient? It is a bit hard to explain this I think, not sure whether I'm able to convey my idea well. I'll try to think of a good way to describe it in the draft, as it is important that the idea is clear.

> I hope it is ok that I am brainstorming with you on this topic.

Sure, but good if you can comment on the mailing list actually. The discussion should be of interest in the pim wg in general.

Stig

> Regards,
> Siva
>
>> -----Original Message-----
>> From: Stig Venaas [mailto:[email-masked]]
>> Sent: Tuesday, October 08, 2013 5:58 PM
>> To: [email-masked]
>> Cc: [email-masked]; [email-masked]
>> Subject: Re: draft-ietf-pim-hierarchicaljoinattr-00.txt comments
>>
>> Hi Siva
>>
>> On 08.10.2013 17:11, Kollipara, Siva (Siva) wrote:
>>> Hi Stig, Isidor, Jesus
>>>
>>> Nice optimization. I wanted to point out the following case, and it
>> would be beneficial to include it in the draft as well.
>>>
>>> The draft suggested the following:
>>>
>>> UNAddr [UN-JPAttribute]
>>> |
>>> |-G1 [G1-JPAttribute]
>>> |  |
>>> |  |-S1 [S1-JPAttribute]
>>> |  |-S2
>>> |
>>> |-G2
>>> |  |-S3
>>> |  |-S4
>>>
>>> In the above example: S2 inherits G1-JPAttribute and S3/S4 inherit
>> UN-JPAttribute.
>>>
>>> One of the impact of this is that if previously, let's say S2 didn't
>> need a JP attribute, then with hierarchical JP attributes (S2,G1) 
>> will have to sent in a separate JP message. In essence, only those 
>> SGs that require an base common set of JP attributes can be bunched 
>> in the same JP message. What previously could've been sent as 1 JP 
>> message may now have to split into multiple JP messages. For example: 
>> if all SGs except one doesn't require/use particular JP attribute, 
>> then its best to separate the SG into another JP message. Ofcourse, 
>> the implementation can choose to use regular JP Attributes despite 
>> over hierarchical JP attributes.
>>>
>>> Optionally, we could also indicate that a SG *should not* inherit an
>> attribute from G/UN. Although, I presume that complicates things 
>> further.
>>>
>>> Please let me know your thoughts.
>>
>> Thanks, I'm planning to do this actually. I've been thinking about a 
>> couple of ways of doing this and will add it to the next draft 
>> revision.
>> Then we'll see next IETF whether people are OK with the additional 
>> flexibility/complexity.
>>
>> I think what I would do is a new attribute type that can contain 
>> types to remove. Like a don't inherit attribute where the value is a 
>> list of attribute types to not inherit. You could put it into say S3 
>> so that it is not inherited just for S3. Or if you put it in say G2 
>> you could prevent inheriting for all under G2...
>>
>> Stig
>>
>>> Regards,
>>> Siva
>>>
>>>>
>>>> -----Original Message-----
>>>> From: [email-masked] [mailto:[email-masked]] On Behalf
>> Of
>>>> [email-masked]
>>>> Sent: Tuesday, October 08, 2013 3:18 PM
>>>> To: [email-masked]
>>>> Cc: [email-masked]
>>>> Subject: [pim] I-D Action: draft-ietf-pim-hierarchicaljoinattr-
>> 00.txt
>>>>
>>>>
>>>>      attribute values need to be specified for multiple sources in 
>>>> a
>> PIM
>>>>      Join/Prune message.
>>>>
>>>>
>>>> Please note that it may take a couple of minutes from the time of 
>>>> submission until the htmlized version and diff are available at 
>>>> tools.ietf.org.
>>>>
>>>> _______________________________________________
>>>> pim mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/pim