Re: [Lsr] [RTG-DIR] RtgDir Review: draft-ietf-isis-segment-routing-msd-15

2018-10-05 Thread Julien Meuric 

  
  
Hi Les,

Indeed, this version resolves my initial comments.

Thank you.

Julien


Oct. 05, 2018 - ginsb...@cisco.com:


  
  
  
  
Bruno/Julien/Benjamin
–
 
V18
of the draft has been published. I believe this addresses
all outstanding comments.
 
Thanx
very much for your input.
 
   
Les
 
 

  

  From:
  bruno.decra...@orange.com
  
  
  Sent: Thursday, October 04, 2018 12:56 AM
  

  
   
  Les,
   
  Thanks
  for the proposed text.
  It’s
  crystal clear. It works for me.
   
  --Bruno
   
  

  
From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]

Sent: Wednesday, October 03, 2018 11:27 PM

  

 
(Hard
to follow Acee’s post – especially for entertainment
value)
 
Bruno
–
 
I
think that we do want some less awkward text. So I am
proposing to add the following into the Introduction:
 
“Label
  Imposition is the act of modifying and/or adding
  labels to the outgoing label stack associated with a
  packet.
This
  includes:
 
o
   replacing the label at the top of the label stack
  with a new label
o
   pushing one or more new  labels onto the label stack.
 
The
  number of labels imposed is then the sum of the labels
  which are replaced and the labels which are pushed.
See
  [RFC3031] for further details.”
 
The
BMI definition then becomes:
 
“Base
  MPLS Imposition MSD (BMI-MSD) signals the total number
  of MPLS
  
  labels which can be imposed, including all
  service/transport/special
  
  labels.”
 
Does
this work??
 
   
Les
 
 

  

  From:
  Acee Lindem (acee)
  
  Sent: Wednesday, October 03, 2018 2:05 PM
  

  
   
  Hi Bruno, 
  
 

  
On Oct 3, 2018, at 10:07 AM, 
bruno.decra...@orange.com wrote:
  
   
  

  Hi
  Acee,


   


   


  

  
From: Acee
Lindem (acee) [mailto:a...@cisco.com] 
  

  
  
 
  
  
Hey
Bruno, Jeff, Les,
  
  
 
  
  
Have
we agreed on the precise definition of
“label imposition”?
  
  
Thanks
for asking.
  
  
Not
so far.
  
  
We
don’t necessarily need to agree on a
precision definition of “label imposition”.
In my latest email (a few hours ago), I
proposed to reuse the phrasing from RFC
3031, which does not use that term. If we
are fine with using RFC 3031 terms, that
would be fine for me.

Re: [Lsr] [RTG-DIR] RtgDir Review: draft-ietf-isis-segment-routing-msd-15

2018-10-05 Thread bruno.decraene 
Les,

V18 addresses all my comments.

Thank you, Les, for the discussion and for reflecting the outcome in the draft.

--Bruno

From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Friday, October 05, 2018 2:14 AM
To: DECRAENE Bruno IMT/OLN; Acee Lindem (acee); MEURIC Julien IMT/OLN; Benjamin 
Kaduk
Cc: Routing Directorate; draft-ietf-isis-segment-routing-...@ietf.org; 
rtg-...@ietf.org; Alvaro Retana; lsr@ietf.org; Jeff Tantsura; MEURIC Julien 
IMT/OLN
Subject: RE: [Lsr] [RTG-DIR] RtgDir Review: 
draft-ietf-isis-segment-routing-msd-15

Bruno/Julien/Benjamin –

V18 of the draft has been published. I believe this addresses all outstanding 
comments.

Thanx very much for your input.

Les


From: bruno.decra...@orange.com 
Sent: Thursday, October 04, 2018 12:56 AM
To: Les Ginsberg (ginsberg) ; Acee Lindem (acee) 

Cc: Routing Directorate ; 
draft-ietf-isis-segment-routing-...@ietf.org; rtg-...@ietf.org; Alvaro Retana 
; lsr@ietf.org; Jeff Tantsura 
; MEURIC Julien IMT/OLN 
Subject: RE: [Lsr] [RTG-DIR] RtgDir Review: 
draft-ietf-isis-segment-routing-msd-15

Les,

Thanks for the proposed text.
It’s crystal clear. It works for me.

--Bruno

From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Wednesday, October 03, 2018 11:27 PM
To: Acee Lindem (acee); DECRAENE Bruno IMT/OLN
Cc: Routing Directorate; 
draft-ietf-isis-segment-routing-...@ietf.org<mailto:draft-ietf-isis-segment-routing-...@ietf.org>;
 rtg-...@ietf.org<mailto:rtg-...@ietf.org>; Alvaro Retana; 
lsr@ietf.org<mailto:lsr@ietf.org>; Jeff Tantsura; MEURIC Julien IMT/OLN
Subject: RE: [Lsr] [RTG-DIR] RtgDir Review: 
draft-ietf-isis-segment-routing-msd-15

(Hard to follow Acee’s post – especially for entertainment value)

Bruno –

I think that we do want some less awkward text. So I am proposing to add the 
following into the Introduction:

“Label Imposition is the act of modifying and/or adding labels to the outgoing 
label stack associated with a packet.
This includes:

o  replacing the label at the top of the label stack with a new label
o  pushing one or more new  labels onto the label stack.

The number of labels imposed is then the sum of the labels which are replaced 
and the labels which are pushed.
See [RFC3031] for further details.”

The BMI definition then becomes:

“Base MPLS Imposition MSD (BMI-MSD) signals the total number of MPLS
   labels which can be imposed, including all service/transport/special
   labels.”

Does this work??

Les


From: Acee Lindem (acee)
Sent: Wednesday, October 03, 2018 2:05 PM
To: Bruno Decraene mailto:bruno.decra...@orange.com>>
Cc: Routing Directorate mailto:rtg-...@ietf.org>>; 
draft-ietf-isis-segment-routing-...@ietf.org<mailto:draft-ietf-isis-segment-routing-...@ietf.org>;
 rtg-...@ietf.org<mailto:rtg-...@ietf.org>; Alvaro Retana 
mailto:aretana.i...@gmail.com>>; 
lsr@ietf.org<mailto:lsr@ietf.org>; Jeff Tantsura 
mailto:jefftant.i...@gmail.com>>; Les Ginsberg 
(ginsberg) mailto:ginsb...@cisco.com>>; MEURIC Julien 
IMT/OLN mailto:julien.meu...@orange.com>>
Subject: Re: [Lsr] [RTG-DIR] RtgDir Review: 
draft-ietf-isis-segment-routing-msd-15

Hi Bruno,

On Oct 3, 2018, at 10:07 AM, 
bruno.decra...@orange.com<mailto:bruno.decra...@orange.com> wrote:

Hi Acee,


From: Acee Lindem (acee) [mailto:a...@cisco.com]

Hey Bruno, Jeff, Les,

Have we agreed on the precise definition of “label imposition”?
Thanks for asking.
Not so far.
We don’t necessarily need to agree on a precision definition of “label 
imposition”. In my latest email (a few hours ago), I proposed to reuse the 
phrasing from RFC 3031, which does not use that term. If we are fine with using 
RFC 3031 terms, that would be fine for me.

Since the MSD type has always been defined in terms of “Imposition” in both the 
OSPF and IS-IS MSD drafts, I think it would be better to clarify any 
ambiguities the text Les quotes below.

Of course, we don’t want to get too bogged down in semantics as has happened in 
the past: https://www.youtube.com/watch?v=-P8IYKxpqG0

Thanks,
Acee



Thanks,
--Bruno


Thanks,
Acee

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of 
Bruno Decraene mailto:bruno.decra...@orange.com>>
Date: Wednesday, October 3, 2018 at 4:37 AM
To: Jeff Tantsura mailto:jefftant.i...@gmail.com>>
Cc: Routing Directorate mailto:rtg-...@ietf.org>>, 
"draft-ietf-isis-segment-routing-...@ietf.org<mailto:draft-ietf-isis-segment-routing-...@ietf.org>"
 
mailto:draft-ietf-isis-segment-routing-...@ietf.org>>,
 "rtg-...@ietf.org<mailto:rtg-...@ietf.org>" 
mailto:rtg-...@ietf.org>>, Alvaro Retana 
mailto:aretana.i...@gmail.com>>, 
"lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>, "Les 
Ginsberg (ginsberg)" mailto:ginsb...@cisco.com>>, MEURIC 
Julien IMT/OLN mailto:julien.meu...@orange.com>>
Subject: Re: [Lsr] [RTG-DIR] RtgDir Review:

Re: [Lsr] [RTG-DIR] RtgDir Review: draft-ietf-isis-segment-routing-msd-15

2018-10-04 Thread Les Ginsberg (ginsberg) 
Bruno/Julien/Benjamin –

V18 of the draft has been published. I believe this addresses all outstanding 
comments.

Thanx very much for your input.

Les


From: bruno.decra...@orange.com 
Sent: Thursday, October 04, 2018 12:56 AM
To: Les Ginsberg (ginsberg) ; Acee Lindem (acee) 

Cc: Routing Directorate ; 
draft-ietf-isis-segment-routing-...@ietf.org; rtg-...@ietf.org; Alvaro Retana 
; lsr@ietf.org; Jeff Tantsura 
; MEURIC Julien IMT/OLN 
Subject: RE: [Lsr] [RTG-DIR] RtgDir Review: 
draft-ietf-isis-segment-routing-msd-15

Les,

Thanks for the proposed text.
It’s crystal clear. It works for me.

--Bruno

From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Wednesday, October 03, 2018 11:27 PM
To: Acee Lindem (acee); DECRAENE Bruno IMT/OLN
Cc: Routing Directorate; 
draft-ietf-isis-segment-routing-...@ietf.org<mailto:draft-ietf-isis-segment-routing-...@ietf.org>;
 rtg-...@ietf.org<mailto:rtg-...@ietf.org>; Alvaro Retana; 
lsr@ietf.org<mailto:lsr@ietf.org>; Jeff Tantsura; MEURIC Julien IMT/OLN
Subject: RE: [Lsr] [RTG-DIR] RtgDir Review: 
draft-ietf-isis-segment-routing-msd-15

(Hard to follow Acee’s post – especially for entertainment value)

Bruno –

I think that we do want some less awkward text. So I am proposing to add the 
following into the Introduction:

“Label Imposition is the act of modifying and/or adding labels to the outgoing 
label stack associated with a packet.
This includes:

o  replacing the label at the top of the label stack with a new label
o  pushing one or more new  labels onto the label stack.

The number of labels imposed is then the sum of the labels which are replaced 
and the labels which are pushed.
See [RFC3031] for further details.”

The BMI definition then becomes:

“Base MPLS Imposition MSD (BMI-MSD) signals the total number of MPLS
   labels which can be imposed, including all service/transport/special
   labels.”

Does this work??

Les


From: Acee Lindem (acee)
Sent: Wednesday, October 03, 2018 2:05 PM
To: Bruno Decraene mailto:bruno.decra...@orange.com>>
Cc: Routing Directorate mailto:rtg-...@ietf.org>>; 
draft-ietf-isis-segment-routing-...@ietf.org<mailto:draft-ietf-isis-segment-routing-...@ietf.org>;
 rtg-...@ietf.org<mailto:rtg-...@ietf.org>; Alvaro Retana 
mailto:aretana.i...@gmail.com>>; 
lsr@ietf.org<mailto:lsr@ietf.org>; Jeff Tantsura 
mailto:jefftant.i...@gmail.com>>; Les Ginsberg 
(ginsberg) mailto:ginsb...@cisco.com>>; MEURIC Julien 
IMT/OLN mailto:julien.meu...@orange.com>>
Subject: Re: [Lsr] [RTG-DIR] RtgDir Review: 
draft-ietf-isis-segment-routing-msd-15

Hi Bruno,

On Oct 3, 2018, at 10:07 AM, 
bruno.decra...@orange.com<mailto:bruno.decra...@orange.com> wrote:

