Re: L2vpn Digest, Vol 98, Issue 6

Dear Robert,

As mentioned in the earlier mail the following restriction is imposed on
the
Model C deployment

The consequence of this is that in model C the service providers must
trust each other also in areas that are not shared. Therefore, model C is
most commonly used today where a single operator uses several ASs on the
backbone. In this case, implicit trust exists between the ASs because they
have the same operational control.

In order to stretch this scheme to other Ases under different admin
control this scheme helps out.

Thanks and regards,
Balaji venkat

On 08/07/12 12:30 AM, "l2vpn-request@ietf.org" <l2vpn-request@ietf.org>
wrote:

>If you have received this digest without all the individual message
>attachments you will need to update your digest options in your list
>subscription.  To do so, go to
>
>https://www.ietf.org/mailman/listinfo/l2vpn
>
>Click the 'Unsubscribe or edit options' button, log in, and set "Get
>MIME or Plain Text Digests?" to MIME.  You can set this option
>globally for all the list digests you receive at this point.
>
>
>
>Send L2vpn mailing list submissions to
>	l2vpn@ietf.org
>
>To subscribe or unsubscribe via the World Wide Web, visit
>	https://www.ietf.org/mailman/listinfo/l2vpn
>or, via email, send a message with subject or body 'help' to
>	l2vpn-request@ietf.org
>
>You can reach the person managing the list at
>	l2vpn-owner@ietf.org
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of L2vpn digest..."
>
>
>Today's Topics:
>
>   1. draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt ...
>      (Robert Raszuk)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Sat, 07 Jul 2012 14:39:56 +0200
>From: Robert Raszuk <robert@raszuk.net>
>To: "l2vpn@ietf.org" <l2vpn@ietf.org>
>Subject: draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt ...
>Message-ID: <4FF82E1C.6000009@raszuk.net>
>Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
>
>I have read the draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt.
>
>It proposed an interesting solution to apply algorithmically computed
>VPN lable (for L2VPNs, but also possible for L3VPN) where inter-as
>option C is used.
>
>However I have a fundamental question .. from who the draft is
>protecting the inter-as service ?
>
>Who other then participating ISPs can spoof a value of VPN label ? If
>the solution is protecting from ISPs itself then I think it does not
>help at all as corresponding ISPs/SPs still have full access to their
>PEs and could inject packets to VPN sites at will.
>
>Moreover main issue with option C is not security (at least for the last
>10+ years). Main issue with option C and MPLS is that participating
>providers need to inject into each other's network all of their
>participating PE's /32 addresses so the end to end MPLS LSP can be
>build. Originally that was recommended to be done by mutual
>redistribution to the IGP .. now the general recommendation is to use
>labeled BGP (both IBGP and EBGP).
>
>So fundamental question to the authors ... who is the potential
>attacker/spoofer this draft is aiming to protect from ?
>
>Best regards,
>R.
>
>
>
>
>
>------------------------------
>
>_______________________________________________
>L2vpn mailing list
>L2vpn@ietf.org
>https://www.ietf.org/mailman/listinfo/l2vpn
>
>
>End of L2vpn Digest, Vol 98, Issue 6
>************************************