[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: spc connections

Dimitri,

The reason that the SPC Label (or Egress Label) should be in a separate object from the ERO
is that the ERO may be ignored.

This is not unrelated to the source of the information, in that the ERO is provided by some
network control or administrative entity while the call endpoint identificaiton is provided by the entity
requesting the service. In fulfilling a service request, a service provider may disregard the ERO
but may not disregard the service request. Thus it makes perfect sense to keep these pieces
of information in separate objects.

Regards,
Ben

Dimitri Papadimitriou wrote:

lyndon, the fact that you may receive the "information" from an nms/ems, manually configured, or any other means does not have to impact the external behaviour of the protocol - what you suggest is the use of a
mechanism that would depend on the originator of the "information" -

while rfc 3473 specifies in section 5.1.1:
"Procedures by which an LSR at the head-end of an LSP obtains the
information needed to construct the Label subobject are outside the
scope of this document."

the only thing that needs to be specified for this subobject is the
placement and ordering in the ERO (as specified in the same section)

in addition - and as far as my understanding goes - there are no functional requirements mandating - this should be somewhat obvious -
the implementation specific mechanism you describe here below

hope this will help you to understand what we're trying to explain
you since last monday (john, adrian, etc. via private and public
e-mails)

thanks,
- dimitri.



This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C3AAF3.F61BAE90
Content-Type: text/plain;
	charset="ks_c_5601-1987"

Hi John,

I apologize for being an uninformed reader :o)  As such I can only rely on the text in
3473, which is very specific and does not discuss SPC labels.

It probably seems intuitively very obvious to you because you have had this in mind
for a while.  It is not necessarily obvious from all points of view.  I see a reasonable
case to be made that an SPC label, being passed down from the management system,
should be in a separate object from the ERO, which may typically be calculated by the
source endpoint rather than passed down from the management system.

Cheers,

Lyndon

-----Original Message-----
From: John Drake [mailto:jdrake@calient.net]
Sent: Friday, November 14, 2003 12:48 PM
To: Ong, Lyndon; 'yhwkim@etri.re.kr'; jonathan.sadler@tellabs.com
Cc: adrian@olddog.co.uk; kireeti@juniper.net; ccamp@ops.ietf.org
Subject: RE: spc connections


Lyndon,

This will be my last post on this topic.

I helped write RFC3471 and RFC3473, and SPC support was always an integral part of them, as Adrian's note informed you.

If you are referring to your original question on this topic, I think the proper response is that it should be blindingly obvious to the informed reader that the egress node doesn't have to put the explicit label for the next hop into a Label Set in the outgoing Path message, because there is no outgoing Path message.

Thanks,

John


------_=_NextPart_001_01C3AAF3.F61BAE90
Content-Type: text/html;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dks_c_5601-1987">
<TITLE>[=C0=FC=C3=BC=C8=B8=BD=C5] Re: [ AuA=A8=F9E=A2=AC=A8=F6A ] spc =
connections</TITLE>