Hi Acee,


From: Acee Lindem (acee) [mailto:a...@cisco.com]

Hey Bruno, Jeff, Les,

Have we agreed on the precise definition of “label imposition”?
Thanks for asking.
Not so far.
We don’t necessarily need to agree on a precision definition of “label 
imposition”. In my latest email (a few hours ago), I proposed to reuse the 
phrasing from RFC 3031, which does not use that term. If we are fine with using 
RFC 3031 terms, that would be fine for me.

Since the MSD type has always been defined in terms of “Imposition” in both the 
OSPF and IS-IS MSD drafts, I think it would be better to clarify any 
ambiguities the text Les quotes below.

Of course, we don’t want to get too bogged down in semantics as has happened in 
the past: https://www.youtube.com/watch?v=-P8IYKxpqG0

Thanks,
Acee



Thanks,
--Bruno


Thanks,
Acee

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of 
Bruno Decraene mailto:bruno.decra...@orange.com>>
Date: Wednesday, October 3, 2018 at 4:37 AM
To: Jeff Tantsura mailto:jefftant.i...@gmail.com>>
Cc: Routing Directorate mailto:rtg-...@ietf.org>>, 
"draft-ietf-isis-segment-routing-...@ietf.org<mailto:draft-ietf-isis-segment-routing-...@ietf.org>"
 
mailto:draft-ietf-isis-segment-routing-...@ietf.org>>,
 "rtg-...@ietf.org<mailto:rtg-...@ietf.org>" 
mailto:rtg-...@ietf.org>>, Alvaro Retana 
mailto:aretana.i...@gmail.com>>, 
"lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>, "Les 
Ginsberg (ginsberg)" mailto:ginsb...@cisco.com>>, MEURIC 
Julien IMT/OLN mailto:julien.meu...@orange.com>>
Subject: Re: [Lsr] [RTG-DIR] RtgDir Review: 
draft-ietf-isis-segment-routing-msd-15

Jeff,

From: Jeff Tantsura [mailto:jefftant.i...@gmail.com]
Sent: Tuesday, October 02, 2018 8:28 PM
To: DECRAENE Bruno IMT/OLN; Alvaro Retana; MEURIC Julien IMT/OLN; Les Ginsberg 
(ginsberg)
Cc: rtg-...@ietf.org<mailto:rtg-...@ietf.org>; 
lsr@ietf.org<mailto:lsr@ietf.org>; rtg-...@ietf.org<mailto:rtg-...@ietf.org>; 
draft-ietf-isis-segment-routing-...@ietf.org<mailto:draft-ietf-isis-segment-routing-...@ietf.org>
Subject: RE: [RTG-DIR] RtgDir Review: draft-ietf-isis-segment-routing-msd-1

Re: [Lsr] [RTG-DIR] RtgDir Review: draft-ietf-isis-segment-routing-msd-15

2018-10-04 Thread bruno.decraene 
Les,

Thanks for the proposed text.
It’s crystal clear. It works for me.

--Bruno

From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Wednesday, October 03, 2018 11:27 PM
To: Acee Lindem (acee); DECRAENE Bruno IMT/OLN
Cc: Routing Directorate; draft-ietf-isis-segment-routing-...@ietf.org; 
rtg-...@ietf.org; Alvaro Retana; lsr@ietf.org; Jeff Tantsura; MEURIC Julien 
IMT/OLN
Subject: RE: [Lsr] [RTG-DIR] RtgDir Review: 
draft-ietf-isis-segment-routing-msd-15

(Hard to follow Acee’s post – especially for entertainment value)

Bruno –

I think that we do want some less awkward text. So I am proposing to add the 
following into the Introduction:

“Label Imposition is the act of modifying and/or adding labels to the outgoing 
label stack associated with a packet.
This includes:

o  replacing the label at the top of the label stack with a new label
o  pushing one or more new  labels onto the label stack.

The number of labels imposed is then the sum of the labels which are replaced 
and the labels which are pushed.
See [RFC3031] for further details.”

The BMI definition then becomes:

“Base MPLS Imposition MSD (BMI-MSD) signals the total number of MPLS
   labels which can be imposed, including all service/transport/special
   labels.”

Does this work??

Les


From: Acee Lindem (acee)
Sent: Wednesday, October 03, 2018 2:05 PM
To: Bruno Decraene 
Cc: Routing Directorate ; 
draft-ietf-isis-segment-routing-...@ietf.org; rtg-...@ietf.org; Alvaro Retana 
; lsr@ietf.org; Jeff Tantsura 
; Les Ginsberg (ginsberg) ; MEURIC 
Julien IMT/OLN 
Subject: Re: [Lsr] [RTG-DIR] RtgDir Review: 
draft-ietf-isis-segment-routing-msd-15

Hi Bruno,

On Oct 3, 2018, at 10:07 AM, 
bruno.decra...@orange.com<mailto:bruno.decra...@orange.com> wrote:

Hi Acee,


From: Acee Lindem (acee) [mailto:a...@cisco.com]


Hey Bruno, Jeff, Les,

Have we agreed on the precise definition of “label imposition”?
Thanks for asking.
Not so far.
We don’t necessarily need to agree on a precision definition of “label 
imposition”. In my latest email (a few hours ago), I proposed to reuse the 
phrasing from RFC 3031, which does not use that term. If we are fine with using 
RFC 3031 terms, that would be fine for me.

Since the MSD type has always been defined in terms of “Imposition” in both the 
OSPF and IS-IS MSD drafts, I think it would be better to clarify any 
ambiguities the text Les quotes below.

Of course, we don’t want to get too bogged down in semantics as has happened in 
the past: https://www.youtube.com/watch?v=-P8IYKxpqG0

Thanks,
Acee



Thanks,
--Bruno


Thanks,
Acee

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of 
Bruno Decraene mailto:bruno.decra...@orange.com>>
Date: Wednesday, October 3, 2018 at 4:37 AM
To: Jeff Tantsura mailto:jefftant.i...@gmail.com>>
Cc: Routing Directorate mailto:rtg-...@ietf.org>>, 
"draft-ietf-isis-segment-routing-...@ietf.org<mailto:draft-ietf-isis-segment-routing-...@ietf.org>"
 
mailto:draft-ietf-isis-segment-routing-...@ietf.org>>,
 "rtg-...@ietf.org<mailto:rtg-...@ietf.org>" 
mailto:rtg-...@ietf.org>>, Alvaro Retana 
mailto:aretana.i...@gmail.com>>, 
"lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>, "Les 
Ginsberg (ginsberg)" mailto:ginsb...@cisco.com>>, MEURIC 
Julien IMT/OLN mailto:julien.meu...@orange.com>>
Subject: Re: [Lsr] [RTG-DIR] RtgDir Review: 
draft-ietf-isis-segment-routing-msd-15

Jeff,

From: Jeff Tantsura [mailto:jefftant.i...@gmail.com]
Sent: Tuesday, October 02, 2018 8:28 PM
To: DECRAENE Bruno IMT/OLN; Alvaro Retana; MEURIC Julien IMT/OLN; Les Ginsberg 
(ginsberg)
Cc: rtg-...@ietf.org<mailto:rtg-...@ietf.org>; 
lsr@ietf.org<mailto:lsr@ietf.org>; rtg-...@ietf.org<mailto:rtg-...@ietf.org>; 
draft-ietf-isis-segment-routing-...@ietf.org<mailto:draft-ietf-isis-segment-routing-...@ietf.org>
Subject: RE: [RTG-DIR] RtgDir Review: draft-ietf-isis-segment-routing-msd-15

Gents,

I’m 100% with Les here, going into platform/asic specifics within this document 
would inevitably create ambiguity.
Absolutely.
And nobody is asking for this.

Cheers
--Bruno



Cheers,
Jeff
On Oct 2, 2018, 11:20 AM -0700, Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>>, wrote:

Bruno –

Trimming the thread…

[Les2:] Label imposition is meant to cover both the SWAP operation and the PUSH 
operation. In the example you provided above where a label stack of “12” is 
replaced by a label stack of “14,15” the number of labels “imposed” is 2.
[Bruno2] In that case, I definitely think that the discussion was useful and 
that this point needs to be clarified in the document.
Whether you choose to call that (1 POP, 2 PUSH) or (1 SWAP, 1 PUSH)  or simply 
a SWAP isn’t relevant here (though it might matter to folks like the RFC 3031 
authors).

With that ibn mind, here is proposed text:

“Base MPLS Imposition MSD (BMI-MSD) signals the total number of MPLS
   la

Re: [Lsr] [RTG-DIR] RtgDir Review: draft-ietf-isis-segment-routing-msd-15

2018-10-03 Thread Les Ginsberg (ginsberg) 
(Hard to follow Acee’s post – especially for entertainment value)

Bruno –

I think that we do want some less awkward text. So I am proposing to add the 
following into the Introduction:

“Label Imposition is the act of modifying and/or adding labels to the outgoing 
label stack associated with a packet.
This includes:

o  replacing the label at the top of the label stack with a new label
o  pushing one or more new  labels onto the label stack.

The number of labels imposed is then the sum of the labels which are replaced 
and the labels which are pushed.
See [RFC3031] for further details.”

The BMI definition then becomes:

“Base MPLS Imposition MSD (BMI-MSD) signals the total number of MPLS
   labels which can be imposed, including all service/transport/special
   labels.”

Does this work??

Les


From: Acee Lindem (acee)
Sent: Wednesday, October 03, 2018 2:05 PM
To: Bruno Decraene 
Cc: Routing Directorate ; 
draft-ietf-isis-segment-routing-...@ietf.org; rtg-...@ietf.org; Alvaro Retana 
; lsr@ietf.org; Jeff Tantsura 
; Les Ginsberg (ginsberg) ; MEURIC 
Julien IMT/OLN 
Subject: Re: [Lsr] [RTG-DIR] RtgDir Review: 
draft-ietf-isis-segment-routing-msd-15

Hi Bruno,


On Oct 3, 2018, at 10:07 AM, 
bruno.decra...@orange.com<mailto:bruno.decra...@orange.com> wrote:

Hi Acee,


From: Acee Lindem (acee) [mailto:a...@cisco.com]



Hey Bruno, Jeff, Les,

Have we agreed on the precise definition of “label imposition”?
Thanks for asking.
Not so far.
We don’t necessarily need to agree on a precision definition of “label 
imposition”. In my latest email (a few hours ago), I proposed to reuse the 
phrasing from RFC 3031, which does not use that term. If we are fine with using 
RFC 3031 terms, that would be fine for me.

Since the MSD type has always been defined in terms of “Imposition” in both the 
OSPF and IS-IS MSD drafts, I think it would be better to clarify any 
ambiguities the text Les quotes below.

Of course, we don’t want to get too bogged down in semantics as has happened in 
the past: https://www.youtube.com/watch?v=-P8IYKxpqG0

Thanks,
Acee




Thanks,
--Bruno


Thanks,
Acee

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of 
Bruno Decraene mailto:bruno.decra...@orange.com>>
Date: Wednesday, October 3, 2018 at 4:37 AM
To: Jeff Tantsura mailto:jefftant.i...@gmail.com>>
Cc: Routing Directorate mailto:rtg-...@ietf.org>>, 
"draft-ietf-isis-segment-routing-...@ietf.org<mailto:draft-ietf-isis-segment-routing-...@ietf.org>"
 
mailto:draft-ietf-isis-segment-routing-...@ietf.org>>,
 "rtg-...@ietf.org<mailto:rtg-...@ietf.org>" 
mailto:rtg-...@ietf.org>>, Alvaro Retana 
mailto:aretana.i...@gmail.com>>, 
"lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>, "Les 
Ginsberg (ginsberg)" mailto:ginsb...@cisco.com>>, MEURIC 
Julien IMT/OLN mailto:julien.meu...@orange.com>>
Subject: Re: [Lsr] [RTG-DIR] RtgDir Review: 
draft-ietf-isis-segment-routing-msd-15

