Re: [Pce] Martin Vigoureux's No Objection on draft-ietf-pce-segment-routing-14: (with COMMENT)

[Jeff Tantsura]

+1 Jon

Cheers,
Jeff
On Jan 10, 2019, 2:58 AM -0800, Jonathan Hardwick 
, wrote:
> Hi Julien
>
> At the moment, the L bit is simply called "the L bit" (not "limit" or 
> "limitless") and is defined like this:
>
> * L: A PCC sets this bit to 1 to indicate that it does not impose
> any limit on the MSD.
>
> Although it might be the opposite of what you'd expect, I think the 
> definition is nevertheless clear as it is written.
>
> Cheers
> Jon
>
> -Original Message-
> From: Julien Meuric 
> Sent: Monday, 7 January, 2019 9:37 AM
> To: Jeff Tantsura 
> Cc: Dhruv Dhody ; Jonathan Hardwick 
> ; Martin Vigoureux 
> ; The IESG ; 
> draft-ietf-pce-segment-rout...@ietf.org; pce@ietf.org
> Subject: Re: Martin Vigoureux's No Objection on 
> draft-ietf-pce-segment-routing-14: (with COMMENT)
>
> Hi Jeff,
>
> You're right. I certainly don't want to change the specification, nor to add 
> another ambiguity. I was just looking for a mnemonic to mitigate the 
> confusion pointed out by Martin, to be considered between bracket (leaving 
> the definition as is).
> Would "limit-blind" make sense?
>
> Cheers,
>
> Julien
>
>
> On 06/01/2019 20:20, Jeff Tantsura wrote:
> > Hi Julien,
> >
> > Happy New Year to you too.
> > There’s a slight difference between limitless (e.g. unlimited) and
> > limit has not been been imposed (not configured/unknown/etc).
> > I think  “limitless” doesn’t convey the exact meaning. In simple terms
> > - if L=1, don’t use MSD as a constraint in the path computation.
> >
> > Thanks,
> > Jeff
> >
> > On Fri, Jan 4, 2019 at 02:28  > <mailto:julien.meu...@orange.com>> wrote:
> >
> > Hi guys and happy new year! :-)
> >
> > Would it temper the confusion below if we added the term
> > "limitless" to
> > the L flag definition (section 5.1.1.)?
> >
> > My 2 cents,
> >
> > Julien
> >
> >
> > On 21/12/2018 18:14, Jonathan Hardwick wrote:
> > > I believe it is too late to change but I find L=1 meaning "no
> > limit" is *very* confusing. For me L stands for Limit and when L=1
> > there is a limit, when L=0 there is none.
> > >
> > > [Jon] Agree, both that it is confusing and too late to change
> > :-)
> >
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Martin Vigoureux's No Objection on draft-ietf-pce-segment-routing-14: (with COMMENT)

[Jonathan Hardwick]

Hi Julien

At the moment, the L bit is simply called "the L bit" (not "limit" or 
"limitless") and is defined like this:

  *  L: A PCC sets this bit to 1 to indicate that it does not impose
 any limit on the MSD.

Although it might be the opposite of what you'd expect, I think the definition 
is nevertheless clear as it is written.

Cheers
Jon 

-Original Message-
From: Julien Meuric  
Sent: Monday, 7 January, 2019 9:37 AM
To: Jeff Tantsura 
Cc: Dhruv Dhody ; Jonathan Hardwick 
; Martin Vigoureux 
; The IESG ; 
draft-ietf-pce-segment-rout...@ietf.org; pce@ietf.org
Subject: Re: Martin Vigoureux's No Objection on 
draft-ietf-pce-segment-routing-14: (with COMMENT)

Hi Jeff,

You're right. I certainly don't want to change the specification, nor to add 
another ambiguity. I was just looking for a mnemonic to mitigate the confusion 
pointed out by Martin, to be considered between bracket (leaving the definition 
as is).
Would "limit-blind" make sense?

Cheers,

Julien


On 06/01/2019 20:20, Jeff Tantsura wrote:
> Hi Julien,
>
> Happy New Year to you too.
> There’s a slight difference between limitless (e.g. unlimited) and 
> limit has not been been imposed (not configured/unknown/etc).
> I think  “limitless” doesn’t convey the exact meaning. In simple terms
> - if L=1, don’t use MSD as a constraint in the path computation.
>
> Thanks,
> Jeff
>
> On Fri, Jan 4, 2019 at 02:28  <mailto:julien.meu...@orange.com>> wrote:
>
> Hi guys and happy new year! :-)
>
> Would it temper the confusion below if we added the term
> "limitless" to
> the L flag definition (section 5.1.1.)?
>
> My 2 cents,
>
> Julien
>
>
> On 21/12/2018 18:14, Jonathan Hardwick wrote:
> > I believe it is too late to change but I find L=1 meaning "no
> limit" is *very* confusing. For me L stands for Limit and when L=1
> there is a limit, when L=0 there is none.
> >
> > [Jon] Agree, both that it is confusing and too late to change 
> :-)
>
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Martin Vigoureux's No Objection on draft-ietf-pce-segment-routing-14: (with COMMENT)

