headers
Adrian Farrel | 1 Oct 2007 12:28
Picon

Security directorate review of draft-ietf-pce-interas-pcecp-reqs-03

Hi,

We asked the Security Area Directorate to provide us with an early review of 
draft-ietf-pce-interas-pcep-reqs. Recently, a fair number of I-Ds from PCE 
and CCAMP have been falling at the security hurdle during IESG review. This 
seems to be particularly the case for inter-AS work, so we thought that we 
should try to get some feed-back before we go to WG last call, and see if we 
can produce a draft that better addresses the Security AD's concerns.

We received comments from Sandy Murphy and Pasi Eronen as shown below. The 
chairs will be working with the document authors to revise the text to 
address the issues raised, but we would all be more than grateful for other 
comments and assistance.

Thanks,
Adrian

+++++ <begin Sandy Murphy>

This draft specifies the requirements for a PCE communication
protocol, i.e., a protocol between PCC and PCE or inter-PCE, when the
communication is taking place across AS boundaries.  This AS boundary
could be within one service provider or may be between service
providers.  The PCEs compute paths for the establishment of LSPs
satisfying PCC provided constraints.

This document refers to the security considerations of RFC4657, which
mandates support for protections agains spoofing, snooping and DOS
between the entities.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Giovanni Martinelli (giomarti | 1 Oct 2007 14:44
Picon
Favicon

RE: Some key issues with Wavelength Switched Optical Networks...

Hi Greg,
 

From: Greg Bernstein [mailto:gregb <at> grotto-networking.com]
Sent: venerdì 28 settembre 2007 21.47
To: Giovanni Martinelli (giomarti)
Cc: ccamp; pce <at> ietf.org
Subject: Re: [Pce] Some key issues with Wavelength Switched Optical Networks...

Hi Giovanni, thanks for the close read.  Looks like you caught some problems with the text.  See below for comments.

Giovanni Martinelli (giomarti) wrote:
Hi Greg,
 
Sorry for the delay in replying. I'm working on this topic since a while so yes, it's interesting. Before going on specific issue I would have some question/clarification regarding the draft itself.
 
 
* Within Abstract and the following.
You don't talk about Optical Cross Connects (OXC) is something missing or understated somewhere?
-->Whoops.  We were trying to find a more general term to include both ROADM (usually a highly asymmetric fabric) and an OXC (a completely symmetric fabric, e.g., any ingress to any egress), but we seemed to have gone with using the ROADM terminology to include both cases.  Talked with some equipment makers that planned/make "switches" that seemed to incorporate both so we made sure the model could deal with both sparse and dense potential connectivity. Diego had some terminology ideas but lately his e-mails have been bouncing back to me.  Any suggestions are appreciated, but we are including both ROADM and OXCs. 
 
My doubt was coming from the ROADM definition in section 2 and picture used later on the draft. At  least in my understanding the OXC is a general case for ROADM (sort of multi-degree ROADM) but ok, it's a matter of terminology.

 
 
 
* Section 3.1 where you state:
"A fixed mapping between the
GMPLS label space and these ITU-T WDM grids as proposed in [Otani] "
Does it implies a sort of network level label space? How relate with usual local label significance?
--> This mapping gives a mapping between labels and wavelengths/lambda, just like in the SONET/SDH case we mapped the ITU-T G.707 "S, U, K, L, M " identification of SDH time slots to a label format in RFC4606 and again this was done in RFC4328 to map G.709 digital wrapper time slot identification into a technology specific label format.  In RFC3471 for lambda switching we just get a 32 bit integer with no meaning attached. Every network and every node could potentially map labels to lambdas in a different way. In [Otani] they are following the RFC4606 and RFC4328 lead and using the ITU-T DWDM and CWDM lambda grid standards to give a fixed association between labels and lambdas just like between labels and TDM time slots in the SDH/ODU case.

This doesn't change the local significance of labels. In the wavelength switched optical case that is influenced by the presence or absence of wavelength converters. 
 
Ok. Local significance  but global semantic (as pointed out by Adrian in a previous mail). 
 
 
* Section 3.4 Wavelength Converters
"Current or envisioned contexts for wavelength converters are : ..."
Could we think to a description/model for wavelength converter that is technology agnostic? Simply something like: full conversion capability, partial conversion capability with some constrains, and may be others.
--> The difference, between the all optical techniques and the OEO based techniques makes that difficult.
 
 
* Section 3.4. the following:
"4. Wavelength converters that are O-E-O based will have a restriction
based on the modulation format and transmission speed"
Not clear to me the type of restriction here when OEO happens... probably I'm missing what you mean here.
--> For example a typical O-E-O based wavelength converter would be build around a 3R regenerator with a tunable laser. A 3R regenerator cares about the modulation type say NRZ or RZ (and which flavor), and the symbol rate since its also doing retiming. An all optical wavelength converter will be fairly independent of these issues (except when we look at impairment factors). Hence the OEO wavelength is going to be more signal specific than the all optical. 
 
ok more clear now, although it would be nice having a general model as you marked  with TBD. 
 
 
* Section 4.1 when you talk about Lightpath temporal characteristics:
"Lightpath connection duration has typically been thought of as
approximately three time frames: "
and the following you define: dynamics, pseudo-static, static.
Why there’s a need of this classification? When you us Short/long is compared to what?
--> In most of the research literature and in optimization practice different techniques are typically used in the dynamic versus static (or psuedo static cases).  In MPLS there is minimum interference routing optimization techniques for the dynamic case. For the static case I could apply multi-commodity flow optimization techniques to a batch of connections.  In the RWA literature there is a similar differentiation.  Exactly what information could be sent to help PCE differentiate I'm not sure. In the case of static, batch optimization we can just use the existing concurrent optimization hooks in PCE. For an individual lightpath request it seemed that it would be helpful to know how long the connection would last so we'd know how much computational effort we might want to put into optimize it. 
 
ok, clear. I still have doubt about quantifiers but fine for the moment.
 
Thanks,
Giovanni

 
 
minor typo on your mail below: point (c) rfc4328 (not 4238) right?
--> Yes.  The G.709 signaling extensions RFC.
 
Thanks,
Giovanni


 

From: Greg Bernstein [mailto:gregb <at> grotto-networking.com]
Sent: giovedì 27 settembre 2007 1.42
To: ccamp; pce <at> ietf.org
Subject: [Pce] Some key issues with Wavelength Switched Optical Networks...

Hi folks, I haven't seen too many comments on our draft "Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks" ( http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switched-01.txt). So I figured I'd point out some potentially controversial issues that the draft brings up.

(a) The draft brings up models for the following WDM network elements:
  1. WDM links
  2. Optical transmitters
  3. Wavelength Converters and OEO regenerators
  4. ROADMs, FOADMs, optical splitters and combiners.
    For items (3) and (4) we are taking the modeling lead rather than some other SDO.  And for ROADMs, in particular, we going beyond the classic ITU-T "fabric" model (M.3100) which has been the mainstay of any connection oriented switch (TDM, ATM, MPLS).

(b) The draft brings up three (not one, not two, but three) different computational models for RWA which can impact GMPLS and PCE protocols:
  1. A single PCE computing both the path and wavelength
  2. Two distinct PCEs, where one computes the path, and a different PCE computes the wavelength assignment
  3. A PCE computes the path and wavelength assignment is accomplished in a distributed fashion via signaling (e.g., using label set objects)
    Do we really need all three models?

(c) G.709 includes the Optical Multiplex Section and Optical Channels.  RFC4238 was aimed at GMPLS extensions for G.709  (Optical Transport Network) control.  Weren't we finished with all this optical stuff years ago?

I'd like to think the draft answers some of these questions.  I also think that network element models and the process models are important enough to warrant this separate framework document.  Your opinions are solicited.

Regards

Greg B.
-- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237

-- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 
<div>
<div dir="ltr" align="left"><span class="125193711-01102007">Hi Greg,</span></div>
<div dir="ltr" align="left">
<span class="125193711-01102007"></span>&nbsp;</div>
<br><blockquote dir="ltr">
  <div class="OutlookMessageHeader" lang="en-us" dir="ltr" align="left">
  From: Greg Bernstein 
  [mailto:gregb <at> grotto-networking.com] <br>Sent: venerd&igrave; 28 settembre 
  2007 21.47<br>To: Giovanni Martinelli (giomarti)<br>Cc: ccamp; 
  pce <at> ietf.org<br>Subject: Re: [Pce] Some key issues with Wavelength 
  Switched Optical Networks...<br><br>
</div>
  <div></div>Hi Giovanni, thanks for the close read.&nbsp; Looks like you caught 
  some problems with the text.&nbsp; See below for comments.<br><br>Giovanni 
  Martinelli (giomarti) wrote: 
  <blockquote cite="mid:1F2FBF50FB955441A11316BAE835CED4042D142B <at> xmb-ams-338.emea.cisco.com" type="cite">
    <div dir="ltr" align="left">Hi 
Greg,</div>
    <div dir="ltr" align="left">&nbsp;</div>
    <div dir="ltr" align="left">Sorry for the 
    delay in replying. I'm working on this topic since a while so yes, it's 
    interesting. Before going on specific issue I would have some 
    question/clarification regarding the draft itself. </div>
    <div dir="ltr" align="left">&nbsp;</div>
    <div dir="ltr" align="left">&nbsp;</div>
    <div dir="ltr" align="left">* Within Abstract 
    and the following.</div>
    <div dir="ltr" align="left">You don't talk about 
    Optical Cross Connects (OXC) is something missing or understated 
    somewhere?</div>
</blockquote>
  <div>--&gt;Whoops.&nbsp; We were trying to find a more general term to include 
  both ROADM (usually a highly asymmetric fabric) and an OXC (a completely 
  symmetric fabric, e.g., any ingress to any egress), but we seemed to have gone 
  with using the ROADM terminology to include both cases.&nbsp; Talked with some 
  equipment makers that planned/make "switches" that seemed to incorporate both 
  so we made sure the model could deal with both sparse and dense potential 
  connectivity. Diego had some terminology ideas but lately his e-mails have 
  been bouncing back to me.&nbsp; Any suggestions are appreciated, but we are 
  including both ROADM and OXCs.<span class="125193711-01102007">&nbsp;</span>
</div>
  <div>
<span class="125193711-01102007"></span>&nbsp;</div>
</blockquote>
<div dir="ltr"><span class="125193711-01102007">My doubt was coming from the ROADM definition in section 2 and picture 
used later on the draft. At&nbsp; least in my understanding the OXC is a general 
case for ROADM (sort of multi-degree ROADM) but ok, it's a matter of 
terminology.</span></div>
<div dir="ltr">
<span class="125193711-01102007"></span><br>&nbsp;</div>
<blockquote dir="ltr">
  <blockquote cite="mid:1F2FBF50FB955441A11316BAE835CED4042D142B <at> xmb-ams-338.emea.cisco.com" type="cite">
    <div dir="ltr" align="left">&nbsp;</div>
    <div dir="ltr" align="left">&nbsp;</div>
    <div dir="ltr" align="left">* Section 3.1 
    where you state: </div>
    <div dir="ltr" align="left">"A fixed 
    mapping between the </div>
    <div dir="ltr" align="left">GMPLS label space 
    and these ITU-T WDM grids as proposed in [Otani] "</div>
    <div dir="ltr" align="left">Does it implies a 
    sort of network level label space? How relate with usual local label 
    significance?</div>
</blockquote>
  <div>--&gt; This mapping gives a mapping between labels and 
  wavelengths/lambda, just like in the SONET/SDH case we mapped the ITU-T G.707 
  "S, U, K, L, M " identification of SDH time slots to a label format in RFC4606 
  and again this was done in RFC4328 to map G.709 digital wrapper time slot 
  identification into a technology specific label format.&nbsp; In RFC3471 for 
  lambda switching we just get a 32 bit integer with no meaning attached. Every 
  network and every node could potentially map labels to lambdas in a different 
  way. In [Otani] they are following the RFC4606 and RFC4328 lead and using the 
  ITU-T DWDM and CWDM lambda grid standards to give a fixed association between 
  labels and lambdas just like between labels and TDM time slots in the SDH/ODU 
  case.<br><br>This doesn't change the local significance of labels. In the 
  wavelength switched optical case that is influenced by the presence or absence 
  of wavelength converters.<span class="125193711-01102007">&nbsp;</span>
</div>
  <div>
<span class="125193711-01102007"></span>&nbsp;</div>
</blockquote>
<div dir="ltr">
<span class="125193711-01102007">Ok. Local significance&nbsp; but global semantic (as pointed out by 
Adrian in a previous mail).&nbsp;</span><br>
</div>
<blockquote dir="ltr">
  <blockquote cite="mid:1F2FBF50FB955441A11316BAE835CED4042D142B <at> xmb-ams-338.emea.cisco.com" type="cite">
    <div dir="ltr" align="left">&nbsp;</div>
    <div dir="ltr" align="left">&nbsp;</div>
    <div dir="ltr" align="left">* Section 3.4 
    Wavelength Converters </div>
    <div dir="ltr" align="left">"Current or 
    envisioned contexts for wavelength converters are : ..."</div>
    <div dir="ltr" align="left">Could we&nbsp;<span class="312013122-27092007">think to </span>a description/model for wavelength 
    converter that is technology agnostic?&nbsp;<span class="312013122-27092007">S</span><span class="312013122-27092007">imply 
    s</span>omething like: full conversion capability, partial conversion 
    capability with some constrains, and may be 
  others.</div>
</blockquote>--&gt; The difference, between the all 
  optical techniques and the OEO based techniques makes that difficult.<br><blockquote cite="mid:1F2FBF50FB955441A11316BAE835CED4042D142B <at> xmb-ams-338.emea.cisco.com" type="cite">
    <div dir="ltr" align="left">&nbsp;</div>
    <div dir="ltr" align="left">&nbsp;</div>
    <div dir="ltr" align="left">* Section 3.4. 
    the following: </div>
    <div dir="ltr" align="left">"4. Wavelength 
    converters that are O-E-O based will have a restriction </div>
    <div dir="ltr" align="left">based on the 
    modulation format and transmission speed" </div>
    <div dir="ltr" align="left">Not clear to me the 
    type of restriction here when OEO happens... probably I'm missing what you 
    mean here.</div>
</blockquote>
  <div>--&gt; For example a typical O-E-O based wavelength converter would be 
  build around a 3R regenerator with a tunable laser. A 3R regenerator cares 
  about the modulation type say NRZ or RZ (and which flavor), and the symbol 
  rate since its also doing retiming. An all optical wavelength converter will 
  be fairly independent of these issues (except when we look at impairment 
  factors). Hence the OEO wavelength is going to be more signal specific than 
  the all optical.<span class="125193711-01102007">&nbsp;</span>
</div>
  <div>
<span class="125193711-01102007"></span>&nbsp;</div>
</blockquote>
<div dir="ltr">
<span class="125193711-01102007">ok&nbsp;more clear now, although it would be nice having&nbsp;a general 
model as you marked&nbsp; with TBD.&nbsp;</span><br>
</div>
<blockquote dir="ltr">
  <blockquote cite="mid:1F2FBF50FB955441A11316BAE835CED4042D142B <at> xmb-ams-338.emea.cisco.com" type="cite">
    <div dir="ltr" align="left">&nbsp;</div>
    <div dir="ltr" align="left">&nbsp;</div>
    <div dir="ltr" align="left">* Section 4.1 when 
    you talk about Lightpath temporal characteristics:</div>
    <div dir="ltr" align="left">"Lightpath 
    connection duration has typically been thought of as </div>
    <div dir="ltr" align="left">approximately 
    three time frames: " </div>
    <div dir="ltr" align="left">and the following 
    you define: dynamics, pseudo-static, static.</div>
    <div dir="ltr" align="left">Why there&#146;s a need 
    of this classification? When you us Short/long is compared to 
    what?</div>
</blockquote>
  <div>--&gt; In most of the research literature and in optimization practice 
  different techniques are typically used in the dynamic versus static (or 
  psuedo static cases).&nbsp; In MPLS there is minimum interference routing 
  optimization techniques for the dynamic case. For the static case I could 
  apply multi-commodity flow optimization techniques to a batch of 
  connections.&nbsp; In the RWA literature there is a similar 
  differentiation.&nbsp; Exactly what information could be sent to help PCE 
  differentiate I'm not sure. In the case of static, batch optimization we can 
  just use the existing concurrent optimization hooks in PCE. For an individual 
  lightpath request it seemed that it would be helpful to know how long the 
  connection would last so we'd know how much computational effort we might want 
  to put into optimize it.<span class="125193711-01102007">&nbsp;</span>
</div>
  <div>
<span class="125193711-01102007"></span>&nbsp;</div>
</blockquote>
<div dir="ltr"><span class="125193711-01102007">ok, clear. I still have doubt about quantifiers but fine for the 
moment.</span></div>
<div>
<span class="125193711-01102007"></span>&nbsp;</div>
<div><span class="125193711-01102007">Thanks,</span></div>
<div><span class="125193711-01102007">Giovanni</span></div>
<div dir="ltr"><br></div>
<blockquote dir="ltr">
  <blockquote cite="mid:1F2FBF50FB955441A11316BAE835CED4042D142B <at> xmb-ams-338.emea.cisco.com" type="cite">
    <div dir="ltr" align="left">&nbsp;</div>
    <div dir="ltr" align="left">&nbsp;</div>
    <div dir="ltr" align="left"><span class="312013122-27092007">minor typo on your mail below: point (c) rfc4328 
    (not 4238) right?</span></div>
</blockquote>--&gt; Yes.&nbsp; The G.709 
  signaling extensions RFC.<br><blockquote cite="mid:1F2FBF50FB955441A11316BAE835CED4042D142B <at> xmb-ams-338.emea.cisco.com" type="cite">
    <div dir="ltr" align="left">&nbsp;</div>
    <div dir="ltr" align="left">Thanks,</div>
    <div dir="ltr" align="left">Giovanni</div>
    <p><br>&nbsp;</p>
    <blockquote dir="ltr">
      <div class="OutlookMessageHeader" lang="en-us" dir="ltr" align="left">
      From: Greg Bernstein [<a class="moz-txt-link-freetext" href="mailto:gregb <at> grotto-networking.com">mailto:gregb <at> grotto-networking.com</a>] 
      <br>Sent: gioved&igrave; 27 settembre 2007 1.42<br>To: ccamp; <a class="moz-txt-link-abbreviated" href="mailto:pce <at> ietf.org">pce <at> ietf.org</a><br>Subject: [Pce] Some 
      key issues with Wavelength Switched Optical 
      Networks...<br><br>
</div>Hi folks, I haven't seen too many comments 
      on our draft "Framework for GMPLS and PCE Control of Wavelength Switched 
      Optical Networks" ( <a href="http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switched-01.txt" moz-do-not-send="true">http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switched-01.txt</a>). 
      So I figured I'd point out some potentially controversial issues that the 
      draft brings up. <br><br>(a) The draft brings up models for the following 
      WDM network elements:<br><ol>
<li>WDM links 
        </li>
<li>Optical transmitters<br>
</li>
<li>Wavelength Converters and OEO regenerators 
        </li>
<li>ROADMs, FOADMs, optical splitters and combiners. 
      </li>
</ol>&nbsp;&nbsp;&nbsp; For items (3) and (4) we are taking the 
      modeling lead rather than some other SDO.&nbsp; And for ROADMs, in 
      particular, we going beyond the classic ITU-T "fabric" model (M.3100) 
      which has been the mainstay of any connection oriented switch (TDM, ATM, 
      MPLS).<br><br>(b) The draft brings up three (not one, not two, but three) 
      different computational models for RWA which can impact GMPLS and PCE 
      protocols:<br><ol>
<li>A single PCE computing both the path and wavelength 
        </li>
<li>Two distinct PCEs, where one computes the path, and a different PCE 
        computes the wavelength assignment 
        </li>
<li>A PCE computes the path and wavelength assignment is accomplished in 
        a distributed fashion via signaling (e.g., using label set objects) 
      </li>
</ol>&nbsp;&nbsp;&nbsp; Do we really need all three 
      models?<br><br>(c) G.709 includes the Optical Multiplex Section and 
      Optical Channels.&nbsp; RFC4238 was aimed at GMPLS extensions for 
      G.709&nbsp; (Optical Transport Network) control.&nbsp; Weren't we finished 
      with all this optical stuff years ago?<br><br>I'd like to think the draft 
      answers some of these questions.&nbsp; I also think that network element 
      models and the process models are important enough to warrant this 
      separate framework document.&nbsp; Your opinions are 
      solicited.<br><br>Regards<br><br>Greg B.<br>-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

    </blockquote>
</blockquote>
<br>-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

</blockquote>
</div>
Permalink | Reply | 0 comments |
headers
Diego Caviglia | 1 Oct 2007 17:16
Picon
Favicon

RE: [Pce] Some key issues with Wavelength Switched Optical Networks...

Hi Igor hi Greg,

                      I think this is a very interesting discussion.  

 

IMHO the point Igor raised is on the boundary between network planning and circuit provisioning I mean the decision to have a node with/without conversion capability is a planning decision, likely dependent by a given traffic forecast and a physical topology.  Moreover the same consideration applies for 3R capabilities I mean is possible that an LSP needs 3R due to optical impairments.

 

A possible solution to say that loopback are not allowed and thus if an LSP for some reason needs a loopback the PCE must return an error.  This information can be used to improve the wavelength conversion/3R capability of the network e.g. planning the deployment of more wavelength converter.  The other solution is to allow loopback. 

 

Best Regards


Diego

 

  

 

From: owner-ccamp <at> ops.ietf.org [mailto:owner-ccamp <at> ops.ietf.org] On Behalf Of Greg Bernstein
Sent: venerdì 28 settembre 2007 23.44
To: Igor Bryskin
Cc: ccamp; pce <at> ietf.org
Subject: Re: [Pce] Some key issues with Wavelength Switched Optical Networks...

 

Very good catch Igor. See in line.

Igor Bryskin wrote:

--snip--




 

2. Considering wavelength conversion inevitably brings to the problem of looped paths, which is a completely new ball game in path computation, and I am surprised that the issue was never mentioned in the draft.

--> How is this different from the "looping" that can occur with a TDM multiplexer in a drop and continue mode?  Also in these two circuit cases (TDM, and optical) do we have the same danger as in the packet case where looping traffic can greatly degrade other flows.  Was there some general looping concerns already published for GMPLS with respect to circuits? 

 

IB>> There is a profound difference. I am not talking here about accidental looping, rather about deliberate looping: if some nodes can perform wavelength conversion while others can not, then you will want to route the connection to one or several conversion points and after that get it back on the main path. In other words you will deliberately request, say, a PCE to produce looped path, and then GMPLS RSVP-TE to signal looped path, which is completely out of normal paradigm of work for both PCE and RSVP.

--> I thought you were worried about accidental loops.  I didn't even consider what you are talking about "looping", but would RSVP processing get fouled up? It sure looks like a loop at the "node" level.
In the ERO the "node" subobject (IP4, IP6, AS) could definitely be repeated, but with a different "Label ERO" subobject appended. This is definitely something somebody would not to in the MPLS or TDM case.  I'll be sure to add it as an important difference in the next revision. Thanks!

 

Cheers,

Igor

 

--snip--

--

===================================================

Dr Greg Bernstein, Grotto Networking (510) 573-2237

 
Permalink | Reply | 0 comments |
headers
Martin Vigoureux | 2 Oct 2007 09:25
Picon
Favicon

Re: Some key issues with Wavelength Switched Optical Networks...

Hi Greg,

please see below

best regards,

martin

Greg Bernstein a écrit :
> Hi Igor, see comments below.
> 
> Igor Bryskin wrote:
>>
>> Greg,
>>
>>  
>>
>> I believe the draft is very useful.
>>
> --> Thanks!
>>
>>  
>>
>> I have a couple of questions comments:
>>
>>  
>>
>> 1. Section : 4.4. Traffic Grooming: Combining WSON and Higher Layer Network 
>>
>>    Optimization
>>
>>  
>>
>> How the problem of grooming of higher layer network traffic over 
>> optical trails is any different from the problem of traffic grooming 
>> in TDM (e.g. VC12 over VC4)? I mean this is a general problem of 
>> inter-layer relationship. I suggest moving all higher layer network 
>> considerations out of scope of the draft and focusing on specifics of 
>> the OCh layer.
>>
> --> Some of my co-authors agree with you on moving this section out.  
> The reason that I put it in was that the optical "Traffic Grooming" 
> problem has received a fair amount of attention in the research and 
> general technical literature and is also a driver for the use of ROADMs 
> (optical bypass).  I guess in general we've got the following 
> inter-related problems: (a) virtual network topology design, (b) lower 
> layer connection routing, (c) higher layer flow routing. In our case (b) 
> is the RWA problem, which is fairly difficult in its own right. I guess 
> I should look closely at the MLN/MRN work and see if a specific example 
> that includes RWA is mentioned.  If so then I'd feel fine removing this 
> section from the document.

Optical considerations are not explicitly covered in MRN/MLN documents
anymore, but we still talk a lot about virtual topologies in
multi-layer/region contexts.
Optical considerations were covered at the very beginning of these 
documents, at the time they were called HPN (Hybrid Photonic Networks).
http://www.tools.ietf.org/html/draft-vigoureux-ccamp-gmpls-architecture-hpn-00
Permalink | Reply | 0 comments |
headers
Fabien VERHAEGHE | 4 Oct 2007 10:06
Favicon

TR: TLV Format

Hello,

 

I did not see any reply for this comment.

I seize the opportunity to clarify my opinion:

 

I think TLV alignment statement must be a general rules for all TLVs of a given object.

The draft then needs also to specify that the alignment padding bytes must be included before

or after the value field.

 

The Length field would carry the actual length of the value without padding bytes due to alignment.

 

Those statements seem important to me for the processing of unknown TLVs.

 

With this general rules there is no need to specify that 2 unused bytes must be added for 4 bytes length

value TLV such as The REQ-MISSING.

 

Note that I’m not sure why the draft proposed a 8 bytes alignment (Why not 4 bytes since in section 7.1

it is said that object length must always be a multiple of 4?).

 

Does it make sense?

 

Best regards

Fabien

 

 

De : Fabien VERHAEGHE [mailto:fabien.verhaeghe <at> marben-products.com]
Envoyé : vendredi 14 septembre 2007 09:45
À : pce <at> ietf.org
Objet : [Pce] TLV Format

 

Hi,

 

I think there is a little problem with PCEP object TLV format.

 

The main problem being that the general format of the TLVs is not described (Type, length value length, 4 bytes alignment…).

 

Besides for existing TLVs we have:

 

 

“The REQ-MISSING TLV is composed of 1 byte for the type,

1 byte specifying the number of bytes in the value field, 2 bytes

for an "Unused" field (the value of which MUST be set to 0), followed by

a fix length value field of 4 bytes specifying the request-id-number

that correspond to the missing request.

The REQ-MISSING TLV is padded to eight-byte alignment.

 

TYPE: To be assigned by IANA

LENGTH: 4

VALUE: request-id-number that corresponds to the missing request”

 

I think the LENGTH field should be set to 6, the unused field 2 bytes being part of the Value field. Otherwise

it means those 2 bytes are part of the TLV header and it should be said that all TLVs will be formatted with

this 4 bytes header i.e. Type (1byte) – Value field Length (1byte) – Unused field (2bytes) – Value field

Otherwise, there may be some problem when decoding a message with unknown TLV.

 

Besides I’m not sure about the “The REQ-MISSING TLV is padded to eight-byte alignment.” statement.

Is it really needed?

 

For the NO-PATH-VECTOR TLV we have

 

“The NO-PATH-VECTOR TLV is composed of 1 byte for the type, 1 byte

   specifying the number of bytes in the value field, followed by a fix

   length value field of 32-bits flags field used to report the

   reason(s) that led to unsuccessful path computation.

 

   The NO-PATH-VECTOR TLV is padded to eight-byte alignment.

 

TYPE: To be assigned by IANA

 

   LENGTH: 4

 

   VALUE: 32-bits flags field”

 

In this case there is no Unused field 2 bytes.

I think it would be better to have the same format for all TLVs of all object.

And again I’m wondering if the LENGTH field should be set to 4 or 6?

 

Can you please clarify this to me? Am I missing something?

 

Thanks

Fabien

 

_______________________________________________
Pce mailing list
Pce <at> lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce

_______________________________________________
Pce mailing list
Pce <at> lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce
Permalink | Reply | 4 comments |
headers
LE ROUX Jean-Louis RD-CORE-LAN | 4 Oct 2007 11:25

RE: TLV Format

Hi Fabien
 
Sorry for the late reply
 
Please see inline,

De : Fabien VERHAEGHE [mailto:fabien.verhaeghe <at> marben-products.com]
Envoyé : jeudi 4 octobre 2007 10:06
À : pce <at> ietf.org
Objet : TR: [Pce] TLV Format

Hello,

 

I did not see any reply for this comment.

I seize the opportunity to clarify my opinion:

 

I think TLV alignment statement must be a general rules for all TLVs of a given object. 

 

Definitely right. We are going to add a section on generic TLV encoding. All TLVs specificed in PCEP objects will have to follow this encoding.

 

Here it is:

 

 

7.1.1. PCEP Object TLVs

 

A PCEP object may include a set of one or more optional TLV(s).
A PCEP object TLV is comprised of 2 octets for the type, 2 octets specifying the TLV length,
and a value field. The Length field defines the length of the value portion in octets.
The TLV is padded to four-octet alignment; padding is not included in the Length field
(so a three octet value would have a length of three, but the total size of the TLV would
be eight octets).

PCEP Object TLV types MUST be managed by IANA.

Unrecognized TLVs MUST be ignored.

 

 

Note that this is the encoding already used in RFC 3630 & 4420.

 

 

 

The draft then needs also to specify that the alignment padding bytes must be included before

or after the value field. 

 

 

The Length field would carry the actual length of the value without padding bytes due to alignment.

 

Those statements seem important to me for the processing of unknown TLVs.

 

Sure

 

With this general rules there is no need to specify that 2 unused bytes must be added for 4 bytes length

value TLV such as The REQ-MISSING.

 

Note that I’m not sure why the draft proposed a 8 bytes alignment (Why not 4 bytes since in section 7.1

it is said that object length must always be a multiple of 4?). 

 

Yes this was a mistake. We are going to align TLV definitions to new section 7.1.1.

 

Thanks for your comment.

 

Regards,

 

JL

 

Does it make sense?

 

Best regards

Fabien

 

 

De : Fabien VERHAEGHE [mailto:fabien.verhaeghe <at> marben-products.com]
Envoyé : vendredi 14 septembre 2007 09:45
À : pce <at> ietf.org
Objet : [Pce] TLV Format

 

Hi,

 

I think there is a little problem with PCEP object TLV format.

 

The main problem being that the general format of the TLVs is not described (Type, length value length, 4 bytes alignment…).

 

Besides for existing TLVs we have:

 

 

“The REQ-MISSING TLV is composed of 1 byte for the type,

1 byte specifying the number of bytes in the value field, 2 bytes

for an "Unused" field (the value of which MUST be set to 0), followed by

a fix length value field of 4 bytes specifying the request-id-number

that correspond to the missing request.

The REQ-MISSING TLV is padded to eight-byte alignment.

 

TYPE: To be assigned by IANA

LENGTH: 4

VALUE: request-id-number that corresponds to the missing request”

 

I think the LENGTH field should be set to 6, the unused field 2 bytes being part of the Value field. Otherwise

it means those 2 bytes are part of the TLV header and it should be said that all TLVs will be formatted with

this 4 bytes header i.e. Type (1byte) – Value field Length (1byte) – Unused field (2bytes) – Value field

Otherwise, there may be some problem when decoding a message with unknown TLV.

 

Besides I’m not sure about the “The REQ-MISSING TLV is padded to eight-byte alignment.” statement.

Is it really needed?

 

For the NO-PATH-VECTOR TLV we have

 

“The NO-PATH-VECTOR TLV is composed of 1 byte for the type, 1 byte

   specifying the number of bytes in the value field, followed by a fix

   length value field of 32-bits flags field used to report the

   reason(s) that led to unsuccessful path computation.

 

   The NO-PATH-VECTOR TLV is padded to eight-byte alignment.

 

TYPE: To be assigned by IANA

 

   LENGTH: 4

 

   VALUE: 32-bits flags field”

 

In this case there is no Unused field 2 bytes.

I think it would be better to have the same format for all TLVs of all object.

And again I’m wondering if the LENGTH field should be set to 4 or 6?

 

Can you please clarify this to me? Am I missing something?

 

Thanks

Fabien

 

<div>
<div dir="ltr" align="left"><span class="747060509-04102007">Hi Fabien</span></div>
<div dir="ltr" align="left">
<span class="747060509-04102007"></span>&nbsp;</div>
<div dir="ltr" align="left"><span class="747060509-04102007">Sorry for the late reply</span></div>
<div dir="ltr" align="left">
<span class="747060509-04102007"></span>&nbsp;</div>
<div dir="ltr" align="left"><span class="747060509-04102007">Please see inline,</span></div>
<br><blockquote dir="ltr">
  <div class="OutlookMessageHeader" lang="fr" dir="ltr" align="left">
  De&nbsp;: Fabien VERHAEGHE 
  [mailto:fabien.verhaeghe <at> marben-products.com] <br>Envoy&eacute;&nbsp;: jeudi 4 
  octobre 2007 10:06<br>&Agrave;&nbsp;: pce <at> ietf.org<br>Objet&nbsp;: TR: 
  [Pce] TLV Format<br><br>
</div>
  <div></div>
  <div class="Section1">
  <p class="MsoNormal"><span>Hello,<p></p></span></p>
  <p class="MsoNormal"><span><p>&nbsp;</p></span></p>
  <p class="MsoNormal"><span lang="EN-GB">I did not see any 
  reply for this comment. <p></p></span></p>
  <p class="MsoNormal"><span lang="EN-GB">I seize the 
  opportunity to clarify my opinion:<p></p></span></p>
  <p class="MsoNormal"><span lang="EN-GB"><p>&nbsp;</p></span></p>
  <p class="MsoNormal"><span lang="EN-GB">I think TLV alignment 
  statement must be a general rules for all TLVs of a given object.<span class="747060509-04102007">&nbsp;</span></span></p>
  <p class="MsoNormal"><span lang="EN-GB"><span class="747060509-04102007"></span></span>&nbsp;</p>
  <p class="MsoNormal"><span lang="EN-GB"><span class="747060509-04102007">Definitely right. We are going to 
  add a section on generic TLV encoding. All TLVs specificed in PCEP objects 
  will have to follow this encoding.</span></span></p>
  <p class="MsoNormal"><span lang="EN-GB"><span class="747060509-04102007"></span></span>&nbsp;</p>
  <p class="MsoNormal"><span lang="EN-GB"><span class="747060509-04102007">Here it 
  is:</span></span></p>
  <p class="MsoNormal"><span lang="EN-GB"><span class="747060509-04102007"></span></span>&nbsp;</p>
  <p class="MsoNormal"><span lang="EN-GB"><span class="747060509-04102007"></span></span>&nbsp;</p>
  <p class="MsoNormal"><span lang="EN-GB"><span class="747060509-04102007">7.1.1. PCEP 
  Object TLVs</span></span></p>
  <p class="MsoNormal"><span lang="EN-GB"><span class="747060509-04102007"></span></span>&nbsp;</p>
  <p class="MsoNormal"><span lang="EN-GB"><span class="747060509-04102007">A PCEP object 
  may include a set of one or more optional TLV(s).<br>A PCEP object TLV is 
  comprised of 2 octets for the type, 2 octets specifying the TLV length, 
  <br>and a value field. The Length field defines the length of the value 
  portion in octets. <br>The TLV is padded to four-octet alignment; padding is 
  not included in the Length field <br>(so a three octet value would have a 
  length of three, but the total size of the TLV would <br>be eight 
  octets).</span></span></p>
  <p class="MsoNormal"><span lang="EN-GB"><span class="747060509-04102007">PCEP Object 
  TLV types MUST be managed by IANA.</span></span></p>
  <p class="MsoNormal"><span lang="EN-GB"><span class="747060509-04102007">Unrecognized 
  TLVs MUST be ignored.</span></span></p>
  <p class="MsoNormal"><span lang="EN-GB"><span class="747060509-04102007"></span></span>&nbsp;</p>
  <p class="MsoNormal"><span lang="EN-GB"><span class="747060509-04102007"></span></span>&nbsp;</p>
  <p class="MsoNormal"><span lang="EN-GB"><span class="747060509-04102007">Note that this is the encoding 
  already used in RFC 3630&nbsp;&amp; 4420.</span></span></p>
  <p class="MsoNormal"><span lang="EN-GB"><span class="747060509-04102007"></span></span>&nbsp;</p>
  <p class="MsoNormal"><span lang="EN-GB"><span class="747060509-04102007"></span></span>&nbsp;</p>
  <p class="MsoNormal"><span lang="EN-GB"><span class="747060509-04102007">&nbsp;</span><p></p></span></p>
  <p class="MsoNormal"><span lang="EN-GB">The draft then needs 
  also to specify that the alignment padding bytes must be included 
  before<p></p></span></p>
  <p class="MsoNormal"><span lang="EN-GB">or after the value 
  field.<span class="747060509-04102007">&nbsp;</span></span></p>
  <p class="MsoNormal"><span lang="EN-GB"><span class="747060509-04102007"></span></span>&nbsp;</p>
  <p class="MsoNormal"><span lang="EN-GB"><p>&nbsp;</p></span><span lang="EN-GB">The Length field 
  would carry the actual length of the value without padding bytes due to 
  alignment.<p></p></span></p>
  <p class="MsoNormal"><span lang="EN-GB"><p>&nbsp;</p></span></p>
  <p class="MsoNormal"><span lang="EN-GB">Those statements seem 
  important to me for the processing of unknown TLVs. 
  <p></p></span></p>
  <p class="MsoNormal"><span lang="EN-GB"><p></p></span>&nbsp;</p>
  <p class="MsoNormal"><span lang="EN-GB"><p><span class="747060509-04102007">Sure</span></p></span></p>
  <p class="MsoNormal"><span lang="EN-GB"><p>&nbsp;</p></span></p>
  <p class="MsoNormal"><span lang="EN-GB">With this general 
  rules there is no need to specify that 2 unused bytes must be added for 4 
  bytes length<p></p></span></p>
  <p class="MsoNormal"><span lang="EN-GB">value TLV such as The 
  REQ-MISSING.<p></p></span></p>
  <p class="MsoNormal"><span lang="EN-GB"><p>&nbsp;</p></span></p>
  <p class="MsoNormal"><span lang="EN-GB">Note that I&#146;m not 
  sure why the draft proposed a 8 bytes alignment (Why not 4 bytes since in 
  section 7.1<p></p></span></p>
  <p class="MsoNormal"><span lang="EN-GB">it is said that 
  object length must always be a multiple of 4?).<span class="747060509-04102007">&nbsp;</span></span></p>
  <p class="MsoNormal"><span lang="EN-GB"><span class="747060509-04102007"></span></span>&nbsp;</p>
  <p class="MsoNormal"><span lang="EN-GB"><span class="747060509-04102007">Yes this&nbsp;was a mistake. We 
  are going to align TLV definitions to new section 
  7.1.1.</span></span></p>
  <p class="MsoNormal"><span lang="EN-GB"><span class="747060509-04102007"></span></span>&nbsp;</p>
  <p class="MsoNormal"><span lang="EN-GB"><span class="747060509-04102007">Thanks for your 
  comment.</span></span></p>
  <p class="MsoNormal"><span lang="EN-GB"><span class="747060509-04102007"></span></span>&nbsp;</p>
  <p class="MsoNormal"><span lang="EN-GB"><span class="747060509-04102007">Regards,</span></span></p>
  <p class="MsoNormal"><span lang="EN-GB"><span class="747060509-04102007"></span></span>&nbsp;</p>
  <p class="MsoNormal"><span lang="EN-GB"><span class="747060509-04102007">JL</span></span></p>
  <p class="MsoNormal"><span lang="EN-GB"><p>&nbsp;</p></span></p>
  <p class="MsoNormal"><span lang="EN-GB">Does it make 
  sense?<p></p></span></p>
  <p class="MsoNormal"><span lang="EN-GB"><p>&nbsp;</p></span></p>
  <p class="MsoNormal"><span lang="EN-GB">Best 
  regards<p></p></span></p>
  <p class="MsoNormal"><span lang="EN-GB">Fabien<p></p></span></p>
  <p class="MsoNormal"><span lang="EN-GB"><p>&nbsp;</p></span></p>
  <p class="MsoNormal"><span lang="EN-GB"><p>&nbsp;</p></span></p>
  <div>
  <div class="MsoNormal" align="center"><span>
  </span></div>
  <p class="MsoNormal"><span>De&nbsp;:</span><span> 
  Fabien 
  VERHAEGHE [mailto:fabien.verhaeghe <at> marben-products.com] 
  <br><span>Envoy&eacute;&nbsp;:</span> vendredi 14 
  septembre 2007 09:45<br><span>&Agrave;&nbsp;:</span> 
  pce <at> ietf.org<br><span>Objet&nbsp;:</span> 
  [Pce] TLV Format</span><p></p></p>
</div>
  <p class="MsoNormal"><span><p>&nbsp;</p></span></p>
  <div>
  <div>
  <p class="MsoNormal"><span lang="EN-GB">Hi,<p></p></span></p>
  <p class="MsoNormal"><span lang="EN-GB"><p>&nbsp;</p></span></p>
  <p class="MsoNormal"><span lang="EN-GB">I think there is a 
  little problem with PCEP object TLV format.<p></p></span></p>
  <p class="MsoNormal"><span lang="EN-GB"><p>&nbsp;</p></span></p>
  <p class="MsoNormal"><span lang="EN-GB">The main problem 
  being that the general format of the TLVs is not described (Type, length value 
  length, 4 bytes alignment&#133;).<p></p></span></p>
  <p class="MsoNormal"><span lang="EN-GB"><p>&nbsp;</p></span></p>
  <p class="MsoNormal"><span lang="EN-GB">Besides for existing 
  TLVs we have:<p></p></span></p>
  <p class="MsoNormal"><span lang="EN-GB"><p>&nbsp;</p></span></p>
  <p class="MsoNormal"><span lang="EN-GB"><p>&nbsp;</p></span></p>
  <p class="MsoNormal"><span lang="EN-GB">&#147;The REQ-MISSING TLV 
  is composed of 1 byte for the type,<p></p></span></p>
  <p class="MsoNormal"><span lang="EN-GB">1 byte specifying the 
  number of bytes in the value field, 2 bytes<p></p></span></p>
  <p class="MsoNormal"><span lang="EN-GB">for an "Unused" field 
  (the value of which MUST be set to 0), followed 
by<p></p></span></p>
  <p class="MsoNormal"><span lang="EN-GB">a fix length value 
  field of 4 bytes specifying the request-id-number<p></p></span></p>
  <p class="MsoNormal"><span lang="EN-GB">that correspond to 
  the missing request. <p></p></span></p>
  <p class="MsoNormal"><span lang="EN-GB">The REQ-MISSING TLV 
  is padded to eight-byte alignment.<p></p></span></p>
  <p class="MsoNormal"><span lang="EN-GB"><p>&nbsp;</p></span></p>
  <p class="MsoNormal"><span lang="EN-GB">TYPE: To be assigned 
  by IANA<p></p></span></p>
  <p class="MsoNormal"><span lang="EN-GB">LENGTH: 
  4<p></p></span></p>
  <p class="MsoNormal"><span lang="EN-GB">VALUE: 
  request-id-number that corresponds to the missing 
  request&#148;<p></p></span></p>
  <p class="MsoNormal"><span lang="EN-GB"><p>&nbsp;</p></span></p>
  <p class="MsoNormal"><span lang="EN-GB">I think the LENGTH 
  field should be set to 6, the unused field 2 bytes being part of the Value 
  field. Otherwise<p></p></span></p>
  <p class="MsoNormal"><span lang="EN-GB">it means those 2 
  bytes are part of the TLV header and it should be said that all TLVs will be 
  formatted with<p></p></span></p>
  <p class="MsoNormal"><span lang="EN-GB">this 4 bytes header 
  i.e. Type (1byte) &#150; Value field Length (1byte) &#150; Unused field (2bytes) &#150; Value 
  field<p></p></span></p>
  <p class="MsoNormal"><span lang="EN-GB">Otherwise, there may 
  be some problem when decoding a message with unknown 
  TLV.<p></p></span></p>
  <p class="MsoNormal"><span lang="EN-GB"><p>&nbsp;</p></span></p>
  <p class="MsoNormal"><span lang="EN-GB">Besides I&#146;m not sure 
  about the &#147;The REQ-MISSING TLV is padded to eight-byte alignment.&#148; 
  statement.<p></p></span></p>
  <p class="MsoNormal"><span lang="EN-GB">Is it really 
  needed?<p></p></span></p>
  <p class="MsoNormal"><span lang="EN-GB"><p>&nbsp;</p></span></p>
  <p class="MsoNormal"><span lang="EN-GB">For the 
  NO-PATH-VECTOR TLV we have<p></p></span></p>
  <p class="MsoNormal"><span lang="EN-GB"><p>&nbsp;</p></span></p>
  <p class="MsoNormal"><span lang="EN-GB">&#147;The NO-PATH-VECTOR 
  TLV is composed of 1 byte for the type, 1 byte<p></p></span></p>
  <p class="MsoNormal"><span lang="EN-GB">&nbsp;&nbsp; 
  specifying the number of bytes in the value field, followed by a 
  fix<p></p></span></p>
  <p class="MsoNormal"><span lang="EN-GB">&nbsp;&nbsp; length 
  value field of 32-bits flags field used to report 
  the<p></p></span></p>
  <p class="MsoNormal"><span lang="EN-GB">&nbsp;&nbsp; 
  reason(s) that led to unsuccessful path 
  computation.<p></p></span></p>
  <p class="MsoNormal"><span lang="EN-GB"><p>&nbsp;</p></span></p>
  <p class="MsoNormal"><span lang="EN-GB">&nbsp;&nbsp; The 
  NO-PATH-VECTOR TLV is padded to eight-byte 
  alignment.<p></p></span></p>
  <p class="MsoNormal"><span lang="EN-GB"><p>&nbsp;</p></span></p>
  <p class="MsoNormal"><span lang="EN-GB">TYPE: To be assigned 
  by IANA<p></p></span></p>
  <p class="MsoNormal"><span lang="EN-GB"><p>&nbsp;</p></span></p>
  <p class="MsoNormal"><span lang="EN-GB">&nbsp;&nbsp; LENGTH: 
  4<p></p></span></p>
  <p class="MsoNormal"><span lang="EN-GB"><p>&nbsp;</p></span></p>
  <p class="MsoNormal"><span lang="EN-GB">&nbsp;&nbsp; VALUE: 
  32-bits flags field&#148;<p></p></span></p>
  <p class="MsoNormal"><span lang="EN-GB"><p>&nbsp;</p></span></p>
  <p class="MsoNormal"><span lang="EN-GB">In this case there is 
  no Unused field 2 bytes. <p></p></span></p>
  <p class="MsoNormal"><span lang="EN-GB">I think it would be 
  better to have the same format for all TLVs of all 
  object.<p></p></span></p>
  <p class="MsoNormal"><span lang="EN-GB">And again I&#146;m 
  wondering if the LENGTH field should be set to 4 or 
  6?<p></p></span></p>
  <p class="MsoNormal"><span lang="EN-GB"><p>&nbsp;</p></span></p>
  <p class="MsoNormal"><span lang="EN-GB">Can you please 
  clarify this to me? Am I missing something?<p></p></span></p>
  <p class="MsoNormal"><span lang="EN-GB"><p>&nbsp;</p></span></p>
  <p class="MsoNormal"><span lang="EN-GB">Thanks<p></p></span></p>
  <p class="MsoNormal"><span lang="EN-GB">Fabien<p></p></span></p>
  <p class="MsoNormal"><span lang="EN-GB"><p>&nbsp;</p></span></p>
</div>
</div>
</div>
</blockquote>
</div>
Permalink | Reply | 3 comments |
headers
Adrian Farrel | 4 Oct 2007 14:50
Picon

Re: TLV Format

Hi,

Did you see the question about padding and lengths on the CCAMP and OSPF 
lists?

It might be worth getting this explained in the PCEP I-D, as well. The 
questions are:

When an object contains a TLV with padding (so the TLV length field does not 
include the length of the padding) what is the value of the length field in 
the object?

When a TLV contains multiple TLVs with padding, what is the value of the 
length field in the object?

When a TLV contains sub-TLVs with padding, what is the value of the length 
field in the TLV?

These three questions seem to have well-known and "obvious" answers for 
other protocols, but are not written down. Let's write them down for PCEP.

Cheers,
Adrian

----- Original Message ----- 
From: "LE ROUX Jean-Louis RD-CORE-LAN" <jeanlouis.leroux <at> orange-ftgroup.com>
To: <fabien.verhaeghe <at> marben-products.com>; <pce <at> ietf.org>
Sent: Thursday, October 04, 2007 10:25 AM
Subject: RE: [Pce] TLV Format

Hi Fabien

Sorry for the late reply

Please see inline,

________________________________

De : Fabien VERHAEGHE [mailto:fabien.verhaeghe <at> marben-products.com]
Envoyé : jeudi 4 octobre 2007 10:06
À : pce <at> ietf.org
Objet : TR: [Pce] TLV Format

Hello,

I did not see any reply for this comment.

I seize the opportunity to clarify my opinion:

I think TLV alignment statement must be a general rules for all TLVs of a 
given object.

Definitely right. We are going to add a section on generic TLV encoding. All 
TLVs specificed in PCEP objects will have to follow this encoding.

Here it is:

7.1.1. PCEP Object TLVs

A PCEP object may include a set of one or more optional TLV(s).
A PCEP object TLV is comprised of 2 octets for the type, 2 octets specifying 
the TLV length,
and a value field. The Length field defines the length of the value portion 
in octets.
The TLV is padded to four-octet alignment; padding is not included in the 
Length field
(so a three octet value would have a length of three, but the total size of 
the TLV would
be eight octets).

PCEP Object TLV types MUST be managed by IANA.

Unrecognized TLVs MUST be ignored.

Note that this is the encoding already used in RFC 3630 & 4420.

The draft then needs also to specify that the alignment padding bytes must 
be included before

or after the value field.

The Length field would carry the actual length of the value without padding 
bytes due to alignment.

Those statements seem important to me for the processing of unknown TLVs.

Sure

With this general rules there is no need to specify that 2 unused bytes must 
be added for 4 bytes length

value TLV such as The REQ-MISSING.

Note that I'm not sure why the draft proposed a 8 bytes alignment (Why not 4 
bytes since in section 7.1

it is said that object length must always be a multiple of 4?).

Yes this was a mistake. We are going to align TLV definitions to new section 
7.1.1.

Thanks for your comment.

Regards,

JL

Does it make sense?

Best regards

Fabien

________________________________

De : Fabien VERHAEGHE [mailto:fabien.verhaeghe <at> marben-products.com]
Envoyé : vendredi 14 septembre 2007 09:45
À : pce <at> ietf.org
Objet : [Pce] TLV Format

Hi,

I think there is a little problem with PCEP object TLV format.

The main problem being that the general format of the TLVs is not described 
(Type, length value length, 4 bytes alignment...).

Besides for existing TLVs we have:

"The REQ-MISSING TLV is composed of 1 byte for the type,

1 byte specifying the number of bytes in the value field, 2 bytes

for an "Unused" field (the value of which MUST be set to 0), followed by

a fix length value field of 4 bytes specifying the request-id-number

that correspond to the missing request.

The REQ-MISSING TLV is padded to eight-byte alignment.

TYPE: To be assigned by IANA

LENGTH: 4

VALUE: request-id-number that corresponds to the missing request"

I think the LENGTH field should be set to 6, the unused field 2 bytes being 
part of the Value field. Otherwise

it means those 2 bytes are part of the TLV header and it should be said that 
all TLVs will be formatted with

this 4 bytes header i.e. Type (1byte) - Value field Length (1byte) - Unused 
field (2bytes) - Value field

Otherwise, there may be some problem when decoding a message with unknown 
TLV.

Besides I'm not sure about the "The REQ-MISSING TLV is padded to eight-byte 
alignment." statement.

Is it really needed?

For the NO-PATH-VECTOR TLV we have

"The NO-PATH-VECTOR TLV is composed of 1 byte for the type, 1 byte

   specifying the number of bytes in the value field, followed by a fix

   length value field of 32-bits flags field used to report the

   reason(s) that led to unsuccessful path computation.

   The NO-PATH-VECTOR TLV is padded to eight-byte alignment.

TYPE: To be assigned by IANA

   LENGTH: 4

   VALUE: 32-bits flags field"

In this case there is no Unused field 2 bytes.

I think it would be better to have the same format for all TLVs of all 
object.

And again I'm wondering if the LENGTH field should be set to 4 or 6?

Can you please clarify this to me? Am I missing something?

Thanks

Fabien

--------------------------------------------------------------------------------

> _______________________________________________
> Pce mailing list
> Pce <at> lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/pce
>
Permalink | Reply | 2 comments |
headers
LE ROUX Jean-Louis RD-CORE-LAN | 4 Oct 2007 16:13

RE: TLV Format

Hi Adrian,

OK, good point.
We will cover these three questions in rev 09.

Thanks,

JL

> -----Message d'origine-----
> De : Adrian Farrel [mailto:adrian <at> olddog.co.uk] 
> Envoyé : jeudi 4 octobre 2007 14:50
> À : LE ROUX Jean-Louis RD-CORE-LAN; 
> fabien.verhaeghe <at> marben-products.com; pce <at> ietf.org
> Objet : Re: [Pce] TLV Format
> 
> Hi,
> 
> Did you see the question about padding and lengths on the 
> CCAMP and OSPF lists?
> 
> It might be worth getting this explained in the PCEP I-D, as 
> well. The questions are:
> 
> When an object contains a TLV with padding (so the TLV length 
> field does not include the length of the padding) what is the 
> value of the length field in the object?
> 
> When a TLV contains multiple TLVs with padding, what is the 
> value of the length field in the object?
> 
> When a TLV contains sub-TLVs with padding, what is the value 
> of the length field in the TLV?
> 
> These three questions seem to have well-known and "obvious" 
> answers for other protocols, but are not written down. Let's 
> write them down for PCEP.
> 
> Cheers,
> Adrian
> 
> ----- Original Message -----
> From: "LE ROUX Jean-Louis RD-CORE-LAN" 
> <jeanlouis.leroux <at> orange-ftgroup.com>
> To: <fabien.verhaeghe <at> marben-products.com>; <pce <at> ietf.org>
> Sent: Thursday, October 04, 2007 10:25 AM
> Subject: RE: [Pce] TLV Format
> 
> 
> Hi Fabien
> 
> Sorry for the late reply
> 
> Please see inline,
> 
> 
> ________________________________
> 
> De : Fabien VERHAEGHE [mailto:fabien.verhaeghe <at> marben-products.com]
> Envoyé : jeudi 4 octobre 2007 10:06
> À : pce <at> ietf.org
> Objet : TR: [Pce] TLV Format
> 
> 
> 
> Hello,
> 
> 
> 
> I did not see any reply for this comment.
> 
> I seize the opportunity to clarify my opinion:
> 
> 
> 
> I think TLV alignment statement must be a general rules for 
> all TLVs of a 
> given object.
> 
> 
> 
> Definitely right. We are going to add a section on generic 
> TLV encoding. All 
> TLVs specificed in PCEP objects will have to follow this encoding.
> 
> 
> 
> Here it is:
> 
> 
> 
> 
> 
> 7.1.1. PCEP Object TLVs
> 
> 
> 
> A PCEP object may include a set of one or more optional TLV(s).
> A PCEP object TLV is comprised of 2 octets for the type, 2 
> octets specifying 
> the TLV length,
> and a value field. The Length field defines the length of the 
> value portion 
> in octets.
> The TLV is padded to four-octet alignment; padding is not 
> included in the 
> Length field
> (so a three octet value would have a length of three, but the 
> total size of 
> the TLV would
> be eight octets).
> 
> PCEP Object TLV types MUST be managed by IANA.
> 
> Unrecognized TLVs MUST be ignored.
> 
> 
> 
> 
> 
> Note that this is the encoding already used in RFC 3630 & 4420.
> 
> 
> 
> 
> 
> 
> 
> The draft then needs also to specify that the alignment 
> padding bytes must 
> be included before
> 
> or after the value field.
> 
> 
> 
> The Length field would carry the actual length of the value 
> without padding 
> bytes due to alignment.
> 
> 
> 
> Those statements seem important to me for the processing of 
> unknown TLVs.
> 
> 
> 
> Sure
> 
> 
> 
> With this general rules there is no need to specify that 2 
> unused bytes must 
> be added for 4 bytes length
> 
> value TLV such as The REQ-MISSING.
> 
> 
> 
> Note that I'm not sure why the draft proposed a 8 bytes 
> alignment (Why not 4 
> bytes since in section 7.1
> 
> it is said that object length must always be a multiple of 4?).
> 
> 
> 
> Yes this was a mistake. We are going to align TLV definitions 
> to new section 
> 7.1.1.
> 
> 
> 
> Thanks for your comment.
> 
> 
> 
> Regards,
> 
> 
> 
> JL
> 
> 
> 
> Does it make sense?
> 
> 
> 
> Best regards
> 
> Fabien
> 
> 
> 
> 
> 
> 
> ________________________________
> 
> 
> De : Fabien VERHAEGHE [mailto:fabien.verhaeghe <at> marben-products.com]
> Envoyé : vendredi 14 septembre 2007 09:45
> À : pce <at> ietf.org
> Objet : [Pce] TLV Format
> 
> 
> 
> Hi,
> 
> 
> 
> I think there is a little problem with PCEP object TLV format.
> 
> 
> 
> The main problem being that the general format of the TLVs is 
> not described 
> (Type, length value length, 4 bytes alignment...).
> 
> 
> 
> Besides for existing TLVs we have:
> 
> 
> 
> 
> 
> "The REQ-MISSING TLV is composed of 1 byte for the type,
> 
> 1 byte specifying the number of bytes in the value field, 2 bytes
> 
> for an "Unused" field (the value of which MUST be set to 0), 
> followed by
> 
> a fix length value field of 4 bytes specifying the request-id-number
> 
> that correspond to the missing request.
> 
> The REQ-MISSING TLV is padded to eight-byte alignment.
> 
> 
> 
> TYPE: To be assigned by IANA
> 
> LENGTH: 4
> 
> VALUE: request-id-number that corresponds to the missing request"
> 
> 
> 
> I think the LENGTH field should be set to 6, the unused field 
> 2 bytes being 
> part of the Value field. Otherwise
> 
> it means those 2 bytes are part of the TLV header and it 
> should be said that 
> all TLVs will be formatted with
> 
> this 4 bytes header i.e. Type (1byte) - Value field Length 
> (1byte) - Unused 
> field (2bytes) - Value field
> 
> Otherwise, there may be some problem when decoding a message 
> with unknown 
> TLV.
> 
> 
> 
> Besides I'm not sure about the "The REQ-MISSING TLV is padded 
> to eight-byte 
> alignment." statement.
> 
> Is it really needed?
> 
> 
> 
> For the NO-PATH-VECTOR TLV we have
> 
> 
> 
> "The NO-PATH-VECTOR TLV is composed of 1 byte for the type, 1 byte
> 
>    specifying the number of bytes in the value field, 
> followed by a fix
> 
>    length value field of 32-bits flags field used to report the
> 
>    reason(s) that led to unsuccessful path computation.
> 
> 
> 
>    The NO-PATH-VECTOR TLV is padded to eight-byte alignment.
> 
> 
> 
> TYPE: To be assigned by IANA
> 
> 
> 
>    LENGTH: 4
> 
> 
> 
>    VALUE: 32-bits flags field"
> 
> 
> 
> In this case there is no Unused field 2 bytes.
> 
> I think it would be better to have the same format for all 
> TLVs of all 
> object.
> 
> And again I'm wondering if the LENGTH field should be set to 4 or 6?
> 
> 
> 
> Can you please clarify this to me? Am I missing something?
> 
> 
> 
> Thanks
> 
> Fabien
> 
> 
> 
> 
> 
> 
> --------------------------------------------------------------
> ------------------
> 
> 
> > _______________________________________________
> > Pce mailing list
> > Pce <at> lists.ietf.org
> > https://www1.ietf.org/mailman/listinfo/pce
> > 
> 
> 
>
Permalink | Reply | 0 comments |
headers
JP Vasseur | 8 Oct 2007 22:35
Picon
Favicon

Fwd: Update on draft-ietf-pce-policy-enabled-path-comp

Dear WG,

Christian Jacquenet on behalf of IPSphere proposed to make several comments on this document.
Christian, could you please send them to the list ?

As agreed, we're still planning to issue a WG LC after this round of discussion.

Thanks.

JP.

Begin forwarded message:

From: JP Vasseur <jvasseur <at> cisco.com>
Date: September 18, 2007 2:10:12 PM EDT
Cc: Thomas Walsh <twalsh <at> juniper.net>, JACQUENET Christian RD-TCH-REN <christian.jacquenet <at> francetelecom.com>
Subject: [Pce] Update on draft-ietf-pce-policy-enabled-path-comp

Dear WG,

From the WG minutes of the IETF-69 meeting:

12) Update on Policy-Enabled Path Computation Framework
draft-ietf-pce-policy-enabled-path-comp-01.txt (Lou - 5mn) [110]

