Subject: Re: [PWE3] OAM capability indication issue

From: "Thomas D. Nadeau" <[email-masked]>
Date: Fri, 7 Oct 2005 15:25:48 -0400

> Hi, all,
>
> During establishing a PW, source U-PE(U-PE1) will use the VCCV  
> interface parameter field in the PW setup message to indicate its  
> OAM capabilities. When the setup message arrives the peer PE(U- 
> PE2), it will choose certain capability or capabilities according  
> to local policy. When U-PE2 establishs the reverse PW, it has two  
> ways to indicate the OAM capability in the setup message:
> 1. indicates all OAM capabilities U-PE2 supports.
> 2. indicates the capabilities choose by U-PE2 during the former PW  
> setup procedure(from U-PE1 to U-PE2).
>
> If we adopt the former, it may cause the different OAM mechanism  
> existed in the different direction of the PW, because the local  
> policy of U-PE1 and U-PE2 is maybe different.

     This could happen, and is intentional. For example, if you have  
a case like this
where PE1 sends PE2 a capability indication of supporting BFD and LSP  
ping:

     PE1 ---- "I can do BFD or LSP ping" ----> PE2

PE2 can indicate its capabilities in the return message
with one of 5 choices:

     1. BFD
     2. LSP ping
     3. Nothing
     4. Both 1 and 2.
     5. Something not in 1 or 2.

     Number 5 is critical to understand here. If we use your  
preferred method,
then PE2 is always constrained to support the set of modes that
PE1 sends it. This is not how we intended the protocol to work.

> If we adopt the latter, then the OAM mechanism of both PW  
> directions is same.
>
> I suggest we should adopt the latter. Welcome for comments.

     I think there is a fundamental misunderstanding of what the  
capability
indication should do. The intent is not for the other side of the PW  
(PE2 in
the example above) to look at what PE1 sent it and determine what subset
of that it can support and then insert that into the LDP reply --  
although it
certainly can do that.  The idea is to simply remember what it sent and
also indicate to the other side what it can understand, and then when  
it comes
time to send VCCV to that peer, look at what it told you it wishes to
accept.  If the PE wants to make an intelligent decision at that point
and see if there are any similarities in what it told the other end that
it wishes to entertain, then that is IMHO a local optimization.
Then either side is free to choose whatever method you told it
it should send you (including nothing).  This is the most flexible  
way of
doing this that supports cases where even one side doesn't want to
receive ANY vccv.

     --Tom

_______________________________________________
pwe3 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pwe3