Jeff,

From: Jeff Tantsura [mailto:jefftant.i...@gmail.com]
Sent: Tuesday, October 02, 2018 8:28 PM
To: DECRAENE Bruno IMT/OLN; Alvaro Retana; MEURIC Julien IMT/OLN; Les Ginsberg 
(ginsberg)
Cc: rtg-...@ietf.org<mailto:rtg-...@ietf.org>; 
lsr@ietf.org<mailto:lsr@ietf.org>; rtg-...@ietf.org<mailto:rtg-...@ietf.org>; 
draft-ietf-isis-segment-routing-...@ietf.org<mailto:draft-ietf-isis-segment-routing-...@ietf.org>
Subject: RE: [RTG-DIR] RtgDir Review: draft-ietf-isis-segment-routing-msd-15

Gents,

I’m 100% with Les here, going into platform/asic specifics within this document 
would inevitably create ambiguity.
Absolutely.
And nobody is asking for this.

Cheers
--Bruno



Cheers,
Jeff
On Oct 2, 2018, 11:20 AM -0700, Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>>, wrote:


Bruno –

Trimming the thread…

[Les2:] Label imposition is meant to cover both the SWAP operation and the PUSH 
operation. In the example you provided above where a label stack of “12” is 
replaced by a label stack of “14,15” the number of labels “imposed” is 2.
[Bruno2] In that case, I definitely think that the discussion was useful and 
that this point needs to be clarified in the document.
Whether you choose to call that (1 POP, 2 PUSH) or (1 SWAP, 1 PUSH)  or simply 
a SWAP isn’t relevant here (though it might matter to folks like the RFC 3031 
authors).

With that ibn mind, here is proposed text:

“Base MPLS Imposition MSD (BMI-MSD) signals the total number of MPLS
   labels which can be imposed, including all service/transport/special
   labels.  Imposition includes swap and/or push operations.

If the advertising router performs label imposition in the context of
   the ingress interface, it is not possible to meaningfully advertise
   per link values.  In such a case only the Node MSD SHOULD be
   advertised.”

[Bruno2] Given that the term “imposition” does not seem to be defined within 
the IETF, I would still favor a form

Re: [Lsr] [RTG-DIR] RtgDir Review: draft-ietf-isis-segment-routing-msd-15

2018-10-03 Thread Acee Lindem (acee) 
Hi Bruno,

On Oct 3, 2018, at 10:07 AM, 
bruno.decra...@orange.com<mailto:bruno.decra...@orange.com> wrote:

Hi Acee,


From: Acee Lindem (acee) [mailto:a...@cisco.com]


Hey Bruno, Jeff, Les,

Have we agreed on the precise definition of “label imposition”?
Thanks for asking.
Not so far.
We don’t necessarily need to agree on a precision definition of “label 
imposition”. In my latest email (a few hours ago), I proposed to reuse the 
phrasing from RFC 3031, which does not use that term. If we are fine with using 
RFC 3031 terms, that would be fine for me.

Since the MSD type has always been defined in terms of “Imposition” in both the 
OSPF and IS-IS MSD drafts, I think it would be better to clarify any 
ambiguities the text Les quotes below.

Of course, we don’t want to get too bogged down in semantics as has happened in 
the past: https://www.youtube.com/watch?v=-P8IYKxpqG0

Thanks,
Acee



Thanks,
--Bruno


Thanks,
Acee

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of 
Bruno Decraene mailto:bruno.decra...@orange.com>>
Date: Wednesday, October 3, 2018 at 4:37 AM
To: Jeff Tantsura mailto:jefftant.i...@gmail.com>>
Cc: Routing Directorate mailto:rtg-...@ietf.org>>, 
"draft-ietf-isis-segment-routing-...@ietf.org<mailto:draft-ietf-isis-segment-routing-...@ietf.org>"
 
mailto:draft-ietf-isis-segment-routing-...@ietf.org>>,
 "rtg-...@ietf.org<mailto:rtg-...@ietf.org>" 
mailto:rtg-...@ietf.org>>, Alvaro Retana 
mailto:aretana.i...@gmail.com>>, 
"lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>, "Les 
Ginsberg (ginsberg)" mailto:ginsb...@cisco.com>>, MEURIC 
Julien IMT/OLN mailto:julien.meu...@orange.com>>
Subject: Re: [Lsr] [RTG-DIR] RtgDir Review: 
draft-ietf-isis-segment-routing-msd-15

Jeff,

From: Jeff Tantsura [mailto:jefftant.i...@gmail.com]
Sent: Tuesday, October 02, 2018 8:28 PM
To: DECRAENE Bruno IMT/OLN; Alvaro Retana; MEURIC Julien IMT/OLN; Les Ginsberg 
(ginsberg)
Cc: rtg-...@ietf.org<mailto:rtg-...@ietf.org>; 
lsr@ietf.org<mailto:lsr@ietf.org>; rtg-...@ietf.org<mailto:rtg-...@ietf.org>; 
draft-ietf-isis-segment-routing-...@ietf.org<mailto:draft-ietf-isis-segment-routing-...@ietf.org>
Subject: RE: [RTG-DIR] RtgDir Review: draft-ietf-isis-segment-routing-msd-15

Gents,

I’m 100% with Les here, going into platform/asic specifics within this document 
would inevitably create ambiguity.
Absolutely.
And nobody is asking for this.

Cheers
--Bruno



Cheers,
Jeff
On Oct 2, 2018, 11:20 AM -0700, Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>>, wrote:

Bruno –

Trimming the thread…

[Les2:] Label imposition is meant to cover both the SWAP operation and the PUSH 
operation. In the example you provided above where a label stack of “12” is 
replaced by a label stack of “14,15” the number of labels “imposed” is 2.
[Bruno2] In that case, I definitely think that the discussion was useful and 
that this point needs to be clarified in the document.
Whether you choose to call that (1 POP, 2 PUSH) or (1 SWAP, 1 PUSH)  or simply 
a SWAP isn’t relevant here (though it might matter to folks like the RFC 3031 
authors).

With that ibn mind, here is proposed text:

“Base MPLS Imposition MSD (BMI-MSD) signals the total number of MPLS
   labels which can be imposed, including all service/transport/special
   labels.  Imposition includes swap and/or push operations.

If the advertising router performs label imposition in the context of
   the ingress interface, it is not possible to meaningfully advertise
   per link values.  In such a case only the Node MSD SHOULD be
   advertised.”

[Bruno2] Given that the term “imposition” does not seem to be defined within 
the IETF, I would still favor a formal definition not using it. e.g. “BMI-MSD 
advertises the ability to increase the depth of the label stack by BMI-MSD 
labels”.
Alternatively, I’d propose the following rewording which seems clearer to me:
OLD: Imposition includes swap and/or push operations.
NEW: A swap operation counts as an imposition of one label; just like one push 
operation.

[Les3:] This gets into implementation specific issues that I would really like 
to avoid.
For example, some implementations perform one and only one  “operation”. 
Conceptually that may involve a swap and a push – but from the internal 
implementation POV it is simply one operation. And this may be true regardless 
of how many labels are involved. Other implementations might perform this in 
several discrete steps. The language we use here should not imply anything 
about how many labels are associated with a specific operation.

The term “increase” isn’t accurate because in the case of a swap there is no 
increase, yet the label which is replaced is counted.

https://tools.ietf.org/html/rfc3031#section-3.10 is relevant here.

The term “imposition” is generic – and as Alvaro has pointed out is used in RFC 
4221. And

Re: [Lsr] [RTG-DIR] RtgDir Review: draft-ietf-isis-segment-routing-msd-15

2018-10-03 Thread bruno.decraene 
Hi Acee,


From: Acee Lindem (acee) [mailto:a...@cisco.com]


Hey Bruno, Jeff, Les,

Have we agreed on the precise definition of “label imposition”?
Thanks for asking.
Not so far.
We don’t necessarily need to agree on a precision definition of “label 
imposition”. In my latest email (a few hours ago), I proposed to reuse the 
phrasing from RFC 3031, which does not use that term. If we are fine with using 
RFC 3031 terms, that would be fine for me.

Thanks,
--Bruno


Thanks,
Acee

From: Lsr  on behalf of Bruno Decraene 

Date: Wednesday, October 3, 2018 at 4:37 AM
To: Jeff Tantsura 
Cc: Routing Directorate , 
"draft-ietf-isis-segment-routing-...@ietf.org" 
, "rtg-...@ietf.org" 
, Alvaro Retana , "lsr@ietf.org" 
, "Les Ginsberg (ginsberg)" , MEURIC Julien 
IMT/OLN 
Subject: Re: [Lsr] [RTG-DIR] RtgDir Review: 
draft-ietf-isis-segment-routing-msd-15

Jeff,

From: Jeff Tantsura [mailto:jefftant.i...@gmail.com]
Sent: Tuesday, October 02, 2018 8:28 PM
To: DECRAENE Bruno IMT/OLN; Alvaro Retana; MEURIC Julien IMT/OLN; Les Ginsberg 
(ginsberg)
Cc: rtg-...@ietf.org; lsr@ietf.org; rtg-...@ietf.org; 
draft-ietf-isis-segment-routing-...@ietf.org
Subject: RE: [RTG-DIR] RtgDir Review: draft-ietf-isis-segment-routing-msd-15

Gents,

I’m 100% with Les here, going into platform/asic specifics within this document 
would inevitably create ambiguity.
Absolutely.
And nobody is asking for this.

Cheers
--Bruno



Cheers,
Jeff
On Oct 2, 2018, 11:20 AM -0700, Les Ginsberg (ginsberg) , 
wrote:

Bruno –

Trimming the thread…

[Les2:] Label imposition is meant to cover both the SWAP operation and the PUSH 
operation. In the example you provided above where a label stack of “12” is 
replaced by a label stack of “14,15” the number of labels “imposed” is 2.
[Bruno2] In that case, I definitely think that the discussion was useful and 
that this point needs to be clarified in the document.
Whether you choose to call that (1 POP, 2 PUSH) or (1 SWAP, 1 PUSH)  or simply 
a SWAP isn’t relevant here (though it might matter to folks like the RFC 3031 
authors).

With that ibn mind, here is proposed text:

“Base MPLS Imposition MSD (BMI-MSD) signals the total number of MPLS
   labels which can be imposed, including all service/transport/special
   labels.  Imposition includes swap and/or push operations.

If the advertising router performs label imposition in the context of
   the ingress interface, it is not possible to meaningfully advertise
   per link values.  In such a case only the Node MSD SHOULD be
   advertised.”

[Bruno2] Given that the term “imposition” does not seem to be defined within 
the IETF, I would still favor a formal definition not using it. e.g. “BMI-MSD 
advertises the ability to increase the depth of the label stack by BMI-MSD 
labels”.
Alternatively, I’d propose the following rewording which seems clearer to me:
OLD: Imposition includes swap and/or push operations.
NEW: A swap operation counts as an imposition of one label; just like one push 
operation.

[Les3:] This gets into implementation specific issues that I would really like 
to avoid.
For example, some implementations perform one and only one  “operation”. 
Conceptually that may involve a swap and a push – but from the internal 
implementation POV it is simply one operation. And this may be true regardless 
of how many labels are involved. Other implementations might perform this in 
several discrete steps. The language we use here should not imply anything 
about how many labels are associated with a specific operation.

The term “increase” isn’t accurate because in the case of a swap there is no 
increase, yet the label which is replaced is counted.

https://tools.ietf.org/html/rfc3031#section-3.10 is relevant here.

The term “imposition” is generic – and as Alvaro has pointed out is used in RFC 
4221. And the language proposed above does define the relationship between 
“swap and push” and “imposition”.

I appreciate your desire for clarity – and I am still open to new language – 
but at this point I still think what I proposed is  the most accurate.

   Les



Thanks,
--Bruno


_



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

Re: [Lsr] [RTG-DIR] RtgDir Review: draft-ietf-isis-segment-routing-msd-15