Lou> ready for Last Call
JP> It sounds ready. Suggestion: offer IPSphere to have a look at the doc before last call. JP will be the point
of contact. Asked Ross whether this is a good idea, and Ross agreed. Once comments are received, last call.
Adrian> OK, but this is not an indefinite consultation. We want to be able to move ahead and complete the I-D
relatively soon.

We have contacted IPSphere and RA WG of IPSphere should provide us some feed-back by
mid-October. I have copied Tom Walsh and Christian Jacquenet (chair of the RAWG) IPSphere.

Thanks.

JP.
_______________________________________________
Pce mailing list

<div>
Dear WG,<div><br class="webkit-block-placeholder"></div>
<div>Christian Jacquenet on behalf of IPSphere proposed to make several comments on this document.</div>
<div>Christian, could you please send them to the list ?</div>
<div><br class="webkit-block-placeholder"></div>
<div>As agreed, we're still planning to issue a WG LC after this round of discussion.</div>
<div><br class="webkit-block-placeholder"></div>
<div>Thanks.</div>
<div><br class="webkit-block-placeholder"></div>
<div>JP.<br><div>
<br><div>Begin forwarded message:</div>
<br class="Apple-interchange-newline"><blockquote type="cite">
<div>From: JP Vasseur &lt;<a href="mailto:jvasseur <at> cisco.com">jvasseur <at> cisco.com</a>&gt;</div>
<div>Date: September 18, 2007 2:10:12 PM EDT</div>
<div>To: <a href="mailto:pce <at> ietf.org">pce <at> ietf.org</a>, Lou Berger &lt;<a href="mailto:lberger <at> labn.net">lberger <at> labn.net</a>&gt;, Igor Bryskin &lt;<a href="mailto:ibryskin <at> movaz.com">ibryskin <at> movaz.com</a>&gt;, Dimitri Papadimitriou &lt;<a href="mailto:dpapadimitriou <at> psg.com">dpapadimitriou <at> psg.com</a>&gt;, <a href="mailto:gash5107 <at> yahoo.com">gash5107 <at> yahoo.com</a>
</div>
<div>Cc: Thomas Walsh &lt;<a href="mailto:twalsh <at> juniper.net">twalsh <at> juniper.net</a>&gt;, JACQUENET Christian RD-TCH-REN &lt;<a href="mailto:christian.jacquenet <at> francetelecom.com">christian.jacquenet <at> francetelecom.com</a>&gt;</div>
<div>Subject: [Pce] Update on draft-ietf-pce-policy-enabled-path-comp</div>
<div><br></div> Dear WG,<div><br class="webkit-block-placeholder"></div>
<div>From the WG minutes of the IETF-69 meeting:<br><div><br class="webkit-block-placeholder"></div>
<div>
<div>12) Update on Policy-Enabled Path Computation Framework</div>
<div>draft-ietf-pce-policy-enabled-path-comp-01.txt (Lou - 5mn) [110]</div>
<div><br class="webkit-block-placeholder"></div>
<div>Lou&gt; ready for Last Call</div>
<div>JP&gt; It sounds ready. Suggestion: offer IPSphere to have a look at the doc before last call. JP will be the point</div>
<div>of contact. Asked Ross whether this is a good idea, and Ross agreed. Once comments are received, last call.</div>
<div>Adrian&gt; OK, but this is not an indefinite consultation. We want to be able to move ahead and complete the I-D</div>
<div>relatively soon.</div>
</div>
<div><br class="webkit-block-placeholder"></div>
<div>We have contacted IPSphere and RA WG of IPSphere should provide us some feed-back by</div>
<div>mid-October. I have copied Tom Walsh and Christian Jacquenet (chair of the RAWG) IPSphere.</div>
<div><br class="webkit-block-placeholder"></div>
<div>Thanks.</div>
<div><br class="webkit-block-placeholder"></div>
<div>JP.</div>
</div>
<div>_______________________________________________</div>
<div>Pce mailing list</div>
<div><a href="mailto:Pce <at> lists.ietf.org">Pce <at> lists.ietf.org</a></div>
<div><a href="https://www1.ietf.org/mailman/listinfo/pce">https://www1.ietf.org/mailman/listinfo/pce</a></div> </blockquote>
</div>
<br>
</div>
</div>
Permalink | Reply | 5 comments |
headers
Fabien VERHAEGHE | 9 Oct 2007 15:38
Favicon

