Subject: Vpls-MIB response to comments at IETF 73

From: "MEDIRATTA Rohit" <[email-masked]>
Date: Tue, 2 Dec 2008 17:38:32 -0600

Hi All,
   Please find the response to the questions raised w.r.t to VPLS-MIB at
IETF-73.
The response to the questions are preprended with RM:

Regards,
Rohit, Kiran & Tom.

-----------------------------

 Questions:
- Kireeti Kompella: You say that VplsBgpRteTargetEntry allows H-VPLS
representation, but that seems pretty orthogonal.  Can you explain that?

RM: RT's can be used to filter which "l2vpn route" should be accepted by
each Node.

Consider the following setup
A-----B------C------D
      |      |
      |      |
      E      F

Assuming
Vpls/Bgp on A is setup to import RT from B only, export RT-A.
Vpls/Bgp on B is setup to import RT from A,C and E, export RT-B

Vpls/Bgp on C is setup to import RT from B,D and F, export RT-C
Vpls/Bgp on D is setup to import RT from C only, export RT-D.
Vpls/Bgp on E is setup to import RT from B only, export RT-E.
Vpls/Bgp on F is setup to import RT from C only, export RT-F.

This will lead to the following PW Setup.

A----B=====C----D
     |     |
     |     |
     E     F

This gives Providers the flexibility to engineer the Auto-discovered
PW's.
To provide the ability to import/export multiple RT's per Vpls we needed
to break RT into a separate table.

- ???: I have a few questions for clarification.  When I read the MIB,
there's
a few things that I couldn't find:
  + VPLS Instance ID in the Configuration Table;
  + A way to define the desired Class of Service to be used by the VPLS

  instance to be used for tunnel selection;
RM: Could we get some more information on the above two and why its a
good idea to add them to the next revision.

+ There are pointers to the Bridge-MIB, but if would be useful if there
was

  a place in MIB to define the maximum # of MAC addresses that should be
  learned by a specific VPLS instance.

RM: There was an object vplsPwBindMacAddressLimit in an earlier
revision.
http://tools.ietf.org/id/draft-nadeau-l2vpn-vpls-mib-00.txt
<http://tools.ietf.org/id/draft-nadeau-l2vpn-vpls-mib-00.txt>
This was removed after suggestion from the group in Montreal-IETF, refer
to discussion in Montreal

+ It would be useful if there was a way to allow someone to clear the
MAC
  addresses in a VPLS instance.

RM: Should this exist in the Vpls-MIB ? Why ?

+ You point to Bridge-MIB, but I don't see a clear identification of the
  interfaces that are bound to a VPLS instance.  I see that for the PW
side,
  but I don't see that for the interfaces.

RM: This is the issue where AC is a PW. We've raised this a few times
and have not really
been able to solicit a clear approach to tackling this.

- Sanjay (?): MIB you're using for configuration doesn't support old FEC
Type

using VC ID.  There are a lot of existing installations today that are
using
FEC 128 and all of them depend on the VC ID for the identifier of the
VPLS
instance.  Would like you to consider in the VPLS instance, if you can
add the

VC ID as a field so that older installations can also be included.

RM: Vpls MIB is FEC Type agnostic. FEC 128 and FEC 129 are in the
PW-MIB.
    Also, VC Id is only an identifier for a PW. Not the Vpls.

---

From: "Norival Figueira" <[email-masked]>
Date: Fri, 5 Dec 2008 14:40:24 -0800

Hi Rohit,

Thank you for addressing below the questions I asked at the 73rd IETF's
L2VPN WG meeting. I would like to take this opportunity to further
clarify those questions and answer your questions below.

> ???: I have a few questions for clarification.  When I read the MIB,
> good idea to add them to the next revision.

VPLS Instance ID (VC ID):
In the context of LDP signaling for VPLS defined in RFC4762, LDP is used
for signaling a full mesh of pseudowires interconnecting VPLS instances.
LDP pseudowire id (PWid) Forwarding Equivalence Class (FEC) element 128
was originally used to carry pseudowire parameters. This is still used
and supported by most of the existing RFC4762 implementations in the
market. Please note that although RFC4762 defines the use of the
Generalized PWid FEC 129, it also describes the use of FEC 128 in
Appendix A ("VPLS Signaling using the PWid FEC Element"), which states
that "this section is being retained because live deployments use this
version of the signaling for VPLS". Therefore, in order to support these
existing implementations, one also needs to define a VPLS Instance Id
(or VC Id). In this case, in each PE containing a VPLS instance for a
given customer, the VPLS instance is configured with a same VPLS
Instance ID, which has global significance across all PEs involved in
the same VPLS instance. The VPLS instance ID is then used as the VC ID
in the FEC element 128. PEs then correlate pseudowires with
corresponding VPLS instances using the VC ID value contained in the FEC
element 128.

The above reasoning also justifies Sanjay's question in your original
message.

VPLS Class of Service (CoS):
Some service providers use a specific CoS for particular VPLS instances.
In that case, the PE needs to choose an appropriate LSP such as an L-LSP
that best satisfies the desired VPLS CoS. A VPLS CoS could be defined as
a 3-bit value. How would a PE select appropriate LSPs in regards to CoS
for each VPLS instance without an explicit definition in the VPLS MIB?

> + There are pointers to the Bridge-MIB, but if would be useful if
there was
revision.
> to discussion in Montreal