[Julien Meuric]

Hi Jeff,

You're right. I certainly don't want to change the specification, nor to
add another ambiguity. I was just looking for a mnemonic to mitigate the
confusion pointed out by Martin, to be considered between bracket
(leaving the definition as is).
Would "limit-blind" make sense?

Cheers,

Julien


On 06/01/2019 20:20, Jeff Tantsura wrote:
> Hi Julien,
>
> Happy New Year to you too.
> There’s a slight difference between limitless (e.g. unlimited) and
> limit has not been been imposed (not configured/unknown/etc).
> I think  “limitless” doesn’t convey the exact meaning. In simple terms
> - if L=1, don’t use MSD as a constraint in the path computation.
>
> Thanks,
> Jeff
>
> On Fri, Jan 4, 2019 at 02:28  > wrote:
>
> Hi guys and happy new year! :-)
>
> Would it temper the confusion below if we added the term
> "limitless" to
> the L flag definition (section 5.1.1.)?
>
> My 2 cents,
>
> Julien
>
>
> On 21/12/2018 18:14, Jonathan Hardwick wrote:
> > I believe it is too late to change but I find L=1 meaning "no
> limit" is *very* confusing. For me L stands for Limit and when L=1
> there is a limit, when L=0 there is none.
> >
> > [Jon] Agree, both that it is confusing and too late to change :-)
>

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Martin Vigoureux's No Objection on draft-ietf-pce-segment-routing-14: (with COMMENT)

[Jeff Tantsura]

Hi Julien,

Happy New Year to you too.
There’s a slight difference between limitless (e.g. unlimited) and limit
has not been been imposed (not configured/unknown/etc).
I think  “limitless” doesn’t convey the exact meaning. In simple terms - if
L=1, don’t use MSD as a constraint in the path computation.

Thanks,
Jeff

On Fri, Jan 4, 2019 at 02:28  wrote:

> Hi guys and happy new year! :-)
>
> Would it temper the confusion below if we added the term "limitless" to
> the L flag definition (section 5.1.1.)?
>
> My 2 cents,
>
> Julien
>
>
> On 21/12/2018 18:14, Jonathan Hardwick wrote:
> > I believe it is too late to change but I find L=1 meaning "no limit" is
> *very* confusing. For me L stands for Limit and when L=1 there is a limit,
> when L=0 there is none.
> >
> > [Jon] Agree, both that it is confusing and too late to change :-)
>
>
>
> _
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and
> delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.
>
>
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Martin Vigoureux's No Objection on draft-ietf-pce-segment-routing-14: (with COMMENT)

[julien.meuric]

Hi guys and happy new year! :-)

Would it temper the confusion below if we added the term "limitless" to
the L flag definition (section 5.1.1.)?

My 2 cents,

Julien


On 21/12/2018 18:14, Jonathan Hardwick wrote:
> I believe it is too late to change but I find L=1 meaning "no limit" is 
> *very* confusing. For me L stands for Limit and when L=1 there is a limit, 
> when L=0 there is none.
>
> [Jon] Agree, both that it is confusing and too late to change :-)


_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Martin Vigoureux's No Objection on draft-ietf-pce-segment-routing-14: (with COMMENT)

[Jonathan Hardwick]

Hi Martin

Sorry for the delayed response.  Please find replies to your comments below.

Best regards
Jon



Could you elaborate on what you mean by: "or to perform a specific service on 
the packet."

[Jon] I think it should say "specific function".  Some examples of this can be 
found in draft-filsfils-spring-srv6-network-programming.  I think this is 
fairly tangential to the PCEP document, so is probably not worth referencing, 
and perhaps we should remove the text about "specific service" altogether.

s/A Segment Routed path/A Segment Routing path/

   In SR networks, an ingress node of an SR path prepends an SR header to
   all outgoing packets.  The SR header consists of a list of SIDs (or
   MPLS labels in the context of this document).
This appears twice in two consecutive paragraphs at the beginning of section 3.

[Jon] Thanks - the redundant text will be deleted.

I'm not a native english speaker but I find the use of "ERO subobject"
confusing when used to refer to the SR-ERO subobject. Maybe say the "the
(SR-ERO) subobject of the ERO".