PathRequests with same RqId

Hello,

 

I have a little concern with PCEP draft.

 

At the end of section 7.3.1 it is said:

“If no path computation reply is received from the PCE, and the PCC wishes to resend its

   request, the same Request-ID-number MUST be used.”

 

I’m not sure what is the purpose here. Is it a kind of retransmission process in case no reply is received

after N seconds or is it to offer the possibility to the PCC to change the Path Computation constraints?

(Actually I guess the intent is the first one, but the draft does not forbid the second case explicitly).

 

In the latter case I think there is a collision case to handle here if the PCC resends the request at the same time

the PCE sends the reply for the first request.

The PCC cannot know if the reply is for the first request or the second one.

 

In the first case the 2 PathRequests are identical so the problem is less important except that the PCC may receive 2 responses

(that may not be identical).

 

Another problem is that if the PathRequest belongs to an SVEC and if there is a collision between a resent PathRequest

and the PathReply, the PCE may not remember the SVEC (since it already replied) so the second received PathReply result

would not have been performed synchronously with other PathRequests of the SVEC.

 

Wouldn’t it be preferable to forbid the reuse of a request id? If a PCC wants to resend a PathRequest it can

send a Cancel Request Notification followed by a new PathRequest with a new Id. It seems more straight forward and robust to me.

 