2018-10-03 Thread Acee Lindem (acee) 
Hey Bruno, Jeff, Les,

Have we agreed on the precise definition of “label imposition”?

Thanks,
Acee

From: Lsr  on behalf of Bruno Decraene 

Date: Wednesday, October 3, 2018 at 4:37 AM
To: Jeff Tantsura 
Cc: Routing Directorate , 
"draft-ietf-isis-segment-routing-...@ietf.org" 
, "rtg-...@ietf.org" 
, Alvaro Retana , "lsr@ietf.org" 
, "Les Ginsberg (ginsberg)" , MEURIC Julien 
IMT/OLN 
Subject: Re: [Lsr] [RTG-DIR] RtgDir Review: 
draft-ietf-isis-segment-routing-msd-15

Jeff,

From: Jeff Tantsura [mailto:jefftant.i...@gmail.com]
Sent: Tuesday, October 02, 2018 8:28 PM
To: DECRAENE Bruno IMT/OLN; Alvaro Retana; MEURIC Julien IMT/OLN; Les Ginsberg 
(ginsberg)
Cc: rtg-...@ietf.org; lsr@ietf.org; rtg-...@ietf.org; 
draft-ietf-isis-segment-routing-...@ietf.org
Subject: RE: [RTG-DIR] RtgDir Review: draft-ietf-isis-segment-routing-msd-15

Gents,

I’m 100% with Les here, going into platform/asic specifics within this document 
would inevitably create ambiguity.
Absolutely.
And nobody is asking for this.

Cheers
--Bruno



Cheers,
Jeff
On Oct 2, 2018, 11:20 AM -0700, Les Ginsberg (ginsberg) , 
wrote:


Bruno –

Trimming the thread…

[Les2:] Label imposition is meant to cover both the SWAP operation and the PUSH 
operation. In the example you provided above where a label stack of “12” is 
replaced by a label stack of “14,15” the number of labels “imposed” is 2.
[Bruno2] In that case, I definitely think that the discussion was useful and 
that this point needs to be clarified in the document.
Whether you choose to call that (1 POP, 2 PUSH) or (1 SWAP, 1 PUSH)  or simply 
a SWAP isn’t relevant here (though it might matter to folks like the RFC 3031 
authors).

With that ibn mind, here is proposed text:

“Base MPLS Imposition MSD (BMI-MSD) signals the total number of MPLS
   labels which can be imposed, including all service/transport/special
   labels.  Imposition includes swap and/or push operations.

If the advertising router performs label imposition in the context of
   the ingress interface, it is not possible to meaningfully advertise
   per link values.  In such a case only the Node MSD SHOULD be
   advertised.”

[Bruno2] Given that the term “imposition” does not seem to be defined within 
the IETF, I would still favor a formal definition not using it. e.g. “BMI-MSD 
advertises the ability to increase the depth of the label stack by BMI-MSD 
labels”.
Alternatively, I’d propose the following rewording which seems clearer to me:
OLD: Imposition includes swap and/or push operations.
NEW: A swap operation counts as an imposition of one label; just like one push 
operation.

[Les3:] This gets into implementation specific issues that I would really like 
to avoid.
For example, some implementations perform one and only one  “operation”. 
Conceptually that may involve a swap and a push – but from the internal 
implementation POV it is simply one operation. And this may be true regardless 
of how many labels are involved. Other implementations might perform this in 
several discrete steps. The language we use here should not imply anything 
about how many labels are associated with a specific operation.

The term “increase” isn’t accurate because in the case of a swap there is no 
increase, yet the label which is replaced is counted.

https://tools.ietf.org/html/rfc3031#section-3.10 is relevant here.

The term “imposition” is generic – and as Alvaro has pointed out is used in RFC 
4221. And the language proposed above does define the relationship between 
“swap and push” and “imposition”.

I appreciate your desire for clarity – and I am still open to new language – 
but at this point I still think what I proposed is  the most accurate.

   Les



Thanks,
--Bruno


_



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.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] [RTG-DIR] RtgDir Review: draft-ietf-isis-segment-routing-msd-15

2018-10-03 Thread bruno.decraene 
Jeff,

From: Jeff Tantsura [mailto:jefftant.i...@gmail.com]
Sent: Tuesday, October 02, 2018 8:28 PM
To: DECRAENE Bruno IMT/OLN; Alvaro Retana; MEURIC Julien IMT/OLN; Les Ginsberg 
(ginsberg)
Cc: rtg-...@ietf.org; lsr@ietf.org; rtg-...@ietf.org; 
draft-ietf-isis-segment-routing-...@ietf.org
Subject: RE: [RTG-DIR] RtgDir Review: draft-ietf-isis-segment-routing-msd-15

Gents,

I’m 100% with Les here, going into platform/asic specifics within this document 
would inevitably create ambiguity.
Absolutely.
And nobody is asking for this.

Cheers
--Bruno



Cheers,
Jeff
On Oct 2, 2018, 11:20 AM -0700, Les Ginsberg (ginsberg) , 
wrote:

Bruno –

Trimming the thread…

[Les2:] Label imposition is meant to cover both the SWAP operation and the PUSH 
operation. In the example you provided above where a label stack of “12” is 
replaced by a label stack of “14,15” the number of labels “imposed” is 2.
[Bruno2] In that case, I definitely think that the discussion was useful and 
that this point needs to be clarified in the document.
Whether you choose to call that (1 POP, 2 PUSH) or (1 SWAP, 1 PUSH)  or simply 
a SWAP isn’t relevant here (though it might matter to folks like the RFC 3031 
authors).

With that ibn mind, here is proposed text:

“Base MPLS Imposition MSD (BMI-MSD) signals the total number of MPLS
   labels which can be imposed, including all service/transport/special
   labels.  Imposition includes swap and/or push operations.

If the advertising router performs label imposition in the context of
   the ingress interface, it is not possible to meaningfully advertise
   per link values.  In such a case only the Node MSD SHOULD be
   advertised.”

[Bruno2] Given that the term “imposition” does not seem to be defined within 
the IETF, I would still favor a formal definition not using it. e.g. “BMI-MSD 
advertises the ability to increase the depth of the label stack by BMI-MSD 
labels”.
Alternatively, I’d propose the following rewording which seems clearer to me:
OLD: Imposition includes swap and/or push operations.
NEW: A swap operation counts as an imposition of one label; just like one push 
operation.

[Les3:] This gets into implementation specific issues that I would really like 
to avoid.
For example, some implementations perform one and only one  “operation”. 
Conceptually that may involve a swap and a push – but from the internal 
implementation POV it is simply one operation. And this may be true regardless 
of how many labels are involved. Other implementations might perform this in 
several discrete steps. The language we use here should not imply anything 
about how many labels are associated with a specific operation.

The term “increase” isn’t accurate because in the case of a swap there is no 
increase, yet the label which is replaced is counted.

https://tools.ietf.org/html/rfc3031#section-3.10 is relevant here.

The term “imposition” is generic – and as Alvaro has pointed out is used in RFC 
4221. And the language proposed above does define the relationship between 
“swap and push” and “imposition”.

I appreciate your desire for clarity – and I am still open to new language – 
but at this point I still think what I proposed is  the most accurate.

   Les



Thanks,
--Bruno


_

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.

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] [RTG-DIR] RtgDir Review: draft-ietf-isis-segment-routing-msd-15

2018-10-03 Thread bruno.decraene 
Les,


From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Tuesday, October 02, 2018 8:20 PM
To: DECRAENE Bruno IMT/OLN; Alvaro Retana; MEURIC Julien IMT/OLN
Cc: rtg-...@ietf.org; lsr@ietf.org; rtg-...@ietf.org; 
draft-ietf-isis-segment-routing-...@ietf.org
Subject: RE: [RTG-DIR] RtgDir Review: draft-ietf-isis-segment-routing-msd-15

Bruno –

Trimming the thread…

[Les2:] Label imposition is meant to cover both the SWAP operation and the PUSH 
operation. In the example you provided above where a label stack of “12” is 
replaced by a label stack of “14,15” the number of labels “imposed” is 2.
[Bruno2] In that case, I definitely think that the discussion was useful and 
that this point needs to be clarified in the document.
Whether you choose to call that (1 POP, 2 PUSH) or (1 SWAP, 1 PUSH)  or simply 
a SWAP isn’t relevant here (though it might matter to folks like the RFC 3031 
authors).

With that ibn mind, here is proposed text:

“Base MPLS Imposition MSD (BMI-MSD) signals the total number of MPLS
   labels which can be imposed, including all service/transport/special
   labels.  Imposition includes swap and/or push operations.

If the advertising router performs label imposition in the context of
   the ingress interface, it is not possible to meaningfully advertise
   per link values.  In such a case only the Node MSD SHOULD be
   advertised.”

[Bruno2] Given that the term “imposition” does not seem to be defined within 
the IETF, I would still favor a formal definition not using it. e.g. “BMI-MSD 
advertises the ability to increase the depth of the label stack by BMI-MSD 
labels”.
Alternatively, I’d propose the following rewording which seems clearer to me:
OLD: Imposition includes swap and/or push operations.
NEW: A swap operation counts as an imposition of one label; just like one push 
operation.

[Les3:] This gets into implementation specific issues that I would really like 
to avoid.
[Bruno3] So am I
For example, some implementations perform one and only one  “operation”. 
Conceptually that may involve a swap and a push – but from the internal 
implementation POV it is simply one operation. And this may be true regardless 
of how many labels are involved. Other implementations might perform this in 
several discrete steps. The language we use here should not imply anything 
about how many labels are associated with a specific operation.
[Bruno3] Let’s not go into implementation specifics. Let’s reuse the 
terminology defined in the MPLS Architecture (RFC 3031) which does use the term 
“operation”.

The term “increase” isn’t accurate because in the case of a swap there is no 
increase, yet the label which is replaced is counted.

https://tools.ietf.org/html/rfc3031#section-3.10 is relevant here.
[Bruno3] Absolutely. So let’s use RFC 3031 terminology

The term “imposition” is generic – and as Alvaro has pointed out is used in RFC 
4221. And the language proposed above does define the relationship between 
“swap and push” and “imposition”.
[Bruno3] AFAIK, the term “imposition” is not defined in the IETF (If I missed 
it, please points to its definition). RFC 4271 uses it without defining it and 
RFC 2171 is informational.

I appreciate your desire for clarity – and I am still open to new language – 
but at this point I still think what I proposed is  the most accurate.

[Bruno3] So let’s reuse RFC 3031 text verbatim
OLD: Imposition includes swap and/or push operations.

NEW: “When a LSR is capable of replacing the label at the top of the label 
stack with a
 specified new label, and then push N specified new labels onto the 
label stack, the LSR advertise a BMI-MSD of N+1.

Text is coming from the MPLS architecture which is the reference for everyone.
Thanks
--Bruno

   Les



Thanks,
--Bruno


_

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.

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] [RTG-DIR] RtgDir Review: draft-ietf-isis-segment-routing-msd-15

2018-10-02 Thread Jeff Tantsura 
Gents,

I’m 100% with Les here, going into platform/asic specifics within this document 
would inevitably create ambiguity.

