Subject: Re: draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt ...

From: Balaji venkat Venkataswami <[email-masked]>
Date: Sun, 8 Jul 2012 17:49:13 +0530

Another question.
How does this interact with ECMP flow hashing on LSRs, rfc6391 and
draft-ietf-mpls-entropy-label?

--
Jakob Heitz.

Dear Jakob,

You are right. With respect to ECMP flow hashing on LSRs (for pseudowires
in RFC 6391) we would have difficulty in providing a clean solution so that
packets are not reordered between multiple ECMP paths. So is also the case
with entropy label draft.

We are in the process of working on this to see if a solution can be given
and if so if it can be given then how elegantly we could give it.

For now the draft proposal for label-hopping would break both of the above.

Your inputs on this would be most useful.

thanks and regards,
balaji venkat

---

From: Balaji venkat Venkataswami <[email-masked]>
Date: Mon, 9 Jul 2012 22:16:41 +0530

Dear Robert,

Message: 4
Date: Mon, 09 Jul 2012 18:14:07 +0200
From: Robert Raszuk <[email-masked]>
To: Balaji venkat Venkataswami <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Shankar Raman M J
        <[email-masked]>,   Bhargav Bhikkaji <[email-masked]>
Subject: Re: L2vpn Digest, Vol 98, Issue 6
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

> If specific set of VPNs alone are to be subject to the scheme

I don't think this is for specific VPNs. It would be applicable for all
VPNs using option C on a given link between pair of peering ASBRs.

<balajivenkat> This is where the scheme proposed differs. One can select
a specific VPN or set of VPNs carried over Option-C to be subject to this
scheme.
Also it may be possible that Option-A and B are deployed over the same ASBR.
How do we distinguish which is A and B Options and which is C ?
We would find ourselves in a quandry there.

> encryption. Otherwise it would have to encrypt all traffic since it
> finds that some of the VPNs are subject to this scheme. This would be an
> overkill.

I do not think so. If there is any risk that my link is insecure between
trusted parties it seems wise to make it secure for all control plane
and data plane traffic which traverses such link.

<balajivenkat> Worried about the scalability aspects here. Line rates
between
ASBRs are high, how would one cope with so much cycles of encryption and
decryption ?

>     In the same time the proposed scheme makes the troubleshooting
>     impossible. How ISPs would decode that for some option C VPNs their
>     customer packets go via ASBR to ASBR link or not ?
>
> Could you please explain a bit more on this. We assume that all Option-C
> traffic has to go through ASBR to ASBR link.

So do I.

Let's assume customer X reports that he can not ping his remote sites.

Today NOC does:

- Logs into PE and see what VPN label his remote PE peer advertised
- Enabled filter on the ASBR and issues a vrf ping on the PE or CE
- Has ability to see or not his customer packets

With your scheme such filtering becomes impossible. So does the
troubleshooting.

<balajivenkat> One possibility is to actually use a certain fixed label for
vrf ping alone. This can be done without too much complexity. Reachability
can be tested this way.

>     Same for billing. To the best of my knowledge ISPs charge
>     differently for the portion of inter-as service. There is need to
>     provide on a per VPN stats from ASBR router. How in this scheme per
>     VPN granularity of traffic statistics will be accomplished for
>     billing purposes ? That's actually one of the key reasons for option
>     B popularity today.
>
>
> The billing can be done as follows. Collect the traffic statistics for
> all VPN labels as if they were separate VPN labels each for a specific
> VPN. At the egress PE collate statistics coming towards it based on a
> set of labels instead of a single label in the regular case. Collate
> this data with the ASBR statistics (identifying the egress PE by the
> outer label) and do the billing.

If there are many PEs and their labels restart that is a lot of
additional complexity and data correlation as compared with today.

<balajivenkat> This happens for single labels anyways but this is a small
price to pay for more security I guess. Besides we are doing this for select
VPN customers only.

Hope this helps.

thanks and regards,
balaji venkat

Many thx,
R.