Actually I’m not sure I get the advantage of reusing the same request Id.

 

Best regards

Fabien

 

<div>

<div class="Section1">

<p class="MsoNormal"><span lang="EN-US">Hello,<p></p></span></p>

<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span lang="EN-US">I have a little concern with PCEP draft.<p></p></span></p>

<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span lang="EN-US">At the end of section 7.3.1 it is said:<p></p></span></p>

<p class="MsoNormal"><span lang="EN-US">&ldquo;If no path computation reply is received from
the PCE, and the PCC wishes to resend its<p></p></span></p>

<p class="MsoNormal"><span lang="EN-US">&nbsp;&nbsp; request, the same Request-ID-number MUST
be used.&rdquo;<p></p></span></p>

<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span lang="EN-US">I&rsquo;m not sure what is the purpose here. Is it a
kind of retransmission process in case no reply is received<p></p></span></p>

<p class="MsoNormal"><span lang="EN-US">after N seconds or is it to offer the possibility to
the PCC to change the Path Computation constraints?<p></p></span></p>

<p class="MsoNormal"><span lang="EN-US">(Actually I guess the intent is the first one, but
the draft does not forbid the second case explicitly).<p></p></span></p>

<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span lang="EN-US">In the latter case I think there is a collision case
to handle here if the PCC resends the request at the same time<p></p></span></p>