Cheers,
Jeff
On Oct 2, 2018, 11:20 AM -0700, Les Ginsberg (ginsberg) , 
wrote:
> Bruno –
>
> Trimming the thread…
>
> [Les2:] Label imposition is meant to cover both the SWAP operation and the 
> PUSH operation. In the example you provided above where a label stack of “12” 
> is replaced by a label stack of “14,15” the number of labels “imposed” is 2.
> [Bruno2] In that case, I definitely think that the discussion was useful and 
> that this point needs to be clarified in the document.
> Whether you choose to call that (1 POP, 2 PUSH) or (1 SWAP, 1 PUSH)  or 
> simply a SWAP isn’t relevant here (though it might matter to folks like the 
> RFC 3031 authors).
>
> With that ibn mind, here is proposed text:
>
> “Base MPLS Imposition MSD (BMI-MSD) signals the total number of MPLS
>    labels which can be imposed, including all service/transport/special
>    labels.  Imposition includes swap and/or push operations.
>
> If the advertising router performs label imposition in the context of
>    the ingress interface, it is not possible to meaningfully advertise
>    per link values.  In such a case only the Node MSD SHOULD be
>    advertised.”
>
> [Bruno2] Given that the term “imposition” does not seem to be defined within 
> the IETF, I would still favor a formal definition not using it. e.g. “BMI-MSD 
> advertises the ability to increase the depth of the label stack by BMI-MSD 
> labels”.
> Alternatively, I’d propose the following rewording which seems clearer to me:
> OLD: Imposition includes swap and/or push operations.
> NEW: A swap operation counts as an imposition of one label; just like one 
> push operation.
>
> [Les3:] This gets into implementation specific issues that I would really 
> like to avoid.
> For example, some implementations perform one and only one  “operation”. 
> Conceptually that may involve a swap and a push – but from the internal 
> implementation POV it is simply one operation. And this may be true 
> regardless of how many labels are involved. Other implementations might 
> perform this in several discrete steps. The language we use here should not 
> imply anything about how many labels are associated with a specific operation.
>
> The term “increase” isn’t accurate because in the case of a swap there is no 
> increase, yet the label which is replaced is counted.
>
> https://tools.ietf.org/html/rfc3031#section-3.10 is relevant here.
>
> The term “imposition” is generic – and as Alvaro has pointed out is used in 
> RFC 4221. And the language proposed above does define the relationship 
> between “swap and push” and “imposition”.
>
> I appreciate your desire for clarity – and I am still open to new language – 
> but at this point I still think what I proposed is  the most accurate.
>
>    Les
>
>
>
> Thanks,
> --Bruno
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] [RTG-DIR] RtgDir Review: draft-ietf-isis-segment-routing-msd-15

2018-10-02 Thread Les Ginsberg (ginsberg) 
Bruno –

Trimming the thread…

[Les2:] Label imposition is meant to cover both the SWAP operation and the PUSH 
operation. In the example you provided above where a label stack of “12” is 
replaced by a label stack of “14,15” the number of labels “imposed” is 2.
[Bruno2] In that case, I definitely think that the discussion was useful and 
that this point needs to be clarified in the document.
Whether you choose to call that (1 POP, 2 PUSH) or (1 SWAP, 1 PUSH)  or simply 
a SWAP isn’t relevant here (though it might matter to folks like the RFC 3031 
authors).

With that ibn mind, here is proposed text:

“Base MPLS Imposition MSD (BMI-MSD) signals the total number of MPLS
   labels which can be imposed, including all service/transport/special
   labels.  Imposition includes swap and/or push operations.

If the advertising router performs label imposition in the context of
   the ingress interface, it is not possible to meaningfully advertise
   per link values.  In such a case only the Node MSD SHOULD be
   advertised.”

[Bruno2] Given that the term “imposition” does not seem to be defined within 
the IETF, I would still favor a formal definition not using it. e.g. “BMI-MSD 
advertises the ability to increase the depth of the label stack by BMI-MSD 
labels”.
Alternatively, I’d propose the following rewording which seems clearer to me:
OLD: Imposition includes swap and/or push operations.
NEW: A swap operation counts as an imposition of one label; just like one push 
operation.

[Les3:] This gets into implementation specific issues that I would really like 
to avoid.
For example, some implementations perform one and only one  “operation”. 
Conceptually that may involve a swap and a push – but from the internal 
implementation POV it is simply one operation. And this may be true regardless 
of how many labels are involved. Other implementations might perform this in 
several discrete steps. The language we use here should not imply anything 
about how many labels are associated with a specific operation.

The term “increase” isn’t accurate because in the case of a swap there is no 
increase, yet the label which is replaced is counted.

https://tools.ietf.org/html/rfc3031#section-3.10 is relevant here.

The term “imposition” is generic – and as Alvaro has pointed out is used in RFC 
4221. And the language proposed above does define the relationship between 
“swap and push” and “imposition”.

I appreciate your desire for clarity – and I am still open to new language – 
but at this point I still think what I proposed is  the most accurate.

   Les



Thanks,
--Bruno

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] [RTG-DIR] RtgDir Review: draft-ietf-isis-segment-routing-msd-15

2018-10-02 Thread bruno.decraene 
Les,

Thanks for the follow up.
Please see inline [Bruno2]

From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Friday, September 28, 2018 7:57 PM
To: DECRAENE Bruno IMT/OLN; Alvaro Retana; MEURIC Julien IMT/OLN
Cc: rtg-...@ietf.org; lsr@ietf.org; rtg-...@ietf.org; 
draft-ietf-isis-segment-routing-...@ietf.org
Subject: RE: [RTG-DIR] RtgDir Review: draft-ietf-isis-segment-routing-msd-15

Bruno –

Inline.

From: bruno.decra...@orange.com 
Sent: Friday, September 28, 2018 1:02 AM
To: Les Ginsberg (ginsberg) ; Alvaro Retana 
; MEURIC Julien IMT/OLN 
Cc: rtg-...@ietf.org; lsr@ietf.org; rtg-...@ietf.org; 
draft-ietf-isis-segment-routing-...@ietf.org
Subject: RE: [RTG-DIR] RtgDir Review: draft-ietf-isis-segment-routing-msd-15

Les, Alvaro,

Jumping in the conversation, please see comments inlined [Bruno]

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Les Ginsberg (ginsberg)
Sent: Thursday, September 27, 2018 8:45 PM
To: Alvaro Retana; MEURIC Julien IMT/OLN
Cc: rtg-...@ietf.org<mailto:rtg-...@ietf.org>; 
lsr@ietf.org<mailto:lsr@ietf.org>; rtg-...@ietf.org<mailto:rtg-...@ietf.org>; 
draft-ietf-isis-segment-routing-...@ietf.org<mailto:draft-ietf-isis-segment-routing-...@ietf.org>
Subject: Re: [Lsr] [RTG-DIR] RtgDir Review: 
draft-ietf-isis-segment-routing-msd-15

Alvaro –

Thanx for helping drive this to closure.
Please see inline.

From: Alvaro Retana mailto:aretana.i...@gmail.com>>
Sent: Thursday, September 27, 2018 10:54 AM
To: Julien Meuric mailto:julien.meu...@orange.com>>; 
Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>; 
draft-ietf-isis-segment-routing-...@ietf.org<mailto:draft-ietf-isis-segment-routing-...@ietf.org>;
 rtg-...@ietf.org<mailto:rtg-...@ietf.org>; 
rtg-...@ietf.org<mailto:rtg-...@ietf.org>
Subject: Re: [RTG-DIR] RtgDir Review: draft-ietf-isis-segment-routing-msd-15

On September 27, 2018 at 6:26:57 AM, Julien Meuric 
(julien.meu...@orange.com<mailto:julien.meu...@orange.com>) wrote:

Hi!

It looks like the outstanding item is this one about the terminology used in §5.

tl;dr: I think that the terminology can be slightly improved to be in line with 
other documents.  See suggestion at the bottom.

>>>> - In section 5, BMI-MSD is defined as "the total number of MPLS
>>>> labels which can be imposed" (which is OK when the incoming packet
>>>> is unlabled). When the incoming packet is labeled (e.g. use of
>>>> segment routing binding SID), if the incoming label is to be
>>>> "replaced" by N outgoing labels, what processing model is assumed
>>>> when advertising the
>> MSD:
>>>> * one swap and one imposition of N-1 labels?
>>>> * one pop and one imposition of N labels?
>>>>
>>> [Les:] What is being defined is the maximum number of SIDs/labels
>>> which
>> can be "imposed". If popping or swapping affects the MSD which can be
>> supported this needs to be accounted for in the advertisement. BMI-MSD
>> is not being used to advertise a value specific to labeled or
>> unlabeled packets nor a value which is "swap specific" or "pop specific".
>>>
>> [JM] We seem to agree on an architecture-agnostic use of BMI-MSD. "If
>> popping or swapping affects the MSD [...] this needs to be accounted
>> for" is a great introduction to the issue and deserves to be included
>> in the I-D. My comment now binds to: in order to have interoperable
>> implementations, I believe the document should be more prescriptive on
>> how we account that for.
>>
> [Les2:] Added text
>
[JM2] Thanks, this is a significant improvement. After talking to Bruno,
we however feel that the proposed wording remains ambiguous, and
especially the phrases "imposed under all conditions" and "be accounted
for". Indeed, section 3.10 of RFC 3031 defines "the operation to perform
on the packet's label stack" and doesn't mention "impose". The closest
concept may be found in:
" replace the label at the top of the label stack with a
specified new label, and then push one or more specified new
labels onto the label stack."
Combining this split to your current text may lead to different
interpretations. Could you clarify the paragraph to be more specific on
the corresponding definitions and fully clear the fuzzy zone?

The document currently (-17) reads:

   Base MPLS Imposition MSD (BMI-MSD) signals the total number of MPLS

   labels which can be imposed, including all service/transport/special

   labels.  The value advertised MUST indicate what can be imposed under

   all conditions e.g., if label popping/swapping affects the number of

   labels which can be imposed this MUST be accounted for in th

Re: [Lsr] [RTG-DIR] RtgDir Review: draft-ietf-isis-segment-routing-msd-15

2018-09-28 Thread Les Ginsberg (ginsberg) 
Bruno –

Inline.

From: bruno.decra...@orange.com 
Sent: Friday, September 28, 2018 1:02 AM
To: Les Ginsberg (ginsberg) ; Alvaro Retana 
; MEURIC Julien IMT/OLN 
Cc: rtg-...@ietf.org; lsr@ietf.org; rtg-...@ietf.org; 
draft-ietf-isis-segment-routing-...@ietf.org
Subject: RE: [RTG-DIR] RtgDir Review: draft-ietf-isis-segment-routing-msd-15

Les, Alvaro,

Jumping in the conversation, please see comments inlined [Bruno]

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Les Ginsberg (ginsberg)
Sent: Thursday, September 27, 2018 8:45 PM
To: Alvaro Retana; MEURIC Julien IMT/OLN
Cc: rtg-...@ietf.org<mailto:rtg-...@ietf.org>; 
lsr@ietf.org<mailto:lsr@ietf.org>; rtg-...@ietf.org<mailto:rtg-...@ietf.org>; 
draft-ietf-isis-segment-routing-...@ietf.org<mailto:draft-ietf-isis-segment-routing-...@ietf.org>
Subject: Re: [Lsr] [RTG-DIR] RtgDir Review: 
draft-ietf-isis-segment-routing-msd-15

Alvaro –

Thanx for helping drive this to closure.
Please see inline.

From: Alvaro Retana mailto:aretana.i...@gmail.com>>
Sent: Thursday, September 27, 2018 10:54 AM
To: Julien Meuric mailto:julien.meu...@orange.com>>; 
Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>; 
draft-ietf-isis-segment-routing-...@ietf.org<mailto:draft-ietf-isis-segment-routing-...@ietf.org>;
 rtg-...@ietf.org<mailto:rtg-...@ietf.org>; 
rtg-...@ietf.org<mailto:rtg-...@ietf.org>
Subject: Re: [RTG-DIR] RtgDir Review: draft-ietf-isis-segment-routing-msd-15

On September 27, 2018 at 6:26:57 AM, Julien Meuric 
(julien.meu...@orange.com<mailto:julien.meu...@orange.com>) wrote:

Hi!

It looks like the outstanding item is this one about the terminology used in §5.

tl;dr: I think that the terminology can be slightly improved to be in line with 
other documents.  See suggestion at the bottom.

