[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: spc connections
Just another 2 cents.
Lyndon correctly says that 3473 does not make the use of egress label control properly
clear.
John and Lou are right that the intention of the authors was to embrace egress label
control.
Two small points worry me.
Lyndon says
...the ERO, which may typically be calculated by the
source endpoint rather than passed down from the management system.
and Ben says
> In fulfilling a service request, a service provider may disregard the ERO
> but may not disregard the service request.
Why is the ERO not considered as part of the service request?
For example, the service requester may have some strong views about which nodes should be
included on the path.
The service provider may run path computation on the (partial) ERO supplied by the
requester.
Even when the ERO from the requester is otherwise empty, it *could* contain the
destination node and egress label.
I think we are arguing about whether implementations can be produced for one solution or
the other. I'm sure they can.
In the debate about whether we have or need to have more than one solution, we should look
at what has been implemented and deployed. We can then decide whether it is harmful to
have two solutions, and whether we need to deprecate one of them.
Adrian
----- Original Message -----
From: "Ben Mack-Crane" <ben.mack-crane@tellabs.com>
To: "Dimitri Papadimitriou" <dpapadimitriou@psg.com>
Cc: "Ong, Lyndon" <LyOng@Ciena.com>; "'John Drake'" <jdrake@calient.net>;
<yhwkim@etri.re.kr>; <Jonathan.Sadler@tellabs.com>; <adrian@olddog.co.uk>;
<kireeti@juniper.net>; <ccamp@ops.ietf.org>
Sent: Friday, November 14, 2003 10:31 PM
Subject: 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> </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
> ============================================================
>
>
>