<META content=3D"MSHTML 5.50.4522.1800" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D738125620-14112003><FONT face=3DArial =
color=3D#0000ff size=3D2>Hi=20
John,</FONT></SPAN></DIV>
<DIV><SPAN class=3D738125620-14112003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D738125620-14112003><FONT face=3DArial =
color=3D#0000ff size=3D2>I=20
apologize for being an uninformed reader :o)&nbsp;&nbsp;As such&nbsp;I =
can only=20
rely on the text in</FONT></SPAN></DIV>
<DIV><SPAN class=3D738125620-14112003><FONT face=3DArial =
color=3D#0000ff size=3D2>3473,=20
which is very specific and does not discuss SPC =
labels.</FONT></SPAN></DIV>
<DIV><SPAN class=3D738125620-14112003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D738125620-14112003><FONT face=3DArial =
color=3D#0000ff size=3D2>It=20
probably seems intuitively very obvious to you because you have had =
this in=20
mind</FONT></SPAN></DIV>
<DIV><SPAN class=3D738125620-14112003><FONT face=3DArial =
color=3D#0000ff size=3D2>for a=20
while.&nbsp; It is not necessarily obvious from all points of =
view.&nbsp; I see=20
a reasonable</FONT></SPAN></DIV>
<DIV><SPAN class=3D738125620-14112003><FONT face=3DArial =
color=3D#0000ff size=3D2>case=20
to be made that an SPC label, being passed down from the management=20
system,</FONT></SPAN></DIV>
<DIV><SPAN class=3D738125620-14112003><FONT face=3DArial =
color=3D#0000ff size=3D2>should=20
be in a separate object from the ERO, which may typically be calculated =
by=20
the</FONT></SPAN></DIV>
<DIV><SPAN class=3D738125620-14112003><FONT face=3DArial =
color=3D#0000ff size=3D2>source=20
endpoint rather than passed down from the management =
system.</FONT></SPAN></DIV>
<DIV><SPAN class=3D738125620-14112003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D738125620-14112003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>Cheers,</FONT></SPAN></DIV>
<DIV><SPAN class=3D738125620-14112003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D738125620-14112003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>Lyndon</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
 <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
 size=3D2>-----Original Message-----<BR><B>From:</B> John Drake=20
 [mailto:jdrake@calient.net]<BR><B>Sent:</B> Friday, November 14, 2003 =
12:48=20
 PM<BR><B>To:</B> Ong, Lyndon; 'yhwkim@etri.re.kr';=20
 jonathan.sadler@tellabs.com<BR><B>Cc:</B> adrian@olddog.co.uk;=20
 kireeti@juniper.net; ccamp@ops.ietf.org<BR><B>Subject:</B> RE: spc=20
 connections<BR><BR></FONT></DIV>
 <DIV><SPAN class=3D605323620-14112003><FONT face=3DArial =
color=3D#0000ff=20
 size=3D2>Lyndon,</FONT></SPAN></DIV>
 <DIV><SPAN class=3D605323620-14112003><FONT face=3DArial =
color=3D#0000ff=20
 size=3D2></FONT></SPAN>&nbsp;</DIV>
 <DIV><SPAN class=3D605323620-14112003><FONT face=3DArial =
color=3D#0000ff size=3D2>This=20
 will be my last post on this topic.</FONT></SPAN></DIV>
 <DIV><SPAN class=3D605323620-14112003><FONT face=3DArial =
color=3D#0000ff=20
 size=3D2></FONT></SPAN>&nbsp;</DIV>
 <DIV><SPAN class=3D605323620-14112003><FONT face=3DArial =
color=3D#0000ff size=3D2>I=20
 helped write RFC3471 and RFC3473, and SPC support was always an =
integral part=20
 of them, as Adrian's note informed&nbsp; you.</FONT></SPAN></DIV>
 <DIV><SPAN class=3D605323620-14112003><FONT face=3DArial =
color=3D#0000ff=20
 size=3D2></FONT></SPAN>&nbsp;</DIV>
 <DIV><SPAN class=3D605323620-14112003><FONT face=3DArial =
color=3D#0000ff size=3D2>If=20
 you are referring to your original question on this topic, I think =
the proper=20
 response is&nbsp;that it should be blindingly obvious to the informed =
reader=20
 that the egress node doesn't have to put the explicit label for the =
next hop=20
 into a Label Set in the outgoing Path message, because there is no =
outgoing=20
 Path message.&nbsp;</FONT></SPAN></DIV>
 <DIV><SPAN class=3D605323620-14112003><FONT face=3DArial =
color=3D#0000ff=20
 size=3D2></FONT></SPAN>&nbsp;</DIV>
 <DIV><SPAN class=3D605323620-14112003><FONT face=3DArial =
color=3D#0000ff=20
 size=3D2>Thanks,</FONT></SPAN></DIV>
 <DIV><SPAN class=3D605323620-14112003><FONT face=3DArial =
color=3D#0000ff=20
 size=3D2></FONT></SPAN>&nbsp;</DIV>
 <DIV><SPAN class=3D605323620-14112003><FONT face=3DArial =
color=3D#0000ff=20
 size=3D2>John</FONT></SPAN></DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C3AAF3.F61BAE90--











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