Subject: [pim] WGLC on draft-ietf-pim-explicit-rpf-vector-00

From: Mike McBride <[email-masked]>
Date: Mon, 10 Jun 2013 23:27:11 -0700

This is a recently adopted draft and the authors feel it is now ready
for progression. Its a short draft so we likely don't have a good
excuse to not read it over the next week. And then please express an
opinion on this drafts readiness for being sent to the IESG as an
Informational RFC:

http://www.ietf.org/id/draft-ietf-pim-explicit-rpf-vector-00.txt

We will end this WGLC on June 24th. Please speak up before then.

thanks,
mike

---

From: William Atwood <[email-masked]>
Date: Tue, 11 Jun 2013 14:40:02 -0400

Question:

Is this document really "Informational"?  It defines new protocol pieces
and their semantics, and it requires IANA action.  This sounds to me as
if it should be standards track...

  Bill

On 11/06/2013 2:27 AM, Mike McBride wrote:
> _______________________________________________
> pim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pim
> 

-- 
Dr. J.W. Atwood, Eng.             tel:   +1 (514) 848-2424 x3046
Distinguished Professor Emeritus  fax:   +1 (514) 848-2830
Department of Computer Science
   and Software Engineering
Concordia University EV 3.185     email:[email-masked]
1455 de Maisonneuve Blvd. West    http://users.encs.concordia.ca/~bill
Montreal, Quebec Canada H3G 1M8

---

From: Stig Venaas <[email-masked]>
Date: Tue, 11 Jun 2013 19:30:09 -0700

Hi

> if it should be standards track...

I'm not sure if I see much need for this to be standards track. The
solution has some shortcomings, and we may find better ways in the
future to achieve what this attribute is trying to do. Also, when the
WG decided to adopt the draft, it assumed to be Informational. This
can certainly be changed if the WG wants though.

Another question is whether this should be informational or 
experimental. It's not very clear to me, but after reading
http://www.ietf.org/iesg/informational-vs-experimental.html
I think informational is appropriate.

I don't have a strong opinion though, and great if others in the
WG can also state their opinion. I recommend reading the doc I
linked to first though.

Stig

---

From: Stig Venaas <[email-masked]>
Date: Wed, 12 Jun 2013 10:10:47 -0700

> if it should be standards track...

Just want to add a comment regarding the IANA action. In this case it
is OK to not be Standards Track because the registry requires "IETF
Review". It does not require "Standards Action". These terms are
explained in RFC 5226.

Stig

---

From: Michael McBride <[email-masked]>
Date: Tue, 25 Jun 2013 06:37:29 +0000

The wglc has ended and we have received solid consensus to progress this draft. Thank you for your responses. The authors have addressed the wglc comments in an updated draft which we will be sending to Adrian and the iesg folks: http://www.ietf.org/id/draft-ietf-pim-explicit-rpf-vector-01.txt 

Bharat, please make sure this updated draft addresses your comments. We will send to Adrian this Friday.

Thanks,
mike

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Mike McBride
> Sent: Monday, June 10, 2013 11:27 PM
> To: [email-masked]
> Subject: [pim] WGLC on draft-ietf-pim-explicit-rpf-vector-00
>

---

From: Bharat Joshi <[email-masked]>
Date: Tue, 25 Jun 2013 08:06:24 +0000

Mike and Authors,

         I read through the draft. I have some more questions/suggestions on this.

         I hope this helps.

Regards,
Bharat

• In section 7, "from the first Explicit vector in the stack" -> "from the topmost Explicit vector in the stack"

• A small typo in "The Metric will therefore not be a tie breaker in the PIM Assert", it should use "not to be a tie"

• In section 7, in following statement:

However, the first Explicit vector should always be directly connected, so the Metric will be zero.

     I think it is not correct to assume that directly connected route's has a metric of zero. IIRC, some vendors provide means to configure such a metric.

• In section 9, "support the Explicit Vector MUST never" -> "support the Explicit Vector attribute MUST never"

• In section 9, in following statement:

Routers that don't support the Explicit Vector MUST never forward the vector to their upstream PIM neighbor. 

     With above statement, its not clear if the attribute should not be forwarded or the PIM join itself should not be forwarded upstream. A PIM join can still be forwarded using normal means if required.

• Will things work if both Explicit RPF vector and normal RPF vector attributes are available in a PIM join? Or should we say that they cannot be used together?

• If the above is possible, can someone support a PIM join with first few explicit RPF vector attributes, then a normal RPF vector and then again few explicit RPF vector? Such a thing may be required if the customer is using a VPN and want to create the tree in his local network as well as remote network based on his own requirements. I am not sure if such a requirement exists or not. I am just checking if such a flexibility is allowed.

• In section 12, "RPF Vector Attribute" -> "Explicit RPF Vector Attribute"

• In security consideration, should not we also mention that Explicit RPF Vector Attribute itself does not add any security implications on PIM-SM functioning.

• In section 5, I think following sentence should be reword:

This draft uses vector attribute 4 for specifying an explicit RPF vector.

to

This draft uses PIM Join attribute type 4 for specifying an Explicit RPF Vector Attribute.

________________________________________
From: [email-masked] [[email-masked]] on behalf of Michael McBride [[email-masked]]
Sent: Tuesday, June 25, 2013 12:07 PM
To: Mike McBride; [email-masked]
Subject: Re: [pim] WGLC on draft-ietf-pim-explicit-rpf-vector-00

Thanks,
mike

**************** 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: Wed, 26 Jun 2013 10:14:32 -0700

>           I read through the draft. I have some more questions/suggestions on this.

I read it once more too and suggested some editorial changes. I would
like to see how those are addressed as well. I should probably have
sent the comments to the list. I'll send comments on the next revision
to the list if I think any additional changes should be made.

Stig

---

From: IJsbrand Wijnands <[email-masked]>
Date: Sat, 29 Jun 2013 09:11:37 +0200

Hi Bharat,

Thanks for the comments, see comments inline;

> • In section 7, "from the first Explicit vector in the stack" -> "from the topmost Explicit vector in the stack"

Ice: Ok.

> • A small typo in "The Metric will therefore not be a tie breaker in the PIM Assert", it should use "not to be a tie"

Ice: Your suggestion does not read to well IMO.

>     I think it is not correct to assume that directly connected route's has a metric of zero. IIRC, some vendors provide means to configure such a metric.

Ice: We can change 'will' into 'may likely'.

> • In section 9, "support the Explicit Vector MUST never" -> "support the Explicit Vector attribute MUST never"

Ice: The draft is about documenting 'Explicit Vector' as a new PIM attribute. Is it not obvious that if we talk about 'Explicit Vector', this is an attribute?

>     With above statement, its not clear if the attribute should not be forwarded or the PIM join itself should not be forwarded upstream. A PIM join can still be forwarded using normal means if req…

Ice: We can clarify, a normal PIM join is allowed.

> • Will things work if both Explicit RPF vector and normal RPF vector attributes are available in a PIM join? Or should we say that they cannot be used together?

Ice: Nothing prevents that.

> • If the above is possible, can someone support a PIM join with first few explicit RPF vector attributes, then a normal RPF vector and then again few explicit RPF vector? Such a thing may be requir…

Ice: Yes.

> • In security consideration, should not we also mention that Explicit RPF Vector Attribute itself does not add any security implications on PIM-SM functioning.

Ice: Does -01 not already address this?

> This draft uses PIM Join attribute type 4 for specifying an Explicit RPF Vector Attribute.

Ice: Ok.

Thx,

Ice.

---

From: Bharat Joshi <[email-masked]>
Date: Mon, 1 Jul 2013 03:58:25 +0000

Hi,

       Please see few replies in line with <Bharat>.

Regards,
Bharat

<Bharat>: Ok. Will leave this to authors.

<Bharat>: That may not solve the problem. My thinking is that we should allow it to compare metrics as it is. If they are same, they will anyway fallback on the other parameters like IP address. So why to add a special case here?

<Bharat>: While I agree that it is obvious but my thinking is that it is better to be consistent across. I suggested this because most of the places this draft uses 'Attribute' as well.

<Bharat>: Ok.

<Bharat>: I think it is better to clarify this in the document. This will help an implementor as well as a reader.

Ice: Yes.

<Bharat>: Ok.

> • In section 12, "RPF Vector Attribute" -> "Explicit RPF Vector Attribute"

<Bharat>: I am assuming that this one will be taken care of.

<Bharat>: It is mentioned but not from this new attribute perspective, please relook at that text.