Subject: [pim] adoption call for draft-venaas-pim-hierarchicaljoinattr-00

From: Mike McBride <[email-masked]>
Date: Sun, 14 Jul 2013 00:24:06 -0700

Today begins a call for adoption of:
http://www.ietf.org/id/draft-venaas-pim-hierarchicaljoinattr-00.txt.
This draft was presented in Orlando where 3 were in favor, of working
on this within the wg, and none against.

Please read this short draft and provide an opinion on the list before
we meet in Berlin.

thanks,
mike

---

From: Bharat Joshi <[email-masked]>
Date: Fri, 19 Jul 2013 10:06:10 +0000

Hi Mike,

      I just read through this draft.

      I agree with the problem this draft is trying to solve in theory so I support its adoption. However I have few questions/suggestions on this draft:

• A nicely written draft.

• It would be great if we can add an example of how this will be used for one of the existing join attribute or if there is any other use case for this.

• In section 3, "using the encoding in Section 4" -> "using the encoding defined in Section 4"

• "message with Join/Prune attributes encoded" -> "message with Hierarchical Join/Prune attributes encoded"

• I think this draft should also point out how the existing join attribute will use this and how some of the functions like join suppression will be handled if the attribute uses this hierarchical join/prune attribute. For example, if a join has RPF vector attribute at group-set level as well as source level. Now if another router sees this join, should it suppress its join even if it uses a different value in RPF vector attribute at group set but same RPF vector at source level?

Regards,
Bharat
________________________________________
From: [email-masked] [[email-masked]] on behalf of Mike McBride [[email-masked]]
Sent: Sunday, July 14, 2013 12:54 PM
To: [email-masked]
Subject: [pim] adoption call for draft-venaas-pim-hierarchicaljoinattr-00

thanks,
mike
_______________________________________________
pim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pim

**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely 
for the use of the addressee(s). If you are not the intended recipient, please 
notify the sender by e-mail and delete the original message. Further, you are not 
to copy, disclose, or distribute this e-mail or its contents to any other person and 
any such actions are unlawful. This e-mail may contain viruses. Infosys has taken 
every reasonable precaution to minimize this risk, but is not liable for any damage 
you may sustain as a result of any virus in this e-mail. You should carry out your 
own virus checks before opening the e-mail or attachment. Infosys reserves the 
right to monitor and review the content of all messages sent to or from this e-mail 
address. Messages sent to or from this e-mail address may be stored on the 
Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***

---

From: Stig Venaas <[email-masked]>
Date: Tue, 23 Jul 2013 10:24:45 -0700

Hi

> • A nicely written draft.

Thanks.

> • It would be great if we can add an example of how this will be used for one of the existing join attribute or if there is any other use case for this.

There is another draft defining a new attribute related to lisp and I
might point to that if we decide to work on that. Otherwise I'll
consider it with an existing attribute.

> • In section 3, "using the encoding in Section 4" -> "using the encoding defined in Section 4"

Agree.

> • "message with Join/Prune attributes encoded" -> "message with Hierarchical Join/Prune attributes encoded"

Need to check, but probably correct.

> • I think this draft should also point out how the existing join attribute will use this and how some of the functions like join suppression will be handled if the attribute uses this hierarchical…

My thinking here is that it is just a more efficient encoding. The
attributes are still per (S,G). So if say an attribute is encoded
in the upstream neighbor field so that it applies to the entire
message, then it is the same as if it is encoded in every single
source address field in the message.

My thinking is that to really compare say two (S,G)-joins (there
may be multiple joins in the message, so just talking about one
individual join) and see if they have the same attributes, you
would first need to basically decode and apply the hierarchical
attributes. This decoding also has to be done when the router
processes a join from a single router too though.

In short, I'm trying not to change the semantics of any attribute,
all I'm trying is to find a more efficient way to encode them. We
have at least one case (one of the proposed LISP attributes) where
we expect to have the same attribute (and value) for every single
(S,G), and we think it makes sense to only add it once to the
message.

Alternatively, we could come up with a different attribute space
and different semantics and say that we have group and message
attributes in addition to what we have now. But I think it is
sufficient to use the existing semantics.

Thanks for the comments,

Stig

---

From: Bharat Joshi <[email-masked]>
Date: Wed, 24 Jul 2013 08:20:23 +0000

Hi Stig,

      Thanks for your reply. Please see my replies in line.

Regards,
Bharat

> > • It would be great if we can add an example of how this will be used
> for one of the existing join attribute or if there is any other use case
> for this.
> 

Ok.

> > • I think this draft should also point out how the existing join
> attribute will use this and how some of the functions like join
> suppression will be handled if the attribute uses this hierarchical
> join/prune attribute. For example, if a join has RPF vector attribute at
> group-set level as well as source level. Now if another router sees this
> join, should it suppress its join even if it uses a different value in
> RPF vector attribute at group set but same RPF vector at source level?
> 

Ok.

> processes a join from a single router too though.

I agree that for individual joins, you would need to parse through the whole message.
 
> (S,G), and we think it makes sense to only add it once to the

Ok.
 
> sufficient to use the existing semantics.

Ok.

What I was trying to point out is that implementors might need some kind of guidence on how to handle 'Join suppression', 'Unsupported attributes' etc. with this scheme. I am not sure whether this draft is the right place or not.

---

From: Stig Venaas <[email-masked]>
Date: Wed, 24 Jul 2013 10:41:01 -0700

On 7/24/2013 1:20 AM, Bharat Joshi wrote:
[...]
> What I was trying to point out is that implementors might need some kind of guidence on how to handle 'Join suppression', 'Unsupported attributes' etc. with this scheme. I am not sure whether this…

Right. There are some things that are not really explained in the
original join attributes draft. Part of what I'm doing in this draft
is to rectify that. Among other things the registry. One thing worth
discussing is join suppression. I think the correct is to only suppress
a join if the attributes (and values) are exactly the same.

Stig