RE: WG LC: draft-ietf-l3vpn-2547bis-mcast-bgp

["NAPIERALA, MARIA H, ATTLABS" <[e-mail]>]

Yakov,

what functionality does the following paragraph in section 13.2
introduces beyond what is already covered in section 12.3:

"When as a result of receiving a new Source Active A-D route a PE
updates its VRF with the route, the PE MUST check if the newly received
route matches any <C-*, C-G> entries. If (a) there is a matching entry,
(b) the PE does not have (C-S, C-G) state in its MVPN-TIB for (C-S, C-G)
carried in the route, and (c) the received route is selected as the
best(using the BGP route selection procedures), then the PE sets up its
forwarding path to receive (C-S,C-G) traffic from the tunnel the
originator of the selected Source Active A-D route uses for sending
(C-S, C-G)."

Maria

> -----Original Message-----
> From: Yakov Rekhter [mailto:[e-mail]]
> Sent: Monday, December 15, 2008 7:47 PM
> To: NAPIERALA, MARIA H, ATTLABS
> Cc: Danny McPherson; [e-mail]
> Subject: Re: WG LC: draft-ietf-l3vpn-2547bis-mcast-bgp
> 
> Maria,
> 
> [small correction to my previous reply...]
> 
> > Comments on section 13.2:
> >
> >   "When as a result of receiving a new Source Active A-D route a PE
> >    updates its VRF with the route, the PE MUST check if the newly
> >    received route matches any <C-*, C-G> entries. If (a) there is a
> >    matching entry, (b) the PE does not have (C-S, C-G) state in its
> >    MVPN-TIB for (C-S, C-G) carried in the route, and (c) the
received
> >    route is selected as the best(using the BGP route selection
> >    procedures), then the PE sets up its forwarding path to receive
> (C-S,
> >    C-G) traffic from the tunnel the originator of the selected
Source
> >    Active A-D route uses for sending (C-S, C-G)."
> >
> > The condition (b) above excludes the following case: a PE that
> received
> > a Source Active A-D route for (C-S,C-G) has both (C-*, C-G) and
(C-S,
> > C-G) states in its MVPN-TIB (because its locally attached site
> switched
> > to SPT for C-S). If this PE does not join the tunnel used for C-S
> > traffic, this PE will not receive the C-S traffic.
> >
> > Also, the section 13.2 has no procedure for the case when a PE that
> > received a Source Active A-D route for (C-S,C-G) has the (C-S,C-G)
> state
> > but not the (C-*, C-G) state in its MVPN-FIB. This could be the
case,
> > for example, when the PE is attached to (a site with) C-RP but it is
> not
> > directly attached to any (C-*, C-G) receiver sites, except those
> behind
> > the C-RP. This PE will also have to join the tunnel used for C-S
> traffic
> > to deliver traffic to those receivers.
> 
> The current spec allows (C-S, C-G) to be carried either on I-PMSI or
S-
> PMSI.
> 
> When (C-S, C-G) is carried on I-PMSI the PE joins the tunnel(s) used
by
> I-PMSI at provisioning time, and therefore does not need to join
> any I-PMSI tunnel(s) when it receives a Source Active A-D route.
> 
> When (C-S, C-G) is carried over an S-PMSI text in 12.3 covers the
issue
> of joining the tunnel.
> 
> So, the current spec already addresses your comment wrt joining
> the tunnel.
> 
> Yakov.
> 
> >
> >
> > Maria
> >
> > > -----Original Message-----
> > > From: [e-mail] [mailto:[e-mail]] On
> Behalf
> > > Of Danny McPherson
> > > Sent: Friday, November 21, 2008 8:52 AM
> > > To: [e-mail]
> > > Subject: WG LC: draft-ietf-l3vpn-2547bis-mcast-bgp
> > >
> > >
> > > Please consider today the start of a 2-week last call
> > > for draft-ietf-l3vpn-2547bis-mcast-bgp, available here:
> > >
> > > http://tools.ietf.org/html/draft-ietf-l3vpn-2547bis-mcast-bgp-05
> > >
> > > Input on this draft's suitability for publication as an
> > > Internet Standards Track document is solicited, feedback
> > > ends December 9, 2008.
> > >
> > > Thanks in advance for your feedback!
> > >
> > > Danny & Marshall
> >