>>>> - In section 5, BMI-MSD is defined as "the total number of MPLS
>>>> labels which can be imposed" (which is OK when the incoming packet
>>>> is unlabled). When the incoming packet is labeled (e.g. use of
>>>> segment routing binding SID), if the incoming label is to be
>>>> "replaced" by N outgoing labels, what processing model is assumed
>>>> when advertising the
>> MSD:
>>>> * one swap and one imposition of N-1 labels?
>>>> * one pop and one imposition of N labels?
>>>>
>>> [Les:] What is being defined is the maximum number of SIDs/labels
>>> which
>> can be "imposed". If popping or swapping affects the MSD which can be
>> supported this needs to be accounted for in the advertisement. BMI-MSD
>> is not being used to advertise a value specific to labeled or
>> unlabeled packets nor a value which is "swap specific" or "pop specific".
>>>
>> [JM] We seem to agree on an architecture-agnostic use of BMI-MSD. "If
>> popping or swapping affects the MSD [...] this needs to be accounted
>> for" is a great introduction to the issue and deserves to be included
>> in the I-D. My comment now binds to: in order to have interoperable
>> implementations, I believe the document should be more prescriptive on
>> how we account that for.
>>
> [Les2:] Added text
>
[JM2] Thanks, this is a significant improvement. After talking to Bruno,
we however feel that the proposed wording remains ambiguous, and
especially the phrases "imposed under all conditions" and "be accounted
for". Indeed, section 3.10 of RFC 3031 defines "the operation to perform
on the packet's label stack" and doesn't mention "impose". The closest
concept may be found in:
" replace the label at the top of the label stack with a
specified new label, and then push one or more specified new
labels onto the label stack."
Combining this split to your current text may lead to different
interpretations. Could you clarify the paragraph to be more specific on
the corresponding definitions and fully clear the fuzzy zone?

The document currently (-17) reads:

   Base MPLS Imposition MSD (BMI-MSD) signals the total number of MPLS

   labels which can be imposed, including all service/transport/special

   labels.  The value advertised MUST indicate what can be imposed under

   all conditions e.g., if label popping/swapping affects the number of

   labels which can be imposed this MUST be accounted for in the value

   which is advertised.

   If the advertising router performs label imposition in the context of

   the ingress interface, it is not possible to meaningfully advertise

   per link values.  In such a case only the Node MSD SHOULD be

   advertised.

I think that the term “label imposition” is relatively well understood, as the 
act of putting labels on the packet (labeling a packet).  However,

Re: [Lsr] [RTG-DIR] RtgDir Review: draft-ietf-isis-segment-routing-msd-15

2018-09-28 Thread Julien Meuric 
Thank you Alvaro. Though not less, I think we're about to find an
agreement on Les's wording.

Julien


Sep. 27, 2018 - aretana.i...@gmail.com:
> I’ll approve the publication either way once you and Julien agree.

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] [RTG-DIR] RtgDir Review: draft-ietf-isis-segment-routing-msd-15

2018-09-28 Thread Julien Meuric 

  
  
Hi Les,

We're converging. Please see below.

Julien


Sep. 27, 2018 - ginsb...@cisco.com:


  
  
  
  
Julien -
 
Snipping out the resolved bits.
 
> -Original Message-
> From: Julien Meuric
  
> Sent: Thursday, September 27, 2018
  3:27 AM
> 
> Hi Les,
> 
> Please see inline.
> 
> Thank you,
> 
> Julien
> 
> 
> 
>  - OLD
>     Path
  Computation Element Protocol (PCEP) SR extensions draft
>    
  [I-D.ietf-pce-segment-routing] signals MSD in SR Path
>  Computation
>     Element (PCE)
  Capability TLV and METRIC Object.
>    NEW
>     The Path
  Computation Element communication Protocol (PCEP) SR
>     extension
  document [I-D.ietf-pce-segment-routing] defines how to
>     signal MSD
  using the SR-PCE-CAPABILITY sub-TLV (per node) and
>     the METRIC
  object (per request).
> 
> >>> [Les:] I have updated
  this and included a reference to RFC 5440
> >>> where
> >> METRIC object was first
  defined.
> >>>
> >> [JM] Even better about
  METRIC. Consistently, "SR Path Computation
> >> Element
> >> (PCE) Capability TLV"
  still remains a loose phrase, the technical
> >> name from [I-
  D.ietf-pce-segment-routing] is "SR-PCE-CAPABILITY",
> >> which avoids ambiguity.
> >>
> >
> > [Les2:] I removed naming the
  specific TLVs and replaced it with " Path
> Computation Element Protocol
  (PCEP)".
> > I think this is better than
  mentioning specific TLV names - particularly since
> one of them is part of a draft and
  the TLV name might change before the
> document becomes an RFC. So any
  possible naming inconsistency is now
> eliminated.
> >
> [JM2] As there's an early IANA
  allocation on this TLV, I don't expect any
> change in its name, but I can hear
  that argument. If you want a full phrase,
> then I prefer the text from v16,
  because "SR Path Computation Element
> (PCE) Capability" matches the
  section title of the PCEP draft (and a slight
> change later wouldn't have much
  impact). In case you're into removing the
> TLV/objects names and just point to
  PCEP, then you MUST use the full
> expansion which is "Path
  Computation Element
> *communication* Protocol" (and
  SHOULD avoid asking about the missing C
> ;-) ).
 
[Les:] I don't really care, but I
  am having trouble with your suggestion.
IT is true that RFC 5440 is
  entitled:  "Path Computation Element (PCE) Communication
  Protocol (PCEP)"
 
However, in the body of the RFC we
  see 
 
"This
  document specifies the Path Computation Element Protocol
  (PCEP)".
 
Also, in
  draft-ietf-pce-segment-routing-12 we also see
  
 
"[RFC5440]
  describes the Path Computation Element Protocol (PCEP)
  ..."
 
So explain to me why this document
  should deviate from these other PCE oriented documents???
 
  

[JM3] That's a recurrent issue. It's true that here are a few
inconsistencies out there, starting from RFC 5440 (the RFC Editor
can be picky, but remains human). This legacy isn't serious enough
to require bis documents. The expansion which has been used most of
the time in the PCE documents (e.g., RFC 8306, 8356, 8408) is the
one from RFC 5440's title and abstract, which includes
"Communication". This is the one we try to enforce with Jon in the
documents we review, so please be my guest. :-)
(By the way, thank you for pointing this issue on
draft-ietf-pce-segment-routing: we may include this update even
before reaching the RFC Editor.)


  
>  - In section 5,
  BMI-MSD is defined as "the total number of MPLS
>  labels which can
  be imposed" (which is OK when the incoming packet
>  is unlabled). When
  the incoming packet is labeled (e.g. use of
>  segment routing
  binding SID), if the incoming label is to be
>  "replaced" by N
  outgoing labels, what processing model is assumed
>  when advertising
  the
> >> MSD:
>   * one swap and

Re: [Lsr] [RTG-DIR] RtgDir Review: draft-ietf-isis-segment-routing-msd-15

2018-09-28 Thread bruno.decraene 
Les, Alvaro,

Jumping in the conversation, please see comments inlined [Bruno]

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Les Ginsberg (ginsberg)
Sent: Thursday, September 27, 2018 8:45 PM
To: Alvaro Retana; MEURIC Julien IMT/OLN
Cc: rtg-...@ietf.org; lsr@ietf.org; rtg-...@ietf.org; 
draft-ietf-isis-segment-routing-...@ietf.org
Subject: Re: [Lsr] [RTG-DIR] RtgDir Review: 
draft-ietf-isis-segment-routing-msd-15

Alvaro –

Thanx for helping drive this to closure.
Please see inline.

From: Alvaro Retana 
Sent: Thursday, September 27, 2018 10:54 AM
To: Julien Meuric ; Les Ginsberg (ginsberg) 

Cc: lsr@ietf.org; draft-ietf-isis-segment-routing-...@ietf.org; 
rtg-...@ietf.org; rtg-...@ietf.org
Subject: Re: [RTG-DIR] RtgDir Review: draft-ietf-isis-segment-routing-msd-15

On September 27, 2018 at 6:26:57 AM, Julien Meuric 
(julien.meu...@orange.com<mailto:julien.meu...@orange.com>) wrote:

Hi!

It looks like the outstanding item is this one about the terminology used in §5.

tl;dr: I think that the terminology can be slightly improved to be in line with 
other documents.  See suggestion at the bottom.

>>>> - In section 5, BMI-MSD is defined as "the total number of MPLS
>>>> labels which can be imposed" (which is OK when the incoming packet
>>>> is unlabled). When the incoming packet is labeled (e.g. use of
>>>> segment routing binding SID), if the incoming label is to be
>>>> "replaced" by N outgoing labels, what processing model is assumed
>>>> when advertising the
>> MSD:
>>>> * one swap and one imposition of N-1 labels?
>>>> * one pop and one imposition of N labels?
>>>>
>>> [Les:] What is being defined is the maximum number of SIDs/labels
>>> which
>> can be "imposed". If popping or swapping affects the MSD which can be
>> supported this needs to be accounted for in the advertisement. BMI-MSD
>> is not being used to advertise a value specific to labeled or
>> unlabeled packets nor a value which is "swap specific" or "pop specific".
>>>
>> [JM] We seem to agree on an architecture-agnostic use of BMI-MSD. "If
>> popping or swapping affects the MSD [...] this needs to be accounted
>> for" is a great introduction to the issue and deserves to be included
>> in the I-D. My comment now binds to: in order to have interoperable
>> implementations, I believe the document should be more prescriptive on
>> how we account that for.
>>
> [Les2:] Added text
>
[JM2] Thanks, this is a significant improvement. After talking to Bruno,
we however feel that the proposed wording remains ambiguous, and
especially the phrases "imposed under all conditions" and "be accounted
for". Indeed, section 3.10 of RFC 3031 defines "the operation to perform
on the packet's label stack" and doesn't mention "impose". The closest
concept may be found in:
" replace the label at the top of the label stack with a
specified new label, and then push one or more specified new
labels onto the label stack."
Combining this split to your current text may lead to different
interpretations. Could you clarify the paragraph to be more specific on
the corresponding definitions and fully clear the fuzzy zone?

The document currently (-17) reads:

   Base MPLS Imposition MSD (BMI-MSD) signals the total number of MPLS

   labels which can be imposed, including all service/transport/special

   labels.  The value advertised MUST indicate what can be imposed under

   all conditions e.g., if label popping/swapping affects the number of

   labels which can be imposed this MUST be accounted for in the value

   which is advertised.

   If the advertising router performs label imposition in the context of

   the ingress interface, it is not possible to meaningfully advertise

   per link values.  In such a case only the Node MSD SHOULD be

   advertised.

I think that the term “label imposition” is relatively well understood, as the 
act of putting labels on the packet (labeling a packet).  However, rfc3031 
doesn’t talk about imposition; instead it says that a ""labeled packet" is a 
packet into which a label has been encoded”, and it talks about pushing labels 
on the stack.  The SR documents (rfc8402 and 
draft-ietf-spring-segment-routing-mpls) also don’t talk about imposition, nor 
do they offer a better alternative.

The text may be interpreted from the point of view of what the LSR can impose, 
vs what can be imposed on the packet…which can result in confusion.  Note that 
§7 clarifies which node is expected to do the imposition: "the head-end (the 
node performing the imposition)”.

rfc4221 does provide a clear precedent of the use of imposition, and a related 
definition (referring to the LSR MIB / rfc3

Re: [Lsr] [RTG-DIR] RtgDir Review: draft-ietf-isis-segment-routing-msd-15

2018-09-27 Thread Alvaro Retana 
On September 27, 2018 at 2:44:34 PM, Les Ginsberg (ginsberg) (
ginsb...@cisco.com) wrote:

Les:

Sometimes less is more. ;-)

My personal opinion is that, given the precedent from rfc4221, the
additional considerations are implied.

I’ll approve the publication either way once you and Julien agree.

Thanks!

Alvaro.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] [RTG-DIR] RtgDir Review: draft-ietf-isis-segment-routing-msd-15

2018-09-27 Thread Les Ginsberg (ginsberg) 
Alvaro –

Thanx for helping drive this to closure.
Please see inline.

