Subject: Spoke pseudowire signaling

From: Benny Ammitzbøll <[email-masked]>
Date: Tue, 12 Oct 2004 13:41:01 +0200

Folks,

>From draft-ietf-l2vpn-vpls-ldp-05.txt, section 8.1.1 "Spoke connectivity for
bridging-capable devices":
   "For each VPLS service, a single spoke pseudowire is set up between the
MTU-s 
   and the PE-rs based on [PWE3-CTRL]. Unlike traditional pseudowires 
   that terminate on a physical (or a VLAN-tagged logical) port at each 
   end, the spoke pseudowire terminates on a virtual bridge instance on 
   the MTU-s and the PE-rs devices. "

>From draft-ietf-pwe3-control-protocol-11.txt, section 5.2.1 "Attachment
Identifiers":
   "If the AGI is non-null, then the Source AI (SAI) consists of the AGI
   together with the SAII, and the Target AI (TAI) consists of the TAII
   together with the AGI.  If the AGI is null, then the SAII and TAII
   are the SAI and TAI respectively."

>From draft-ietf-l2vpn-vpls-ldp-05.txt, section 4.1.1 "Using the Generalized
PWid FEC Element":
   "AGI, Length, Value: The unique name of this VPLS.  The AGI 
   identifies a type of name, the length denotes the length of Value, 
   which is the name of the VPLS.  We will use the term AGI 
   interchangeably with VPLS identifier. 
    
   TAII, SAII: These are null because the mesh of PWs in a VPLS 
   terminate on MAC learning tables, rather than on individual 
   attachment circuits. "

So how is a spoke pseudowire being signaled using Generalized PWid FEC? The
TAII and SAII can not both be null in this case, because one of them must
point out an attachment identifier (AI) in the MTU-s. Also, note that the AI
in the MTU-s *must* consist of the VPLS AGI and a local AII. So the MTU-s
*must* support attachment identifiers where the AGI is non-null and equal to
the VPLS AGI.

My proposal would be to allow the TAII or SAII to be non-null when signaling
a connection between a VPLS forwarder and a PWE-3 (single point / physical
interface) forwarder. This may also be the intention, but the text in
draft-ietf-l2vpn-vpls-ldp-05.txt should clearly state this.

Regards,

Benny Lønstrup Ammitzbøll, M.Sc.E.E.
T|Pack A/S
Lautrupbjerg 7-11
DK-2750 Ballerup, Denmark