Subject: [pim] Questions regarding draft-rosen-vpn-mcast-05.txt

From: Suresh Boddapati <[email-masked]>
Date: Tue, 9 Sep 2003 10:26:03 -0700 (PDT)

I am a little confused with the statements in Section
2. 
 
a)In section 2.1, it says 
"Each PE router also runs a provider-wide instance of
PIM-SM, in which it has a PIM adjacency with each of
its IGMP neighbors (i.e., with P routers), but NOT
with any CE routers, and not with other PE routers
(unless they happen to be adjacent in the SP's
network)".
 
b)Further in section 2.2, it says
"For each MD, a Multicast Tunnel (MT) is created in
the provider-wide PIM instance, using ordinary PIM-SM
techniques. The various PEs in the MD discover each
other by joining the shared tree rooted at the RP". 
How does one PE discover another PE just because it
joins a shared tree rooted at the RP (a third PE)?
 
c)Finally, in section 2.3, it says
"If a particular VRF is in a particular MD, the
corresponding MT is treated by that VRF's VPN-specific
PIM instances as a LAN interface. The PEs which are
adjacent on the MT must execute the PIM LAN
procedures, including the generation and processing of
Assert packets".
 
>From (b) and (c), it seems like the PEs form
adjacencies over the MT for a given MD. Is this
correct? Do they send Hellos over the MT encapsulated
by the MD's group address?Although, it seems to be in
direct contradiction with (a) above wherein it
explicitly states that the PEs do not form adjacencies
with other PEs. 
 
Can someone clarify? Thanks in advance.
 
Suresh

_______________________________________________
pim mailing list
[email-masked]
http://catarina.usc.edu/mailman/listinfo/pim

---

From: Yiqun Cai <[email-masked]>
Date: Tue, 9 Sep 2003 11:07:29 -0700 (PDT)

> correct? 

Yes.

> Do they send Hellos over the MT encapsulated
> by the MD's group address?

Yes.

> Although, it seems to be in

No it doesn't.  Because a) describes the behavior of an instance of
PIM running in the context of the global table (or SP's network) while
b) and c) describe the behavior of PIM running in an MD.

-- 
Yiqun

---

From: Suresh Boddapati <[email-masked]>
Date: Tue, 9 Sep 2003 11:35:53 -0700 (PDT)

Thanks for the quick reply. It would be clearer IMO, 
if the draft explicitly stated somewhere saying 
" the PEs discover each other by sending encapsulated
Hellos to the MD's group address and form adjacencies
with each other within that MD". Discovering each
other by joining the shared tree rooted at the RP, as
the spec states does not convey the same idea.

Also, is this the best way to do this? As far as the
PEs go, they need to know about the existence of each
other and the MDs they represent. Why do they have to
form adjacencies for each MD? Would it not be better
if they just formed an adjacency in the provider wide
instance and learned through, say a new message
similar to the BSM, the MD memberships of each PE.
Otherwise, the number of adjacencies in a given PE can
get in the order of 1000s (imagine a simple scenario
with 8 PEs and 1000 VRFs ==> 7000 adjacencies), which
seems a bit unnecessary. Comments?

Suresh

---

From: Yiqun Cai <[email-masked]>
Date: Tue, 9 Sep 2003 17:55:24 -0700 (PDT)

> the spec states does not convey the same idea.

Thanks for the suggestion.  We will look at when we rev the draft
next time.

> similar to the BSM, the MD memberships of each PE.

But you still form adjacencies in this way.  The only difference is
that you replace the encapsulated Hello's with this new message.  The
amount of information each PE router processes is the same w.r.t the
number of PE routers and MDs.  

> seems a bit unnecessary. Comments?

If there are 8 PEs and each PE has 1000 VRFs, on each PE, within each
VRF, it keeps track of 7 other PEs.  

It is a lot of amount of information.  But the overlay model which
caused this much information to be kept on the PE routers, allows the
core to keep smaller states.

---

From: Suresh Boddapati <[email-masked]>
Date: Wed, 10 Sep 2003 09:15:53 -0700 (PDT)

> number of PE routers and MDs. 

But the number of control packets is reduced by an
order of magnitude. The customer's control and data
packets and the PE's control packets are all using the
same MT. All of this compounded with the fact that
there are several MTs and the aggregate traffic of all
these MTs is what is going through the P routers to
the PE routers. Instead of 1000 hellos going out from
each PE for 1000 VRFs, there would be far fewer
messages going from each PE listing its MD membership
(2-3 messages to account for 1000 group addresses,
still an order of 1000 difference). Of course, the
information at the PE remains the same, but the
information is obtained at a much lower cost. The
point is scaling I guess. Now I am  not saying it
cannot be done with adjacencies per MD. Of course, you
can tweak hello timers and hold timers to make sure
that adjacencies do not time out, but is this the best
way? An almost similar analogy to this would be to
have BGP peerings per VRF in 2547. Why, when it can be
achieved with just one peering?
 
> core to keep smaller states.

The core still keeps smaller state. Just to make sure
we are on the same page, what I am suggesting is that
the PEs form adjacencies with each other using only
one well known MD, call it the Control MD or Admin MD
and then distribute the information regarding their MD
membership using new messages, instead of forming
adjacencies with each other for each MD. The core does
not even know about the existence of this new message
and maintains the same state as the draft solution
does. Nothing changes from the P point of view.

Suresh

---

From: Yiqun Cai <[email-masked]>
Date: Thu, 11 Sep 2003 00:18:21 -0700 (PDT)

If you have 1000 PEs but each PE has only a handful of VRFs, which is
a more likely scenario these days, the saving is less significant.

You have a good point,  but there is always a trade-off among
1) reduce (periodic) control traffic
2) reduce PIM adjacency
3) avoid upgrading the core routers when rolling out new edge services

> one well known MD, call it the Control MD or Admin MD

If you do that,  you would have to modify PIM join/prune messages
as well to encode MD/VRF information.  This is not the goal.

If we can do without a whole lot of change to the PIM protocol itself,
and try to leverage whatever scaling improvement PIM protocol will
bring us in the future as it evolves,  wouldn't that be better?

---

From: Suresh Boddapati <[email-masked]>
Date: Thu, 11 Sep 2003 17:55:48 -0700 (PDT)

> a more likely scenario these days, the saving is

What seems unlikely today tends to become reality
tomorrow. I am sure you would agree that we should not
design for a specific scenario. 2547 VPNs are just
cooking; once they become well deployed and popular
(if they do), then you never know how they are going
to use them.

> 3) avoid upgrading the core routers when rolling out
I agree there is a tradeoff between 1 and 2. In the
context we are talking, 3 is not a problem with either
solution.

> as well to encode MD/VRF information.  This is not
No, you do not have to modify Join/Prune messages. My
scheme of forming adjacency using a well known MD is
just to get the MD membership information. So let's
say X is that well known group address for the Control
MD. All the PEs send their encapsulated hellos to this
group address X, which for a core router is just
multicast traffic. The PEs form adjacency with each
other for this MD. They use a new message to
distribute their MD membership information, which
essentially says, "I am PE1 and I have MDs 1 through
4". If PE2 wants to send a Join to MD 1 to PE1, PE2
will check if PE1 has membership in MD1 and since it
does, will send the encapsulated Join to the MD1 group
address, just like the draft says. So there is no need
to encode any MD VRF information in the Join message. 

> bring us in the future as it evolves,  wouldn't that
Point taken. The scheme that I am proposing adheres to
this point. There is not a whole lot of change we are
talking here. Just a new message type. Whatever
scaling improvements PIM will bring in the future will
not take away the fact that there are still 1000s of
PIM instances that need to scale and if we can get
better scaling with a small change, may be worth
looking at it. If the authors feel not, that's fine
too. At least we had a good discussion.  

Suresh