Subject: RE: Clarifications of Generalized ID FECs

From: Nick Weeds <[email-masked]>
Date: Wed, 7 Apr 2004 15:24:06 +0100

Wei: Thanks for your reply.  The L2VPN signaling draft is indeed clearer
(especially section 2.3 paragraph 7), though it doesn't describe the Label
Release usage as clearly as your reply.  As you point out, the L2TP drafts
are clear that Local End ID = SAII and Remote End ID = TAII.

Eric & Wei:

Do we have agreement to follow option (b) ?
This means that we always set SAII = sender's local AII and TAII = remote
AII, so that in a Label Release the SAII and TAII are reversed compared to
the Label Mapping being released.
The one drawback I see is that if the receiver doesn't understand the AGI,
SAII and TAII IDs in a Label Mapping then it is unable to send a Label
Release with the correct FEC.  According to
draft-ietf-pwe3-control-protocol-06.txt these IDs are application-specific,
and I haven't yet seen any ID values specified, so failure to recognize the
IDs does seem to be a possibility.  I don't think this drawback arises in
L2TP because a CDN ("disconnect") identifies the call by session ID instead
of Local & Remote End IDs.  I don't think this drawback in LDP is a
show-stopper, but option (a) does avoid it.

	Nick.

> -----Original Message-----
> From: Wei Luo [mailto:[email-masked]]
> Sent: 03 April 2004 01:49
> To: [email-masked]; Nick Weeds
> Cc: 'Luca Martini'; [email-masked] (E-mail)
> Subject: Re: [PWE3] Clarifications of Generalized ID FECs
> 
> 
> (resend with the complete response, hit the send button too 
> early by mistake)
> 
> 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 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
> 
>  > 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: Wed, 07 Apr 2004 09:54:24 -0700

Nick,

Nick Weeds wrote:
> Release with the correct FEC.

In RFC3036, Section 3.4.1.1

"   If it encounters a FEC Element type it cannot decode, it should stop
    decoding the FEC TLV, abort processing the message containing the
    TLV, and send an "Unknown FEC" Notification message to its LDP peer
    signaling an error.
"

Based on the RFC text, if the receiver does not understand FEC 129, it should 
send a Notification message instead of a Label Release, and the Notification 
message does not contain a FEC TLV.  So it should not be a problem for LDP 
signaling even if the receiver does not understand FEC 129.

---Wei

>  According to