RE: SPCs

[John Drake <jdrake@calient.net>]

To quote a former President, "There you go again".

We're done

Thanks,

John

> -----Original Message-----
> From: Ong, Lyndon [mailto:LyOng@Ciena.com]
> Sent: Thursday, November 20, 2003 11:18 PM
> To: John Drake; 'ccamp@ops.ietf.org'
> Subject: RE: SPCs
> 
> 
> Hi John,
> 
> Thanks for reading RFC 3474 :o)  Note that it says "may provide
> a mechanism" as opposed to "already defines a mechanism". No
> one is arguing that explicit label control *cannot* be used
> (with "clarification" as the editor has already suggested),
> the argument is over whether it is already supported in 3473
> and whether this is the right mechanism compared to
> an SPC_Label subobject.
> 
> Note also neither 3471 or 3473 contain the terms "soft permanent
> connection", "spc" or "egress label".
> 
> Cheers,
> 
> Lyndon
> 
> 
> -----Original Message-----
> From: John Drake [mailto:jdrake@calient.net]
> Sent: Thursday, November 20, 2003 8:08 AM
> To: 'ccamp@ops.ietf.org'
> Subject: SPCs
> 
> 
> I thought it might be useful to see what RFC3474 actually 
> says about SPCs:
> 
> "The processing of the SPC_LABEL sub-object follows that of the
>    EGRESS_LABEL sub-object [OIF-UNI1].  Note that although 
> the explicit
>    label control described in [RFC3471] and [RFC3473] may provide a
>    mechanism to support specifying the egress label in the context of
>    supporting the GMPLS application, the SPC services support for the
>    ASON model uses the GENERALIZED_UNI object for this 
> extension to help
>    align the model for both switched connection and soft permanent
>    connection, as well as to use the service level and diversity
>    attributes of the GENERALIZED_UNI object."
> 
> A few observations:
> 
> 1)  I don't think any clarifications to RFC3471/3473 wrt egress node
> explicit label
> control are required.  If the authors of RFC3474 can figure 
> out the correct
> behavior,
> I'm sure anyone else can.
> 
> 2)  Any divergence between RFC3471/3473 and RFC3474 is clearly the
> responsibility
> of the authors of RFC3474.
> 
> 3)  'call' vs 'connection' is not cited as one of the reasons for this
> divergence.
> In fact, once again 'connection' is used in the text.  (I'm 
> not surprised,
> as the
> GENERALIZED_UNI object was defined in OIF UNI 1.0, which 
> doesn't support
> calls.)
> 
> 4)  The diversity attribute is completely useless in the 
> multi-domain case,
> since
> it is a list of connections within the context of a specific 
> UNI.  No border
> node
> is going to have any way to identify those connections or 
> determine how they
> are
> routed.
> 
> 5)  I thought "the SPC services support for the ASON model uses the
> GENERALIZED_UNI
> object" was rather imperious.  It's pretty clear that the 
> GENERALIZED_UNI
> object
> is not required by the ASON model.
>  
> Thanks,
> 
> John
> 
> John Drake
> Calient Networks
> 5853 Rue Ferrari
> San Jose, CA 95138
> jdrake@calient.net
> 408 972-3720 
>