Subject: Re: Clarifications of Generalized ID FECs

From: Wei Luo <[email-masked]>
Date: Fri, 02 Apr 2004 16:21:42 -0800

The L2VPN signaling draft that defines the usage of Generalized ID FEC more or 
less explains the scenario, and it could certainly be more precise in future 
revisions.

1. When PE1 sends a Label Mapping with SAII (Fred) and TAII (Bill) to PE2, PE2 
treats it as a connection request from PE1 to its local attachment named Bill.

2. PE2 examines whether it should accept this connection request according to 
its local configuration.  If not, it could save the label binding for future use 
if using liberal retention or discard it, and the processing is complete.

3. If yes, PE2 either has already sent or is about to send a Label Mapping with 
SAII (Bill) and TAII (Fred) to PE1.  After

> Nick> The sense of the SAII and TAII is clear in Label Mapping messages, but
> Nick> the draft doesn't  explicitly state the sense of the  SAII and TAII in
> Nick> LDP  messages flowing  in  the reverse  direction,  for example  Label
> Nick> Release.  Two possibilities come to mind:
> Nick> 
> Nick> (a) The FEC  TLV sent in a  Label Release is  the same as the  FEC TLV
> Nick>     received  in the  Label Mapping  being released  (but  without the
> Nick>     interface parameters).  More generally, the FEC TLV is the same in
> Nick>     all LDP  messages relating  to the same  LSP.  In a  Label Release
> Nick>     this means that the SAII is  the remote peer's AII and the TAII is
> Nick>     the sender's local AII. 
> Nick> 
> Nick> (b) The FEC  TLV sent in a  Label Release is  the same as the  FEC TLV
> Nick>     sent in  a Label Mapping  (for the reverse LSP).   More generally,
> Nick>     the SAII  is always  the sender's  local AII and  the TAII  is the
> Nick>     remote peer's  AII.  In a Label  Release this means  that the SAII
> Nick>     and  TAII  are  reversed  compared  to  the  Label  Mapping  being
> Nick>     released. 
> 
> Nick> Which of these is intended? 
> 
> Uh oh.   After 10 minutes of  intensive thought, and having  changed my mind
> three times during  that period, I think I'd like to  say that the intention
> was  (a).  When you  talk about  a particular  LSP, you  should use  the FEC
> associated with  that LSP, and  a Label Release  is about the  incoming LSP.
> However, comments of "but I interpreted it the other way" are welcomed!
> 
> 
> 
> 
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3

---

From: Wei Luo <[email-masked]>
Date: Fri, 02 Apr 2004 16:48:33 -0800

(resend with the complete response, hit the send button too early by mistake)

1. When PE1 sends a Label Mapping with SAII (Fred) and TAII (Bill) to PE2, PE2
treats it as a pseudowire connection request from PE1 to its local attachment 
named Bill.

2. PE2 examines whether it should accept this connection request according to
its local configuration.  If the attachment Bill is not provisioned, it could 
save the label binding for future use if using liberal retention or discard it, 
and the processing is complete.

3. If the attchment Bill is provisioned but with a targeted PE other than PE1, 
PE2 sends a Label Release with SAII (Bill) and TAII (Fred) to PE1 and the error 
code is set to "attachment bound to different PE".  PE1 treats the Label Release 
message as the refusal of the original pseudowire connection request.

4. If the attachment Bill is provisioned with PE1 as the targeted PE but with a 
targeted attachment other than Fred, PE2 sends a Label Release with SAII (Bill) 
and TAII (Fred) and the error code is set to "attachment bound to different 
remote attachment". PE1 treats the Label Release message as the refusal of the 
original pseudowire connection request.

In essence, SAII and TAII are properties pertaining to the *bidirectional* 
pseudowire instead of individual LSPs.  Therefore, whenever receiving a Label 
message regardless its type, the TAII always correponds to an attachment 
provisioned locally, and the SAII always correponds to an attachment provisioned 
remotely.  This is what described in option b) below.  This consistence 
eliminates confusions often raised when mixing unidirectional LSP and 
bidirectional pseudowire in the same context.  It is also consistent with the 
other L2VPN signaling protocol.

---Wei