<p class="MsoNormal"><span lang="EN-US">the PCE sends the reply for the first request.<p></p></span></p>

<p class="MsoNormal"><span lang="EN-US">The PCC cannot know if the reply is for the first
request or the second one.<p></p></span></p>

<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span lang="EN-US">In the first case the 2 PathRequests are identical so
the problem is less important except that the PCC may receive 2 responses<p></p></span></p>

<p class="MsoNormal"><span lang="EN-US">(that may not be identical).<p></p></span></p>

<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span lang="EN-US">Another problem is that if the PathRequest belongs to
an SVEC and if there is a collision between a resent PathRequest<p></p></span></p>

<p class="MsoNormal"><span lang="EN-US">and the PathReply, the PCE may not remember the SVEC
(since it already replied) so the second received PathReply result<p></p></span></p>

<p class="MsoNormal"><span lang="EN-US">would not have been performed synchronously with
other PathRequests of the SVEC. <p></p></span></p>

<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span lang="EN-US">Wouldn&rsquo;t it be preferable to forbid the reuse
of a request id? If a PCC wants to resend a PathRequest it can<p></p></span></p>

<p class="MsoNormal"><span lang="EN-US">send a Cancel Request Notification followed by a new
PathRequest with a new Id.
It seems more straight forward and robust to me.<p></p></span></p>

<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span lang="EN-US">Actually I&rsquo;m not sure I get the advantage of
reusing the same request Id.<p></p></span></p>

<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span lang="EN-US">Best regards<p></p></span></p>

<p class="MsoNormal"><span lang="EN-US">Fabien<p></p></span></p>

<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>

</div>

</div>
Permalink | Reply | 0 comments |

Gmane