-----Original Message-----John -
From: Jonathan Sadler [mailto:jonathan.sadler@tellabs.com]
Sent: Friday, November 21, 2003 9:24 AM
To: John Drake
Cc: 'Ong, Lyndon'; 'ccamp@ops.ietf.org'
Subject: Re: SPCsTo paraphrase a previous message in this discussion:
Do you keep repeating yourself with the idea that it will make it so?Bringing this back to a technical discussion -- I don't believe
that we have agreement regarding 3473 and:
- a concept of call with call attributes (3474 handles this
using the Generalized_UNI object)JD: No one claimed RFC3471/3473 supported calls. That's why
we have draft-dimitri-ccamp-gmpls-rsvp-te-ason. RFC3474 handles
one bundled call/connection.
- a concept of call addressing that allows service providers to
keep network resource names (SNPP and SNP names) and their formats
private (3474 handles this through TNA addresses, port identifier
and egress label)JD: This is handled in RFC3471/3473. The Sender Template/Session Object identifies the globally
unique ingress/egress LSP endpoints. As you indicated, the egress label needs to be known globally,
whether it is carried in the Generalized_UNI object or in the last hop of an ERO. Incidentally, the
ERO either an RFC 3473 or an RFC 3474 multi-domain network is going to be the same except for
the explicit label in the last hop. See http://www.ietf.org/internet-drafts/draft-ayyangar-inter-region-te-01.txt
- the handling of SPCs through the same Call process as UNI requests
(which has implications for SPC/UNI interworking issues)JD: According to G.7713, an SPC call is established in a completely
different manner than an SVC call. Kireeti's proposed text for the
overlay draft detailed UNI/SPC connection interworking.
Emails on these issues have been sent to the without response. Perhaps we should continue the technical discussion.
Jonathan Sadler
John Drake wrote:
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
>
============================================================
The information contained in this message may be privileged
and confidential and protected from disclosure. If the
reader of this message is not the intended recipient, or an
employee or agent responsible for delivering this message to
the intended recipient, you are hereby notified that any
reproduction, dissemination or distribution of this
communication is strictly prohibited. If you have received
this communication in error, please notify us immediately by
replying to the message and deleting it from your computer.
Thank you.
Tellabs
============================================================