From: Alvaro Retana 
Sent: Thursday, September 27, 2018 10:54 AM
To: Julien Meuric ; Les Ginsberg (ginsberg) 

Cc: lsr@ietf.org; draft-ietf-isis-segment-routing-...@ietf.org; 
rtg-...@ietf.org; rtg-...@ietf.org
Subject: Re: [RTG-DIR] RtgDir Review: draft-ietf-isis-segment-routing-msd-15

On September 27, 2018 at 6:26:57 AM, Julien Meuric 
(julien.meu...@orange.com) wrote:

Hi!

It looks like the outstanding item is this one about the terminology used in §5.

tl;dr: I think that the terminology can be slightly improved to be in line with 
other documents.  See suggestion at the bottom.

 - In section 5, BMI-MSD is defined as "the total number of MPLS
 labels which can be imposed" (which is OK when the incoming packet
 is unlabled). When the incoming packet is labeled (e.g. use of
 segment routing binding SID), if the incoming label is to be
 "replaced" by N outgoing labels, what processing model is assumed
 when advertising the
>> MSD:
 * one swap and one imposition of N-1 labels?
 * one pop and one imposition of N labels?

>>> [Les:] What is being defined is the maximum number of SIDs/labels
>>> which
>> can be "imposed". If popping or swapping affects the MSD which can be
>> supported this needs to be accounted for in the advertisement. BMI-MSD
>> is not being used to advertise a value specific to labeled or
>> unlabeled packets nor a value which is "swap specific" or "pop specific".
>>>
>> [JM] We seem to agree on an architecture-agnostic use of BMI-MSD. "If
>> popping or swapping affects the MSD [...] this needs to be accounted
>> for" is a great introduction to the issue and deserves to be included
>> in the I-D. My comment now binds to: in order to have interoperable
>> implementations, I believe the document should be more prescriptive on
>> how we account that for.
>>
> [Les2:] Added text
>
[JM2] Thanks, this is a significant improvement. After talking to Bruno,
we however feel that the proposed wording remains ambiguous, and
especially the phrases "imposed under all conditions" and "be accounted
for". Indeed, section 3.10 of RFC 3031 defines "the operation to perform
on the packet's label stack" and doesn't mention "impose". The closest
concept may be found in:
" replace the label at the top of the label stack with a
specified new label, and then push one or more specified new
labels onto the label stack."
Combining this split to your current text may lead to different
interpretations. Could you clarify the paragraph to be more specific on
the corresponding definitions and fully clear the fuzzy zone?

The document currently (-17) reads:

   Base MPLS Imposition MSD (BMI-MSD) signals the total number of MPLS

   labels which can be imposed, including all service/transport/special

   labels.  The value advertised MUST indicate what can be imposed under

   all conditions e.g., if label popping/swapping affects the number of

   labels which can be imposed this MUST be accounted for in the value

   which is advertised.

   If the advertising router performs label imposition in the context of

   the ingress interface, it is not possible to meaningfully advertise

   per link values.  In such a case only the Node MSD SHOULD be

   advertised.

I think that the term “label imposition” is relatively well understood, as the 
act of putting labels on the packet (labeling a packet).  However, rfc3031 
doesn’t talk about imposition; instead it says that a ""labeled packet" is a 
packet into which a label has been encoded”, and it talks about pushing labels 
on the stack.  The SR documents (rfc8402 and 
draft-ietf-spring-segment-routing-mpls) also don’t talk about imposition, nor 
do they offer a better alternative.

The text may be interpreted from the point of view of what the LSR can impose, 
vs what can be imposed on the packet…which can result in confusion.  Note that 
§7 clarifies which node is expected to do the imposition: "the head-end (the 
node performing the imposition)”.

rfc4221 does provide a clear precedent of the use of imposition, and a related 
definition (referring to the LSR MIB / rfc3813): "mplsMaxLabelStackDepth 
defines the maximum size of a imposed label stack supported at this LSR”.  This 
definition is akin to what this document already says: “MSD...the number of 
SIDs supported” (§1.1).  The definition in rfc4221 also presents a subtle 
difference (from the text in this document): it talks about the “imposed label 
stack supported” (not “labels which can be imposed”).  I interpret the “imposed 
label stack” as already taking into consideration any operations that can be 
performed (rfc3031).

My suggestion is to borrow from rfc4221 and simplify the definition:

NEW>

   Base MPLS Imposition MSD (BMI-MSD) indicates the maximum size of an

   imposed label stack supported by the node.

   If it is not possible to meaningfully advertise

   per

Re: [Lsr] [RTG-DIR] RtgDir Review: draft-ietf-isis-segment-routing-msd-15

2018-09-27 Thread Les Ginsberg (ginsberg) 
Julien -



Snipping out the resolved bits.



> -Original Message-

> From: Julien Meuric 

> Sent: Thursday, September 27, 2018 3:27 AM

> To: Les Ginsberg (ginsberg) ; rtg-...@ietf.org

> Cc: lsr@ietf.org; rtg-...@ietf.org; draft-ietf-isis-segment-routing-

> m...@ietf.org

> Subject: Re: [RTG-DIR] RtgDir Review: draft-ietf-isis-segment-routing-msd-15

>

> Hi Les,

>

> Please see inline.

>

> Thank you,

>

> Julien

>

>

> 

>  - OLD

> Path Computation Element Protocol (PCEP) SR extensions draft

> [I-D.ietf-pce-segment-routing] signals MSD in SR Path

>  Computation

> Element (PCE) Capability TLV and METRIC Object.

>    NEW

> The Path Computation Element communication Protocol (PCEP) SR

> extension document [I-D.ietf-pce-segment-routing] defines how to

> signal MSD using the SR-PCE-CAPABILITY sub-TLV (per node) and

> the METRIC object (per request).

> 

> >>> [Les:] I have updated this and included a reference to RFC 5440

> >>> where

> >> METRIC object was first defined.

> >>>

> >> [JM] Even better about METRIC. Consistently, "SR Path Computation

> >> Element

> >> (PCE) Capability TLV" still remains a loose phrase, the technical

> >> name from [I- D.ietf-pce-segment-routing] is "SR-PCE-CAPABILITY",

> >> which avoids ambiguity.

> >>

> >

> > [Les2:] I removed naming the specific TLVs and replaced it with " Path

> Computation Element Protocol (PCEP)".

> > I think this is better than mentioning specific TLV names - particularly 
> > since

> one of them is part of a draft and the TLV name might change before the

> document becomes an RFC. So any possible naming inconsistency is now

> eliminated.

> >

> [JM2] As there's an early IANA allocation on this TLV, I don't expect any

> change in its name, but I can hear that argument. If you want a full phrase,

> then I prefer the text from v16, because "SR Path Computation Element

> (PCE) Capability" matches the section title of the PCEP draft (and a slight

> change later wouldn't have much impact). In case you're into removing the

> TLV/objects names and just point to PCEP, then you MUST use the full

> expansion which is "Path Computation Element

> *communication* Protocol" (and SHOULD avoid asking about the missing C

> ;-) ).



[Les:] I don't really care, but I am having trouble with your suggestion.

IT is true that RFC 5440 is entitled:  "Path Computation Element (PCE) 
Communication Protocol (PCEP)"



However, in the body of the RFC we see



"This document specifies the Path Computation Element Protocol (PCEP)".



Also, in draft-ietf-pce-segment-routing-12 we also see



"[RFC5440] describes the Path Computation Element Protocol (PCEP) ..."



So explain to me why this document should deviate from these other PCE oriented 
documents???



>  - In section 5, BMI-MSD is defined as "the total number of MPLS

>  labels which can be imposed" (which is OK when the incoming packet

>  is unlabled). When the incoming packet is labeled (e.g. use of

>  segment routing binding SID), if the incoming label is to be

>  "replaced" by N outgoing labels, what processing model is assumed

>  when advertising the

> >> MSD:

>   * one swap and one imposition of N-1 labels?

>   * one pop and one imposition of N labels?

> 

> >>> [Les:] What is being defined is the maximum number of SIDs/labels

> >>> which

> >> can be "imposed". If popping or swapping affects the MSD which can be

> >> supported this needs to be accounted for in the advertisement.

> >> BMI-MSD is not being used to advertise a value specific to labeled or

> >> unlabeled packets nor a value which is "swap specific" or "pop specific".

> >>>

> >> [JM] We seem to agree on an architecture-agnostic use of BMI-MSD. "If

> >> popping or swapping affects the MSD [...] this needs to be accounted

> >> for" is a great introduction to the issue and deserves to be included

> >> in the I-D. My comment now binds to: in order to have interoperable

> >> implementations, I believe the document should be more prescriptive

> >> on how we account that for.

> >>

> > [Les2:] Added text

> >

> [JM2] Thanks, this is a significant improvement. After talking to Bruno, we

> however feel that the proposed wording remains ambiguous, and especially

> the phrases "imposed under all conditions" and "be accounted for". Indeed,

> section 3.10 of RFC 3031 defines "the operation to perform on the packet's

> label stack" and doesn't mention "impose". The closest concept may be

> found in:

> "replace the label at the top of the label stack with a

>  specified new label, and then push one or more specified new

>  labels onto the label stack."

> Combining this split to your current text may lead to different

> interpretations. Could you clarify the paragraph to be more specific on the

> corresponding definitions and fully clear the fuzzy zone?

Re: [Lsr] [RTG-DIR] RtgDir Review: draft-ietf-isis-segment-routing-msd-15

2018-09-27 Thread Alvaro Retana 
On September 27, 2018 at 6:26:57 AM, Julien Meuric (julien.meu...@orange.com)
wrote:

Hi!

It looks like the outstanding item is this one about the terminology used
in §5.

tl;dr: I think that the terminology can be slightly improved to be in line
with other documents.  See suggestion at the bottom.

 - In section 5, BMI-MSD is defined as "the total number of MPLS
 labels which can be imposed" (which is OK when the incoming packet
 is unlabled). When the incoming packet is labeled (e.g. use of
 segment routing binding SID), if the incoming label is to be
 "replaced" by N outgoing labels, what processing model is assumed
 when advertising the
>> MSD:
 * one swap and one imposition of N-1 labels?
 * one pop and one imposition of N labels?

>>> [Les:] What is being defined is the maximum number of SIDs/labels
>>> which
>> can be "imposed". If popping or swapping affects the MSD which can be
>> supported this needs to be accounted for in the advertisement. BMI-MSD
>> is not being used to advertise a value specific to labeled or
>> unlabeled packets nor a value which is "swap specific" or "pop specific"..

>>>
>> [JM] We seem to agree on an architecture-agnostic use of BMI-MSD. "If
>> popping or swapping affects the MSD [...] this needs to be accounted
>> for" is a great introduction to the issue and deserves to be included
>> in the I-D. My comment now binds to: in order to have interoperable
>> implementations, I believe the document should be more prescriptive on
>> how we account that for.
>>
> [Les2:] Added text
>
[JM2] Thanks, this is a significant improvement. After talking to Bruno,
we however feel that the proposed wording remains ambiguous, and
especially the phrases "imposed under all conditions" and "be accounted
for". Indeed, section 3.10 of RFC 3031 defines "the operation to perform
on the packet's label stack" and doesn't mention "impose". The closest
concept may be found in:
" replace the label at the top of the label stack with a
specified new label, and then push one or more specified new
labels onto the label stack."
Combining this split to your current text may lead to different
interpretations. Could you clarify the paragraph to be more specific on
the corresponding definitions and fully clear the fuzzy zone?

The document currently (-17) reads:

   Base MPLS Imposition MSD (BMI-MSD) signals the total number of MPLS
   labels which can be imposed, including all service/transport/special
   labels.  The value advertised MUST indicate what can be imposed under
   all conditions e.g., if label popping/swapping affects the number of
   labels which can be imposed this MUST be accounted for in the value
   which is advertised.

   If the advertising router performs label imposition in the context of
   the ingress interface, it is not possible to meaningfully advertise
   per link values.  In such a case only the Node MSD SHOULD be
   advertised.