[Jon] I think the original is OK.  In general, if I read "the  subobject", 
I interpret that as "the subobject of type ".


   Length:  Contains the total length of the subobject in octets,
  including the L, Type and Length fields.  The Length MUST be at
  least 8, and MUST be a multiple of 4.  An SR-ERO subobject MUST
  contain at least one of a SID or an NAI.  The length should
  include the SID and NAI fields if and only if they are not absent.
I am confused about the minimum length. L, Type and Length use 2 octets. What 
bring this to 8 considering that a SID is 4? 

[Jon] The NT and Flags fields add another 2 octets.  The diagram shows them but 
the text does not mention them, whereas it does mention L, Type and Length.  
Perhaps this would be less confusing:

OLD
   Length:  Contains the total length of the subobject in octets,
  including the L, Type and Length fields.
NEW
   Length:  Contains the total length of the subobject in octets.
END

Also the last sentence is very confusing. It seems normal not to count 
something which is not there. No need to say so. The current statement seems to 
contradict the preceding sentence in fact, so I'd just remove it.

[Jon] Agreed.

  *  A 4 octet MPLS label, where the 20 most significant bits encode
 the label value per [RFC3032].
s/MPLS label/MPLS Label Stack Entry/

I believe it is too late to change but I find L=1 meaning "no limit" is *very* 
confusing. For me L stands for Limit and when L=1 there is a limit, when L=0 
there is none.

[Jon] Agree, both that it is confusing and too late to change :-)

On the metric object.
You have the requirement that "the PCE MUST minimize the SID depth". This is a 
non actionable requirement. You need to set a bound. I very much understand 
that the bound is the specified sid depth (and you say it properly afterwards 
("the PCE MUST NOT return a path whose SID depth exceeds the given 
metric-value"), but still the sentence I point to is a non actionable 
requirement which you may want to reformulate.

[Jon] Agreed.  How about "the PCE minimizes the SID depth".

   If a PCEP session is established with a non-zero default MSD value,
   then the PCC MUST NOT send an MSD METRIC object with an MSD greater
   than the session's default MSD.
Out of curiosity, why do you forbid that case?

[Jon] The PCC starts a session saying its MSD is 4.  It then requests a path 
saying that the MSD must not exceed 5.  This is a clear contradiction.

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

[Pce] Martin Vigoureux's No Objection on draft-ietf-pce-segment-routing-14: (with COMMENT)

[Martin Vigoureux]

Martin Vigoureux has entered the following ballot position for
draft-ietf-pce-segment-routing-14: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing/



--
COMMENT:
--

Hello,

thank you for this document. I have few comments/questions:

Could you elaborate on what you mean by: "or to perform a specific service on
the packet."

s/A Segment Routed path/A Segment Routing path/

   In SR networks, an ingress node of an SR path prepends an SR header to
   all outgoing packets.  The SR header consists of a list of SIDs (or
   MPLS labels in the context of this document).
This appears twice in two consecutive paragraphs at the beginning of section 3.

I'm not a native english speaker but I find the use of "ERO subobject"
confusing when used to refer to the SR-ERO subobject. Maybe say the "the
(SR-ERO) subobject of the ERO".

   Length:  Contains the total length of the subobject in octets,
  including the L, Type and Length fields.  The Length MUST be at
  least 8, and MUST be a multiple of 4.  An SR-ERO subobject MUST
  contain at least one of a SID or an NAI.  The length should
  include the SID and NAI fields if and only if they are not absent.
I am confused about the minimum length. L, Type and Length use 2 octets. What
bring this to 8 considering that a SID is 4? Also the last sentence is very
confusing. It seems normal not to count something which is not there. No need
to say so. The current statement seems to contradict the preceding sentence in
fact, so I'd just remove it.

  *  A 4 octet MPLS label, where the 20 most significant bits encode
 the label value per [RFC3032].
s/MPLS label/MPLS Label Stack Entry/

I believe it is too late to change but I find L=1 meaning "no limit" is *very*
confusing. For me L stands for Limit and when L=1 there is a limit, when L=0
there is none.

On the metric object.
You have the requirement that "the PCE MUST minimize the SID depth". This is a
non actionable requirement. You need to set a bound. I very much understand
that the bound is the specified sid depth (and you say it properly afterwards
("the PCE MUST NOT return a path whose SID depth exceeds the given
metric-value"), but still the sentence I point to is a non actionable
requirement which you may want to reformulate.

   If a PCEP session is established with a non-zero default MSD value,
   then the PCC MUST NOT send an MSD METRIC object with an MSD greater
   than the session's default MSD.
Out of curiosity, why do you forbid that case?


___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce