Subject: Generalized PWID FEC and the question of the Group ID

From: Luca Martini <[email-masked]>
Date: Tue, 27 Apr 2004 16:03:41 -0600

Hello!

It has been pointed out that the GPW FEC design was somewhat 
inconsistent with the other PWId design in the control draft.
I have fixed several issues related to length fields, and clarified the 
label with draw procedures. The only thing that remains is the GR ID 
functionality.
This was initially suggested at a diner/meeting at the San Diego IETF. 
The idea is that if there are large amounts of PWs originating  on a 
port , with a few dozen different destinations it would be much faster 
to send a few dozen withdraw ( or status messages ) instead of thousands 
individual PW withdraw , or PW status messages.
We left the association of GR IDs open to implementors, as it is not 
relevant for protocol compatibility.

This time around, I would like to keep the same functionality, but 
remove the GR ID from the FEC if possible.

So I propose the following:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     129       |C|         PW Type             |PW info Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Group ID=0   |   Length=4    |      Value                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      AGI      |    Length     |      Value                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                      Value (contd.)                           ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     SAII      |    Length     |      Value                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                      Value (contd.)                           ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     TAII      |    Length     |      Value                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                      Value (contd.)                           ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                    Interface Parameters                       |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

To identify the GR ID we set the type to the reserved type of 0 ...
the length is set to 4 to specify a 16 bit value , but we can make that 
bigger if needed. ( however I cannot think of an application requiring 
more then 16 bit of locally defined groups )

the semantics would remain similar with the following exception:

The GR ID is not part of the FEC, is OPTIONAL, and will not be 
advertised except in the initial PW FEC advertisement.
If the GR ID is advertised , then the advertising PE can use the wild 
card withdraw semantics, and the if the remote PEs accepts the FEC it 
MUST implement this.
If a PE chooses not to implement the GR ID, and it receives an 
advertisement containing one,  a Label Release MUST be sent, with an "GR 
ID not Supported"   status code. In this case, the PW will not be 
enabled. ( the PE is free to advertise a new PW FEC without the GR ID, 
but that is a matter of local configuration policy )

0x00000029 "GR ID not Supported"

To issue a wild card command ( status/or withdraw ):
Set the PW Info Length to 0 , and send only the GR ID in the FEC. ( we 
could also make this be the correct length, since we can recognize the 
GR ID , by the code point = 0 )

One other option is to make this mandatory, in a similar way as with FEC 
128.

Of course we will need to reissue a last call for this section as well 
as the status TLV section.

Comments ?

Thanks.
Luca

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 29 Apr 2004 13:13:19 -0400

This is certainly a reasonable proposal.

In fact, I would prefer making this mandatory, since that would simplify 
the procedures and remove the need for the new status code.  Just to be 
clear, even if we don't make it mandatory, I'm still in favor of this change.

Cheers,
Andy

----------

At 4/27/2004 04:03 PM -0600, Luca Martini wrote:
>Hello!
>
>It has been pointed out that the GPW FEC design was somewhat inconsistent 
>with the other PWId design in the control draft.
>This was initially suggested at a diner/meeting at the San Diego IETF. The 
>idea is that if there are large amounts of PWs originating  on a port , 
>with a few dozen different destinations it would be much faster to send a 
>few dozen withdraw ( or status messages ) instead of thousands individual 
>PW withdraw , or PW status messages.
>This time around, I would like to keep the same functionality, but remove 
>the GR ID from the FEC if possible.
>
><clipped for brevity - see Luca's original message>
>
>One other option is to make this mandatory, in a similar way as with FEC 128.
>
>Of course we will need to reissue a last call for this section as well as 
>the status TLV section.
>
>Comments ?
>
>Thanks.
>Luca