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

From: Nick Weeds <[email-masked]>
Date: Wed, 5 May 2004 19:09:17 +0100

Thanks Luca.

My main concern is to ensure that the AGI, SAII and TAII can be identified
clearly and distinguished from interface parameters.  The GR ID might
complicate that, especially if it is optional.

If the GR ID isn't at the start of the FEC then describing the general case
is awkward, but we have two cases (full FEC or wildcard) that are easily
described separately.  I guess they appear as follows (possibly with 32 bit
GR ID values instead of 16 bit values):

Full FEC:

 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   AGI ID      |    Length     |      Value                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                      Value (contd.)                           ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   SAII ID     |    Length     |      Value                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                      Value (contd.)                           ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   TAII ID     |    Length     |      Value                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                      Value (contd.)                           ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Group ID=0   |   Length=4    |      Value                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |

|                    Interface Parameters                       |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Here the AGI, SAII and TAII are required, MUST be the first three elements,
and MUST be in the order shown above.
The IDs of the AGI, SAII and TAII are assigned from a distinct space
separate from interface parameters.  They MUST NOT be assigned ID=0.
Either the GR ID is mandatory and MUST be the 4th element or it is
distinguished from interface parameters by ID=0.

Wildcard:

 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                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Here the AGI, SAII and TAII MUST be omitted.  Also the interface parameters
SHOULD be omitted.

Ideally PW Info Length = 4 so that FEC element length = (4 + PW Info Length)
as before.

Using PW Info Length = 0 would make FEC element length determination more
complicated so it would be worth careful explanation.

	Nick.

> -----Original Message-----
> From: Luca Martini [mailto:[email-masked]]
> Sent: 03 May 2004 20:35
> To: Nick Weeds
> Subject: Re: [PWE3] Generalized PWID FEC and the question of the Group
> ID
> 
> 
> 
> 
> Nick Weeds wrote:
> 
> >Luca,
> >
> >A few thoughts...
> >
> >(1) Is the GR ID implementing essentially the same function 
> as the Group ID
> >in the PWid FEC?  If so then it would be helpful to make the 
> definitions as
> >close as possible.
> >
> >  
> >
> yes.
> 
> >(2) You suggest a 16-bit value, perhaps so that the entire 
> 00 04 XX XX
> >encoding fits into 32 bits.  A 32-bit value might be 
> preferred to match the
> >Group ID.  Either way, best use a fixed-length value not 
> exceeding 32 bits.
> >I hope that's consistent with your observation that "we can 
> make [it]bigger
> >if needed".
> >
> >  
> >
> yes , I can make it 32 bits , the only issues I see is the word 
> alignment , but that is not much of an issue.
> 
> >(3) It would be simpler to make the GR ID mandatory in all 
> messages (like
> >the Group ID).
> >- Mandatory GR ID, AGI, SAII and TAII make it easy to 
> identify these 4
> >fields.  Making them optional makes it harder to distinguish 
> them from
> >interface parameters.
> >- Mandatory GR ID avoids the need for special procedures in 
> case the GR ID
> >is omitted or not supported.
> >
> >  
> >
> ok, you are the second person to suggest this. I am not opposed to 
> making it mandatory.
> 
> >(4) If the GR ID is mandatory, could we use the same format 
> as the PWid FEC
> >for the first 8 bytes, followed by the AGI, SAII, TAII etc. ?
> >
> >  
> >
> that , Eric has a problem with. He does not want the Gr ID in 
> the FEC. 
> To accommodate this the GR ID needs to be last, and only used in the 
> wild card withdraw status  messages.
> 
> >(5) Does the PW Info Length include the GR ID?  If so it 
> might be helpful to
> >require this in all cases, rather than use PW Info Length = 
> 0 to indicate
> >"Only GR ID present".  Or do you intend the PW Info Length 
> to exclude the GR
> >ID (like the Group ID in the PWid FEC)?
> >
> >  
> >
> no. Here the GR ID is identified by a type == 0, SO in theory 
> we don't 
> even need to set the length to 0.
> I'm open to suggestions on this point.
> 
> >(6) Is the Label Release "GR ID not supported" needed?  Or could the
> >receiver just ignore the GR ID?  Obviously the receiver wouldn't use
> >wildcard label withdraw or wildcard PW status notifications, but that
> >wouldn't matter to the downstream node.  Am I missing something?
> >
> >  
> >
> yes,  the transmitter is the PE that will issue a wild card PW status 
> notification, hence if the receiver of the gr ID ingnores it 
> , it will 
> not be able to process the wild card  status/withdraw 
> messages correctly.
> 
> >Thanks,
> >
> >	Nick.
> >
> >  
> >
> Please CC the PWE3 list if you don't mind with the next 
> response. This 
> way we show some interest and support for this.
> 
> Thanks.
> Luca
> 
> >>-----Original Message-----
> >>From: Luca Martini [mailto:[email-masked]]
> >>Sent: 27 April 2004 23:04
> >>To: [email-masked]
> >>Subject: [PWE3] Generalized PWID FEC and the question of 
> the Group ID
> >>
> >>
> >>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
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>_______________________________________________
> >>pwe3 mailing list
> >>[email-masked]
> >>https://www1.ietf.org/mailman/listinfo/pwe3
> >>
> >>    
> >>
> >
> >  
> >
>

---

From: Eric Rosen <[email-masked]>
Date: Fri, 07 May 2004 10:28:54 -0400

I'd like to see both the  group id and the interface parameters removed from
the FEC  element entirely, and  carried in separate  LDP TLVs.  I  know Luca
doesn't like that idea :-); I'd be interested in what others think.