Subject: PWid/Generalised FEC Element query

From: [email-masked]
Date: Tue, 9 Sep 2003 00:15:48 +0100

I have a query regarding the use of AIs/PWids in
draft-ietf-pwe3-control-protocol-03.txt. The draft states "There are cases
where the PWid FEC element cannot be used, because both endpoints have not
been provisioned with a common 32-bit PWid. In such cases, the "Generalized
ID FEC Element" is used instead."

Can anyone give examples of such cases? If endpoints belong to the same VPN,
why would they need to be provisioned with different PWid's? I guess this
also raises the question of why do we really need the Generalised ID FEC
element? 

If I understand the PWid FEC element correctly, the PWid can be used to
uniquely identify the VPWS/VPLS and a combination of the PWid and PE IP
address can be used to uniquely identify the forwarder. Why then in the
Generalised ID FEC do we need unique IDs for endpoint (SAII/TAIIs) as well
as a VPN ID (AGI)? Why doesn't the AGI in combination with the PE IP address
uniquely identify the endpoints/forwarders?

An example given of a TAII is "ATM3VPI4VCI5" or a string such as "Fred"
which is associated by configuration with a particular Attachment Circuit. I
assume that Attachment Circuits must also be associated by configuration
with an AGI? In which case, the operator must configure two associations
(AGI and SAII) for each Attachment Circuit if the Generalised ID FEC element
is used but only one association (PWid) if the PWid FEC Element is used. The
extra configuration necessary in the Generalised FEC element case increases
the chance of configuration errors, so what problem does the Generalised FEC
element solve that warrants this extra configuration?

Apologies if this subject has been discussed before or if I'm missing
something obvious!

Thanks,

Richard

---

From: "Hamid Ould-Brahim" <[email-masked]>
Date: Tue, 9 Sep 2003 16:34:53 -0400

Richard,

> also raises the question of why do we really need the 

It is needed for supporting other provisioning models besides
the double-sided provisioning model supported by the PWid FEC.

Hamid.

> uniquely identify the VPWS/VPLS
> and a combination of the PWid 
> and PE IP
> address can be used to uniquely identify the forwarder.
> Why 
> then in the
> is used but only one association (PWid) if the PWid FEC 
> Element is used. 
>The
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>

---

From: [email-masked]
Date: Wed, 10 Sep 2003 09:18:18 +0100

Hamid,

Can you give me any further details/examples of the provisioning models that
the Generalised FEC element supports that the PWid FEC element doesn't?

I am struggling to find a scenario where the PWid FEC is not sufficient. The
PWid uniquely identifies the VPWS/VPLS and a combination of the PWid and PE
IP address uniquely identifies the VPN endpoints.

The only reason I can think of for having the Generalised FEC is perhaps to
offer the service provider flexibility in provisioning, e.g. an automated
provisioning system might use a SAII like "ATM3VPI4VCI5" to automatically
associate a VPN with a particular attachment circuit. By using the SAII the
association is explicit rather than implicit. However, I do not believe that
the  SAII is essential, if an attachment circuit is associated with a
particular VPN (using a PWid) then I believe this (implicit association)
should be sufficient.

Thanks,

Richard

> -----Original Message-----
> From: Hamid Ould-Brahim [mailto:[email-masked]]
> Sent: 09 September 2003 21:35
> To: Spencer,R,Richard,XGH5 R; [email-masked]
> Subject: RE: [PWE3] PWid/Generalised FEC Element query
> 
> 
> Richard,
> 
> >

---

From: "Hamid Ould-Brahim" <[email-masked]>
Date: Wed, 10 Sep 2003 11:32:06 -0400

Richard,

> I am struggling to find a scenario where the PWid FEC is not 
> sufficient. 

Sure. The PWid FEC implies (as indicated in the draft) that
both ends of a pseudo-wire needs to be configured with that
ID which is in fact required to be unique only within 
the targeted LDP session between the two PEs. That in itself 
implies that for a pseudo-wire (and subsequently for the two opposite
LSPs to be established) both ends -forwarders- needs to be 
configured with exactly the same information (in addition to
the IP addresses). That scheme excludes scenarios
where for example pseudowires are member of layer-2 VPN and
a discovery mechanism is used, or where switched on-demand PWs 
are used, or even when distributed VPLS is used. In addition to that, 
for VPLS the PWid FEC needs to be globally unique 
and in this case the 32 bits of the PWid will not make it.

For all these situations, it is desirable that only of
end of a pseudo-wire is configured with information about the remote 
end and not both ends. That information can be combined with the 
information carried in the discovery mechanism (if any) to successfully
complete the signaling procedures. 

The Generalized ID FEC tries to address all these cases. One can view 
the Generalized ID FEC as one signaling scheme that covers the superset 
of cases (that include the PWid provisioning model). 

> particular VPN (using a PWid) then I believe this (implicit 

If one will just use pseudo-wires in a double-sided
provisioning model (and not for VPLS) then the PWid FEC is sufficient, 
but I assume there are cases (as mentioned above) where this seems 
too restrictive.

Hamid.