re: Identifying an ingress PE in ingress replication approach//re: WG LC:draft-ietf-l3vpn-2547bis-mcast

[Xu Xiaohu <[e-mail]>]

Hi All,

Sorry for confusing you since I mistaked MP2MP for MP2P.  What I said in the
previous email is just related to ingress replication through unicast
tunnel.

Xiaohu

> -----邮件原件-----
> 发件人: [e-mail] [mailto:[e-mail]] 
> 代表 Xu Xiaohu
> 发送时间: 2008年12月5日 9:52
> 收件人: 'L3VPN'; 'Eric Rosen'; 'Rahul Aggarwal'
> 主题: Identifying an ingress PE in ingress replication 
> approach//re: WG LC:draft-ietf-l3vpn-2547bis-mcast
> 
> Hi all,
> 
> Three years ago, there were still some doubts about whether 
> there is a need for the inner label to identify the ingress 
> PE ( see the following threads ).  Now in latest version of 
> draft-ietf-l3vpn-2547bis-mcast, there is already some 
> corresponding mechanism to addres this issue, that is  "it 
> MUST carry, as its second label, a label which has been bound 
> to the packet's ingress PE. This label is an 
> upstream-assigned label that the LSP's root node has bound to 
> the ingress PE and has distributed via an A-D Route ".  
> 
> Using an upstream-assigned label to identify the ingress PE 
> is not a bad idea. However, we can still use one 
> downstream-assigned label (simpler in both control plane and 
> data plane) to identify both the MVRF instance and the 
> ingress PE. Just like the usage of the PW label, the egress 
> PE can assign different labels for the same mVRF to different 
> PE neighbors. Any comments?
> 
> =====================================================
> 11.3. Encapsulations Identifying a Distinguished PE
> 
> 11.3.1. For MP2MP LSP P-tunnels
> 
>    As discussed in section 9, if a multicast data packet belongs to a
>    Sparse Mode or Single Source Mode multicast group, it is highly
>    desirable for the PE that receives the packet from a PMSI 
> to be able
>    to determine the identity of the PE that transmitted the 
> data packet
>    onto the PMSI.  The encapsulations of the previous sections all
>    provide this information, except in one case.  If a PMSI is being
>    instantiated by a MP2MP LSP, then the encapsulations 
> discussed so far
>    do not allow one to determine the identity of the PE that 
> transmitted
>    the packet onto the PMSI.
> 
>    Therefore, when a packet that belongs to a Sparse Mode or Single
>    Source Mode multicast group is traveling on a MP2MP LSP 
> P-tunnel, it
>    MUST carry, as its second label, a label which has been 
> bound to the
>    packet's ingress PE.  This label is an upstream-assigned label that
>    the LSP's root node has bound to the ingress PE and has distributed
>    via an A-D Route (see section 4; precise details of this 
> distribution
>    procedure will be included in the next revision of this document).
>    This label will appear immediately beneath the labels that are
>    discussed in sections 11.1.3 and 11.2.
> ======================================================
> 
> 
> http://www.ietf.org/mail-archive/web/l3vpn/current/msg01369.html
> 
> http://www.ietf.org/proceedings/05nov/slides/l3vpn-1/l3vpn-1.ppt 
> 
> 
> Xiaohu
> 
> > -----邮件原件-----
> > 发件人: [e-mail] [mailto:[e-mail]]
> > 代表 Thomas Morin
> > 发送时间: 2008年12月4日 18:48
> > 收件人: L3VPN; Eric Rosen; Rahul Aggarwal
> > 主题: Re: WG LC: draft-ietf-l3vpn-2547bis-mcast
> > 
> > Hello,
> > 
> > It occurred to me that if/when the PIM assert mechanism is used on 
> > PMSI tunnels, then there is a small issue related to 
> S-PMSIs that does 
> > not seem to be addressed in current specifications : when two PEs 
> > happen to send traffic for a same (S,G) on a P-tunnel, at 
> least one of 
> > the PEs needs to receive the packets sent by the other PE 
> or the PIM 
> > Assert mechanism won't get triggered. But if we are in a situation 
> > where the two PEs have bound an (S,G) to an S-PMSI, then nothing 
> > guarantees that one of them will see the packets from the other.
> > 
> > I would see different ways to resolve this (there might be others):
> > * impose that PEs join all S-PMSI tunnels for (C-S,C-G) as soon as 
> > they have VRF PIM state for (C-S,C-G), *even* if the RPF 
> interface is 
> > not the MI-PMSI or such an S-PMSI  -- that way we can be 
> sure that the 
> > PIM Assert mechanism will trigger
> > * or, impose that, when there are multiple S-PMSI signalled 
> for a said 
> > (C-S,C-G), a said PE with state for (C-S,C-G) does not join 
> more than 
> > one of them -- that way even though the PIM assert doesn't 
> trigger, we 
> > avoid duplicates being forwarded down to the CEs
> > * (or, make it clear that the upstream dataplane check is mandatory 
> > and that the PIM Asserts mechanism is not used on the MI-PMSI)
> > * (or, don't use S-PMSIs when their are dual-homed sources and 
> > PIM-based C-multicast routing is used)
> > 
> > (the above does not apply if BGP-based C-multicast routing is used)
> > 
> > Thank you,
> > 
> > -Thomas
> > 
> > 
> > Danny McPherson :
> > > 
> > > Please consider today the start of a 2-week last call for 
> > > draft-ietf-l3vpn-2547bis-mcast, available here:
> > > 
> > > http://tools.ietf.org/html/draft-ietf-l3vpn-2547bis-mcast-07
> > > 
> > > 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
> > 
> > 
> 
> 
>