VPLS Maximum Number of MAC addresses:
My understanding from the Montreal discussions is that the group was
concerned with the definition in the VPLS MIB of features that are
implementation specific. I also agree that implementation specific
definitions should not be part of a standard VPLS MIB. However, defining
the maximum number of MAC addressed for a VPLS instance is not an
implementation specific issue. A VPLS maximum number of MAC addresses is
needed to support service provider's L2VPN business models. Without this
feature, service providers will not able to properly deploy large scale
VPLS services.

Service providers deploying VPLS as an L2VPN service usually define
L2VPN business models with different service levels. For example
(completely hypothetical), a service provider may define a customer VPLS
service starting at a maximum of 40 MAC addresses and charge for
additional increments of 40 MAC addresses. This business model allows
the service provider to optimize MAC address table resources and to plan
the capacity of its network in terms of the number of VPLS instances
that can be supported by each PE (i.e., it allows the service provider
to define admission control policies that take PEs' MAC address tables'
capabilities into consideration). Defining a maximum number of MAC
addresses per VPLS instance is also necessary to protect the network
against customer (unintended or intended) MAC address storm attacks.
Without a per VPLS (i.e., customer) limit, a single VPLS could consume
the whole MAC address table available in a PE. This would cause service
disruption to other VPLS customers.

Please note that the maximum number of MAC addresses discussed here is a
VPLS instance property. The MAC address limits defined earlier in
vplsLdpPwBindMacAddressLimit (which was later removed) and in
vplsPwBindMacAddressLimit (which is still defined in the current VPLS
MIB draft), represent something else and are not appropriate to provide
an overall VPLS MAC address limit. An overall VPLS MAC address limit
does not care for how many MAC addresses were learned by specific PWs or
endpoint interfaces. An overall VPLS MAC address limit is what service
providers care about to implement their L2VPN business models and to
allow for the proper management and protection of individual VPLS
services.

Please note that with the advent of PBB-VPLS integration, customer MAC
addresses will no longer be learned by VPLS instances. This could be
used by someone as an argument against the inclusion of a VPLS MAC limit
in the VPLS MIB. However, the VPLS MIB must be applicable to existing
deployments where PBB-VPLS integration is not used. Please note that
customer MAC addresses will be learned by PEs that also provide PBB
Backbone Edge Bridge (BEB)functionality, but this is a subject for a
separate discussion on a PBB-VPLS thread.

MAC
> RM: Should this exist in the Vpls-MIB ? Why ?

VPLS Clear MAC Addresses:
The group has been discussing different ways to flush the learned MAC
address of a VPLS instance to support dual homing. In simple terms, with
dual homing a CPE (customer premises equipment) could be physically
attached to two PEs supporting a VPLS service for the customer. Only one
PE would initially forward the customer traffic. In the event that the
active PE lost connectivity to the CPE or the PE itself failed, the
other PE would take over the responsibility of forwarding the customer
traffic. Without further actions, this could create a "black hole"
effect where other PE's in the network would continue to send traffic to
the original PE until learned MAC entries aged out or were re-learned to
point to the new PE as the proper destination. To solve this problem,
one can use explicit MAC withdraw (or flush) messages or implicit
mechanisms to determined that a MAC flush is required. In both cases, a
MAC flush is only issued when there is a VPLS service switchover from on
PE to another PE in a dual homing scenario. The case exists for allowing
one to manually (administratively) flush the learned MAC addresses of a
VPLS instances (for dual homing and non-dual homing scenarios). This is
useful for debugging purposes (e.g., the service provider wants to
re-start MAC learning for a particular VPLS instance) and also for
allowing the manual switchover of service from one PE to another (e.g.,
in a non-dual homing scenario).

> side, but I don't see that for the interfaces.
>

VSIs are interconnected by a full mesh of network pseudowires. To
provide services to customers a VSI must also support port mode and
tagged mode (VLAN) attachments (or endpoints). My question regards these
two types. Analogous to the PW bind table defined in the VPLS MIB, one
could have an explicit attachment bind table (possibly indexed by
vplsConfigIndex and ifindex of endpoint).

There seems to be a lean towards SNMP Context Mapping MIB to represent
the endpoints. However, this seems to only apply in the context of SNMP
v3. For SNMPv2c and SNMPv1, each context will need to be mapped to a
community string, which will need to be configured on the management
station. This seems impractical, since any number of VPLS instances are
possible, with each one having its own unique endpoint attachments.

Regards,
Norival Figueira

----------------------------------------------------------------------

Date: Tue, 2 Dec 2008 17:38:32 -0600
From: "MEDIRATTA Rohit" <[email-masked]>
Subject: Vpls-MIB response to comments at IETF 73
To: <[email-masked]>
Cc: Agrahara S Kiran Koushik <[email-masked]>
Message-ID:
	
<[email-masked]
	
Content-Type: text/plain;	charset="us-ascii"

Hi All,

Regards,
Rohit, Kiran & Tom.

 Questions:

Assuming

A----B=====C----D
     |     |
     |     |
     E     F

------------------------------

_______________________________________________
L2vpn mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/l2vpn

End of L2vpn Digest, Vol 55, Issue 2
************************************

---

From: "Norival Figueira" <[email-masked]>
Date: Fri, 5 Dec 2008 14:25:40 -0800

Hi Rohit,

there was
revision.

MAC

Regards,
Norival Figueira

	

Hi All,

Regards,
Rohit, Kiran & Tom.

 Questions:

Assuming

A----B=====C----D
     |     |
     |     |
     E     F