I think that the term “label imposition” is relatively well understood, as
the act of putting labels on the packet (labeling a packet).  However,
rfc3031 doesn’t talk about imposition; instead it says that a ""labeled
packet" is a packet into which a label has been encoded”, and it talks
about pushing labels on the stack.  The SR documents (rfc8402
and draft-ietf-spring-segment-routing-mpls) also don’t talk about
imposition, nor do they offer a better alternative.

The text may be interpreted from the point of view of what the LSR can
impose, vs what can be imposed on the packet…which can result in
confusion.  Note that §7 clarifies which node is expected to do the
imposition: "the head-end (the node performing the imposition)”.

rfc4221 does provide a clear precedent of the use of imposition, and a
related definition (referring to the LSR MIB / rfc3813):
"mplsMaxLabelStackDepth defines the maximum size of a imposed label stack
supported at this LSR”.  This definition is akin to what this document
already says: “MSD...the number of SIDs supported” (§1..1).  The definition
in rfc4221 also presents a subtle difference (from the text in this
document): it talks about the “imposed label stack supported” (not “labels
which can be imposed”).  I interpret the “imposed label stack” as already
taking into consideration any operations that can be performed (rfc3031).

My suggestion is to borrow from rfc4221 and simplify the definition:

NEW>

   Base MPLS Imposition MSD (BMI-MSD) indicates the maximum size of an
   imposed label stack supported by the node.

   If it is not possible to meaningfully advertise
   per link values, then only the Node MSD SHOULD be
   advertised.


 In line with that suggestion, we could clean up some of the related text:

§1 s/the controller learns the Maximum SID Depth (MSD) that can be imposed
at each node/link/the controller learns the Maximum SID Depth (MSD)
supported at each node/link

§1 s/not exceed the number of SIDs the node is capable of imposing/not
exceed the number of SIDs the node

Re: [Lsr] [RTG-DIR] RtgDir Review: draft-ietf-isis-segment-routing-msd-15

2018-09-27 Thread Julien Meuric 
Hi Les,

Please see inline.

Thank you,

Julien


Sep. 26, 2018 - ginsb...@cisco.com:
> Julien -
> 
> Thanx for the additional comments.
> V17 has been published to address these - subject to my responses below.
> See Les2
> 
>> -Original Message-
>> From: rtg-dir  On Behalf Of Julien Meuric
>> Sent: Monday, September 24, 2018 8:12 AM
>>
>> Hi Les,
>>
>> Thanks for you feedback. Please find some responses, marked [JM] below.
>> You may consider the trimmed ones as resolved. For others, please keep 
>> in mind that the directorate's purpose is to improve documents'
>> readability before publication, as opposed to store clarification in 
>> mailing list archives.
>>
> [Les2:]  I fully appreciate both the purpose of the review and the effort you 
> have put in. Yours is one of the better reviews I have seen in my years...
> If I push back it is not because I do not value your input - but simply 
> because I disagree. :-)
> 
>> Julien
>>
>>
>> Sep. 24, 2018 - ginsb...@cisco.com:
>>> Julien -
>>>
>>> Thanx for your detailed review - and your patience in waiting for a
>> response (I returned from vacation only a few days ago).
>>>
>>> I have published V16 of the draft which addresses your comments 
>>> except
>> as noted inline below.
>>>
>>>
 -Original Message-
 From: Julien Meuric 
 Sent: Monday, September 10, 2018 8:28 AM

>> 

 - The abstract uses the acronym "SID", however:
 * It should be expanded at first use,
 * It should be defined, e.g. by adding a (normative) reference 
 to RFC 8402 (at least in the introduction),
 * The SR context is missing and should be explicitly mentioned 
 (adding a phrase such as "in a Segment Routing-enabled network" 
 would
>> be enough).
>>>
>>> [Les:] SID has been added to the terminology section and a reference 
>>> to
>> RFC 8402 added.
>>> However, I don’t think "SR context" is missing. The first sentence 
>>> of the Introduction starts with
>>>
>>> " When Segment Routing (SR) paths are computed..."
>>>
>> [JM] I fully agree about the introduction, but my comment was about 
>> the abstract where the SR context needs to be guessed from the use of 
>> the "SID" terminology: an explicit phrase would be welcome to a rookie 
>> reading the abstract.
>>
> [Les2:] I have modified the abstract.
> 
[JM2] ...and addressed most of my comment, thanks. (The RFC Editor may
still request you to expand "SID".)


 - OLD
Path Computation Element Protocol (PCEP) SR extensions draft
[I-D.ietf-pce-segment-routing] signals MSD in SR Path 
 Computation
Element (PCE) Capability TLV and METRIC Object.
   NEW
The Path Computation Element communication Protocol (PCEP) SR
extension document [I-D.ietf-pce-segment-routing] defines how to
signal MSD using the SR-PCE-CAPABILITY sub-TLV (per node) and
the METRIC object (per request).

>>> [Les:] I have updated this and included a reference to RFC 5440 
>>> where
>> METRIC object was first defined.
>>>
>> [JM] Even better about METRIC. Consistently, "SR Path Computation 
>> Element
>> (PCE) Capability TLV" still remains a loose phrase, the technical name 
>> from [I- D.ietf-pce-segment-routing] is "SR-PCE-CAPABILITY", which 
>> avoids ambiguity.
>>
> 
> [Les2:] I removed naming the specific TLVs and replaced it with " Path  
> Computation Element Protocol (PCEP)".
> I think this is better than mentioning specific TLV names - particularly 
> since one of them is part of a draft and the TLV name might change before the 
> document becomes an RFC. So any possible naming inconsistency is now 
> eliminated.
> 
[JM2] As there's an early IANA allocation on this TLV, I don't expect
any change in its name, but I can hear that argument. If you want a full
phrase, then I prefer the text from v16, because "SR Path Computation
Element (PCE) Capability" matches the section title of the PCEP draft
(and a slight change later wouldn't have much impact). In case you're
into removing the TLV/objects names and just point to PCEP, then you
MUST use the full expansion which is "Path Computation Element
*communication* Protocol" (and SHOULD avoid asking about the missing C
;-) ).

>>>
 - The introduction says that the solution to complement BGP-LS lies 
 in IS-IS (the OSPF draft claiming the counterpart on its side). 
 This is a bit rough, the sentence 2 paragraph below already does 
 the necessary scoping job: "This document defines an extension to 
 >>> here>". I suggest to temper the early sentence by rephrasing the
 beginning of page 3 into: "MSD capabilities should be advertised by 
 every router in the network involved in the IGP."

>>> [Les:] The draft says
>>>
>>> " MSD capabilities should be
>>>advertised by every Intermediate System to Intermediate System(IS-IS)
>>>router in the network."
>>>
>>> which I believe meets your suggestion.
>>>
>> [JM] My comment was exactly starting

Re: [Lsr] [RTG-DIR] RtgDir Review: draft-ietf-isis-segment-routing-msd-15

2018-09-26 Thread Jeff Tantsura 
Gents,

Thanks for the great review!

Both drafts are on the Telechat tomorrow, would be great to come to the 
agreement, so ospf draft could be updated before tomorrow’s call.

Regards,
Jeff

> On Sep 26, 2018, at 13:21, Les Ginsberg (ginsberg)  wrote:
> 
> Julien -
> 
> Thanx for the additional comments.
> V17 has been published to address these - subject to my responses below.
> See Les2
> 
>> -Original Message-
>> From: rtg-dir  On Behalf Of Julien Meuric
>> Sent: Monday, September 24, 2018 8:12 AM
>> To: Les Ginsberg (ginsberg) ; rtg-...@ietf.org
>> Cc: lsr@ietf.org; rtg-...@ietf.org; draft-ietf-isis-segment-routing- 
>> m...@ietf.org
>> Subject: Re: [RTG-DIR] RtgDir Review: 
>> draft-ietf-isis-segment-routing-msd-15
>> 
>> Hi Les,
>> 
>> Thanks for you feedback. Please find some responses, marked [JM] below.
>> You may consider the trimmed ones as resolved. For others, please keep 
>> in mind that the directorate's purpose is to improve documents'
>> readability before publication, as opposed to store clarification in 
>> mailing list archives.
>> 
> [Les2:]  I fully appreciate both the purpose of the review and the effort you 
> have put in. Yours is one of the better reviews I have seen in my years...
> If I push back it is not because I do not value your input - but simply 
> because I disagree. :-)
> 
>> Julien
>> 
>> 
>> Sep. 24, 2018 - ginsb...@cisco.com:
>>> Julien -
>>> 
>>> Thanx for your detailed review - and your patience in waiting for a
>> response (I returned from vacation only a few days ago).
>>> 
>>> I have published V16 of the draft which addresses your comments 
>>> except
>> as noted inline below.
>>> 
>>> 
 -Original Message-
 From: Julien Meuric 
 Sent: Monday, September 10, 2018 8:28 AM
 
>> 
 
 - The abstract uses the acronym "SID", however:
* It should be expanded at first use,
* It should be defined, e.g. by adding a (normative) reference 
 to RFC 8402 (at least in the introduction),
* The SR context is missing and should be explicitly mentioned 
 (adding a phrase such as "in a Segment Routing-enabled network" 
 would
>> be enough).
>>> 
>>> [Les:] SID has been added to the terminology section and a reference 
>>> to
>> RFC 8402 added.
>>> However, I don’t think "SR context" is missing. The first sentence 
>>> of the Introduction starts with
>>> 
>>> " When Segment Routing (SR) paths are computed..."
>>> 
>> [JM] I fully agree about the introduction, but my comment was about 
>> the abstract where the SR context needs to be guessed from the use of 
>> the "SID" terminology: an explicit phrase would be welcome to a rookie 
>> reading the abstract.
>> 
> [Les2:] I have modified the abstract.
> 
 
 - OLD
   Path Computation Element Protocol (PCEP) SR extensions draft
   [I-D.ietf-pce-segment-routing] signals MSD in SR Path 
 Computation
   Element (PCE) Capability TLV and METRIC Object.
  NEW
   The Path Computation Element communication Protocol (PCEP) SR
   extension document [I-D.ietf-pce-segment-routing] defines how to
   signal MSD using the SR-PCE-CAPABILITY sub-TLV (per node) and
   the METRIC object (per request).
 
>>> [Les:] I have updated this and included a reference to RFC 5440 
>>> where
>> METRIC object was first defined.
>>> 
>> [JM] Even better about METRIC. Consistently, "SR Path Computation 
>> Element
>> (PCE) Capability TLV" still remains a loose phrase, the technical name 
>> from [I- D.ietf-pce-segment-routing] is "SR-PCE-CAPABILITY", which 
>> avoids ambiguity.
>> 
> 
> [Les2:] I removed naming the specific TLVs and replaced it with " Path  
> Computation Element Protocol (PCEP)".
> I think this is better than mentioning specific TLV names - particularly 
> since one of them is part of a draft and the TLV name might change before the 
> document becomes an RFC. So any possible naming inconsistency is now 
> eliminated.
> 
>>> 
 - The introduction says that the solution to complement BGP-LS lies 
 in IS-IS (the OSPF draft claiming the counterpart on its side). 
 This is a bit rough, the sentence 2 paragraph below already does 
 the necessary scoping job: "This document defines an extension to 
 >>> here>". I suggest to temper the early sentence by rephrasing the
 beginning of page 3 into: "MSD capabilities should be advertised by 
 every router in the network involved in the IGP."
 
>>> [Les:] The draft says
>>> 
>>> " MSD capabilities should be
>>>   advertised by every Intermediate System to Intermediate System(IS-IS)
>>>   router in the network."
>>> 
>>> which I believe meets your suggestion.
>>> 
>> [JM] My comment was exactly starting from there. Let me rephrase:
>> - This I-D says "should be advertised by every IS-IS router";
>> - draft-ietf-ospf-segment-routing-msd says "should be advertised by 
>> every OSPF router".
>> Now that we have a single LSR WG, I suggest to drop these competing 
>>