[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: spc connections
ben,
your response is confusing what you say is that
the operator at the as boundary can accept a call
that specifies accessing a specific end-point but
does not accept the connection request associated
to this call - does this make any sense ?
more fundamentally, i don't see where the delivery
of call functionality for spc's does have to imply
some implementation specific restrictions to fulfil
this functional requirement ? when you point out
here that the "ERO may be disregarded" it becomes
a protocol requirement not a functional requirement
and afaik G.8080 does have nothing to do with any
implementation specifics
now concerning the source of information, you're
mismatching what lyndon said "passing information
from the management to the control plane" with
the control plane exchange of information between
call/connection controllers
the conclusion, as also drawn by several people on
this list seem clear:
"There is no change in protocol to enable this function,
merely a description of how it all works."
something that will be addressed in order to avoid
spreading of misunderstanding
thanks,
- dimitri.
> 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> </DIV>
> >><DIV><SPAN class=3D738125620-14112003><FONT face=3DArial =
> >>color=3D#0000ff size=3D2>I=20
> >>apologize for being an uninformed reader :o) As such 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> </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. It is not necessarily obvious from all points of =
> >>view. 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> </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> </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> </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> </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 you.</FONT></SPAN></DIV>
> >> <DIV><SPAN class=3D605323620-14112003><FONT face=3DArial =
> >>color=3D#0000ff=20
> >> size=3D2></FONT></SPAN> </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 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. </FONT></SPAN></DIV>
> >> <DIV><SPAN class=3D605323620-14112003><FONT face=3DArial =
> >>color=3D#0000ff=20
> >> size=3D2></FONT></SPAN> </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> </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
> ============================================================
>
>
>