Subject: draft-ietf-l3vpn-2547bis-mcast-08

From: Eric Rosen <[email-masked]>
Date: Thu, 05 Mar 2009 11:42:04 -0500

I have posted a new version of  this draft, which has a few modifications in
response to  the LC comments.   Following is a  summary of the  comments and
modifications (or not made) made in response.  

>From Thomas Morin:

>       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.

Section  7.1 ("General  Considerations when  Switching P-tunnels")  has been
reworked to make it clearer how a PE  needs to act when it decides to bind a
C-flow to a  particular P-tunnel, and how  a PE needs to act  when it learns
that some  other PE has bound a  C-flow to a particular  P-tunnel.  There is
text in section 7.1.2 to address  the specific case of ensuring that the PIM
Assert mechanism works properly.

>From Thomas Morin:  

>     section 9.1, first paragraph,  indicates that a dataplane check has
>     to be made, but:
>
>     - the level of requirement for this dataplane check is vague ("will
>       check") and text in other section imply that it is not
>       necessarily in use (it is indeed exact that there are cases where
>       the check is not strictly needed)

>   I would suggest clearer wording in section 9.1 about if the dataplane
>   check is a MUST, SHOULD or MAY ;

Section 9 has been reworked to  make it clear that there are three different
procedures that can  be used for preventing duplicates (one  of which is the
dataplane check),  and that any  given MPVN must  use at least one  of them.
The need for  the dataplane check is dependent on  what other procedures you
are using.

>   - the check as currently described, may not be compatible with
>     Extranet

If so, this will be dealt with in any forthcoming draft about Extranet.

>     what happens (what work/what breaks, side effects) 

The existing material seems satisfactory.

>   if PIM Asserts have to be implemented for the MI-PMSI Lan Interface

PIM is specified  in RFC 4601. Any necessary modifications  to PIM (e.g., to
enable it to work between PEs  when there are no unicast routing adjacencies
between PEs) are specified in section 5 of the MVPN architecture document.

>   check in 9.1 is REQUIRED to allow the use of algorithms that do not
>   guarantee selection of a same UMH by two distincts PEs

Section 5.1.3 already  points out that if different  UMH's are selected, you
can  get  steady  state duplication  of  traffic  if  you don't  follow  the
procedures of section 9.

Xu Xiaohui  has pointed out a  problem that occurs  under certain conditions
when  using ingress replication  through unicast  P-tunnels, if  the unicast
P-tunnels are instantiated as LSPs on which penultimate-hop-popping is done.
Text has been added to section 6.4.5 ("Ingress Replication") cautioning that
certain combinations of options will not work if such P-tunnels are used.  

Thomas Morin raised a question about the text in the Security Considerations
section re  UDP-based S-PMSI Join Messages.   This text has  been revised to
state that UDP messages with  IP destination address ALL-PIM-ROUTERs and UDP
destination  port  3232  are  to  be  discarded when  received  over  a  VRF
interface.  Also,  text has  been added to  section 7.4.2.1 to  clarify that
these messages are only legal when received over a PMSI.

Thomas  Morin  suggested that  additional  text  be  added to  the  Security
Considerations section on the subject of resource protection.  Text has been
added.  

Text  has also  been  added to  Security  Considerations cautioning  against
receiving MCAST-VPN NLRI or VRF Route Import Attributes from a CE.

Venu Hemige  and Mark  Fine raised an  issue against  section 13 of  the BGP
spec, and Mark raised the same issue against section 9.1 of the architecture
spec.  Actually, I believe he meant section 9.2 (which is section 9.3 in the
latest revision).

Section 9 has been reworked to increase clarity in this area.