Re: [Lsr] IPR Poll on draft-ietf-isis-segment-routing-extensions-16 (Shepherd write-up)

[bruno.decraene]

I’m not aware of non-disclosed IPR.

Regards,
--Bruno,


From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Uma Chunduri
Sent: Monday, June 11, 2018 9:18 PM
To: lsr@ietf.org
Subject: [Lsr] IPR Poll on draft-ietf-isis-segment-routing-extensions-16 
(Shepherd write-up)

Dear All,

Are you aware of any IPR that applies to
https://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions-16 ?

Sending this email as suggested by LSR chairs - as this was not noticed 
during/around WGLC.

===
If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as a document author or contributor please respond
to this email regardless of whether or not you are aware of any
relevant IPR. *The response needs to be sent to the LSR WG mailing
list.* The document will not advance to the next stage until a
response has been received from each author and contributor.

If you are on the LSR WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of
any IPR that has not yet been disclosed in conformance with IETF rules.
===

--
Uma C.

_

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] I-D Action: draft-ietf-isis-mpls-elc-05.txt

[bruno.decraene]

Hi authors,

"4.  Advertising ELC Using IS-IS

   One bit of the Non-IGP Functional Capability Bits (Bit 0 is desired)
   is to be assigned by the IANA for the ELC [RFC6790]."

RFC6790 defines ELC capability on a per FEC/LSP egress basis.
Please defines what you mean exactly with this per node capability. If this is 
expected to advertise ELC capability in spring networks, it's not crystal clear 
to me how it works in multi-area/domain network with IP prefix/SID 
redistribution.
Possibly the ELC flag would need to be advertised on a per prefix basis.

Thanks,
Regards,
--Bruno


 > -Original Message-
 > From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of 
 > bruno.decra...@orange.com
 > Sent: Thursday, August 02, 2018 10:24 PM
 > To: draft-ietf-isis-mpls-...@ietf.org
 > Cc: lsr@ietf.org
 > Subject: Re: [Lsr] I-D Action: draft-ietf-isis-mpls-elc-05.txt
 > 
 > Hi authors,
 > 
 > Please find below some minor comments:
 > 
 > 1) Abstract:
 > " In addition, this document introduces the Non-IGP Functional
 >Capabilities Sub-TLV for advertising IS-IS router's actual non-IGP
 >functional capabilities.  ELC is one of such non-IGP functional
 >capabilities."
 > 
 > It's a matter of opinion but reducing the number of occurrences of " non-IGP 
 > functional
 > capabilities" may improve the S/N ration.
 > 
 > 2)
 >The format of the Router Non-IGP Functional Capabilities Sub-TLV is  as 
 > follows:
 > 
 > 0   1   2   3
 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 >|Type=TBD1  |Length=4   |
 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 > 
 > 
 > The sub-TLV is not hard coded/defined with a length of 4, hence this value 
 > should not be part of
 > the definition.
 > 
 > 3)
 > "Length: Indicates the length of the value portion in octets and  will be a 
 > multiple of 4 octets"
 > 
 > Possibly :s/will/MUST
 > Please specify the error handling. (e.g. disregards the whole sub-TLV, 
 > disregards the last 1 to 3
 > octets, accept the whole sub-TLV...)
 > 
 > 
 > 4)
 > "One bit of the Non-IGP Functional Capability Bits (Bit 0 is desired)  is to 
 > be assigned by the
 > IANA for the ELC [RFC6790]."
 > 
 > Since this document defines the new sub-TLV, it can freely do any allocation 
 > itself.
 > 
 > 5)
 > "The registration procedure is "Expert Review" as defined in   [RFC8126]."
 > 
 > You may want to read RFC 8126 https://tools.ietf.org/html/rfc8126#section-4.5
 > Which, In particular, states:
 > " The registry's
 >definition needs to make clear to registrants what information is
 >necessary.
 > 
 >   [...]
 > 
 >The required documentation and review criteria, giving clear guidance
 >to the designated expert, should be provided when defining the
 >registry.  It is particularly important to lay out what should be
 >considered when performing an evaluation and reasons for rejecting a
 >request.  It is also a good idea to include, when possible, a sense
 >of whether many registrations are expected over time, or if the
 >registry is expected to be updated infrequently or in exceptional
 >circumstances only. "
 > 
 > 6)
 > "This capability, referred to as Entropy  Readable Label Depth (ERLD) as 
 > defined in  [I-D.ietf-
 > mpls-spring-entropy-label] "
 > 
 > This probably calls for this document to be a normative reference.
 > 
 > 
 > "   A new MSD-type of the Node MSD b-TLV
 >[I-D.ietf-isis-segment-routing-msd], called ERLD is defined to
 >advertise the ERLD of a given router."
 > 
 > May be adding the reference to the document defining the ERLD:
 > OLD: advertise the ERLD
 > NEW: advertise the ERLD [I-D.ietf-mpls-spring-entropy-label]
 > 
 > 7)
 > "If a router has
 >multiple line cards, the router MUST NOT announce the ELC [RFC6790]
 >unless all of its linecards are capable of processing ELs."
 > 
 > May be you mean
 > OLD: all of its linecards
 > OLD: all of the linecards of the links advertised as IS-IS adjacencies.
 > 
 > Regards,
 > --Bruno
 > 
 >  > -Original Message-
 >  > From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of 
 > internet-dra...@ietf.org
 >  > Sent: Tuesday, July 31, 2018 4:07 PM
 >  > To: i-d-annou...@ietf.org
 >  > Cc: lsr@ietf.org
 >  > Subject: [Lsr] I-D Action: draft-ietf-isis-mpls-elc-05.txt
 >  >
 >  >
 >  > A New Internet-Draft is available from the on-line Internet-Drafts 
 > directories.
 >  > This draft is a work item of the Link State Routing WG of the IETF.
 >  >
 >  > Title   : Signaling Entropy Label Capability and Entropy 
 > Readable Label Depth Using
 >  > IS-IS
 >  > Authors : Xiaohu Xu
 >  >   Sriganesh Kini
 >  >   Siva Sivabalan
 >  >   Clarence Filsfils
 >  >   Stephane Litkowski
 >  >   Filename 

Re: [Lsr] LSR Working Group Adoption Poll for Flex Algorithm Drafts

[bruno.decraene]

+1
(I guess you meant :s/LSR/SR   ;-) )

Thanks
--Bruno

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Tuesday, April 17, 2018 5:24 PM
To: lsr@ietf.org
Subject: Re: [Lsr] LSR Working Group Adoption Poll for Flex Algorithm Drafts

Speaking as WG member, I support draft adoption. It was being presented at 2 
IETFs and it is one of the more exciting developments in LSR (I’m sure there 
are other WGs that are feeling insecure based on the power and flexibility of 
this enhancement ;^).

Speaking as WG Co-Chair – I think it would be great to combine the drafts. The 
normative sections on SPF computation are common to both OSPF and IS-IS.

Thanks,
Acee

From: Lsr > on behalf of Acee 
Lindem >
Date: Tuesday, April 17, 2018 at 10:44 AM
To: "lsr@ietf.org" >
Subject: [Lsr] LSR Working Group Adoption Poll for Flex Algorithm Drafts

This begins a two-week adoption poll for the following Flex Algorithm drafts:

https://datatracker.ietf.org/doc/draft-hegdeppsenak-isis-sr-flex-algo/
https://datatracker.ietf.org/doc/draft-ppsenak-ospf-sr-flex-algo/

The adoption poll will end at 12:00 AM EST on May 2nd, 2018. Please indicate 
your support of opposition of the drafts.

Additionally, the authors are amenable to combining the drafts into a single 
draft. If you have an opinion, please state that as well.

Thanks,
Acee




_

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

[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 message and its attachments.

As emails 

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

[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;
 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 mailto:bruno.decra...@orange.com>>
Cc: Routing Directorate mailto:rtg-...@ietf.org>>; 
draft-ietf-isis-segment-routing-...@ietf.org;
 rtg-...@ietf.org; Alvaro Retana 
mailto:aretana.i...@gmail.com>>; 
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 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>>,
 "rtg-...@ietf.org" 
mailto:rtg-...@ietf.org>>, Alvaro Retana 
mailto:aretana.i...@gmail.com>>, 
"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 

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

[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; 
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 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; 
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).  

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

[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) 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 

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

[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 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>>,
 "rtg-...@ietf.org" 
mailto:rtg-...@ietf.org>>, Alvaro Retana 
mailto:aretana.i...@gmail.com>>, 
"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; 
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) 
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 

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

[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

[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

[Lsr] Entropy label for SR-MPLS

[bruno.decraene]

Hi SPRING WG,

draft-ietf-isis-mpls-elc defines an IS-IS extension to allow the use of MPLS 
entropy labels in SR-MPLS networks.
https://tools.ietf.org/html/draft-ietf-isis-mpls-elc-05

As a reminder, entropy label has been defined in RFC 6790 by the MPLS WG. It 
improves load-balancing / allows the effective use of parallel paths. It 
requires a signaling and RFC 6790 defined it for LDP, RSVP-TE and BGP. As 
segment routing does not uses LDP nor RSVP-TE, an IGP extension is indeed 
required. https://tools.ietf.org/html/rfc6790

As of today (-05) the IGP encoding chosen by draft-ietf-isis-mpls-elc:
- may support inter-area/level deployments, albeit with additional complexity 
(currently not specified)
- does not support inter-AS and inter-protocol deployments. (Inter-protocol 
being the redistribution of prefixes/segments from a protocol (instance) to 
another IGP protocol (instance))

Following some discussions, this restriction is not an IGP technical issue as 
it would be easy to allow for this feature by using a different IGP encoding. 
It's a question of requirements so it would be better discussed in the SPRING 
WG.

I'd like to see a discussion on whether this restriction is a good or a bad 
thing from a SPRING requirement standpoint.
In other words, do we want to allow (or not) the use of entropy label in 
inter-AS and inter-protocol deployments or do we accept this regression 
compared to LDP and RSVP-TE?

Thanks,
Regards,
--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] Entropy label for SR-MPLS

[bruno.decraene]

Speaking as an individual contributor and a service provider,

1) ELC (Entropy Label Capability)
I support the ability to use entropy label and hence advertise ELC (Entropy 
Label Capability) inter-AS and inter-protocol deployments
- In Orange we do have both inter-area/level and inter-AS w/ inter-protocol 
deployments, in particular for the support of MPLS VPNs across ASes.
- I don't see a reason to introduce such limitation to segment routing 
(compared to LDP & RSVP-TE) especially as this feature could easily be 
supported by the IGP extension.

2) ERLD (Entropy Readable Label Depth)
On a side note, as the draft also defines the IGP extension to advertise ERLD 
(Entropy Readable Label Depth) I don't think that we (equally) need to 
propagate ELRD advertisement between areas/levels/ASes/protocols as:
- ELC advertisement is a MUST while ERLD is both only nice to have and only 
required for SR-policies with "many" labels, which should be the minority in 
most deployments
- ELC only requires the advertisement of a flag per segment/prefix which can 
easily be propagated between IGP topologies. While the use of ERLD requires the 
knowledge of the IGP topology, which by definition is not available in 
inter-area/level/AS/protocol scenarios.
  I see two main cases of the use of ERLD in inter AS scenario:
- along the shortest path: in this case, only one or two 
labels/SIDs is required hence ERLD is not a concern. (Note that this applies to 
any type of metric and to Flex Algo)
- along a TE/specific path: in this case, the computation of the 
path requires the knowledge of the topology along the path, hence the LSDB of 
both ASes. It would typically be performed by a PCE rather than the ingress 
node (although the ingress could also learn the remote topology, e.g. with 
BGP-LS)
In summary, in both cases there is no need to propagate the ERLC between LSDB

Thanks,
Regards,
--Bruno



From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of bruno.decra...@orange.com
Sent: Monday, September 03, 2018 2:07 PM
To: spr...@ietf.org
Cc: lsr@ietf.org; draft-ietf-isis-mpls-...@ietf.org
Subject: [Lsr] Entropy label for SR-MPLS

Hi SPRING WG,

draft-ietf-isis-mpls-elc defines an IS-IS extension to allow the use of MPLS 
entropy labels in SR-MPLS networks.
https://tools.ietf.org/html/draft-ietf-isis-mpls-elc-05

As a reminder, entropy label has been defined in RFC 6790 by the MPLS WG. It 
improves load-balancing / allows the effective use of parallel paths. It 
requires a signaling and RFC 6790 defined it for LDP, RSVP-TE and BGP. As 
segment routing does not uses LDP nor RSVP-TE, an IGP extension is indeed 
required. https://tools.ietf.org/html/rfc6790

As of today (-05) the IGP encoding chosen by draft-ietf-isis-mpls-elc:
- may support inter-area/level deployments, albeit with additional complexity 
(currently not specified)
- does not support inter-AS and inter-protocol deployments. (Inter-protocol 
being the redistribution of prefixes/segments from a protocol (instance) to 
another IGP protocol (instance))

Following some discussions, this restriction is not an IGP technical issue as 
it would be easy to allow for this feature by using a different IGP encoding. 
It's a question of requirements so it would be better discussed in the SPRING 
WG.

I'd like to see a discussion on whether this restriction is a good or a bad 
thing from a SPRING requirement standpoint.
In other words, do we want to allow (or not) the use of entropy label in 
inter-AS and inter-protocol deployments or do we accept this regression 
compared to LDP and RSVP-TE?

Thanks,
Regards,
--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.

_

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 

Re: [Lsr] draft-ginsberg-lsr-isis-invalid-tlv

[bruno.decraene]

Les,

Thank you for accommodating my comments.
-02 looks good.
1 follow up comment:

§3.2  "ISes MUST NOT accept purges that contain TLVs other than the 
authentication TLV"

§3.1 "   Therefore TLVs in a PDU which are disallowed MUST be
   ignored and MUST NOT cause the PDU itself to be rejected by the
   receiving IS."

I would assume that a purge is a PDU. Hence both sentences seems to contradict 
as they are both related to same case (a TLV which is disallowed in a PDU) 
while they require opposite actions:

-  The first sentence calls for not accepting the PDU

-  The second sentence calls for not rejecting the PDU.

I understand that purge with authentication TLV is an exception, but the "MUST 
NOT" in §3.1 does not allow for exception.
May be
OLD: Therefore TLVs in a PDU which are disallowed
NEW: Therefore, in a non-purge PDU, TLVs which are disallowed

Thanks you,
Regards,
--Bruno

From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Wednesday, March 27, 2019 12:32 AM
To: DECRAENE Bruno TGI/OLN; lsr@ietf.org; 
draft-ginsberg-lsr-isis-invalid-...@ietf.org
Cc: Alvaro Retana
Subject: RE: draft-ginsberg-lsr-isis-invalid-tlv

Bruno -

Thanx for your comments.

V2 of the draft has been posted which addresses a number of the issues.
More inline.

From: bruno.decra...@orange.com 
Sent: Friday, March 22, 2019 4:02 AM
To: lsr@ietf.org; draft-ginsberg-lsr-isis-invalid-...@ietf.org
Cc: Alvaro Retana 
Subject: RE: draft-ginsberg-lsr-isis-invalid-tlv

§4
   The presence of a TLV (or sub-TLV) with content which does not
   conform to the relevant specification MUST NOT cause the LSP itself
   to be rejected.

Again, thank you for your effort to clarify the specification.

Given the "MUST", I feel that this sentence may be read as contradicting with 
some other text. E.g

"   An implementation that implements HMAC-MD5 authentication and
   receives HMAC-MD5 Authentication Information MUST discard the PDU if
   the Authentication Value is incorrect."
https://tools.ietf.org/html/rfc5304#section-2

Do you think it could be slightly rephrased? May be something along 
:s/rejected/considered invalid [or incorrect, although 10589 seems to use 
the term "invalid PDU"]
(as "rejected" could be read as similar to "discarded")

[Les:] The behavior described in RFC 5304 is normative (i.e., MUST is both 
intentional and correct) and implementations which conform to RFC 5304 will 
indeed discard such a PDU.
If your concern is about the word "discard" - this follows the terminology used 
in ISO 10589 - for example Section 7.3.14.2e:

"An Intermediate system receiving a Link State PDU with an incorrect LSP 
Checksum or with an invalid PDU syntax shall

1)   generate a corruptedLSPReceived circuit event,

2) discard the PDU.

Therefore I prefer to continue to use "discard".


Thanks,
--Bruno


From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of 
bruno.decra...@orange.com
Sent: Friday, March 22, 2019 11:41 AM
To: lsr@ietf.org; 
draft-ginsberg-lsr-isis-invalid-...@ietf.org
Cc: Alvaro Retana
Subject: [Lsr] draft-ginsberg-lsr-isis-invalid-tlv

Hi all,

To be clear, I support that document. Thanks for writing it.
I have some comments, mostly asking for even more of this/such document. 
(although I expect that some comments will trigger a discussion ;-) )


§3.1
"Any codes in a received PDU that are not recognised shall be
   ignored."

   Therefore the presence of TLVs in a PDU which are not allowed MUST
   NOT cause the PDU itself to be rejected by the receiving IS.


I don't think that "not recognized" is the same as "not allowed".

IMHO, the fact that unknown TLV are to be ignored seem rather obvious as this 
is a designed goal of the TLV format. Yet, it's good that 
[ISO10589]
 explicitly stated it.
I definitely support that LSR defines the behavior for TLV (and sub-TLV) which 
are not allowed. But I find the justification and reference debatable. I'd 
rather prefer that we remove it, or at least remove the "Therefore". I'd favor 
something along
OLD: Therefore
NEW: In addition, this document specifies that

§3.3

Registries associated with sub-TLVs are

   associated with the TLV Codepoints Registry and specify in which TLVs

   a given sub-TLV is allowed.  As with TLVs, it is required that sub-

   TLVs which are NOT allowed MUST be ignored on receipt.

In addition to "not recognized" and "not allowed by the registry" I believe 
that there are others cases that would benefit from been clarified. Such as:
- not allowed by the specification (in a given case/condition)
- REQUIRED (MUST) but not present e.g. "it MUST include this sub-TLV on 
point-to-point adjacencies" https://tools.ietf.org/html/rfc5305#section-3.3
- Malformed (bad syntax)
- Correctly formed but illegal value (in a given 

Re: [Lsr] draft-ginsberg-lsr-isis-invalid-tlv

[bruno.decraene]

Les,

-03 looks good.

Thank you.

--Bruno

From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Wednesday, April 3, 2019 8:04 PM
To: DECRAENE Bruno TGI/OLN; lsr@ietf.org; 
draft-ginsberg-lsr-isis-invalid-...@ietf.org
Cc: Alvaro Retana
Subject: RE: draft-ginsberg-lsr-isis-invalid-tlv

Bruno -

V3 of the draft has been posted.
Hopefully it addresses your remaining comment.

Les


From: bruno.decra...@orange.com 
Sent: Tuesday, April 02, 2019 6:59 AM
To: Les Ginsberg (ginsberg) ; lsr@ietf.org; 
draft-ginsberg-lsr-isis-invalid-...@ietf.org
Cc: Alvaro Retana 
Subject: RE: draft-ginsberg-lsr-isis-invalid-tlv

Les,

Thank you for accommodating my comments.
-02 looks good.
1 follow up comment:

§3.2  "ISes MUST NOT accept purges that contain TLVs other than the 
authentication TLV"

§3.1 "   Therefore TLVs in a PDU which are disallowed MUST be
   ignored and MUST NOT cause the PDU itself to be rejected by the
   receiving IS."

I would assume that a purge is a PDU. Hence both sentences seems to contradict 
as they are both related to same case (a TLV which is disallowed in a PDU) 
while they require opposite actions:

-  The first sentence calls for not accepting the PDU

-  The second sentence calls for not rejecting the PDU.

I understand that purge with authentication TLV is an exception, but the "MUST 
NOT" in §3.1 does not allow for exception.
May be
OLD: Therefore TLVs in a PDU which are disallowed
NEW: Therefore, in a non-purge PDU, TLVs which are disallowed

Thanks you,
Regards,
--Bruno

From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Wednesday, March 27, 2019 12:32 AM
To: DECRAENE Bruno TGI/OLN; lsr@ietf.org; 
draft-ginsberg-lsr-isis-invalid-...@ietf.org
Cc: Alvaro Retana
Subject: RE: draft-ginsberg-lsr-isis-invalid-tlv

Bruno -

Thanx for your comments.

V2 of the draft has been posted which addresses a number of the issues.
More inline.

From: bruno.decra...@orange.com 
mailto:bruno.decra...@orange.com>>
Sent: Friday, March 22, 2019 4:02 AM
To: lsr@ietf.org; 
draft-ginsberg-lsr-isis-invalid-...@ietf.org
Cc: Alvaro Retana mailto:aretana.i...@gmail.com>>
Subject: RE: draft-ginsberg-lsr-isis-invalid-tlv

§4
   The presence of a TLV (or sub-TLV) with content which does not
   conform to the relevant specification MUST NOT cause the LSP itself
   to be rejected.

Again, thank you for your effort to clarify the specification.

Given the "MUST", I feel that this sentence may be read as contradicting with 
some other text. E.g

"   An implementation that implements HMAC-MD5 authentication and
   receives HMAC-MD5 Authentication Information MUST discard the PDU if
   the Authentication Value is incorrect."
https://tools.ietf.org/html/rfc5304#section-2

Do you think it could be slightly rephrased? May be something along 
:s/rejected/considered invalid [or incorrect, although 10589 seems to use 
the term "invalid PDU"]
(as "rejected" could be read as similar to "discarded")

[Les:] The behavior described in RFC 5304 is normative (i.e., MUST is both 
intentional and correct) and implementations which conform to RFC 5304 will 
indeed discard such a PDU.
If your concern is about the word "discard" - this follows the terminology used 
in ISO 10589 - for example Section 7.3.14.2e:

"An Intermediate system receiving a Link State PDU with an incorrect LSP 
Checksum or with an invalid PDU syntax shall

1)   generate a corruptedLSPReceived circuit event,

2) discard the PDU.

Therefore I prefer to continue to use "discard".


Thanks,
--Bruno


From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of 
bruno.decra...@orange.com
Sent: Friday, March 22, 2019 11:41 AM
To: lsr@ietf.org; 
draft-ginsberg-lsr-isis-invalid-...@ietf.org
Cc: Alvaro Retana
Subject: [Lsr] draft-ginsberg-lsr-isis-invalid-tlv

Hi all,

To be clear, I support that document. Thanks for writing it.
I have some comments, mostly asking for even more of this/such document. 
(although I expect that some comments will trigger a discussion ;-) )


§3.1
"Any codes in a received PDU that are not recognised shall be
   ignored."

   Therefore the presence of TLVs in a PDU which are not allowed MUST
   NOT cause the PDU itself to be rejected by the receiving IS.


I don't think that "not recognized" is the same as "not allowed".

IMHO, the fact that unknown TLV are to be ignored seem rather obvious as this 
is a designed goal of the TLV format. Yet, it's good that 
[ISO10589]
 explicitly stated it.
I definitely support that LSR defines the behavior for TLV (and sub-TLV) which 
are not allowed. But I find the justification and reference 

[Lsr] draft-ginsberg-lsr-isis-invalid-tlv

[bruno.decraene]

Hi all,

To be clear, I support that document. Thanks for writing it.
I have some comments, mostly asking for even more of this/such document. 
(although I expect that some comments will trigger a discussion ;-) )


§3.1
"Any codes in a received PDU that are not recognised shall be
   ignored."

   Therefore the presence of TLVs in a PDU which are not allowed MUST
   NOT cause the PDU itself to be rejected by the receiving IS.


I don't think that "not recognized" is the same as "not allowed".

IMHO, the fact that unknown TLV are to be ignored seem rather obvious as this 
is a designed goal of the TLV format. Yet, it's good that 
[ISO10589]
 explicitly stated it.
I definitely support that LSR defines the behavior for TLV (and sub-TLV) which 
are not allowed. But I find the justification and reference debatable. I'd 
rather prefer that we remove it, or at least remove the "Therefore". I'd favor 
something along
OLD: Therefore
NEW: In addition, this document specifies that

§3.3

Registries associated with sub-TLVs are

   associated with the TLV Codepoints Registry and specify in which TLVs

   a given sub-TLV is allowed.  As with TLVs, it is required that sub-

   TLVs which are NOT allowed MUST be ignored on receipt.

In addition to "not recognized" and "not allowed by the registry" I believe 
that there are others cases that would benefit from been clarified. Such as:
- not allowed by the specification (in a given case/condition)
- REQUIRED (MUST) but not present e.g. "it MUST include this sub-TLV on 
point-to-point adjacencies" https://tools.ietf.org/html/rfc5305#section-3.3
- Malformed (bad syntax)
- Correctly formed but illegal value (in a given case/condition)

I would like LSR to specify all types of error handling. Either in this 
document, or in another document if general error handling is considered out of 
scope of this document.
---

§1

"   PDUs which are valid MUST be accepted even if an individual TLV

   contained within that PDU is invalid in some way."



I wish "valid" be further defined. E.g. do you mean from a syntax/parsing point 
of view? Or do you mean something else?

In particular 
[ISO10589]
 use the terms "invalid PDU syntax". If you mean the same, I'd favor using the 
same terms. If you mean something different, please clarify the differences.

---

"   Nevertheless, a certain degree of "common knowledge" is assumed on

   the part of implementors in regards to these behaviors."



What do you mean by that? That some "common knowledge" are required for the 
protocol to (correctly) work but that this knowledge is not written in a 
specification? If so, I believe LSR should write down such behavior.



"   This document serves to make explicit what is expected.  While it

   does not alter any existing protocol behavior or specifications, it

   is intended to close any gaps between what is explicitly stated and

   what has been "commonly understood"."



Same comment.

A behavior is either specified or not specified. I don't understand the meaning 
of the term "commonly understood".



Thank you,

Regards,

--Bruno


PS: To clarify, I'm copying Alvaro as an individual contributor, as he 
expressed interest in error handling in BGP-LS which for some code points may 
be related to error handing in IS-IS.


_

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] draft-ginsberg-lsr-isis-invalid-tlv

[bruno.decraene]

§4
   The presence of a TLV (or sub-TLV) with content which does not
   conform to the relevant specification MUST NOT cause the LSP itself
   to be rejected.

Again, thank you for your effort to clarify the specification.

Given the "MUST", I feel that this sentence may be read as contradicting with 
some other text. E.g

"   An implementation that implements HMAC-MD5 authentication and
   receives HMAC-MD5 Authentication Information MUST discard the PDU if
   the Authentication Value is incorrect."
https://tools.ietf.org/html/rfc5304#section-2

Do you think it could be slightly rephrased? May be something along 
:s/rejected/considered invalid [or incorrect, although 10589 seems to use 
the term "invalid PDU"]
(as "rejected" could be read as similar to "discarded")

Thanks,
--Bruno


From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of bruno.decra...@orange.com
Sent: Friday, March 22, 2019 11:41 AM
To: lsr@ietf.org; draft-ginsberg-lsr-isis-invalid-...@ietf.org
Cc: Alvaro Retana
Subject: [Lsr] draft-ginsberg-lsr-isis-invalid-tlv

Hi all,

To be clear, I support that document. Thanks for writing it.
I have some comments, mostly asking for even more of this/such document. 
(although I expect that some comments will trigger a discussion ;-) )


§3.1
"Any codes in a received PDU that are not recognised shall be
   ignored."

   Therefore the presence of TLVs in a PDU which are not allowed MUST
   NOT cause the PDU itself to be rejected by the receiving IS.


I don't think that "not recognized" is the same as "not allowed".

IMHO, the fact that unknown TLV are to be ignored seem rather obvious as this 
is a designed goal of the TLV format. Yet, it's good that 
[ISO10589]
 explicitly stated it.
I definitely support that LSR defines the behavior for TLV (and sub-TLV) which 
are not allowed. But I find the justification and reference debatable. I'd 
rather prefer that we remove it, or at least remove the "Therefore". I'd favor 
something along
OLD: Therefore
NEW: In addition, this document specifies that

§3.3

Registries associated with sub-TLVs are

   associated with the TLV Codepoints Registry and specify in which TLVs

   a given sub-TLV is allowed.  As with TLVs, it is required that sub-

   TLVs which are NOT allowed MUST be ignored on receipt.

In addition to "not recognized" and "not allowed by the registry" I believe 
that there are others cases that would benefit from been clarified. Such as:
- not allowed by the specification (in a given case/condition)
- REQUIRED (MUST) but not present e.g. "it MUST include this sub-TLV on 
point-to-point adjacencies" https://tools.ietf.org/html/rfc5305#section-3.3
- Malformed (bad syntax)
- Correctly formed but illegal value (in a given case/condition)

I would like LSR to specify all types of error handling. Either in this 
document, or in another document if general error handling is considered out of 
scope of this document.
---

§1

"   PDUs which are valid MUST be accepted even if an individual TLV

   contained within that PDU is invalid in some way."



I wish "valid" be further defined. E.g. do you mean from a syntax/parsing point 
of view? Or do you mean something else?

In particular 
[ISO10589]
 use the terms "invalid PDU syntax". If you mean the same, I'd favor using the 
same terms. If you mean something different, please clarify the differences.

---

"   Nevertheless, a certain degree of "common knowledge" is assumed on

   the part of implementors in regards to these behaviors."



What do you mean by that? That some "common knowledge" are required for the 
protocol to (correctly) work but that this knowledge is not written in a 
specification? If so, I believe LSR should write down such behavior.



"   This document serves to make explicit what is expected.  While it

   does not alter any existing protocol behavior or specifications, it

   is intended to close any gaps between what is explicitly stated and

   what has been "commonly understood"."



Same comment.

A behavior is either specified or not specified. I don't understand the meaning 
of the term "commonly understood".



Thank you,

Regards,

--Bruno


PS: To clarify, I'm copying Alvaro as an individual contributor, as he 
expressed interest in error handling in BGP-LS which for some code points may 
be related to error handing in IS-IS.


_



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 

Re: [Lsr] Status of draft-ietf-isis-encapsulation-cap

[bruno.decraene]

Hi Adrian,

> On the other hand,
> https://datatracker.ietf.org/doc/draft-ietf-ospf-encapsulation-cap/ found
> its way onto the RFC Editor Queue at around the same date and has languished
> there ever since.

The OSPF document progressed well. The decision was made to normatively  
reference the IDR document for some codepoints, mostly because the IDR document 
was pre-dating.
But then IDR document did not progress that fast and hence the OSPF document is 
in RFC editor queue waiting for the normative reference (for 538 days i.e. 1,5 
years and counting).

> https://datatracker.ietf.org/doc/draft-ietf-isis-encapsulation-cap/ shows 
> expired in October 2017,

The OSPF document had been significantly updated/rewritten toward the end which 
required some significant work. Since there were less traction with the IS-IS 
counterpart, to be honest I did not feel motivated to do the equivalent work 
for the IS-IS draft.
If there is an interest for the IS-IS draft, we can revive and update it. OTOH, 
I'd rather avoid doing the work just to see the WG not progressing it to IESG 
during last call

I assume (1) that your interest is coming from the IESG review on 
draft-ietf-mpls-sr-over-ip. draft-ietf-mpls-sr-over-ip is built over the IGP 
use case and hence relies on IGP advertising the encapsulation capability. 
Hence the normative reference, hence the fear the document would stay in the 
RFC editor queue for some time/ever. I think that this process question is 
mostly for the IESG. Personally I feel that a pragmatic approach would be to 
keep OSPF as a normative reference and downgrade IS-IS as informative. That may 
seem like a strange difference of treatment but the alternative is likely to 
just "silently" remove the IS-IS reference which would be an even bigger 
different of treatment.

Regards,

Bruno

(1) Actually, your PS made it clear.

PS:
> Any clues?
Thanks for not asking for the solution. That makes me feel more useful, for the 
same amount of work ;-)


-Original Message-
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Adrian Farrel
Sent: Saturday, April 13, 2019 5:59 PM
To: lsr@ietf.org
Subject: [Lsr] Status of draft-ietf-isis-encapsulation-cap

Hi,

Any clues?

https://datatracker.ietf.org/doc/draft-ietf-isis-encapsulation-cap/ shows
expired in October 2017, so I guess that is good and dead.

On the other hand,
https://datatracker.ietf.org/doc/draft-ietf-ospf-encapsulation-cap/ found
its way onto the RFC Editor Queue at around the same date and has languished
there ever since.

Did the ISIS work get replaced by some other draft without the "replaced by"
link being set up?
Was it deemed unnecessary in ISIS?

Thanks,
Adrian (who is trying to get draft-ietf-mpls-sr-over-ip through the IESG and
finds a reference to this draft)
--
Fairy tales from North Wales for adults of all ages
https://www.feedaread.com/profiles/8604/
Available from your favourite online bookseller.
Or contact me to receive a signed copy by mail.

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

_

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] WG Adoption Call: draft-ginsberg-lsr-isis-invalid-tlv

[bruno.decraene]

Support.

--Bruno

-Original Message-
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps
Sent: Wednesday, June 12, 2019 2:05 PM
To: lsr@ietf.org
Cc: lsr-cha...@ietf.org; lsr-...@ietf.org; Christian Hopps; 
draft-ginsberg-lsr-isis-invalid-...@ietf.org
Subject: [Lsr] WG Adoption Call: draft-ginsberg-lsr-isis-invalid-tlv

This begins a 2 week WG adoption call for draft-ginsberg-lsr-isis-invalid-tlv.

https://datatracker.ietf.org/doc/draft-ginsberg-lsr-isis-invalid-tlv/

Please express your support or non-support.

Authors: Please indicate your knowledge of any IPR related to this work
to the list as well.

Thanks,
Chris & Acee.



_

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] Working Group Adoption Call for "IS-IS Extensions to Support Routing over IPv6 Dataplane" - draft-bashandy-isis-srv6-extensions-05.txt

[bruno.decraene]

Support adoption. (as a co-author)

--Bruno

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Thursday, May 9, 2019 3:50 PM
To: lsr@ietf.org
Subject: [Lsr] Working Group Adoption Call for "IS-IS Extensions to Support 
Routing over IPv6 Dataplane" - draft-bashandy-isis-srv6-extensions-05.txt

We been holding off WG adoption until the base SRv6 draft was adopted in 
SPRING. Now that 
https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-network-programming/ 
has been adopted, we are starting a two week LSR WG adoption poll for the 
subject draft. Please register your support or objection prior to 12:00 AM UTC, 
on May 25th, 2019.

For your convenience, here is a URL for the draft:

https://datatracker.ietf.org/doc/draft-bashandy-isis-srv6-extensions/

Thanks,
Acee


_

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] IETF 105 LSR Working Slot Requests

[bruno.decraene]

Hi,

I would to like to request one slot :

Draft: draft-decraene-lsr-isis-flooding-speed-00
Speaker: Bruno Decraene
Duration: 12 minutes
https://tools.ietf.org/html/draft-decraene-lsr-isis-flooding-speed-00


Thanks,
Bruno

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Tuesday, June 25, 2019 12:31 AM
To: lsr@ietf.org
Subject: [Lsr] IETF 105 LSR Working Slot Requests

We are now accepting agenda requests for the LSR Working Group meeting IETF 
105. Please send us your request for a presentation slot , indicating draft 
name, speaker, and desired duration (covering presentation and discussion). If 
it is not the first presentation of the draft, please give a reason why it is 
required to have a new presentation slot.

Thanks,
Acee



_

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] When to augment LSR base YANG modules...

[bruno.decraene]

Hi,

I don't know anything about yang (module) so everything looks easy from 1 
feet. Yet, my 2 cents.

> I think the main requirement (speaking as an operator) is to get the YANG 
> part (ops+cfg) standardized at the same time.

+1 to Stéphane & Christian

Whether this is done in the same document or via a normative reference to 
another document is less of an issue, but I think that many IGP extensions 
typically require a very small extension to the yang model hence could be done 
in the same document.

> While YANG is easy to write, it could still scare pure IGP guys that are 
> focused on protocol encodings

Probably the first draft could be "hard", but given an existing model/example, 
I would assume that most IGP extensions would be reasonably similar in term or 
yang additions.

 > I'm a bit worried about having too many tiny modules
[...]
> we have few (or even no) experience today on managing modules revisions

I think that we need to start walking to gain experience, and then define 
yang/whatever extensions to improve on either/both of those problems. On the 
first point, possibly a meta model could reference a set of tiny models, but 
regardless of the details, I trust yang people to find a solution.
In all cases, I don't think those problems would disappear by taking another 
path. (except deferring yang extensions for... ever). I don't think that 
delaying yang revisions every N years would be easier as the authors of the IGP 
extensions are probably the best persons to define the cfg/operational objects 
needed for their extensions.

In all cases, thank you Christian for raising the point.

Regards,
--Bruno

-Original Message-
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of 
stephane.litkow...@orange.com
Sent: Tuesday, April 16, 2019 9:52 AM
To: Christian Hopps; lsr@ietf.org
Subject: Re: [Lsr] When to augment LSR base YANG modules...

Hi,

On one hand, I'm a bit worried about having too many tiny modules (finding the 
right module name to get the right feature, managing prefixes...). The good 
thing I see is that we could mandate in each LSR draft the YANG management part 
so both are published at the same time. While YANG is easy to write, it could 
still scare pure IGP guys that are focused on protocol encodings -> this 
implies that people may need to rely on people with YANG skills to write the 
management section.

On the other hand, we have few (or even no) experience today on managing 
modules revisions, do we also foresee some level of complexity ? The issue I 
see if we update the main YANG base module is that the timing may be different 
from the protocol encoding spec. Also, are we ready to publish a revision for 
each tiny feature ?(why not but who takes the pen ? Speaking as editor of ISIS 
yang module, I'm not really ready to have the pen to modify it for the rest of 
my life ;)

I think the main requirement (speaking as an operator) is to get the YANG part 
(ops+cfg) standardized at the same time. 


Brgds,


-Original Message-
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps
Sent: Friday, March 29, 2019 09:17
To: lsr@ietf.org
Cc: cho...@chopps.org
Subject: [Lsr] When to augment LSR base YANG modules...


The base YANG modules for IS-IS and OSPF both include operational state to 
describe TLV data. During the discussion about OSPFv3's version of this data, I 
brought up the issue of when and how the base modules should be augmented to 
add new TLV types to the model, suggesting it be done inline and with the RFC 
that adds the new feature/functionality to the protocol.

I'll go farther here and say this should apply to all the YANG required for 
management of the new feature, and it should all be added inline with the 
feature (i.e., in the same draft). In other words new features/functionality 
should include the YANG augment required to manage said features/functionality.

This has been suggested/tried previously with SNMP with varying (low) levels of 
success. The difference here is 1) YANG additions (a new module perhaps just 
augmenting the base) is easy, whereas SNMP wasn't. Additionally, operators 
weren't using SNMP to fully manage functionality (e.g., not doing 
configuration) so a requirement for extra work was harder to justify. Operators 
*do* want to fully manage their networks/servers with YANG though.

The argument against this during the meeting was that it would create many 
small modules. I don't find this compelling (i.e., "so"? :)

Assume I'm an operator -- the actual consumer of this management stuff:

  - If I'm going to use this new feature X, I need to be able to manage it. So 
I need it YANG for it. Not only do I need any new TLV data in the operational 
state, but I need the configuration and any other operational state right along 
with it. Otherwise each vendor has to add new YANG to their vendor modules, or 
the feature is useless to me. I can't use something if I can't turn it on.

  - I don't care 

[Lsr] FW: IPR Disclosure Juniper's Statement about IPR related to draft-decraene-lsr-isis-flooding-speed

[bruno.decraene]

FYI

-Original Message-
From: IETF Secretariat [mailto:ietf-...@ietf.org] 
Sent: Friday, August 2, 2019 8:37 PM
To: draft-decraene-lsr-isis-flooding-sp...@ietf.org
Cc: ipr-annou...@ietf.org
Subject: IPR Disclosure Juniper's Statement about IPR related to 
draft-decraene-lsr-isis-flooding-speed

Dear Bruno Decraene, Chris Bowers, Jayesh, Tony Li, Gunter Van de Velde:


An IPR disclosure that pertains to your Internet-Draft entitled "IS-IS
Flooding Speed advertisement" (draft-decraene-lsr-isis-flooding-speed) was
submitted to the IETF Secretariat on  and has been posted on the "IETF Page
of Intellectual Property Rights Disclosures"
(https://datatracker.ietf.org/ipr/3670/). The title of the IPR disclosure is
"Juniper's Statement about IPR related to
draft-decraene-lsr-isis-flooding-speed"


Thank you

IETF Secretariat


_

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] Working Group Last Call for "Signaling Entropy Label Capability and Entropy Readable Label-stack Depth Using OSPF" - draft-ietf-ospf-mpls-elc-08

[bruno.decraene]

Support.
This is needed for using MPLS Entropy Label in SR-MPLS.

Please find below some proposed comments. Please feel free to silently discard.

§1 Introduction
OLD:

“This capability, referred to as Entropy

   Readable Label Depth (ERLD) as defined in

   
[I-D.ietf-mpls-spring-entropy-label]
 may be used by ingress LSRs to

   determine whether it's necessary to insert an EL for a given LSP in

   the case where there has already been at least one EL in the label

   stack 
[I-D.ietf-mpls-spring-entropy-label].”

NEW:

This capability, referred to as Entropy

   Readable Label Depth (ERLD) as defined in

   
[I-D.ietf-mpls-spring-entropy-label]
 may be used by ingress LSRs to

   determine the position of the EL label in the stack, and whether it's 
necessary to insert multiple ELs at different depth.



§7 Security Considerations



“This document does not introduce any new security risks.”



Incorrectly setting the E flag (ELC capable) (during origination, propagation, 
redistribution) may lead to black-holing the traffic on the egress node. I 
believe this risk should be mentioned.



§3.x

“0x04 - E-Flag (ELC Flag): Set by the advertising router to indicate that the 
prefix originator is capable of processing ELs”



I’m not that familiar with OSPF so I may be wrong. But it seems like one could 
understand “prefix originator” as the router advertising the prefix in the OSPF 
message. In which case this would be wrong in the case of inter-AS (and 
possibly inter area) as this OSPF originator would not be the egress of the 
MPLS LSP. RFC 6790 refers to “Egress LSR” for such node.

I would propose :s/prefix originator/Egress of the MPLS LSP for this prefix


Thanks
Regards,
--Bruno


From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Friday, August 30, 2019 9:42 PM
To: lsr@ietf.org
Cc: m...@ietf.org; lsr-...@ietf.org; draft-ietf-ospf-mpls-...@ietf.org
Subject: [Lsr] Working Group Last Call for "Signaling Entropy Label Capability 
and Entropy Readable Label-stack Depth Using OSPF" - draft-ietf-ospf-mpls-elc-08

We’ve gone through a number of iterations with these ELC drafts and I believe 
they are ready and meets all the use case requirements. Note that “Entropy 
Label for Spring tunnels” – draft-ietf-mpls-spring-entropy-label-12 is on the 
RFC editor’s queue.
This begins a two week last call for the subject draft. Please indicate your 
support or objection on this list prior to 12:00 AM UTC on Sept 14th, 2014.
Thanks,
Acee

_

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] Working Group Last Call for "Signaling Entropy Label Capability and Entropy Readable Label-stack Depth Using ISIS" - draft-ietf-isis-mpls-elc-07

[bruno.decraene]

Support.
This is needed for using MPLS Entropy Label in SR-MPLS.

Please find below some proposed comments. Please feel free to silently discard.
§1 Introduction
OLD:

“This capability, referred to as Entropy

   Readable Label Depth (ERLD) as defined in

   
[I-D.ietf-mpls-spring-entropy-label]
 may be used by ingress LSRs to

   determine whether it's necessary to insert an EL for a given LSP in

   the case where there has already been at least one EL in the label

   stack 
[I-D.ietf-mpls-spring-entropy-label].”

NEW:

This capability, referred to as Entropy

   Readable Label Depth (ERLD) as defined in

   
[I-D.ietf-mpls-spring-entropy-label]
 may be used by ingress LSRs to

   determine the position of the EL label in the stack, and whether it's 
necessary to insert multiple EL at different depth.



§7 Security Considerations



“This document does not introduce any new security risks.”



Incorrectly setting the E flag (ELC capable) (during origination, propagation, 
redistribution) may lead to black-holing the traffic on the egress node. I 
believe this risk should be mentioned.


Regards,
--Bruno
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Les Ginsberg (ginsberg)
Sent: Monday, September 2, 2019 6:48 AM
To: Acee Lindem (acee); lsr@ietf.org
Cc: m...@ietf.org; lsr-...@ietf.org; draft-ietf-isis-mpls-...@ietf.org
Subject: Re: [Lsr] Working Group Last Call for "Signaling Entropy Label 
Capability and Entropy Readable Label-stack Depth Using ISIS" - 
draft-ietf-isis-mpls-elc-07

I support moving forward with these drafts.
There are clearly use cases for this functionality and the solution has been 
vetted with providers who intend to deploy this.

   Les


From: Lsr  On Behalf Of Acee Lindem (acee)
Sent: Friday, August 30, 2019 12:44 PM
To: lsr@ietf.org
Cc: m...@ietf.org; lsr-...@ietf.org; draft-ietf-isis-mpls-...@ietf.org
Subject: [Lsr] Working Group Last Call for "Signaling Entropy Label Capability 
and Entropy Readable Label-stack Depth Using ISIS" - draft-ietf-isis-mpls-elc-07

We’ve gone through a number of iterations with these ELC drafts and I believe 
they are ready and meets all the use case requirements. Note that “Entropy 
Label for Spring tunnels” – draft-ietf-mpls-spring-entropy-label-12 is on the 
RFC editor’s queue.
This begins a two week last call for the subject draft. Please indicate your 
support or objection on this list prior to 12:00 AM UTC on Sept 14th, 2014. 
Also, review comments are certainly welcome.
Thanks,
Acee

_

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] Working Group Last Call for "Signaling Entropy Label Capability and Entropy Readable Label-stack Depth Using ISIS" - draft-ietf-isis-mpls-elc-07

[bruno.decraene]

Hi Peter,

Thanks, looks good.

--Bruno

-Original Message-
From: Peter Psenak [mailto:ppse...@cisco.com] 
Sent: Monday, September 2, 2019 1:04 PM
To: DECRAENE Bruno TGI/OLN; Acee Lindem (acee); lsr@ietf.org; 
draft-ietf-isis-mpls-...@ietf.org
Cc: m...@ietf.org; lsr-...@ietf.org
Subject: Re: Working Group Last Call for "Signaling Entropy Label Capability 
and Entropy Readable Label-stack Depth Using ISIS" - draft-ietf-isis-mpls-elc-07

Hi Bruno,

On 02/09/2019 11:59, bruno.decra...@orange.com wrote:
> Support.
> 
> This is needed for using MPLS Entropy Label in SR-MPLS.
> 
> Please find below some proposed comments. Please feel free to silently 
> discard.
> 
> §1 Introduction
> 
> OLD:
> 
> “This capability, referred to as Entropy
> 
> Readable Label Depth (ERLD) as defined in
> 
> [I-D.ietf-mpls-spring-entropy-label  
> ]
>  may be used by ingress LSRs to
> 
> determine whether it's necessary to insert an EL for a given LSP in
> 
> the case where there has already been at least one EL in the label
> 
> stack [I-D.ietf-mpls-spring-entropy-label  
> ].”
> 
> NEW:
> 
> This capability, referred to as Entropy
> 
> Readable Label Depth (ERLD) as defined in
> 
> [I-D.ietf-mpls-spring-entropy-label  
> ]
>  may be used by ingress LSRs to
> 
> determine the position of the EL label in the stack, and whether it's 
> necessary to insert multiple EL at different depth.

What about the slightly modified wording:

"This capability, referred to as Entropy Readable Label Depth (ERLD) as
defined in  may be
used by ingress LSRs determine the position of the EL in the stack, and 
whether it's necessary to insert multiple ELs at different position in 
the label stack."

> 
> §7Security Considerations
> 
> “This document does not introduce any new security risks.”
> 
> Incorrectly setting the E flag (ELC capable) (during origination, 
> propagation, redistribution) may lead to black-holing the traffic on the 
> egress node. I believe this risk should be mentioned.

done.

thanks,
Peter
> 
> Regards,
> 
> --Bruno
> 
> *From**:*Lsr [mailto:lsr-boun...@ietf.org] *On Behalf Of * Les Ginsberg 
> (ginsberg)
> *Sent:* Monday, September 2, 2019 6:48 AM
> *To:* Acee Lindem (acee); lsr@ietf.org
> *Cc:* m...@ietf.org; lsr-...@ietf.org; draft-ietf-isis-mpls-...@ietf.org
> *Subject:* Re: [Lsr] Working Group Last Call for "Signaling Entropy 
> Label Capability and Entropy Readable Label-stack Depth Using ISIS" - 
> draft-ietf-isis-mpls-elc-07
> 
> I support moving forward with these drafts.
> 
> There are clearly use cases for this functionality and the solution has 
> been vetted with providers who intend to deploy this.
> 
>     Les
> 
> *From:*Lsr  *On Behalf Of *Acee Lindem (acee)
> *Sent:* Friday, August 30, 2019 12:44 PM
> *To:* lsr@ietf.org
> *Cc:* m...@ietf.org; lsr-...@ietf.org; draft-ietf-isis-mpls-...@ietf.org
> *Subject:* [Lsr] Working Group Last Call for "Signaling Entropy Label 
> Capability and Entropy Readable Label-stack Depth Using ISIS" - 
> draft-ietf-isis-mpls-elc-07
> 
> We’ve gone through a number of iterations with these ELC drafts and I 
> believe they are ready and meets all the use case requirements. Note 
> that “Entropy Label for Spring tunnels” – 
> draft-ietf-mpls-spring-entropy-label-12 is on the RFC editor’s queue.
> 
> This begins a two week last call for the subject draft. Please indicate 
> your support or objection on this list prior to 12:00 AM UTC on Sept 
> 14^th , 2014. Also, review comments are certainly welcome.
> 
> Thanks,
> Acee
> 
> _
> 
> 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.
> 


_

Ce message et ses pieces 

[Lsr] draft-decraene-lsr-isis-flooding-speed

[bruno.decraene]

Hi all,

Following the presentation and discussion today, we would welcome comments on 
the draft.
https://tools.ietf.org/html/draft-decraene-lsr-isis-flooding-speed-01

If you have multiple significant comments on the draft, expecting to turn into 
a discussion, it would probably be easier to handle by sending multiple emails 
and keeping a single technical point par email.

Thanks,
Regards,
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] Working Group Last Call for "Signaling Entropy Label Capability and Entropy Readable Label-stack Depth Using ISIS" - draft-ietf-isis-mpls-elc-07

[bruno.decraene]

Hi Xiaohu,

Please see inline [Bruno]

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of ???(??)
Sent: Thursday, September 12, 2019 3:51 AM
To: Lsr; Peter Psenak; Acee Lindem (acee); lsr@ietf.org; 
draft-ietf-isis-mpls-...@ietf.org
Cc: m...@ietf.org; lsr-...@ietf.org
Subject: Re: [Lsr] Working Group Last Call for "Signaling Entropy Label 
Capability and Entropy Readable Label-stack Depth Using ISIS" - 
draft-ietf-isis-mpls-elc-07

Hi Bruno,

It's the ELC which is used to determine the POSSIBLE position of inserting the 
EL in the stack, meanwhile, it's the ERLC  which is
used to determine the necessity of inserting an EL at any possible position of 
the EL except the deepest position.

[Bruno] I agree, but I don’t see any inconsistency between the above and my 
comment.
Note: “ERLC” is not defined in this document. I ‘m assuming that you mean 
:s/ERLC/ERLD (although :s/ERLC/ELC would equally be a single letter typo)

Hence, the OLD definition of the ERLC seems more straightforward, IMHO.

[Bruno] That’s not my opinion but I can surely live with both. As I had 
previously stated  I clearly leave the choice to the editor. (“Please feel free 
to silently  discard. »)
That been said, my comment was purely editorial and does not change the meaning 
(the proposed change was :s/ different depth/ different position in the label 
stack). Interestingly, in your above comment you also use the term “position”.

Best regards,
--Bruno

Best regards,
Xiaohu




--
From:bruno.decraene 
Send Time:2019年9月2日(星期一) 22:33
To:Peter Psenak ; Acee Lindem (acee) ; 
lsr@ietf.org ; draft-ietf-isis-mpls-...@ietf.org 

Cc:m...@ietf.org ; lsr-...@ietf.org 
Subject:Re: [Lsr] Working Group Last Call for "Signaling Entropy Label 
Capability and Entropy Readable Label-stack Depth Using ISIS" - 
draft-ietf-isis-mpls-elc-07

Hi Peter,

Thanks, looks good.

--Bruno

-Original Message-
From: Peter Psenak [mailto:ppse...@cisco.com]
Sent: Monday, September 2, 2019 1:04 PM
To: DECRAENE Bruno TGI/OLN; Acee Lindem (acee); lsr@ietf.org; 
draft-ietf-isis-mpls-...@ietf.org
Cc: m...@ietf.org; lsr-...@ietf.org
Subject: Re: Working Group Last Call for "Signaling Entropy Label Capability 
and Entropy Readable Label-stack Depth Using ISIS" - draft-ietf-isis-mpls-elc-07

Hi Bruno,

On 02/09/2019 11:59, bruno.decra...@orange.com wrote:
> Support.
>
> This is needed for using MPLS Entropy Label in SR-MPLS.
>
> Please find below some proposed comments. Please feel free to silently
> discard.
>
> §1 Introduction
>
> OLD:
>
> “This capability, referred to as Entropy
>
> Readable Label Depth (ERLD) as defined in
>
> [I-D.ietf-mpls-spring-entropy-label  
> ]
>  may be used by ingress LSRs to
>
> determine whether it's necessary to insert an EL for a given LSP in
>
> the case where there has already been at least one EL in the label
>
> stack [I-D.ietf-mpls-spring-entropy-label  
> ].”
>
> NEW:
>
> This capability, referred to as Entropy
>
> Readable Label Depth (ERLD) as defined in
>
> [I-D.ietf-mpls-spring-entropy-label  
> ]
>  may be used by ingress LSRs to
>
> determine the position of the EL label in the stack, and whether it's
> necessary to insert multiple EL at different depth.

What about the slightly modified wording:

"This capability, referred to as Entropy Readable Label Depth (ERLD) as
defined in  may be
used by ingress LSRs determine the position of the EL in the stack, and
whether it's necessary to insert multiple ELs at different position in
the label stack."

>
> §7Security Considerations
>
> “This document does not introduce any new security risks.”
>
> Incorrectly setting the E flag (ELC capable) (during origination,
> propagation, redistribution) may lead to black-holing the traffic on the
> egress node. I believe this risk should be mentioned.

done.

thanks,
Peter
>
> Regards,
>
> --Bruno
>
> *From**:*Lsr [mailto:lsr-boun...@ietf.org] *On Behalf Of * Les Ginsberg
> (ginsberg)
> *Sent:* Monday, September 2, 2019 6:48 AM
> *To:* Acee Lindem (acee); lsr@ietf.org
> *Cc:* m...@ietf.org; lsr-...@ietf.org; draft-ietf-isis-mpls-...@ietf.org
> *Subject:* Re: [Lsr] Working Group Last Call for "Signaling Entropy
> Label Capability and Entropy Readable Label-stack Depth Using ISIS" -
> draft-ietf-isis-mpls-elc-07
>
> I support moving forward with these drafts.
>
> There are clearly use cases for this functionality and the solution has
> been vetted with providers who intend to deploy this.
>
> Les
>
> *From:*Lsr  *On Behalf Of *Acee Lindem (acee)
> *Sent:* Friday, August 30, 2019 12:44 PM
> *To:* lsr@ietf.org
> *Cc:* m...@ietf.org; lsr-...@ietf.org; draft-ietf-isis-mpls-...@ietf.org
> 

Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

[bruno.decraene]

Les,

Please see inline[Bruno]

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Les Ginsberg (ginsberg)
Sent: Wednesday, February 19, 2020 3:32 AM
To: lsr@ietf.org
Subject: Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

Base protocol operation of the Update process tracks the flooding of
LSPs/interface and guarantees timer-based retransmission on P2P interfaces
until an acknowledgment is received.

Using this base protocol mechanism in combination with exponential backoff of 
the
retransmission timer provides flow control in the event of temporary overload
of the receiver.

This mechanism works without protocol extensions, is dynamic, operates
independent of the reason for delayed acknowledgment (dropped packets, CPU
overload), and does not require additional signaling during the overloaded
period.

This is consistent with the recommendations in RFC 4222 (OSPF).

Receiver-based flow control (as proposed in 
https://datatracker.ietf.org/doc/draft-decraene-lsr-isis-flooding-speed/ )
requires protocol extensions and introduces additional signaling during
periods of high load. The asserted reason for this is to optimize throughput -
but there is no evidence that it will achieve this goal.

Mention has been made to TCP-like flow control mechanisms as a model - which
are indeed receiver based. However, there are significant differences between
TCP sessions and IGP flooding.

TCP consists of a single session between two endpoints. Resources
(primarily buffer space) for this session are typically allocated in the
control plane and current usage is easily measurable..

IGP flooding is point-to-multi-point, resources to support IGP flooding
involve both control plane queues and dataplane queues, both of which are
typically not per interface - nor even dedicated to a particular protocol
instance. What input is required to optimize receiver-based flow control is not 
fully specified.

https://datatracker.ietf.org/doc/draft-decraene-lsr-isis-flooding-speed/ 
suggests (Section 5) that the values
to be advertised:

"use a formula based on an off line tests of
   the overall LSPDU processing speed for a particular set of hardware
   and the number of interfaces configured for IS-IS"

implying that the advertised value is intentionally not dynamic. As such,
it could just as easily be configured on the transmit side and not require
additional signaling. As a static value, it would necessarily be somewhat
conservative as it has to account for the worst case under the current
configuration - which means it needs to consider concurrent use of the CPU
and dataplane by all protocols/features which are enabled on a router - not all 
of whose
use is likely to be synchronized with peak IS-IS flooding load.
[Bruno] _Assuming_ that the parameters are static, those parameters

o   are the same as the one implemented (configured) on multiple 
implementations, including the one from your employer. Now do you believe that 
those parameters can be determined?

§  If yes, how do you do _today_ on your implementation? (this seems to 
contradict your statement that you have no way to figure out how to find the 
right value)

§  If no, why did you implement those parameters, and ask network operator to 
configure them?

§  There is also the option to reply: I don't know but don't care as I leave 
the issue to the network operator.

o   can still provide some form of dynamicity, by using the PSNP as dynamic 
acknowledgement.

o   are really dependent on the receiver, not the sender.

§  the sender will never overload itself.

§  The receiver has more information,  knowing its processing power (low end, 
high end, 80s, 20s (currently we are stuck with 20 years old value assuming the 
worst possible receiver (and worst there were, including with packet processing 
partly done in the control plane processor)), its expected IS-IS load 
(#neighbors), its preference for bursty LSP reception (high delay between IS-IS 
CPU allocation cycles, memory not an issue up to x kilo-octet...), its expected 
control plane load if IS-IS traffic has not higher priority over other control 
plane traffic...), it's expected level of QoS prioritization [1]

·  [1] looks for "Extended SPD Headroom". E.g. "Since IGP and link 
stability are more tenuous and more crucial than BGP stability, such packets 
are now given the highest priority and are given extended SPD headroom with a 
default of 10 packets. This means that these packets are not dropped if the 
size of the input hold queue is lower than 185 (input queue default size + spd 
headroom size + spd extended headroom)."

o   And this is for distributed architecture, 15 years ago. So what about using 
the above number (in the router configuration), applies Tony's proposal 
(*oversubscription/number of IS neighbhors), and advertise this value to your 
LSP sender?



[1] 
https://www.cisco.com/c/en/us/support/docs/routers/12000-series-routers/29920-spd.html


-
--Bruno


Unless a good case 

Re: [Lsr] clarification of locator block and locator node in draft-ietf-spring-srv6-network-programming and draft-ietf-lsr-isis-srv6-extensions

[bruno.decraene]

Hi Ketan,



From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Ketan Talaulikar (ketant)
Sent: Friday, February 28, 2020 6:30 AM


Hi Chris,

I agree with Peter and I would suggest to drop LSR since this is not a protocol 
specific thing.

I believe the text in draft-ietf-spring-srv6-network-programming clears says 
what locator block and locator node are. What more details do you think are 
required?

[Bruno] Speaking as an individual, the draft could possibly clarify the usage 
of these information/fields by the receiver. Possibly using the same name/term 
(e.g. SRv6 SID Locator Block length) to ease the references between both drafts.

Thanks,
--Bruno

Thanks,
Ketan

From: Lsr  On Behalf Of Chris Bowers
Sent: 27 February 2020 22:46
To: lsr@ietf.org; SPRING WG List 
Cc: Peter Psenak (ppsenak) 
Subject: [Lsr] clarification of locator block and locator node in 
draft-ietf-spring-srv6-network-programming and 
draft-ietf-lsr-isis-srv6-extensions

SPRING and LSR WGs,

I think that we need a much more detailed description of the locator block and 
locator node in either draft-ietf-spring-srv6-network-programming or 
draft-ietf-lsr-isis-srv6-extensions.  See original email below.

Thanks,
Chris

On Thu, Feb 27, 2020 at 11:08 AM Peter Psenak 
mailto:ppse...@cisco.com>> wrote:
Hi Chris,

On 27/02/2020 17:54, Chris Bowers wrote:
> LSR WG,
>
> Section 9 of draft-ietf-lsr-isis-srv6-extensions-05 defines the  SRv6
> SID Structure Sub-Sub-TLV. In particular, it defines encoding for the
> locator block length and the locator node length.  The text refers to
> [I-D.ietf-spring-srv6-network-programming] for the definition of these
> concepts.
>
> As far as I can tell, the only reference to locator block and locator
> node in draft-ietf-spring-srv6-network-programming-10 is section 3.1
> which has the following text:
>
> A locator may be represented as B:N where B is the SRv6 SID block
> (IPv6 subnet allocated for SRv6 SIDs by the operator) and N is the
> identifier of the parent node instantiating the SID..
>
> I think that we need a much more detailed description of the locator
> block and locator node.

sure, but that would be in the
draft-ietf-spring-srv6-network-programming-10, not in
draft-ietf-lsr-isis-srv6-extensions, as these are not a protocol
specific constructs.

thanks,
Peter

>
> Thanks,
>
> Chris
>

_

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] clarification of locator block and locator node in draft-ietf-spring-srv6-network-programming and draft-ietf-lsr-isis-srv6-extensions

[bruno.decraene]

Hi Ketan,

Thanks fort the follow up.
Clarification inline [Bruno]

From: Ketan Talaulikar (ketant) [mailto:ket...@cisco.com]
Sent: Friday, February 28, 2020 11:11 AM
To: DECRAENE Bruno TGI/OLN; Ketan Talaulikar (ketant); Chris Bowers
Cc: lsr@ietf.org; SPRING WG List; draft-ietf-spring-srv6-network-programming; 
Peter Psenak (ppsenak)
Subject: RE: [Lsr] clarification of locator block and locator node in 
draft-ietf-spring-srv6-network-programming and 
draft-ietf-lsr-isis-srv6-extensions

Hi Bruno,

I believe the description and usage of Locator is very well described and 
covered in the net-pgm draft as also the corresponding IGP extensions. Is the 
question is more about the “block” part of it (what is not in the block part is 
in the node part as per the text in the net-pgm draft)?

The “block” is again not a new thing. Please check the following:
Under 
https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26#section-5 
… look for “block”
https://tools.ietf.org/html/rfc8402#section-2 … look under SRGB for SRv6

[Bruno]
To clarify, my question was not specific to “block” but related to the usage, 
by the receiver, of the following piece of information:

  LB Length: SRv6 SID Locator Block length
  LN Length: SRv6 SID Locator Node length
  Fun. Length: SRv6 SID Function length
  Arg. Length: SRv6 SID Arguments length


So perhaps I don’t get Chris’s point and would wait for him to clarify.
[Bruno] I’ll leave this to Chris.

Thanks,
Ketan

From: Lsr  On Behalf Of bruno.decra...@orange.com
Sent: 28 February 2020 14:34
To: Ketan Talaulikar (ketant) ; Chris Bowers 

Cc: lsr@ietf.org; SPRING WG List ; 
draft-ietf-spring-srv6-network-programming 
; Peter Psenak (ppsenak) 

Subject: Re: [Lsr] clarification of locator block and locator node in 
draft-ietf-spring-srv6-network-programming and 
draft-ietf-lsr-isis-srv6-extensions

Hi Ketan,



From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Ketan Talaulikar (ketant)
Sent: Friday, February 28, 2020 6:30 AM

Hi Chris,

I agree with Peter and I would suggest to drop LSR since this is not a protocol 
specific thing.

I believe the text in draft-ietf-spring-srv6-network-programming clears says 
what locator block and locator node are. What more details do you think are 
required?

[Bruno] Speaking as an individual, the draft could possibly clarify the usage 
of these information/fields by the receiver. Possibly using the same name/term 
(e.g. SRv6 SID Locator Block length) to ease the references between both drafts.

Thanks,
--Bruno

Thanks,
Ketan

From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
Chris Bowers
Sent: 27 February 2020 22:46
To: lsr@ietf.org; SPRING WG List 
mailto:spr...@ietf.org>>
Cc: Peter Psenak (ppsenak) mailto:ppse...@cisco.com>>
Subject: [Lsr] clarification of locator block and locator node in 
draft-ietf-spring-srv6-network-programming and 
draft-ietf-lsr-isis-srv6-extensions

SPRING and LSR WGs,

I think that we need a much more detailed description of the locator block and 
locator node in either draft-ietf-spring-srv6-network-programming or 
draft-ietf-lsr-isis-srv6-extensions.  See original email below.

Thanks,
Chris

On Thu, Feb 27, 2020 at 11:08 AM Peter Psenak 
mailto:ppse...@cisco.com>> wrote:
Hi Chris,

On 27/02/2020 17:54, Chris Bowers wrote:
> LSR WG,
>
> Section 9 of draft-ietf-lsr-isis-srv6-extensions-05 defines the  SRv6
> SID Structure Sub-Sub-TLV. In particular, it defines encoding for the
> locator block length and the locator node length.  The text refers to
> [I-D.ietf-spring-srv6-network-programming] for the definition of these
> concepts.
>
> As far as I can tell, the only reference to locator block and locator
> node in draft-ietf-spring-srv6-network-programming-10 is section 3.1
> which has the following text:
>
> A locator may be represented as B:N where B is the SRv6 SID block
> (IPv6 subnet allocated for SRv6 SIDs by the operator) and N is the
> identifier of the parent node instantiating the SID..
>
> I think that we need a much more detailed description of the locator
> block and locator node.

sure, but that would be in the
draft-ietf-spring-srv6-network-programming-10, not in
draft-ietf-lsr-isis-srv6-extensions, as these are not a protocol
specific constructs.

thanks,
Peter

>
> Thanks,
>
> Chris
>

_



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 

Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

[bruno.decraene]

Les,


From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Les Ginsberg (ginsberg)
Sent: Wednesday, February 19, 2020 6:49 PM
To: Robert Raszuk
Cc: lsr@ietf.org
Subject: Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

Robert –

Thanx for your input.

Note that one of the suggestions in 
https://datatracker.ietf.org/doc/draft-ginsberg-lsr-isis-flooding-scale/  is to 
prioritize the reception of SNPs over LSPs so that we are less likely to drop 
ACKs.
It is not clear to me why you think SNP generation would be an issue.
Once a received LSP is processed one of the outputs is to set a per interface 
flag indicating that an ACK (PSNP) needs to be sent (SSN flag). Implementations 
usually implement some small delay so that multiple ACKs can be sent in a 
single PSNP – but I do not see why this should be viewed as a bottleneck.

If your concern is that we need to emphasize the importance of sending timely 
ACKs, I think we could look at text that makes that point.
[Bruno]
So you need a new behavior on the Rx side (Rx with respect to LSP).  This is 
_not_ Tx only with no need for protocol change.
And BTW, this is called a feedback from the Rx to the Tx.

As we change the protocol on the Rx side, we have the opportunity to report 
more information from Rx to the Tx.

--Bruno

   Les


From: Lsr  On Behalf Of Robert Raszuk
Sent: Wednesday, February 19, 2020 1:07 AM
To: Les Ginsberg (ginsberg) 
Cc: lsr@ietf.org
Subject: Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

Hi Les & all,

Watching this discussion I would like to state that IMO going with transmitter 
based rate limiting (I would not call it flow control) is much easier option to 
deploy and operate. It also has no dependency across other side of p2p adj 
which is a very important factor. The only issue here is if generation of 
[P|C]SNPs is fast enough.

Receiver based flow control is simple in flow theory however I have a feeling 
that if we are to go that path we would be much better to actually run ISIS 
flooding over DC-TCP and avoid reinventing the wheel.

Thx,
Robert.

On Wed, Feb 19, 2020 at 3:26 AM Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>> wrote:
Two recent drafts advocate for the use of faster LSP flooding speeds in IS-IS:

https://datatracker.ietf.org/doc/draft-decraene-lsr-isis-flooding-speed/
https://datatracker.ietf.org/doc/draft-ginsberg-lsr-isis-flooding-scale/

There is strong agreement on two key points:

1)Modern networks require much faster flooding speeds than are commonly in use 
today

2)To deploy faster flooding speeds safely some form of flow control is needed

The key point of contention between the two drafts is how flow control should 
be implemented.

https://datatracker.ietf.org/doc/draft-decraene-lsr-isis-flooding-speed/ 
advocates for a receiver based flow control where the receiver advertises in 
hellos the parameters which indicate the rate/burst size which the receiver is 
capable of supporting on the interface. Senders are required to limit the rate 
of LSP transmission on that interface in accordance with the values advertised 
by the receiver.

https://datatracker.ietf.org/doc/draft-ginsberg-lsr-isis-flooding-scale/  
advocates for a transmit based flow control where the transmitter monitors the 
number of unacknowledged LSPs sent on each interface and implements a backoff 
algorithm to slow the rate of sending LSPs based on the length of the per 
interface unacknowledged queue.

While other differences between the two drafts exist, it is fair to say that if 
agreement could be reached on the form of flow control  then it is likely other 
issues could be resolved easily.

This email starts the discussion regarding the flow control issue.



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

_

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] WG Last Call draft-ietf-lsr-isis-srv6-extensions

[bruno.decraene]

Hi authors, WG,



I've re-read the draft. Please find below some minor comments and nits.



Best regards,

--Bruno



Minors:

==

" A node indicates that it has support for SRv6 by advertising a new SRv6 
Capabilities sub-TLV"

I'm not completely certain that "support for SRv6" is perfectly defined. Do you 
have a reference? Otherwise may be "is an SRv6 Segment Endpoint Node" would be 
better.

Cf 
https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26#section-3



---

§4.3

"The Maximum H.Encaps MSD Type specifies the maximum number of SIDs  that can 
be included as part of the "H.Encaps" behavior"



This is not crystal clear to me when the "reduced encapsulation" is used. In 
such case we have:

a) the number of SID included (N)

b) the number of SID included in the SRH (N-1)



Could you clarify which one you are referring to?



I assume that this is "b" given the text:

"If the advertised value is zero then the router can apply H.Encaps only by 
encapsulating the incoming packet in another  IPv6 header without SRH the same 
way IPinIP encapsulation is performed."

But to avoid interop issue, I'd prefer the spec to be non ambiguous. (typically 
by saying "SIDs in a SRH" as indicated in §4.4



---

§4.2

"in  the top SRH in an SRH stack to which the router can apply "PSP" or  USP" 
as defined in [I-D.ietf-spring-srv6-network-programming]  flavors"



[I-D.ietf-spring-srv6-network-programming] does not define (anymore) "SRH 
stack", nor "top SRH". Please remove those two terms.



---

§4.4



"  If the advertised value is zero or no value is advertised

  then it is assumed that the router cannot apply

  "End.DX6" or "End.DT6" behaviors if the extension

  header right underneath the outer IPv6 header is an SRH."



There is no requirement for the SRH to be "right underneath the outer IPv6 
header".

Cf https://tools.ietf.org/html/rfc8200#section-4.1



Please clarify what is meant precisely. E.g.:

a) if there is an SRH

b) if there is a IPv6 routing header

c) if there is  an IPv6 extension header

?

.



Given the wording in §4.2, I would suggest "a". However, the technical question 
remains: are those MSD numbers affected by the presence of another IPv6 
extension header (before the SRH)?



---

OLD: This is to prevent inconsistent forwarding entries on SRv6 capable/SRv6 
incapable routers.





I think the below would be clearer

NEW: This is to prevent inconsistent forwarding entries between SRv6 capable 
and SRv6 incapable routers.





§7.1



"

 Type: 27 (Suggested value to be assigned by IANA)



 Length: variable.



 MTID: Multitopology Identifier as defined in 
[RFC5120].

 Note that the value 0 is legal."



Personally I would find clearer to move the above text (describing the SRv6 
Locator TLV) just after the Figure of the SRv6 Locator TLV.



That would also allow the removal of "Locator entry:" since as a result the 
text and figures for the local entry would also be grouped together.





§7.1

"Loc-Size: 1 octet. Number of bits in the Locator field."



I think that this is the number of bits of the SRv6 Locator, rather than the 
number of bits of the field.



Proposed NEW: Loc-Size: 1 octet. Number of bits in the SRv6 Locator.



"The Locator is encoded in the minimal number of  octets for the given number 
of bits."

Do we want to define the trailing bits? E.g. MUST be sent as zero and ignored 
when received.





§8.1 (idem for §8.2)

I may be missing something...



"All End.X SIDs MUST be a subnet of a Locator with matching topology
   and algorithm which is advertised by the same node in an SRv6 Locator
   TLV. »


OK.

So what's the point of advertising a field 'algorithm' in the SRv6 End.X SID 
sub-TLV? The 128-bits SID allows identifying the Locator, which already 
advertise an algorithm.

Advertising again the algorithm with the End.X SID waste space and is an 
opportunity for inconsistency hence additional error handling 
rules/implementations.





§8.2

"System-ID: 6 octets of IS-IS System-ID of length "ID Length" as defined in 
[ISO10589].
 »



The field seems of fixed length (6 octets) while the encoded System ID seems to 
be of a variable length. If so, wouldn't it be useful to indicate how a System 
ID of a length shorter than 6 octets is encoded? (in most or least significant 
octets?).





§9

A priori the sum of all 4 sizes must be 128 bits. Could you specify the error 
handling when this is not the case? (a choice could be to ignore this 
Sub-Sub-TLV; but given the error handling specified for another error, you seem 
to prefer to ignore the whole parent TLV.



§9

"ISIS SRv6 SID Structure Sub-Sub-TLV MUST NOT appear more than once in
   its parent sub-TLV.  If it appears more than once in its parent TLV,
   the parent TLV MUST be ignored by the 

Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

[bruno.decraene]

Les,


From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Friday, January 24, 2020 5:39 PM
To: DECRAENE Bruno TGI/OLN; lsr@ietf.org
Cc: lsr-...@ietf.org; Christian Hopps; Acee Lindem (acee)
Subject: RE: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

Bruno -

Regarding


§8.2
"System-ID: 6 octets of IS-IS System-ID of length "ID Length" as defined in 
[ISO10589]. »

The field seems of fixed length (6 octets) while the encoded System ID seems to 
be of a variable length. If so, wouldn't it be useful to indicate how a System 
ID of a length shorter than 6 octets is encoded? (in most or least significant 
octets?).


It is well known that - although ISO 10589 supports a system-id length between 
1-8 octets - in practice the length 6 is always used. And of course all nodes 
have to agree to use the same length.
[Bruno] Just to clarify, I was asking for consistency between the length of the 
field ('6 octets') and the lengths of its content ('  "ID Length" as defined in 
[ISO10589] ').

The comparable text from RFC 8667 Section 2.2.2 says:

"Neighbor System-ID:  IS-IS System-ID of length "ID Length" as
   defined in [ISO10589]."

I suggest that the text in this draft be modified to match this - and the ASCII 
art text changes "6 octets" to "ID Length octets" - again matching RFC 8667.

[Bruno] Looks better as this is consistent. I feel that it could be even better 
as I still see two options:

-  a) If the length of the System ID is fixed to 6, I think that this 
needs to be indicated in the draft (rather than "as defined in [ISO10589]" 
which allows for a variable length).

-  b) If the length of the System ID is variable "as defined in 
[ISO10589]", then I don't see how the receiver can know this length and 
successfully parse the sub-TLV, except may be by looking at another field in 
the LSP

Looking at RFC 5305, it seems to define/hard code a length of 6 for the ID, 
which is aligned with option "a" and what is much probably meant in this draft. 
https://tools.ietf.org/html/rfc5305#section-3
(That been said RFC 5306 (i.e. next RFC) , which you co-author, seems to allow 
for a variable length)


Hence I would rather propose  "System-ID: 6 octets of IS-IS System-ID" as per 
option "a". But I'm also fine with option "b" if you want.

--Bruno
I think there is no need to spend time discussing lengths other than 6.
Would you agree?


   Les


From: Lsr  On Behalf Of bruno.decra...@orange.com
Sent: Friday, January 24, 2020 7:25 AM
To: lsr@ietf.org
Cc: lsr-...@ietf.org; Christian Hopps ; Acee Lindem (acee) 

Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions


Hi authors, WG,



I've re-read the draft. Please find below some minor comments and nits.



Best regards,

--Bruno



Minors:

==

" A node indicates that it has support for SRv6 by advertising a new SRv6 
Capabilities sub-TLV"

I'm not completely certain that "support for SRv6" is perfectly defined. Do you 
have a reference? Otherwise may be "is an SRv6 Segment Endpoint Node" would be 
better.

Cf 
https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26#section-3



---

§4.3

"The Maximum H.Encaps MSD Type specifies the maximum number of SIDs  that can 
be included as part of the "H.Encaps" behavior"



This is not crystal clear to me when the "reduced encapsulation" is used. In 
such case we have:

a) the number of SID included (N)

b) the number of SID included in the SRH (N-1)



Could you clarify which one you are referring to?



I assume that this is "b" given the text:

"If the advertised value is zero then the router can apply H.Encaps only by 
encapsulating the incoming packet in another  IPv6 header without SRH the same 
way IPinIP encapsulation is performed."

But to avoid interop issue, I'd prefer the spec to be non ambiguous. (typically 
by saying "SIDs in a SRH" as indicated in §4.4



---

§4.2

"in  the top SRH in an SRH stack to which the router can apply "PSP" or  USP" 
as defined in [I-D.ietf-spring-srv6-network-programming]  flavors"



[I-D.ietf-spring-srv6-network-programming] does not define (anymore) "SRH 
stack", nor "top SRH". Please remove those two terms.



---

§4.4



"  If the advertised value is zero or no value is advertised

  then it is assumed that the router cannot apply

  "End.DX6" or "End.DT6" behaviors if the extension

  header right underneath the outer IPv6 header is an SRH."



There is no requirement for the SRH to be "right underneath the outer IPv6 
header".

Cf https://tools.ietf.org/html/rfc8200#section-4.1



Please clarify what is meant precisely. E.g.:

a) if there is an SRH

b) if there is a IPv6 routing header

c) if there is  an IPv6 extension header

?

.



Given the wording in §4.2, I would suggest "a". However, the technical question 
remains: are those MSD numbers affected by the presence of another IPv6 
extension header (before the SRH)?



---

OLD: This is to prevent inconsistent 

Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

[bruno.decraene]

Hi Peter,

Thank you.
Looks good.

Just one follow up

> > §9
> > 
> > A priori the sum of all 4 sizes must be 128 bits. Could you specify the 
> > error handling when this is not the case? (a choice could be to ignore 
> > this Sub-Sub-TLV; but given the error handling specified for another 
> > error, you seem to prefer to ignore the whole parent TLV.
> 
> ##PP
> the sum may not need to be 128, some fields may be advertised as 0 - 
> e.g. not all SIDs have arguments.

You are correct.
Let me rephrase:

A priori the sum of all 4 sizes must be lower or equal 128 bits.
Could you specify the error handling when this is not the case?
Especially since there seem to be two possible responses:
a) ignore this Sub-Sub-TLV
b) ignore the whole parent TLV (as specified for another error condition)

Thank you
--Bruno

> -Original Message-
> From: Peter Psenak [mailto:ppse...@cisco.com] 
> Sent: Monday, January 27, 2020 1:43 PM
> To: DECRAENE Bruno TGI/OLN; lsr@ietf.org
> Cc: lsr-...@ietf.org; Christian Hopps; Acee Lindem (acee)
> Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions
> 
> Hi Bruno,
> 
> please see inline (##PP):
> 
> On 24/01/2020 16:24, bruno.decra...@orange.com wrote:
> > Hi authors, WG,
> > 
> > I've re-read the draft. Please find below some minor comments and nits.
> > 
> > Best regards,
> > 
> > --Bruno
> > 
> > Minors:
> > 
> > ==
> > 
> > " A node indicates that it has support for SRv6 by advertising a new 
> > SRv6 Capabilities sub-TLV"
> > 
> > I'm not completely certain that "support for SRv6" is perfectly defined. 
> > Do you have a reference? Otherwise may be "is an SRv6 Segment Endpoint 
> > Node" would be better.
> > 
> > Cfhttps://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26#section-3
> 
> ##PP
> I changed to "SR Segment Endpoint Node"
> 
> 
> 
> > 
> > ---
> > 
> > §4.3
> > 
> > "The Maximum H.Encaps MSD Type specifies the maximum number of SIDsthat 
> > can be included as part of the "H.Encaps" behavior"
> > 
> > This is not crystal clear to me when the "reduced encapsulation" is 
> > used. In such case we have:
> > 
> > a) the number of SID included (N)
> > 
> > b) the number of SID included in the SRH (N-1)
> > 
> > Could you clarify which one you are referring to?
> > 
> > I assume that this is "b" given the text:
> > 
> > "If the advertised value is zero then the router can apply H.Encaps only 
> > by encapsulating the incoming packet in anotherIPv6 header without SRH 
> > the same way IPinIP encapsulation is performed."
> > 
> > But to avoid interop issue, I'd prefer the spec to be non ambiguous. 
> > (typically by saying "SIDs in a SRH" as indicated in §4.4
> 
> ##PP
> the Maximum H.Encaps MSD Type specifies the maximum number of segments 
> that a node can use as part of the encapsulation operation, regardless 
> of whether that is H.Encaps or H.Encaps.Red. If the node advertises N it 
> can either do H.Encaps with N SIDs in SRH or do H.Encaps.Red with (N-1) 
> in the SRH +1 in the IPv6 DA.
> 
> 
> > 
> > ---
> > 
> > §4.2
> > 
> > "inthe top SRH in an SRH stack to which the router can apply "PSP" 
> > orUSP" as defined in [I-D.ietf-spring-srv6-network-programming]flavors"
> > 
> > [I-D.ietf-spring-srv6-network-programming] does not define (anymore) 
> > "SRH stack", nor "top SRH". Please remove those two terms.
> 
> > 
> > ##PP
> > Changed to:
> > 
> > "The Maximum End Pop MSD Type specifies the maximum number of SIDs in
> > the SRH to which the router can apply "PSP" or USP" behavior, as defined 
> > in [I-D.ietf-spring-srv6-network-programming] flavors."
> > 
> > > 
> > > ---
> > > 
> > > §4.4
> > > 
> > > "If the advertised value is zero or no value is advertised
> > > 
> > > then it is assumed that the router cannot apply
> > > 
> > > "End.DX6" or "End.DT6" behaviors if the extension
> > > 
> > > header right underneath the outer IPv6 header is an SRH."
> > > 
> > > There is no requirement for the SRH to be "right underneath the outer 
> > > IPv6 header".
> > 
> > ##PP
> > Changed to:
> > 
> > "If the advertised value is zero or no value is advertised
> > then it is assumed that the router cannot apply
> > "End.DX6" or "End.DT6" behaviors if the outer IPv6 header contains an SRH."
> > 
> > 
> > > 
> > > Cfhttps://tools.ietf.org/html/rfc8200#section-4.1
> > > 
> > > Please clarify what is meant precisely. E.g.:
> > > 
> > > a) if there is an SRH
> > > 
> > > b) if there is a IPv6 routing header
> > > 
> > > c) if there isan IPv6 extension header
> > > 
> > > ?
> > > 
> > > 
> > > 
> > > Given the wording in §4.2, I would suggest "a". However, the technical 
> > > question remains: are those MSD numbers affected by the presence of 
> > > another IPv6 extension header (before the SRH)?
> > 
> > ##PP
> > no, the presence of another IPv6 extension header has no impact on the 
> > MSDs we define here.
> > 
> > > 
> > > ---
> > > 
> > > OLD: This is to prevent inconsistent forwarding entries on SRv6 
> > > capable/SRv6 incapable 

Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

[bruno.decraene]

> From: Peter Psenak [mailto:ppse...@cisco.com] 
> 
> Hi Bruno,
> 
> On 28/01/2020 18:05, bruno.decra...@orange.com wrote:
> > Hi Peter,
> > 
> > Thank you.
> > Looks good.
> > 
> > Just one follow up
> > 
> >>> §9
> >>>
> >>> A priori the sum of all 4 sizes must be 128 bits. Could you specify the
> >>> error handling when this is not the case? (a choice could be to ignore
> >>> this Sub-Sub-TLV; but given the error handling specified for another
> >>> error, you seem to prefer to ignore the whole parent TLV.
> >>
> >> ##PP
> >> the sum may not need to be 128, some fields may be advertised as 0 -
> >> e.g. not all SIDs have arguments.
> > 
> > You are correct.
> > Let me rephrase:
> > 
> > A priori the sum of all 4 sizes must be lower or equal 128 bits.
> > Could you specify the error handling when this is not the case?
> > Especially since there seem to be two possible responses:
> > a) ignore this Sub-Sub-TLV
> > b) ignore the whole parent TLV (as specified for another error condition)
> 
> I would go for (b) and ignore the parent sub-TLV.
> Will update accordingly.

Thank you Peter.

--Bruno

> thanks,
> Peter
> 
> 
> 
> > 
> > Thank you
> > --Bruno
> > 
> >> -Original Message-
> >> From: Peter Psenak [mailto:ppse...@cisco.com]
> >> Sent: Monday, January 27, 2020 1:43 PM
> >> To: DECRAENE Bruno TGI/OLN; lsr@ietf.org
> >> Cc: lsr-...@ietf.org; Christian Hopps; Acee Lindem (acee)
> >> Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions
> >>
> >> Hi Bruno,
> >>
> >> please see inline (##PP):
> >>
> >> On 24/01/2020 16:24, bruno.decra...@orange.com wrote:
> >>> Hi authors, WG,
> >>>
> >>> I've re-read the draft. Please find below some minor comments and nits.
> >>>
> >>> Best regards,
> >>>
> >>> --Bruno
> >>>
> >>> Minors:
> >>>
> >>> ==
> >>>
> >>> " A node indicates that it has support for SRv6 by advertising a new
> >>> SRv6 Capabilities sub-TLV"
> >>>
> >>> I'm not completely certain that "support for SRv6" is perfectly defined.
> >>> Do you have a reference? Otherwise may be "is an SRv6 Segment Endpoint
> >>> Node" would be better.
> >>>
> >>> Cfhttps://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26#section-3
> >>
> >> ##PP
> >> I changed to "SR Segment Endpoint Node"
> >>
> >>
> >>
> >>>
> >>> ---
> >>>
> >>> §4.3
> >>>
> >>> "The Maximum H.Encaps MSD Type specifies the maximum number of SIDsthat
> >>> can be included as part of the "H.Encaps" behavior"
> >>>
> >>> This is not crystal clear to me when the "reduced encapsulation" is
> >>> used. In such case we have:
> >>>
> >>> a) the number of SID included (N)
> >>>
> >>> b) the number of SID included in the SRH (N-1)
> >>>
> >>> Could you clarify which one you are referring to?
> >>>
> >>> I assume that this is "b" given the text:
> >>>
> >>> "If the advertised value is zero then the router can apply H.Encaps only
> >>> by encapsulating the incoming packet in anotherIPv6 header without SRH
> >>> the same way IPinIP encapsulation is performed."
> >>>
> >>> But to avoid interop issue, I'd prefer the spec to be non ambiguous.
> >>> (typically by saying "SIDs in a SRH" as indicated in §4.4
> >>
> >> ##PP
> >> the Maximum H.Encaps MSD Type specifies the maximum number of segments
> >> that a node can use as part of the encapsulation operation, regardless
> >> of whether that is H.Encaps or H.Encaps.Red. If the node advertises N it
> >> can either do H.Encaps with N SIDs in SRH or do H.Encaps.Red with (N-1)
> >> in the SRH +1 in the IPv6 DA.
> >>
> >>
> >>>
> >>> ---
> >>>
> >>> §4.2
> >>>
> >>> "inthe top SRH in an SRH stack to which the router can apply "PSP"
> >>> orUSP" as defined in [I-D.ietf-spring-srv6-network-programming]flavors"
> >>>
> >>> [I-D.ietf-spring-srv6-network-programming] does not define (anymore)
> >>> "SRH stack", nor "top SRH". Please remove those two terms.
> >>
> >>>
> >>> ##PP
> >>> Changed to:
> >>>
> >>> "The Maximum End Pop MSD Type specifies the maximum number of SIDs in
> >>> the SRH to which the router can apply "PSP" or USP" behavior, as defined
> >>> in [I-D.ietf-spring-srv6-network-programming] flavors."
> >>>
> 
>  ---
> 
>  §4.4
> 
>  "If the advertised value is zero or no value is advertised
> 
>  then it is assumed that the router cannot apply
> 
>  "End.DX6" or "End.DT6" behaviors if the extension
> 
>  header right underneath the outer IPv6 header is an SRH."
> 
>  There is no requirement for the SRH to be "right underneath the outer
>  IPv6 header".
> >>>
> >>> ##PP
> >>> Changed to:
> >>>
> >>> "If the advertised value is zero or no value is advertised
> >>> then it is assumed that the router cannot apply
> >>> "End.DX6" or "End.DT6" behaviors if the outer IPv6 header contains an 
> >>> SRH."
> >>>
> >>>
> 
>  Cfhttps://tools.ietf.org/html/rfc8200#section-4.1
> 
>  Please clarify what is meant precisely. E.g.:
> 
>  a) if there is an SRH
> 
>  b) if there is a IPv6 routing header

Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

[bruno.decraene]

Chris,

I'm not aware of non-disclosed IPR.

Regards,
--Bruno
-Original Message-
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps
Sent: Wednesday, January 22, 2020 1:15 AM
To: lsr@ietf.org
Cc: lsr-...@ietf.org; Christian Hopps; Acee Lindem (acee)
Subject: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

This begins a 2 week WG Last Call, ending after Feb 4, 2020, for 
draft-ietf-lsr-isis-srv6-extensions

  https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/

Authors please indicate if you aware of any other IPR beyond what is posted:

  https://datatracker.ietf.org/ipr/3796/

Thanks,
Chris & Acee.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

_

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] WG Last Call draft-ietf-lsr-isis-invalid-tlv

[bruno.decraene]

I support publication of the draft.

Improving interoperability is definitely something that I support (1), in 
particular for mission critical protocols.

Thank you to authors & Alvaro for the work and the initiative.

Bruno

(1) Including during error conditions ;-)
 
-Original Message-
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps
Sent: Thursday, January 2, 2020 8:07 PM
To: lsr@ietf.org
Cc: lsr-...@ietf.org; Christian Hopps; Antoni Przygienda
Subject: [Lsr] WG Last Call draft-ietf-lsr-isis-invalid-tlv

This begins a 2 week WG Last Call, ending after Jan 16th, 2020, for 
draft-ietf-lsr-isis-invalid-tlv.

  https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-invalid-tlv/

Tony P (other authors already responded during the adoption poll), please 
indicate your knowledge of any IPR related to this work to the list as well.

Thanks,
Chris & Acee.

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

_

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

[Lsr] New Version Notification for draft-decraene-lsr-isis-flooding-speed-03.txt

[bruno.decraene]

Hi all,

Following many interesting discussions on the mailing list, during IETF 
meetings 105 & 106 and of-list, please find below an updated version. 

Htmlized:   
https://datatracker.ietf.org/doc/html/draft-decraene-lsr-isis-flooding-speed
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-decraene-lsr-isis-flooding-speed-03

Main changes are:
   Flooding Parameters TLV: name changed, advertised in both Hello and SNP 
rather than just Hello, contains sub-TLVs, parameters encoded in 4 octets.
   Terminology: upstream/downstream terms removed, in favor of terms from ISO 
specification (transmitter, receiver); burst-size rename to receive-window.
   Significant editorials changes.
   New section on the faster acknowledgment of LSPs.
   New section on the faster retransmission of lost LSPs.


Comments are welcomed.

Thank you,
Regards,
--Bruno on behalf of all co-authors

-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
Sent: Monday, March 9, 2020 3:11 PM
To: Jayesh J; Tony Li; Chris Bowers; Gunter Van de Velde; DECRAENE Bruno TGI/OLN
Subject: New Version Notification for 
draft-decraene-lsr-isis-flooding-speed-03.txt


A new version of I-D, draft-decraene-lsr-isis-flooding-speed-03.txt
has been successfully submitted by Bruno Decraene and posted to the
IETF repository.

Name:   draft-decraene-lsr-isis-flooding-speed
Revision:   03
Title:  IS-IS Flooding Parameters advertisement
Document date:  2020-03-09
Group:  Individual Submission
Pages:  13
URL:
https://www.ietf.org/internet-drafts/draft-decraene-lsr-isis-flooding-speed-03.txt
Status: 
https://datatracker.ietf.org/doc/draft-decraene-lsr-isis-flooding-speed/
Htmlized:   
https://tools.ietf.org/html/draft-decraene-lsr-isis-flooding-speed-03
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-decraene-lsr-isis-flooding-speed
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-decraene-lsr-isis-flooding-speed-03

Abstract:
   This document proposes a mechanism that can be used to increase the
   speed at which link state information is exchanged between two
   routers when multiple LSPs need to be flooded, such as in case of a
   node failure.  It also reduces the likelihood of overloading the
   router receiving the LSPs.  This document defines a new TLV to be
   advertised in SNP and or Hello messages.  This TLV may carry a set of
   parameters indicating the performance capacity to receive LSPs: the
   number of LSPs which can the received back to back, the minimum delay
   between further two consecutive LSPs and the minimum delay before
   retransmission of an LSP.


  


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



_

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] Flow Control Discussion for IS-IS Flooding Speed

[bruno.decraene]

With regards to punting to TCP, I think that TCP (stacks) enforce packet 
ordering.
i.e. if you receive packets 1, 3,4, …,N, then you can only use packet 1 until 
you receive packet 2. In the meantime, you cannot use the (N-2) packets that 
you did received.
That seems like a regression for IS-IS which doesn’t requiring LSPs ordering. 
(vs BGP).

Also, from what I’ve been told from BGP implementers, TCP is not magic and 
can’t be treated as a black box (if you want scale/performance).

1 cent
--Bruno

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Tony Przygienda
Sent: Tuesday, March 10, 2020 4:23 PM
To: Christian Hopps
Cc: lsr@ietf.org; tony...@tony.li; Tony Li; Peter Psenak (ppsenak)
Subject: Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

Hey Christian, MaxTX is not that hard to derive since it's basically limited by 
the local system and its CPU/prioritization/queing architecture.

For the rest of your email, in short, you have my observations in the previous 
email what I think is useful and can be done ... BTW, timestamps are useless 
unless you synchronize clocks and with all the queing that ISIS does through 
the system normally to get stuff done it is very hard to account for delays 
between packet being generated (or rx'ed on interface) and last queue it's 
pulled from usually. More musings below backed by good amount of work & 
empirical experience ;-)

If we try to punt to TCP (like BGP did in its time which I argued wasn't the 
optimal idea that has bitten us back endless amount of times for the shortcut 
it was ;-) then de facto, no real heavy duty IP box is using stock TCP stack, 
at least in the scope of experience I have across bunch of leading vendors. If 
you worked on mod'ing TCP for convergence speed with BGP and cute little things 
like GR/NSR you will know the practical problems and also why stock TCP is 
actually fairly underwhelming when it comes to push large amounts of control 
data around (mod' distro, mod rusty 2c, mod etc but that's my data)..

And agreed, control theory is a wonderful thing and transfer windowing 
protocols etc are long research if you know where to look and lots of the stuff 
is e.g. present in TCP, QUIC or https://tools.ietf.org/html/rfc4340 and so on. 
All of them are quite a lot of stuff to put into ISIS/link-state and mostly do 
not do precisely what we need or precondition things we can't afford under 
heavy load (very fast, non slip timers which are absolutely non trivial if 
you're not in kernel). On top of that you'd need to drag 2 protocol transports 
around now with old ISIS flooding with RE-TX and and the new thing that should 
be doing the stuff by itself (and negotiate transport on top and so on). To 
give you a rought idea DDCP which is probably smallest is ~ 10KLOC of C in user 
space in BETA and zero docs ;-) I looked @ the practically existing stuff 2+ 
years ago in detail when doing RIFT ;-) and with all what I practically found I 
ended up carving out the pieces we need for fast flooding without introducing 
fast-acks which IMO would be a non-starter for high scale link-state or rather, 
if we really want that, the loop closes and we should go practically speaking 
to TCP (or 4340 which looked like a better choice to me but  just like e.g. 
Open-R did and be done with it) or wait for the mythical QUIC 
all-singing-all-dancing public domain implementation maybe. For many reasons I 
do not think it would be a particularly good development entangling a control 
protocol again with a user transport in the whole ball of yarn that IP is 
already.

kind of all I had to say, next thing ;-)

--- tony

On Tue, Mar 10, 2020 at 7:48 AM Christian Hopps 
mailto:cho...@chopps.org>> wrote:

Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>> writes:

> Tony –
>
> If you have a suggestion for Tx back-off algorithm please feel free to share.
> The proposal in the draft is just a suggestion.
> As this is a local matter there is no interoperability issue, but certainly 
> documenting a better algorithm is worthwhile.

[as WG member]

The main thing I'm afraid of is we're just making up some new overly simple 
congestion control algorithm (are there CC experts reviewing this?); maybe 
simulate it a few ways, deploy it, and have it work poorly or make things 
worse. In any case, damn the torpedos...

In this current algorithm how does MaxLSPTx get set? What happens if MaxLSPTx 
is too high? If its too low we could be missing a much faster convergence 
capability.

What if we had more quality information from the receiver, could we do a better 
job here? Maybe faster ACKs, or could we include a timestamp somehow to 
calculate RTT? This is the type of data that is used by existing CC algorithms 
(https://tools.ietf.org/html/rfc4342, https://tools.ietf.org/html/rfc5348). Of 
course going through these documents (which I've had to do for in another area) 
can start making one think "Punt to TCP" :)

What would be nice, if we're going to attempt 

Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

[bruno.decraene]

Les,

Thank you for this first answer. This is inline with my understanding of the 
behavior.
I wish some of the behaviors and values (e.g. queue size, rate limiting) could 
be shared. At minimum a range of typical values for platform which are not end 
of sale. I don't think this is secret. Actually, this is something that network 
provider would need in order to configure the right value for the parameters 
which are implemented on the platforms of your employer, so this should be on 
the public documentation of your employer. One could also think that you may be 
proud of your implementations and eager to show that it performs well.

Waiting some more details, as per you below email, the IS-IS receiver does have 
a queue, sometimes dedicated to IS-IS, but in general relatively dedicated to 
very important and time sensitive traffic to the control plane. Details are 
indeed implementation specific. But in general, this queue is designed to 
protect the IS-IS traffic from lower priority traffic, e.g. bursty BGP. So can 
we assume that the receiver have (or at least may have) such a queue, and work 
with this?

--Bruno

From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Friday, April 17, 2020 10:41 PM
To: DECRAENE Bruno TGI/OLN
Cc: lsr@ietf.org
Subject: RE: Flow Control Discussion for IS-IS Flooding Speed

Bruno -

Returning to this old thread...

The following is a generic description of how receive path for IS-IS PDUs 
functions today - based on examination of implementations on a variety of 
platforms from my employer. It is, for obvious reasons,  generic and 
intentionally omits any discussion of implementation details.
But it is hopefully detailed enough to illustrate some of the challenges in 
regards to providing real-time  accurate feedback to the control plane that 
could be used by a receiver based flow control mechanism.

Stage 1: Input Policing

As a first step, a policer operates at ingress to rate limit the number of 
packets which will be punted for local processing. This typically operates in 
an interface independent manner - limiting the total number of packets per 
second across all interfaces.
The policer may rate limit different classes of packets or simply limit all 
types of packets. A given platform may apply a limit specific to IS-IS PDUs or 
apply a limit to a class of packets (e.g., OSPF+BGP+IS-IS combined).

Stage 2: Punt Queue Shaping

Received packets are then placed in a queue for eventual transfer to the 
control plane. The number of queues varies. In some cases a single queue for 
all packet types is used. In other cases packets are placed on different queues 
based on packet classes.
Each queue is typically bounded to a maximum number of packets. As the queue 
usage approaches a limit, shaping policies are applied to prioritize certain 
packet types over others.
An upper limit specific to IS-IS packets may be employed - or a limit may be 
applied to a larger class of packet types of which IS-IS is only one of the 
packet types in the class.

Stage 3: Transfer to control Plane

Packets are then transferred to the control plane. Control plane input queues 
may map 1-1 with the data plane queues or map many to 1.
If the incoming packets are encapsulated (for example GRE) they may be 
transferred to a media specific control plane queue to process the 
encapsulation header. In some cases encapsulation may be processed in the data 
plane prior to transfer to the control plane.

Stage 4: Transfer to IS-IS

Packets are then transferred to a queue which is read directly by IS-IS. In the 
event there are multiple IS-IS instances, implementations may choose to have a 
shared queue which drives the execution of all instances or have instance 
specific queues filtered based on incoming interface.

A single queue is typically used for all interfaces and all IS-IS packet types. 
Subsequent processing may requeue packets based on packet type e.g., separating 
processing of hellos from processing of LSPs/SNPs.

*

A receiver based flow control mechanism which attempts to make dynamic 
adjustments needs to obtain real-time feedback from one or more of the above 
stages. Monitoring the state of the input queue to IS-IS is easy to do, but 
would not account for drops at previous stages.
Obtaining feedback from earlier stages requires real-time updates from data 
plane to IS-IS in the control plane. This is much more challenging. 
Idiosyncrasies of platforms will have a significant impact on how to 
meaningfully interpret and use the data. How to integrate data from the various 
stages - especially when the numbers are not specific to IS-IS packets - is not 
intuitive.

https://tools.ietf.org/html/draft-decraene-lsr-isis-flooding-speed-03 provides 
no guidance on how information from the dataplane could be used.
As an alternative, it suggests that static parameters derived from offline 
tests could be advertised. But static parameters would necessarily have to be 

Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

[bruno.decraene]

Les,

After nearly 2 months, can we expect an answer from your side?

More specifically, the below question

[Bruno] _Assuming_ that the parameters are static, the parameters proposed in 
draft-decraene-lsr-isis-flooding-speed are the same as the one implemented 
(configured) on multiple implementations, including the one from your employer.
Now do you believe that those parameters can be determined?

§  If yes, how do you do _today_ on your implementation? (this seems to 
contradict your statement that you have no way to figure out how to find the 
right value)

§  If no, why did you implement those parameters, and ask network operator to 
configure them?


Thank you,
--Bruno

From: DECRAENE Bruno TGI/OLN
Sent: Wednesday, February 26, 2020 8:03 PM
To: 'Les Ginsberg (ginsberg)'
Cc: lsr@ietf.org
Subject: RE: Flow Control Discussion for IS-IS Flooding Speed

Les,

Please see inline[Bruno]

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Les Ginsberg (ginsberg)
Sent: Wednesday, February 19, 2020 3:32 AM
To: lsr@ietf.org
Subject: Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

Base protocol operation of the Update process tracks the flooding of
LSPs/interface and guarantees timer-based retransmission on P2P interfaces
until an acknowledgment is received.

Using this base protocol mechanism in combination with exponential backoff of 
the
retransmission timer provides flow control in the event of temporary overload
of the receiver.

This mechanism works without protocol extensions, is dynamic, operates
independent of the reason for delayed acknowledgment (dropped packets, CPU
overload), and does not require additional signaling during the overloaded
period.

This is consistent with the recommendations in RFC 4222 (OSPF).

Receiver-based flow control (as proposed in 
https://datatracker.ietf.org/doc/draft-decraene-lsr-isis-flooding-speed/ )
requires protocol extensions and introduces additional signaling during
periods of high load. The asserted reason for this is to optimize throughput -
but there is no evidence that it will achieve this goal.

Mention has been made to TCP-like flow control mechanisms as a model - which
are indeed receiver based. However, there are significant differences between
TCP sessions and IGP flooding.

TCP consists of a single session between two endpoints. Resources
(primarily buffer space) for this session are typically allocated in the
control plane and current usage is easily measurable..

IGP flooding is point-to-multi-point, resources to support IGP flooding
involve both control plane queues and dataplane queues, both of which are
typically not per interface - nor even dedicated to a particular protocol
instance. What input is required to optimize receiver-based flow control is not 
fully specified.

https://datatracker.ietf.org/doc/draft-decraene-lsr-isis-flooding-speed/ 
suggests (Section 5) that the values
to be advertised:

"use a formula based on an off line tests of
   the overall LSPDU processing speed for a particular set of hardware
   and the number of interfaces configured for IS-IS"

implying that the advertised value is intentionally not dynamic. As such,
it could just as easily be configured on the transmit side and not require
additional signaling. As a static value, it would necessarily be somewhat
conservative as it has to account for the worst case under the current
configuration - which means it needs to consider concurrent use of the CPU
and dataplane by all protocols/features which are enabled on a router - not all 
of whose
use is likely to be synchronized with peak IS-IS flooding load.
[Bruno] _Assuming_ that the parameters are static, those parameters

o   are the same as the one implemented (configured) on multiple 
implementations, including the one from your employer. Now do you believe that 
those parameters can be determined?

§  If yes, how do you do _today_ on your implementation? (this seems to 
contradict your statement that you have no way to figure out how to find the 
right value)

§  If no, why did you implement those parameters, and ask network operator to 
configure them?

§  There is also the option to reply: I don't know but don't care as I leave 
the issue to the network operator.

o   can still provide some form of dynamicity, by using the PSNP as dynamic 
acknowledgement.

o   are really dependent on the receiver, not the sender.

§  the sender will never overload itself.

§  The receiver has more information,  knowing its processing power (low end, 
high end, 80s, 20s (currently we are stuck with 20 years old value assuming the 
worst possible receiver (and worst there were, including with packet processing 
partly done in the control plane processor)), its expected IS-IS load 
(#neighbors), its preference for bursty LSP reception (high delay between IS-IS 
CPU allocation cycles, memory not an issue up to x kilo-octet...), its expected 
control plane load if IS-IS traffic has not higher priority over other control 

Re: [Lsr] problem joining interim [Re: A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02]

[bruno.decraene]

Chris, 

Please see inline.


> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps
> Sent: Friday, April 3, 2020 12:00 AM
> To: Robert Raszuk
> 
> 
> 
> > On Apr 2, 2020, at 5:17 PM, Robert Raszuk  wrote:
> > 
> > Many thx,
> > R.
> > 
> > PS. As we are talking LSR here it is strange that joining virtual LSR 
> > meeting is not for everyone. I was waiting and tried three times today for 
> > host approval to join which was not granted. 
> > 
> 
> I am very sorry to hear this! We had 64 participants, at least at one point 
> that I saw. I set the meeting up, and I don't believe there is any way to 
> exclude anyone in particular, I certainly would never have chosen to do that.
> 
> However, Webex has a password requirement when setting up meetings (I guess, 
> I tried to not have one, it wouldn't let me) which we included in all the 
> details wherever the details were posted, it was "linkstate".
> 
> I did notice an email, from webex, during the meeting about a request from 
> Bruno to join as guest, but he was in the participant list when I then 
> checked.
> 

So may be my experience may help for next time(s). See below.

An email from the IESG secretary was sent on 2020-03-19, saying "Information 
about remote participation: https://ietf.webex.com/meet/lsr "
Hence I used that URL.
On this webex, the meeting did not start on time so I've waited for some time. 
Then 10-15 minutes past the start, I decided to 'notify the host', but never 
got accepted on the webex.
At that point I assumed a technical issue with webex and monitored the mailing 
list, but no one was complaining, which is not inline with typical IETF 
reaction ;-) .
So I assumed the error was only on my side and I searched for more emails and 
found one from Chris (2020-03-31) saying that the URL was 
https://ietf.webex.com/ietf/j.php?MTID=mbef20efa9e66c7e97f9d6b18ea84eca8 
And this one worked fine.
My guess is that the 'interim' webex did not use the 'lsr' webex. Also the 
'official' notification from the IESG secretary with the incorrect webex URL 
did not helped.

--Bruno
 
> I didn't receive any other emails like that (and FWIW I had 5 windows over 2 
> monitors going at once trying to manage all this, so noticing the 1 email was 
> lucky).
> 
> Did it let you skip entering a password (or did it not offer the option in 
> the first place)?
> 
> It would be good to figure this out before the next interim.
>
> Thanks,
> Chris.
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

_

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] Flow Control Discussion for IS-IS Flooding Speed

[bruno.decraene]

Ø  ISIS flooding churn (and room for optimization) becomes a problem when node 
boots up (IMHO this is not a problem) and when node fails while having many 
neighbors attached. Yes maybe second case could be improved but well designed 
and operated network should have pre-programmed bypass paths against such cases 
so IMO stressing IGP to "converge" faster while great in principle may not be 
really needed in practice.


I don’t think that FRR is a replacement for “fast” (I’d rather say adequate) 
IGP convergence & flooding.

For multiple reasons such as:

-  Multiple ‘things’ depends on the IGP, such as BGP best path 
selection, CSPF/TE/PCE computations, FRR computations

-  Slow flooding increase the likelihood of multiple IGP SPF 
computations which is harmful for other computations which are typically 
heavier and manifolds (cf above)

-  Multiple IGP SPF computations also create multiple transient 
forwarding loops. There are some techniques to remove forwarding loops but this 
is still an advanced topic and some implementations do not handle consecutives 
IGP SPF (with ‘overlapping’ convergences and combined distributed forwarding 
loops)

-  For FRR, you mostly need to pre-decide/configure whether you want to 
protect link or node failures. Tradeoff are involved and given probability of 
events, link protection is usually enabled (hence not node protection)

-  …

Also, given the current “state of the art”, there is no stressing involved. 
Really. Using TCP, my 200€ mobile running on battery and over 
wifi+ADSL+Internet can achieve better communication throughput than a n*100k€ 
high end IS-IS router.
I think many persons agree that IS-IS could do better in term of flooding. 
(possibly not as good as a brand new approach, but incremental improvement also 
have some benefits). Eventually, we don’t need everyone to agree on this.



Ø  PS. Does anyone have a pointer to any real data showing that performance of 
real life WAN ISIS deployments is bad ?

In some of our ASes, we do monitor IS-IS by listening to and recording flooded 
LSPs. I can’t share any data.
Next question could be what is “good enough”. I guess this may depend on the 
size of your network, its topology, and your requirements.

We also ran tests in labs. I may share some results during my presentation. (no 
names, possibly no KPI, but some high level outcomes).

Regards,
Bruno


From: Robert Raszuk [mailto:rob...@raszuk.net]
Sent: Friday, April 24, 2020 12:42 PM
To: DECRAENE Bruno TGI/OLN
Cc: Tony Przygienda; Les Ginsberg (ginsberg); lsr@ietf.org
Subject: Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

Hi Bruno  & all,

[Bruno] On my side, I’ll try once and I think the LSR WG should also try to 
improve IS-IS performance. May be if we want to move, we should first release 
the brakes.

Well from my observations releasing the breaks means increasing the risks.

Take BGP - breaks are off and see what happens :)

My personal observation is that ISIS implementations across vendors are just 
fine for vast majority of deployments today. That actually also includes vast 
majority of compute clusters as they consists of max 10s of racks.

Of course there are larger clusters with 1000+ or 10K and above network 
elements itself and x 20 L3 computes, but is there really a need to stretch 
protocol to accommodate those ? Those usually run BGP anyway. And also there is 
DV+LS hybrid too now.

ISIS flooding churn (and room for optimization) becomes a problem when node 
boots up (IMHO this is not a problem) and when node fails while having many 
neighbors attached. Yes maybe second case could be improved but well designed 
and operated network should have pre-programmed bypass paths against such cases 
so IMO stressing IGP to "converge" faster while great in principle may not be 
really needed in practice.

Last I am worried that when IETF defines changes to core protocol behaviour the 
quality of the implementations of those changes may really differ across 
vendors overall resulting in much worse performance and stability as compared 
to where we are today.

I am just not sure if possible gains for few deployments are greater then risk 
for 1000s of today's deployments. Maybe one size does not fit all and for 
massive scale ISIS we should define a notion of "ISIS-DC-PLUGIN" which can be 
optionally in run time added when/if needed. If that requires protocol changes 
to accommodate such dynamic plugins - that work should take place.

Many thx,
R.

PS. Does anyone have a pointer to any real data showing that performance of 
real life WAN ISIS deployments is bad ?


On Fri, Apr 24, 2020 at 11:26 AM 
mailto:bruno.decra...@orange.com>> wrote:
Tony

From: Tony Przygienda [mailto:tonysi...@gmail.com]
Sent: Thursday, April 23, 2020 7:29 PM
To: DECRAENE Bruno TGI/OLN
Cc: lsr@ietf.org; Les Ginsberg (ginsberg)
Subject: Re: [Lsr] Flow Control Discussion for 

Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

[bruno.decraene]

Tony

From: Tony Przygienda [mailto:tonysi...@gmail.com]
Sent: Thursday, April 23, 2020 7:29 PM
To: DECRAENE Bruno TGI/OLN
Cc: lsr@ietf.org; Les Ginsberg (ginsberg)
Subject: Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

I was refering to RFC4960. Bruno, for all practical purposes I think that seems 
to go down the path of trying to reinvent RFC4960 (or ultimately use it).
[Bruno] I don’t think that SCTP (RC4960) is a better fit than TCP. Many more 
features and options than TCP, way more than needed given existing IS-IS 
flooding mechanism. Much less implementations experience and improvement than 
TCP.
Or, changing the packet formats heavily to incorporate all the control loop 
data you need to the point you have a different control channel along those 
lines since you'll find most of the problems RFC4960 is describing (minus stuff 
like multiple paths).
[Bruno] Really, adding one sub-TLV in IS-IS is not “changing the packet formats 
heavily”.
Nothing wrong with that but it's ambitious on a 30 years old anitque artefact 
we're nursing forward here ;-)
[Bruno] I’m perfectly fine with revolution approaches. I think that we can also 
provide incremental improvement to IS-IS.
As entertaining footnote, I saw in last 20 years at least 3 attempts to allow 
multiple TCP sessions in BGP between peers to speed/prioritize things up. All 
failed, after the first one I helped to push I smarted up ;-)
 [Bruno] On my side, I’ll try once and I think the LSR WG should also try to 
improve IS-IS performance. May be if we want to move, we should first release 
the brakes. I’m seen some progress, e.g., from “there is no need to improve 
flooding” to “we all agree to improve flooding”, or from “Network operator just 
need to configure existing CLI” to “We agree that we need something more 
automated/dynamic”. But this has been very slow progress over a year.

--Bruno

As another footnote: I looked @ all the stuff in RIFT (tcp, quic, 4960, more 
ephemeral stuff). I ended up adding to rift bunch very rudimentary things and 
do roughly what Les/Peter/Acee started to write (modulo algorith I contributed 
and bunch things that would be helpful but we can't fit into existing packet 
format). This was as much decision as to "what's available & well debugged" as 
well as "does it meet requirements" as "how complex is that vs. rtx in flooding 
architecture  we have today + some feedback". Not on powerpoint, in real 
production code ;-) rift draft shows you the outcome of that as IMO best 
trade-off to achieve high flooding speeds ;-)

my 2c

-- tony

On Thu, Apr 23, 2020 at 10:15 AM 
mailto:bruno.decra...@orange.com>> wrote:
Tony,
Thanks for engaging.
Please inline [Bruno2]



From: Tony Przygienda [mailto:tonysi...@gmail.com]
Sent: Wednesday, April 22, 2020 9:25 PM
To: DECRAENE Bruno TGI/OLN
Cc: lsr@ietf.org; Les Ginsberg (ginsberg)
Subject: Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed



On Wed, Apr 22, 2020 at 11:03 AM 
mailto:bruno.decra...@orange.com>> wrote:
Tony, all,

Thanks Tony for the technical and constructive feedback.
Please inline [Bruno]

From: Tony Przygienda [mailto:tonysi...@gmail.com]
Sent: Wednesday, April 22, 2020 1:19 AM
To: Les Ginsberg (ginsberg)
Cc: DECRAENE Bruno TGI/OLN; lsr@ietf.org
Subject: Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

neither am I aware of anything like this (i.e. per platform/product flooding 
rate constants) in any major vendor stack for whatever that's worth. It's 
simply unmaintanable, point. All major vendors have extensive product lines 
over so many changing hardware configuration/setups it is simply not viable to 
attempt precise measurements (and even then, user changing config can throw the 
stuff off in a millisecond). There may have been here and there per deployment 
scenario some "recommended config" (not something I immediately recall either) 
but that means very fixed configuration of things & how they go into networks 
and even then I'm not aware of anyone having had a "precise model of the chain 
in the box". yes, probes to measure lots and lots of stuff in the boxes exist 
but again, those are chip/linecard/backplane/chassis/routing engine specific 
and mostly used in complex test/peformance scenarios and not to derive some 
kind of equations that can predict anything much ...
[Bruno] Good points.
Yet, one of the information that we propose to advertise by the LSP receiver to 
the LSP sender is the Receive Window.

-  This is a very common parameter and algorithm. Nothing fancy nor 
reinvented. In particular it’s a parameter used by TCP.

-  I would argue that TCP implementations also run on a variety of 
hardware and systems, must wider range than IS-IS platform. And those TCP 
implementations on all those platform manage to advertise this parameter (TCP 
window)

-  I fail to understand that when some WG 

Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

[bruno.decraene]

Peter,
 
> From: Peter Psenak [mailto:ppse...@cisco.com] 
> 
> Bruno,
> 
> On 22/04/2020 20:04, bruno.decra...@orange.com wrote:
> > Les,
> > 
> > Pleasesee inline
> > 
> > *From:*Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
> > *Sent:* Tuesday, April 21, 2020 11:48 PM
> > *To:* DECRAENE Bruno TGI/OLN
> > *Cc:* lsr@ietf.org
> > *Subject:* RE: Flow Control Discussion for IS-IS Flooding Speed
> > 
> > Bruno –
> > 
> > You have made an assumption that historically vendors have tuned LSP 
> > transmission rates to a platform specific value.
> > 
> > [Bruno] I don’t think so. What makes you think so?
> > 
> > In all cases, that is not my assumption, and for multiple reasons.
> > 
> > That certainly is not true in the case of my employer (happy to hear 
> > what other vendors have been doing for the past 20 years).
> > 
> > The default value is based on minimumBroadcastLSPTransmissionInterval 
> > specified in ISO10589.
> > 
> > A knob is available to allow tuning (faster or slower) in a given 
> > deployment – though in my experience this knob is rarely used.
> > 
> > *//*[Bruno] I would agree on both. More interestingly is the why: why 
> > aren’t those existing sending parameters tuned, while we agree that 
> > default configuration are suboptimal?
> > 
> > My take is that:
> > 
> > -We don’t want to overload the receiver and create loss of LSP (as this 
> > will delay the LSDB synchronization and decrease the goodput). Hence 
> > this (the parameters) is receiver dependent (e.g., platform type, number 
> > of IGP adjacencies, …).
> > 
> > -We don’t know which value to configure : difficult for the network 
> > operator to evaluate without a significant knowledge of the receiver 
> > implementation (in particular QoS parameters for incoming LSP), vendors 
> > are not really proposing value or guidance, especially since the sending 
> > behavior is not standardized and slightly different between vendors. So 
> > everyone stay safe with default 20 years old values.
> > 
> > We already discuss in 
> > https://tools.ietf.org/html/draft-ginsberg-lsr-isis-flooding-scale-02#section-2
> >  
> > that this common interpretation isn’t the most appropriate, but 
> > historically the concern has been to avoid flooding too fast – not to 
> > optimize flooding speed.
> > 
> > Obviously, we are revisiting that approach and saying it needs to change 
> > – which is something I think we have consensus on.
> > 
> > I have provided a description in my recent response as to why it is 
> > difficult to derive an optimal value on a per platform basis. You may 
> > disagree – but please do not claim that we actually have been doing this 
> > for years. We haven’t been.
> > 
> > *//*[Bruno] I’m not sure how to rephrase my below email so that we could 
> > understand each other, have an answer from your side (I mean employer 
> > side), and progress.
> > 
> > More succinctly: How do network operator correctly configure the 
> > flooding parameters value on the implementation of your employer? In 
> > particular given the variety of conditions on the LSP receiver side.
> 
> the answer is test and see which value fits best in your specific 
> environment.

I don't think that's good enough, or even feasible given the very diverse set 
of platforms and environments in large networks, and/or the availability of 
human resources in smaller networks.
Since Les is reporting that virtually nobody is changing the default value 
-although we now all agree that they are suboptimal- I think that this is an 
indication that this strategy is not working.
That's why I brought this to the LSR WG.

We need the IS-IS protocol to work adequately without requiring constant or 
personalized tuning from the network operator. Coming back to TCP, general 
user/terminals are not been asked to run test per terminal and per 
destination/server. It just work relatively adequately.
 
> One reason to have some sort of feedback mechanism (being it tx or rx 
> based) is to avoid the need to tune today's static parameters and flood 
> as fast as the receiver is able to consume and slow down if the receiver 
> is not able to cope with the rate we flood.

+1
 
Thanks,
Bruno

> thanks,
> Peter
> 
> 
> 
> 
> 
> 
> > 
> > --Bruno
> > 
> >Les
> > 
> > *From:*bruno.decra...@orange.com 
> > *Sent:* Monday, April 20, 2020 4:47 AM
> > *To:* Les Ginsberg (ginsberg) 
> > *Cc:* lsr@ietf.org
> > *Subject:* RE: Flow Control Discussion for IS-IS Flooding Speed
> > 
> > Les,
> > 
> > After nearly 2 months, can we expect an answer from your side?
> > 
> > More specifically, the below question
> > 
> > [Bruno] _Assuming_ that the parameters are static, the parameters 
> > proposed in draft-decraene-lsr-isis-flooding-speed are the same as the 
> > one implemented (configured) on multiple implementations, including the 
> > one from your employer.
> > 
> > Now do you believe that those parameters can be determined?
> > 
> > §  If yes, how do you do _today_ on your 

Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

[bruno.decraene]

Tony,
Thanks for engaging.
Please inline [Bruno2]



From: Tony Przygienda [mailto:tonysi...@gmail.com]
Sent: Wednesday, April 22, 2020 9:25 PM
To: DECRAENE Bruno TGI/OLN
Cc: lsr@ietf.org; Les Ginsberg (ginsberg)
Subject: Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed



On Wed, Apr 22, 2020 at 11:03 AM 
mailto:bruno.decra...@orange.com>> wrote:
Tony, all,

Thanks Tony for the technical and constructive feedback.
Please inline [Bruno]

From: Tony Przygienda [mailto:tonysi...@gmail.com]
Sent: Wednesday, April 22, 2020 1:19 AM
To: Les Ginsberg (ginsberg)
Cc: DECRAENE Bruno TGI/OLN; lsr@ietf.org
Subject: Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

neither am I aware of anything like this (i.e. per platform/product flooding 
rate constants) in any major vendor stack for whatever that's worth. It's 
simply unmaintanable, point. All major vendors have extensive product lines 
over so many changing hardware configuration/setups it is simply not viable to 
attempt precise measurements (and even then, user changing config can throw the 
stuff off in a millisecond). There may have been here and there per deployment 
scenario some "recommended config" (not something I immediately recall either) 
but that means very fixed configuration of things & how they go into networks 
and even then I'm not aware of anyone having had a "precise model of the chain 
in the box". yes, probes to measure lots and lots of stuff in the boxes exist 
but again, those are chip/linecard/backplane/chassis/routing engine specific 
and mostly used in complex test/peformance scenarios and not to derive some 
kind of equations that can predict anything much ...
[Bruno] Good points.
Yet, one of the information that we propose to advertise by the LSP receiver to 
the LSP sender is the Receive Window.

-  This is a very common parameter and algorithm. Nothing fancy nor 
reinvented. In particular it’s a parameter used by TCP.

-  I would argue that TCP implementations also run on a variety of 
hardware and systems, must wider range than IS-IS platform. And those TCP 
implementations on all those platform manage to advertise this parameter (TCP 
window)

-  I fail to understand that when some WG contributors proposed the use 
of TCP, nobody said that determining and advertising a Receive Window would be 
an issue, difficult or even impossible. But when we propose to advertise a 
Receive Window in an IS-IS TLV, this becomes difficult or even impossible for 
some platforms. Can anyone help me understand the technical difference?


Bruno, I was waiting for that ;-)
[Bruno2] Good ;-)

Discounted for the fact that I'm not a major TCP expert: TCP is a very 
different beast. it has a 100-200msec fast timer & 500msec slow (which have to 
be quite accurate, it's really one timer for all connections + mbuf and other 
magic) and it sends a _lot_ of packets back and forth with window size 
indications so the negotiation can happen very quickly.  Also, TCP can detect 
losses based on sequence number received contrary to routing protocols (that's 
one of the things we added in RIFT BTW) and it can retransmit quickly when it 
sees a "hole". Contrary to that in ISIS ACKs may or may not come, they may be 
bundled, hellos may or may not come and we can't retransmit stuff on 100msec 
timers either. It's an utterly different transport channel.
[Bruno2] I would distinguish two things, which I think we have done in 
https://tools.ietf.org/html/draft-decraene-lsr-isis-flooding-speed-03

-  How fast you can adapt the sending rate. This seems mostly dependent 
on the speed of the feedback loop, rather than the format of message. E.g. In 
IS-IS the receiver can give a feedback more or less quickly (e.g. depending on 
how fast/bundled it sends the PSNP). In theory, I don’t see a major different. 
From an in implementation standpoint, I’m guessing that the difference is 
probably bigger (e.g. TCP is probably lower level/closer to the 
system/hardware, than IS-IS which is more user space and possibly Platform 
Independent in some organizations))

-  How fast you can detect packet loss. I agree that TCP & IS-IS are 
very different on this. We have proposed to improve this by allowing the 
receiver to advertise to the sender how fast it will ack the LSP. Currently the 
timer/behavior is known to receiver but no to the sender. Hence the sender 
needs to assume the wort case (ISO default).

In more abstract terms, TCP is a sliding N-window protocol (where N is adjusted 
all the time & losses can be efficiently detected) whereas LSR flooding is not 
a windowing protocol (or rather LSDB-size window protocol with selective 
retransmission but no detection of loss [or only very slow based on lack of ACK 
& CSNPs]). Disadvantage of something like TCP (I think I sent out the RFC with 
UDP control protocol work to make it more TCP like)
[Bruno2]  If you are referring to 

[Lsr] Research acitivity on IS-IS flooding

[bruno.decraene]

Hi all,

Following the meeting today, and the first results with existing algorithm, it 
would a priori be interesting to have simulations or implementations tests 
results on the proposed algorithms.

This email is a call to for info / contribution on this.

-  Do you know research team(s) which would have the required 
knowledge/capability?

-  Would you be interested in contributing (simulation or 
implementation or testing)?

-  Are you aware of open source IS-IS implementation(s) that could be 
used to implement this?

-  ...

Also I'm biased, I'd agree with John that this would make a good paper. With 
real interest from the industry, from both vendors and operators.

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] Flow Control Discussion for IS-IS Flooding Speed

[bruno.decraene]

Tony, all,

Thanks Tony for the technical and constructive feedback.
Please inline [Bruno]

From: Tony Przygienda [mailto:tonysi...@gmail.com]
Sent: Wednesday, April 22, 2020 1:19 AM
To: Les Ginsberg (ginsberg)
Cc: DECRAENE Bruno TGI/OLN; lsr@ietf.org
Subject: Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

neither am I aware of anything like this (i.e. per platform/product flooding 
rate constants) in any major vendor stack for whatever that's worth. It's 
simply unmaintanable, point. All major vendors have extensive product lines 
over so many changing hardware configuration/setups it is simply not viable to 
attempt precise measurements (and even then, user changing config can throw the 
stuff off in a millisecond). There may have been here and there per deployment 
scenario some "recommended config" (not something I immediately recall either) 
but that means very fixed configuration of things & how they go into networks 
and even then I'm not aware of anyone having had a "precise model of the chain 
in the box". yes, probes to measure lots and lots of stuff in the boxes exist 
but again, those are chip/linecard/backplane/chassis/routing engine specific 
and mostly used in complex test/peformance scenarios and not to derive some 
kind of equations that can predict anything much ...
[Bruno] Good points.
Yet, one of the information that we propose to advertise by the LSP receiver to 
the LSP sender is the Receive Window.

-  This is a very common parameter and algorithm. Nothing fancy nor 
reinvented. In particular it’s a parameter used by TCP.

-  I would argue that TCP implementations also run on a variety of 
hardware and systems, must wider range than IS-IS platform. And those TCP 
implementations on all those platform manage to advertise this parameter (TCP 
window)

-  I fail to understand that when some WG contributors proposed the use 
of TCP, nobody said that determining and advertising a Receive Window would be 
an issue, difficult or even impossible. But when we propose to advertise a 
Receive Window in an IS-IS TLV, this becomes difficult or even impossible for 
some platforms. Can anyone help me understand the technical difference?

Bruno, if you're so deeply interested in that stuff we can talk 1:1 off-line 
about implementation work on rift towards adapatable flooding rate
[Bruno] Sure. My pleasure. Please propose me some timeslot offline. Please note 
that I’m based in Europe (CEST), so a priori during your morning and my evening.
If you can also extend the offer to discuss the implementation work on the 
IS-IS implementation of your employer with regards to adaptable flooding rate, 
and/or how network operator can configure the CLI parameters of the LSP senders 
so as to improve flooding rate without overloading the Juniper receiver 
(possibly depending on the capability of the receiver, its number of IS-IS 
neighbors… and/or whatever parameter that you feel are relevant) that would be 
most appreciated. And if you believe that the Juniper LSP receiver can handle 
any rate from any reasonable (e.g. 50)  number of IGP neighbors, without 
(significantly) dropping the received LSPs, that would be even simpler, please 
advise.

--Bruno
(algorithm you see in the -02 draft Les put out is a _very rough_ approximation 
of that BTW. I joined as co-author after we had some very fruitful discussions 
and I consider the draft close to what can be _realistically_ done  today in 
ISIS. I don't consider further details generic enough to merit wide forum 
discussions). And RIFT put a couple of things into packet formats we can't put 
into ISIS (I talked with Les about it) to improve the adaptability of the 
flooding rate BTW and some interesting, coarse indication from receiver. Again, 
this is not a constant that is calculated, it's all adaptive driven almost 
completely from the transmitter side and the feedback it gathers.

all my very own 2c

-- tony

On Tue, Apr 21, 2020 at 2:48 PM Les Ginsberg (ginsberg) 
mailto:40cisco@dmarc.ietf.org>> wrote:
Bruno –

You have made an assumption that historically vendors have tuned LSP 
transmission rates to a platform specific value.
That certainly is not true in the case of my employer (happy to hear what other 
vendors have been doing for the past 20 years).

The default value is based on minimumBroadcastLSPTransmissionInterval specified 
in ISO10589.
A knob is available to allow tuning (faster or slower) in a given deployment – 
though in my experience this knob is rarely used.

We already discuss in 
https://tools.ietf.org/html/draft-ginsberg-lsr-isis-flooding-scale-02#section-2 
that this common interpretation isn’t the most appropriate, but historically 
the concern has been to avoid flooding too fast – not to optimize flooding 
speed.
Obviously, we are revisiting that approach and saying it needs to change – 
which is something I think we have consensus on.

I have provided a description in my recent response as to 

Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

[bruno.decraene]

Les,

Please see inline

From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Tuesday, April 21, 2020 11:48 PM
To: DECRAENE Bruno TGI/OLN
Cc: lsr@ietf.org
Subject: RE: Flow Control Discussion for IS-IS Flooding Speed

Bruno -

You have made an assumption that historically vendors have tuned LSP 
transmission rates to a platform specific value.
[Bruno] I don't think so. What makes you think so?
In all cases, that is not my assumption, and for multiple reasons.

That certainly is not true in the case of my employer (happy to hear what other 
vendors have been doing for the past 20 years).

The default value is based on minimumBroadcastLSPTransmissionInterval specified 
in ISO10589.
A knob is available to allow tuning (faster or slower) in a given deployment - 
though in my experience this knob is rarely used.
[Bruno] I would agree on both. More interestingly is the why: why aren't those 
existing sending parameters tuned, while we  agree that default configuration 
are suboptimal?
My take is that:

-  We don't want to overload the receiver and create loss of LSP (as 
this will delay the LSDB synchronization and decrease the goodput). Hence this 
(the parameters) is receiver dependent (e.g., platform type,  number of IGP 
adjacencies, ...).

-  We don't know which value to configure : difficult for the network 
operator to evaluate without a significant knowledge of the receiver 
implementation (in particular QoS parameters for incoming LSP), vendors are not 
really proposing value or guidance, especially since the sending behavior is 
not standardized and slightly different between vendors. So everyone stay safe 
with default 20 years old values.

We already discuss in 
https://tools.ietf.org/html/draft-ginsberg-lsr-isis-flooding-scale-02#section-2 
that this common interpretation isn't the most appropriate, but historically 
the concern has been to avoid flooding too fast - not to optimize flooding 
speed.
Obviously, we are revisiting that approach and saying it needs to change - 
which is something I think we have consensus on.

I have provided a description in my recent response as to why it is difficult 
to derive an optimal value on a per platform basis. You may disagree - but 
please do not claim that we actually have been doing this for years. We haven't 
been.
[Bruno] I'm not sure how to rephrase my below email so that we could understand 
each other, have an answer from your side (I mean employer side), and progress.
More succinctly: How do network operator correctly configure the flooding 
parameters value on the implementation of your employer? In particular given 
the variety of conditions on the LSP receiver side.

--Bruno

  Les

From: bruno.decra...@orange.com 
Sent: Monday, April 20, 2020 4:47 AM
To: Les Ginsberg (ginsberg) 
Cc: lsr@ietf.org
Subject: RE: Flow Control Discussion for IS-IS Flooding Speed

Les,

After nearly 2 months, can we expect an answer from your side?

More specifically, the below question

[Bruno] _Assuming_ that the parameters are static, the parameters proposed in 
draft-decraene-lsr-isis-flooding-speed are the same as the one implemented 
(configured) on multiple implementations, including the one from your employer.
Now do you believe that those parameters can be determined?

§  If yes, how do you do _today_ on your implementation? (this seems to 
contradict your statement that you have no way to figure out how to find the 
right value)

§  If no, why did you implement those parameters, and ask network operator to 
configure them?


Thank you,
--Bruno

From: DECRAENE Bruno TGI/OLN
Sent: Wednesday, February 26, 2020 8:03 PM
To: 'Les Ginsberg (ginsberg)'
Cc: lsr@ietf.org
Subject: RE: Flow Control Discussion for IS-IS Flooding Speed

Les,

Please see inline[Bruno]

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Les Ginsberg (ginsberg)
Sent: Wednesday, February 19, 2020 3:32 AM
To: lsr@ietf.org
Subject: Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

Base protocol operation of the Update process tracks the flooding of
LSPs/interface and guarantees timer-based retransmission on P2P interfaces
until an acknowledgment is received.

Using this base protocol mechanism in combination with exponential backoff of 
the
retransmission timer provides flow control in the event of temporary overload
of the receiver.

This mechanism works without protocol extensions, is dynamic, operates
independent of the reason for delayed acknowledgment (dropped packets, CPU
overload), and does not require additional signaling during the overloaded
period.

This is consistent with the recommendations in RFC 4222 (OSPF).

Receiver-based flow control (as proposed in 
https://datatracker.ietf.org/doc/draft-decraene-lsr-isis-flooding-speed/ )
requires protocol extensions and introduces additional signaling during
periods of high load. The asserted reason for this is to optimize throughput -
but there is no evidence 

[Lsr] Flooding across a network

[bruno.decraene]

Les,

> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Les Ginsberg (ginsberg)
> Sent: Monday, May 4, 2020 4:39 PM
[...]
> when only some nodes in the network support faster flooding the behavior of 
> the whole network may not be "better" when faster flooding is enabled because 
> it prolongs the period of LSDB inconsistency.  

1) Do you have data on this?

2) If not, can you provide an example where increasing the flooding rate on one 
adjacency prolongs the period of LSDB inconsistency across the network?

3) In the meantime, let's try the theoretical analysis on a simple scenario 
where a single LSP needs to be flooded across the network.

- Let's call Dij the time needed to flood the LSP from node i to the adjacent 
node j. Clearly Dij>0.
- Let's call k the node originating this LSP at t0=0s

>From t0, the LSDB is inconsistent across the network as all nodes but k are 
>missing the LSP and hence only know about the 'old' topology.

Let's call  SPT(k) the SPT rooted on k, using Dij as the metric between 
adjacent nodes i and j. Let's call SP(k,i) the shortest path from k to i; and 
D(k,i) the shortest distance between k and i.

It seems that the time needed:
- for node j to learn about the LSP, and get in sync with k, is D(k,j)
- for all nodes across the network to learn about the LSP, and get in sync with 
k, is Max[for all j] D(k,j)

Then how can reducing the flooding delay on one adjacency could prolongs the 
period of LSDB inconsistency?
It seems to me that it can only improve/decrease it. Otherwise, this would mean 
that decreasing the cost on a link can increase the cost of the shortest path.

Note: I agree that there are other cases, such as  multiple LSPs originated by 
the same node, and multiple LSPs originated by multiple nodes, but let's start 
with the simple case. 

Thanks,
--Bruno

> -Original Message-
> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Les Ginsberg (ginsberg)
> Sent: Monday, May 4, 2020 4:39 PM
> 
> Henk -
> 
> Thanx for your thoughtful posts.
> I have read your later posts on this thread as well - but decided to reply to 
> this one.
> Top posting for better readability.
> 
> There is broad agreement that faster flooding is desirable.
> There are now two proposals as to how to address the issue - neither of which 
> is proposing to use TCP (or equivalent).
> 
> I have commented on why IS-IS flooding requirements are significantly 
> different than that for which TCP is used.
> I think it is also useful to note that even the simple test case which Bruno 
> reported on in last week's interim meeting demonstrated that without any 
> changes to the protocol at all IS-IS was able to flood an order of magnitude 
> faster than it commonly does today.
> This gives me hope that we are looking at the problem correctly and will not 
> need "TCP".
> 
> Introducing a TCP based solution requires:
> 
> a)A major change to the adjacency formation logic
> 
> b)Removal of the independence of the IS-IS protocol from the address families 
> whose reachability advertisements it supports - something which I think is a 
> great strength of the protocol - particularly in environments where multiple 
> address family support is needed
> 
> I really don't want to do either of the above.
> 
> Your comments regarding PSNP response times are quite correct - and both of 
> the draft proposals discuss this - though I agree more detail will be 
> required.
> It is intuitive that if you want to flood faster you also need to ACK faster 
> - and probably even retransmit faster when that is needed.
> The basic relationship between retransmit interval and PSNP interval is 
> expressed in ISO 10589:
> 
> " partialSNPInterval - This is the amount of time between periodic
> action for transmission of Partial Sequence Number PDUs.
> It shall be less than minimumLSPTransmission-Interval."
> 
> Of course ISO 10589 recommended values (2 seconds and 5 seconds respectively) 
> associated with a much slower flooding rate and implementations I am aware of 
> use values in this order of magnitude. These numbers need to be reduced if we 
> are to flood faster, but the relationship between the two needs to remain the 
> same.
> 
> It is also true - as you state - that sending ACKs more quickly will result 
> in additional PDUs which need to be received/processed by IS-IS - and this 
> has some impact. But I think it is reasonable to expect that an 
> implementation which can support sending and receiving LSPs at a faster rate 
> should also be able to send/receive PSNPs at a faster rate. But we still need 
> to be smarter than sending one PSNP/one LSP in cases where we have a burst.
> 
> LANs are a more difficult problem than P2P - and thus far 
> draft-ginsberg-lsr-isis-flooding-scale has been silent on this - but not 
> because we aren't aware of this - just have focused on the P2P behavior first.
> What the best behavior on a LAN may be is something I am still considering. 
> 

Re: [Lsr] Flooding across a network

[bruno.decraene]

Les,

From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Wednesday, May 6, 2020 1:35 AM
To: DECRAENE Bruno TGI/OLN; lsr@ietf.org
Subject: RE: Flooding across a network


Bruno -



Seems like it was not too long ago that we were discussing this in person.  
Ahhh...the good old days...

[Bruno] Indeed, may be not to the point of concluding. Indeed.



First, let's agree that the interesting case does not involve 1 or even a small 
number of LSPs. For those cases flooding speed does not matter.

The interesting cases involve a large number of LSPs (hundreds or thousands). 
And in such cases LFA/microloop avoidance techniques are not applicable.



Take the following simple topology:



   |  | ... ||

 +---+ +---+

 | C | | E |

 +---+ +---+

   | | 1000

 +---+ +---+

 | B |-| D |

 +---+   1000  +---+

   | |

   | |

\   /

 \/

  \ /

   \  /

 +---+

 | A |

 +---+



There is a topology northbound of C and E (not shown) and a topology southbound 
of A (not shown).

Cost on all links is 10 except B-D and D-E where cost is high.



C is a node with 1000 neighbors.

When all links are up, shortest path for all northbound destinations is via C.

All nodes in the network support fast flooding except for Node D.

Let's say fast flooding is 500 LSPs/second and slow flooding (Node D) is 20 
LSPs/seconds.

If  Node C fails we have 1000 LSPs to flood.

All nodes except for D can receive these in 2 seconds (plus internode delay 
time).

D can receive LSPs in 50 seconds.



[Bruno] Thanks for your example. Agreed so far.



When A and B and all southbound nodes receive/process the LSP updates they will 
start sending traffic to Northbound destinations via D.

But for the better part of 50 seconds, Node D has yet to receive all LSP 
updates and still believes that shortest path is via B-C. It will loop traffic.



[Bruno] May I remind you that we are discussing IS-IS flooding in order to sync 
LSDB (LSP database). That is already a big enough subject. It does not 
including FIB (updates), nor IP forwarding.



Quoting you "when only some nodes in the network support faster flooding the 
behavior of the whole network may not be "better" when faster flooding is 
enabled because it prolongs the period of LSDB inconsistency."



Taking your own examples, in both cases (all nodes support fast flooding; all 
nodes but D support fast flooding) the period of LSDB inconsistency is 50 
seconds. Hence this example does not illustrate your statement.



Hence I'm restating my questions:



> > when only some nodes in the network support faster flooding the behavior

> of the whole network may not be "better" when faster flooding is enabled

> because it prolongs the period of LSDB inconsistency.

>

> 1) Do you have data on this?

>

> 2) If not, can you provide an example where increasing the flooding rate on

> one adjacency prolongs the period of LSDB inconsistency across the

> network?





Had all nodes used slow flooding, it still would have taken 50 seconds to 
converge, but there would be significantly less looping. There could be a good 
amount of blackholing, but this is preferable to looping.

[Bruno] You are using an example where ordering FIB updates across the network, 
e.g. as per [1], allows to reduce _FIB_ inconsistency across the path/network. 
And you seem to conclude from this that this translates to LSDB update 
ordering. Those are two different things. In this thread, I'd suggest that we 
focus on IGP flooding and LSDB sync only. (*)

[1] https://tools.ietf.org/html/rfc6976

(*) We can discuss loop free IGP converge in a different thread if you want.. 
IMO, the use of segment routing/source routing is better than oFIB. But at some 
point, it still relies on fast flooding when multiple LSPs are involved. (and I 
mean _fast_ not _ordered_)



--Bruno



One can always come up with examples - based on a specific topology and a 
specific failure - where things might be better/worse/unchanged in the face of 
inconsistent flooding speed support.

But I hope this simple example illustrates the pitfalls.



Les



> -Original Message-

> From: bruno.decra...@orange.com 

> Sent: Tuesday, May 05, 2020 8:28 AM

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

> Subject: Flooding across a network

>

> Les,

>

> > From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Les Ginsberg

> (ginsberg)

> > Sent: Monday, May 4, 2020 4:39 PM

> [...]

> > when only some nodes in the network support faster flooding the behavior

> of the whole network may not be "better" when faster flooding is enabled

> because it prolongs the period of LSDB inconsistency.

>

> 1) Do you have data on this?

>

> 2) If not, can you provide an example where 

Re: [Lsr] Flooding across a network

[bruno.decraene]

> From: Christian Hopps [mailto:cho...@chopps.org] 
> 
> Bruno persistence has made me realize something fundamental here.
> 
> The minute the LSP originator changes the LSP and floods it you have LSDB 
> inconsistency. 

Exactly my point. Thank you Chris.
I would even say: "The minute the LSP originator changes the LSP then you have 
LSDB inconsistency." But no big deal if there is disagreement on this detail.

> That is going to last until the last node in the network has updated it's 
> LSDB.

Absolutely.
So the faster we flood, the shorter the LSBD inconsistency.

Now IMO, even if a single/few nodes flood faster, there is a chance of 
shortening the LSDB inconsistency. But in all cases, I don't see how this could 
make the LSDB inconsistency longer.

 
> Les is pointing out that LSDB inconsistency can be bad in certain 
> circumstances e.g., if a critical node is slow and thus inconsistent.
> 
> I believe the right way to fix this is a simple one, help the operator flag 
> the broken router software/hardware for replacement, but otherwise IS-IS 
> should just try to do the best job it can do to which is to flood around the 
> problem (i.e., flood as optimally as possible).

+1
On a side note, I would not call a router flooding slowly as "broken". I find 
it understandable that in a given network there are different type of routers 
(core vs aggregation), different roles (P having 50 IGP adjacencies with 50 PEs 
vs PE having only 2 IGP adjacencies with 2 P), different hardware generations, 
different software, different vendors with different perspectives/markets.

Thank you Chris.

--Bruno
> 
> Thanks,
> Chris.
> [as WG member]
> 
> 
> > On May 6, 2020, at 10:33 AM, bruno.decra...@orange.com wrote:
> > 
> > Les,
> >  
> > From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] 
> > Sent: Wednesday, May 6, 2020 4:14 PM
> > To: DECRAENE Bruno TGI/OLN
> > Cc: lsr@ietf.org
> > Subject: RE: Flooding across a network
> >  
> > Bruno –
> >  
> > I am somewhat at a loss to understand your comments.
> > The example is straightforward and does not need to consider FIB update 
> > time nor the ordering of prefix updates on different nodes.
> > [Bruno] The example is straightforward but you are referring to FIB and IP 
> > packets forwarding as per those FIBs.
> > I’d like we focus on LSP flooding and LSDB consistency.
> >  
> > Consider the state of Node B and Node D at various time points from the 
> > trigger event.
> >  
> > T+ 2 seconds:
> > -
> > B has received all LSP Updates. It triggers an SPF and for all Northbound 
> > destinations previously reachable via C it installs paths via D.
> > Let’s assume it take 5 seconds to update the forwarding plane.
> >  
> > D has received 40 of the 1000 LSP updates. It triggers an SPF and finds 
> > that all Northbound destinations are reachable via B-C. It makes no changes 
> > to the forwarding plane.
> >  
> > T+7 seconds
> > -
> > B has completed FIB updates. Traffic to all Northbound destinations is 
> > being forwarded via D.
> >  
> > D has now received 140 of the 1000 LSP updates. Entries in its forwarding 
> > plane for Northbound destinations still point to B.
> >  
> > We have a loop.
> >  
> > T + 30 seconds
> > 
> > D has now received 600 of the 1000 LSP updates. Still no changes to its 
> > forwarding plane.
> > Traffic to Northbound destinations is still looping.
> >  
> > T+ 50 seconds
> > ---
> > D has finally received all 1000 LSP updates..
> > It triggers (another) SPF and calculates paths to Northbound destinations 
> > via E. It begins to update its forwarding plane.
> > Let’s assume this will take 5 seconds..
> >  
> > T + 55 seconds
> > 
> > D has completed forwarding plane updates – no more looping.
> >  
> > That is all I am trying to illustrate.
> >  
> > If you want to start arguing that node protecting LFAs + microloop 
> > avoidance could help (NOTE I explicitly  took those out of the example for 
> > simplicity) – it is easy enough to change the example to include multiple 
> > node failures or a node failure plus some northbound link failures on other 
> > nodes.
> > [Bruno] I’m not talking about LFA/FRR. And with regards to microloops 
> > avoidance, some algorithms can handle any graph transition so including 
> > multiple node failures.
> >  
> > But again, let’s stick to LSP flooding and LSDB consistency. (you are the 
> > one speaking about microloops in the forwarding plane).
> >  
> > The point here is to look at the impact of long-lived LSDB inconsistency 
> > which results when some nodes support flooding an order of magnitude faster 
> > flooding than other nodes – which is what you asked me to clarify.
> > [Bruno] No. I asked you to clarify why having a node with faster flooding 
> > could prolongs the period of LSDB inconsistency.
> >  
> > Again, with you own words: “when only some nodes in the network support 
> > faster flooding the 

Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

[bruno.decraene]

Hi Peter,

> From: Peter Psenak [mailto:ppse...@cisco.com]
> 
> Hi Bruno,
> 
> please see inline:
> 
> On 07/09/2020 17:31, bruno.decra...@orange.com wrote:
> > Hi Peter,
> >
> >> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak
> >> Sent: Thursday, September 3, 2020 9:55 AM
> >>
> >> Hi Shraddha,
> >>
> >> On 03/09/2020 05:39, Shraddha Hegde wrote:
> >>> Peter,
> >>>
> >>> In order to make the document clearer on this point, I would like the
> text
> >> below to be added
> >>> to section 11 to make it explicit that setting the L-bit is valid for 
> >>> flex-algo
> for
> >> ISIS.
> >>>
> >>> =
> >>> Section 11.
> >>>
> >>> “The ASLA TLV in ISIS supports the L-Bit as described in section 4.2 of
> >>> [draft-ietf-isis-te-app]. When the L-bit is set, applications MUST use
> >>> legacy advertisements for that link. Flex algorithm application MUST
> >> support
> >>> sending and receiving link attributes with ASLA TLV having L-bit set.
> >>
> >>
> >> I can add the above,
> >
> > Yes please. (It's not clear to me whether "can add" means "will add" or
> "could add". So better safe than sorry).
> >
> > Also in §5.1:
> >
> > " 1: Min Unidirectional Link Delay as defined in [RFC8570],
> >   section 4.2, encoded in the Application Specific Link
> >   Attributes Sub-TLV [I-D.ietf-isis-te-app]."
> >
> > It could be read as the delay (value) needs to be encoded in the ASLA
> Attributes Sub-TLV, while when the L-bit is set, the delay (value) is encoded
> in the RFC8570 sub-TLV.
> > So in order to avoid interop issues, I'd appreciate if you could clarify.
> > May be :s/in/as per
> > Or :s/./or in the RFC8570 Sub-TLV when the ASLA L-Flag is set.
> > Or whatever change at your preference.
> 
> 
> what about:
> 
> "Min Unidirectional Link Delay as defined in [RFC8570],
>   section 4.2, encoded as specified in [I-D.ietf-isis-te-app]."
> 
> That covers the L-bit with delay in legacy TLV.

Looks good.

Thank you.

--Bruno

> >
> > Then same comment for Metric-Type 2 (TE Metric), in the next sentence.
> 
> sure.
> 
> thanks,
> Peter
> 
> >
> >
> > Thank you,
> > Regards,
> > --Bruno
> >
> >
> >> although, it's clear from the
> >> draft-ietf-isis-te-app that L-bit with legacy advertisement MAY be used
> >> for any app.
> >>
> >>>
> >>> Note that earlier versions of this document did not mandate use of ASLA
> >> TLVs
> >>> and hence may not inter-operate with early implementations that use
> >> legacy advertisements."
> >>
> >> it is not true that "earlier versions of this document" did not mandate
> >> ASLA.
> >>
> >> https://tools.ietf.org/html/draft-ietf-lsr-flex-algo-00, which only
> >> supported the include/exclude Admin Groups, clearly stated:
> >>
> >>
> >> 9.  Advertisement of Link Attributes for Flex-Algorithm
> >>
> >>  Various link include or exclude rules can be part of the Flex-
> >>  Algorithm definition.  These rules use Admin Groups (AG) as defined
> >>  in [RFC7308] and [RFC5305], or Extended Administrative Groups (EAG)
> >>  as defined in [RFC7308].
> >>
> >>  To advertise a link affinity in a form of the AG or EAG that is used
> >>  during Flex-Algorithm calculation, an Application Specific Link
> >>  Attributes sub-TLV as described in [I-D.ietf-isis-te-app], or sub-TLV
> >>  of Extended Link TLV as described in
> >>  [I-D.ietf-ospf-te-link-attr-reuse] MUST be used.  The advertisement
> >>  MUST indicate that it is usable by the Flex-Algorithm application.
> >>
> >>
> >> thanks,
> >> Peter
> >>
> >>
> >>
> >>> 
> >>>
> >>>
> >>> Rgds
> >>> Shraddha
> >>>
> >>>
> >>> Juniper Business Use Only
> >>>
> >>> -Original Message-
> >>> From: Peter Psenak 
> >>> Sent: Wednesday, September 2, 2020 2:43 PM
> >>> To: Shraddha Hegde ;
> >> olivier.dug...@orange.com; tony...@tony.li; Robert Raszuk
> >> 
> >>> Cc: Christian Hopps ; draft-ietf-lsr-flex-
> >> algo@ietf.org; Les Ginsberg (ginsberg)
> >> ; lsr@ietf.org; lsr-...@ietf.org;
> >> Acee Lindem (acee) 
> >>> Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo
> >>>
> >>> [External Email. Be cautious of content]
> >>>
> >>>
> >>> Hi Shraddha,
> >>>
> >>> please see inline:
> >>>
> >>>
> >>> On 02/09/2020 06:45, Shraddha Hegde wrote:
>  Peter,
> 
>  It is worthwhile to note the history of the flex-algo draft and the
>  te-app draft and how many  backward incompatible changes have been
>  introduced in the course of the flex-algo draft.
> 
>  The original drafts of flex-algo did not mention the te-app draft and
>  was completely based on legacy advertisements.
>  Two years ago, after the working group adopted the original drafts
>  without the ASLA TLV, the text was changed to require the ASLA TLV.
> >>>
> >>> draft-ietf-lsr-flex-algo-00, which was the initial version of the WG
> >> document already mandated the ASLA usage. I don't believe we have to
> go
> >> back to the individual drafts that predated the WG 

Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

[bruno.decraene]

Hi Tony,

Thanks for your reply.
All good to me.

Thanks,
--Bruno


From: Tony Li [mailto:tony1ath...@gmail.com] On Behalf Of tony...@tony.li
Sent: Saturday, September 5, 2020 2:18 AM
To: DECRAENE Bruno TGI/OLN 
Cc: lsr@ietf.org
Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt


Hi Bruno,

Thank you for your comments.

1)

OLD: The
   advertisement in the Proxy LSP informs the remainder of the network
   that packets directed to the SID will be forwarded by one of the
   Inside Edge Nodes and the Area SID will be consumed.

NEW:

The

   advertisement in the Proxy LSP informs the outside area

   that packets directed to the SID will be forwarded to one of the

   Inside Edge Nodes and the Area SID will be consumed.

Motivation:
1)  More precise/descriptive and use the terminology defined in the draft
2)  The SID is a priori global in the outside area and hence will be 
forwarded by all nodes in the outside area (and not just by the Inside Edge 
Nodes). The destination is anycast to/toward any Inside Edge node.


Ok.



2)
§ 4.3.2.  The Area SID Sub-TLV

The Area SID Sub-TLV allows the Area Leader to advertise a prefix and

   SID



§4.4.13.  The Area SID

  The Area Leader SHOULD advertise the Area SID information in the

   Proxy LSP as a Node SID as defined in [RFC8667] Section 
2.1.


RFC8667 requires that for a Node SID, the prefix be an IP address (/32 or /138) 
(rather than an IP prefix of an arbitrary length) [1].
[1] https://tools.ietf.org/html/rfc8667#section-2.1.1.2

You may want to refer to this restriction when defining the Area SID Sub-TLV in 
section 4.3.2 . e.g. :s/advertise a prefix/advertise an IP address. 
Alternatively open the option to advertise a prefix SID without the N-Flag if 
this is a prefix.


We are implicitly doing that by permitting a prefix.



3)
1 typo in -04 :s/ Inisde/ Inside


Fixed, thanks.



4)
OLD:
The Area Leader will generate a Proxy LSP that must be flooded across
   the Inside Area.  Inside Routers MUST ignore the contents of the
   Proxy LSP other than for flooding

My personal preference would be
NEW
The Area Leader will generate a Proxy LSP that will be flooded across
   the Inside Area.  Inside Routers MUST ignore the contents of LSP(s) 
originated with the Area Proxy System Identifier other than for flooding.

Motivation:
a)  Clarify that no new behavior is involved
b)  Specifies how the proxy LSP is to be identified as a proxy LSP.



?  Ignoring the contents of an LSP is a new behavior.  I propose something 
slightly different:

  The Area Leader will generate a Proxy LSP that will be
  flooded across the Inside Area.  Inside Routers MUST ignore
  the contents of the Proxy LSP other than for flooding.  The
  Proxy LSP uses the Area Proxy System Identifier as its Source
  ID.




5) Open question: is the Area Proxy LSP to be advertised/read from L1 or L2 
LSP/LSDB or both?

“All routers within the Inside Area speak Level 1 and Level 2 IS-IS on all of 
the links within the topology.”
OK.

“A node advertises the Area Proxy TLV in its L2 LSP”
So my reading/guessing is that the Area Proxy TLV is only sent in the L2 LSP of 
all Inside routers. (i.e. not in the L1 LSP).
If so:
-  Can you clarify the behavior when an Area Proxy TLV is received in 
an L1 LSP? (e.g. ignore, and if not, what is the behavior when the TLV is 
different in L1 and L2).


We already say:

   The Area Leader MUST advertise the Area Proxy System
   Identifier Sub-TLV when it observes that all Inside Routers
   are advertising the Area Proxy TLV.

The statement that you quote is pretty clear that the Area Proxy TLV is found 
in the L2 LSP.  I take it that you feel that this is insufficient.
I propose to add:

 Nodes MUST NOT advertise the Area Proxy TLV in a L1 LSP. Nodes MUST
  ignore the Area Proxy TLV if it is found in a L1 LSP.



-  “they will advertise the Area Proxy TLV.” May be adding “in their L2 
LSP”


Ok.



-  “All Inside Edge Routers learn the Area Proxy System Identifier from 
the Level 1 LSDB”. I would have assumed  “from the Area Proxy TLV advertised in 
the level 2 LSDB.  So it may be a typo or I’m missing something, which is very 
possible.


That was a bug, thanks.  I changed it to: “ … from the Area Proxy TLV 
advertised by the Area Leader … “



o   “it MUST inject   the Area Proxy System Identifier into the Level 1 LSDB.” 
Same comment.


Also a bug.  Should be L2.  Fixed.


Thanks for the detailed review!


Tony


_

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 

Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

[bruno.decraene]

Hi Tony,

Thanks for your reply.
At this point, area proxy spec is clear with regards to nominal behavior. So 
indeed we are discussing error handling / transitions. (and thank you for 
considering those cases, much appreciated).

From memory, my understanding is the area proxy nominal behaviour requires:

-  All routers in the area are L1 & L2

-  All inside routers advertise the area proxy TLV

-  An area leader advertises the Area Proxy System Identifier Sub-TLV

If the above is not fulfilled, what is the expected behaviour? There is a 
priori 2 options:

-  A) Return to regular IS-IS behaviour. i.e. all L2 LSPs from inside 
routers are flooded to L2 outside routers

o   Pro: no new behaviour/code as this is regular IS-IS. Correct transit 
forwarding across the area.

o   Con: suddenly increase size of L2 LSDB

-  B) Keep filtering L2 LSP from inside routers

o   Pro: no sudden increase of L2 LSDB size

o   Con: transit traffic is partially dropped (if area LSP advertised while 
some routers are L1 only), no transit is possible (if area LSP is not 
advertised), or partial transit (some inside edge node do not advertise the 
area proxy TLV).

§  Lack of transit is not an issue if there is a backup proxy area (e.g. a 
proxy area a replace a big single chassis).  It’s likely an issue is there is 
no backup proxy area (e.g. the area has built-in redundancy (e.g. spife/leaf) 
hence there is no need for another/backup proxy area. Network operator needs to 
be well aware in order to choose the correct design (rather than experience a 
bad surprise)

That’s an open question.
As this point I do not have a preference, although naively I had “A” in mind. 
From your below answer, I think that you have “B” in mind.
A priori the choice may be dependent on the missing condition.
Possibly this could be clarified in a “operational consideration” or “error 
handling” section for network operator to be aware of the behaviour under 
failure/transition condition.
FYI, I’m considering such failure to be plausible over the years as all it need 
is one L1 router to boot and not advertise the area proxy TLV or be configured 
as L1 only.

Regards,
--Bruno
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of tony...@tony.li
Sent: Saturday, September 5, 2020 2:43 AM
To: DECRAENE Bruno TGI/OLN 
Cc: lsr@ietf.org
Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt


Hi Bruno,



“A Level 2 LSP that contains the Area Proxy TLV MUST NOT be flooded to an 
Outside Router. »
Agreed (so far)

“A Level 2 LSP with a source system identifier that is found in the Level 1 
LSDB MUST NOT be flooded to an Outside Router.”
I’m not sure to agree.
If that LSP carries the Area Proxy TLV, the previous rule is enough.
If that LSP does not carry the Area Proxy TLV, then no Area Leader advertise 
the Area Proxy System Identifier Sub-TLV and hence the new Area Proxy is not 
enabled. In which case I feel that normal IS-IS flooding should occur, and 
L1-L2 nodes should have their L2 LSP flooded.
So, I would propose to remove that sentence which doesn’t seem needed.


This was intentional. We are trying to protect against a case where a router 
boots and has not yet processed its full configuration yet.  It could easily 
generate an LSP prior to adding the Area Proxy TLV.
This could also happen during the transition to Area Proxy, where an Inside 
Node has not yet been configured for Area Proxy.

We are trying to prevent flooding of its LSP to the Outside Area because that 
may confuse other L2 nodes.


“A Level 2 LSP that contains the Area Proxy TLV MUST NOT be flooded to an 
Outside Router. »
I think we additionally need that an Area Leader advertise the Area Proxy 
System Identifier Sub-TLV.


We already say:

  The Area Leader has several responsibilities.  First, it MUST
   inject the Area Proxy System Identifier into the Level 2
   LSDB.



Otherwise, hence the new Area Proxy is not enabled. I which case I feel that 
normal IS-IS flooding should occur, and L1-L2 nodes should have their L1 & L2 
LSP flooded.
That condition would seem application to the whole section 5.2 or even to the 
whole section 5



Again, we want to restrict flooding if Area Proxy is configured, even if it’s 
not fully enabled.  Again, we’re just trying to make the transition as smooth 
as possible.


Tony



_

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 

Re: [Lsr] Fwd: I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

[bruno.decraene]

Hi Tony,

I've read the diff for -03 and -04.
The new encoding of the Area SID is good for me.

And thank you for listening to my use case and suggestion.

Thanks,
--Bruno


From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of tony...@tony.li
Sent: Monday, August 24, 2020 7:02 PM
To: lsr@ietf.org
Subject: [Lsr] Fwd: I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt


Hi folks,

This updated draft has been published for a few weeks now.  We would like to 
solicit your opinion on this.  In particular, we have changed the encoding of 
the Area SID.  Do you find this encoding adequate and appropriate?

Thanks,
Tony



Begin forwarded message:

From: internet-dra...@ietf.org
Subject: I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt
Date: August 5, 2020 at 1:17:39 PM PDT
To: mailto:i-d-annou...@ietf.org>>
Cc: lsr@ietf.org
Reply-To: internet-dra...@ietf.org, 
lsr@ietf.org


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Link State Routing WG of the IETF.

   Title   : Area Proxy for IS-IS
   Authors : Tony Li
 Sarah Chen
 Vivek Ilangovan
 Gyan S. Mishra
  Filename: draft-ietf-lsr-isis-area-proxy-03.txt
  Pages   : 19
  Date: 2020-08-05

Abstract:
  Link state routing protocols have hierarchical abstraction already
  built into them.  However, when lower levels are used for transit,
  they must expose their internal topologies to each other, leading to
  scale issues.

  To avoid this, this document discusses extensions to the IS-IS
  routing protocol that would allow level 1 areas to provide transit,
  yet only inject an abstraction of the level 1 topology into level 2.
  Each level 1 area is represented as a single level 2 node, thereby
  enabling greater scale.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-area-proxy/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-03
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-area-proxy-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-isis-area-proxy-03


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


_

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] Fwd: I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

[bruno.decraene]

Hi Tony,

Please find below some nits/minor comments. Please feel free to silently 
discard.

1)

OLD: The
   advertisement in the Proxy LSP informs the remainder of the network
   that packets directed to the SID will be forwarded by one of the
   Inside Edge Nodes and the Area SID will be consumed.

NEW:

The

   advertisement in the Proxy LSP informs the outside area

   that packets directed to the SID will be forwarded to one of the

   Inside Edge Nodes and the Area SID will be consumed.

Motivation:

1)  More precise/descriptive and use the terminology defined in the draft

2)  The SID is a priori global in the outside area and hence will be 
forwarded by all nodes in the outside area (and not just by the Inside Edge 
Nodes). The destination is anycast to/toward any Inside Edge node.


2)
§ 4.3.2.  The Area SID Sub-TLV

The Area SID Sub-TLV allows the Area Leader to advertise a prefix and

   SID



§4.4.13.  The Area SID

  The Area Leader SHOULD advertise the Area SID information in the

   Proxy LSP as a Node SID as defined in [RFC8667] Section 
2.1.


RFC8667 requires that for a Node SID, the prefix be an IP address (/32 or /138) 
(rather than an IP prefix of an arbitrary length) [1].
[1] https://tools.ietf.org/html/rfc8667#section-2.1.1.2

You may want to refer to this restriction when defining the Area SID Sub-TLV in 
section 4.3.2 . e.g. :s/advertise a prefix/advertise an IP address. 
Alternatively open the option to advertise a prefix SID without the N-Flag if 
this is a prefix.


3)
1 typo in -04 :s/ Inisde/ Inside

4)
OLD:
The Area Leader will generate a Proxy LSP that must be flooded across
   the Inside Area.  Inside Routers MUST ignore the contents of the
   Proxy LSP other than for flooding

My personal preference would be
NEW
The Area Leader will generate a Proxy LSP that will be flooded across
   the Inside Area.  Inside Routers MUST ignore the contents of LSP(s) 
originated with the Area Proxy System Identifier other than for flooding.

Motivation:

a)  Clarify that no new behavior is involved

b)  Specifies how the proxy LSP is to be identified as a proxy LSP.

5) Open question: is the Area Proxy LSP to be advertised/read from L1 or L2 
LSP/LSDB or both?

"All routers within the Inside Area speak Level 1 and Level 2 IS-IS on all of 
the links within the topology."
OK.

"A node advertises the Area Proxy TLV in its L2 LSP"
So my reading/guessing is that the Area Proxy TLV is only sent in the L2 LSP of 
all Inside routers. (i.e. not in the L1 LSP).
If so:

-  Can you clarify the behavior when an Area Proxy TLV is received in 
an L1 LSP? (e.g. ignore, and if not, what is the behavior when the TLV is 
different in L1 and L2).

-  "they will advertise the Area Proxy TLV." May be adding "in their L2 
LSP"

-  "All Inside Edge Routers learn the Area Proxy System Identifier from 
the Level 1 LSDB". I would have assumed  "from the Area Proxy TLV advertised in 
the level 2 LSDB.  So it may be a typo or I'm missing something, which is very 
possible.

o   "it MUST inject   the Area Proxy System Identifier into the Level 1 LSDB." 
Same comment.


Thanks,
--Bruno


From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of 
bruno.decra...@orange.com
Sent: Friday, September 4, 2020 2:29 PM
To: tony...@tony.li
Cc: lsr@ietf.org
Subject: Re: [Lsr] Fwd: I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

Hi Tony,

I've read the diff for -03 and -04.
The new encoding of the Area SID is good for me.

And thank you for listening to my use case and suggestion.

Thanks,
--Bruno


From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of 
tony...@tony.li
Sent: Monday, August 24, 2020 7:02 PM
To: lsr@ietf.org
Subject: [Lsr] Fwd: I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt


Hi folks,

This updated draft has been published for a few weeks now.  We would like to 
solicit your opinion on this.  In particular, we have changed the encoding of 
the Area SID.  Do you find this encoding adequate and appropriate?

Thanks,
Tony



Begin forwarded message:

From: internet-dra...@ietf.org
Subject: I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt
Date: August 5, 2020 at 1:17:39 PM PDT
To: mailto:i-d-annou...@ietf.org>>
Cc: lsr@ietf.org
Reply-To: internet-dra...@ietf.org, 
lsr@ietf.org


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Link State Routing WG of the IETF.

   Title   : Area Proxy for IS-IS
   Authors : Tony Li
 Sarah Chen
 Vivek Ilangovan
 Gyan S. Mishra
Filename: draft-ietf-lsr-isis-area-proxy-03.txt
Pages 

Re: [Lsr] Fwd: I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

[bruno.decraene]

Hi Tony,

I may have a comment on 5.2.  Filtering LSP information.
This is old text, but new re-reading.

"A Level 2 LSP that contains the Area Proxy TLV MUST NOT be flooded to an 
Outside Router. >
Agreed (so far)

"A Level 2 LSP with a source system identifier that is found in the Level 1 
LSDB MUST NOT be flooded to an Outside Router."
I'm not sure to agree.
If that LSP carries the Area Proxy TLV, the previous rule is enough.
If that LSP does not carry the Area Proxy TLV, then no Area Leader advertise 
the Area Proxy System Identifier Sub-TLV and hence the new Area Proxy is not 
enabled. In which case I feel that normal IS-IS flooding should occur, and 
L1-L2 nodes should have their L2 LSP flooded.
So, I would propose to remove that sentence which doesn't seem needed.


"A Level 2 LSP that contains the Area Proxy TLV MUST NOT be flooded to an 
Outside Router. >
I think we additionally need that an Area Leader advertise the Area Proxy 
System Identifier Sub-TLV. Otherwise, hence the new Area Proxy is not enabled. 
I which case I feel that normal IS-IS flooding should occur, and L1-L2 nodes 
should have their L1 & L2 LSP flooded.
That condition would seem application to the whole section 5.2 or even to the 
whole section 5

Thanks,
--Bruno


From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of 
bruno.decra...@orange.com
Sent: Friday, September 4, 2020 2:29 PM
To: tony...@tony.li
Cc: lsr@ietf.org
Subject: Re: [Lsr] Fwd: I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

Hi Tony,

I've read the diff for -03 and -04.
The new encoding of the Area SID is good for me.

And thank you for listening to my use case and suggestion.

Thanks,
--Bruno


From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of 
tony...@tony.li
Sent: Monday, August 24, 2020 7:02 PM
To: lsr@ietf.org
Subject: [Lsr] Fwd: I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt


Hi folks,

This updated draft has been published for a few weeks now.  We would like to 
solicit your opinion on this.  In particular, we have changed the encoding of 
the Area SID.  Do you find this encoding adequate and appropriate?

Thanks,
Tony



Begin forwarded message:

From: internet-dra...@ietf.org
Subject: I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt
Date: August 5, 2020 at 1:17:39 PM PDT
To: mailto:i-d-annou...@ietf.org>>
Cc: lsr@ietf.org
Reply-To: internet-dra...@ietf.org, 
lsr@ietf.org


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Link State Routing WG of the IETF.

   Title   : Area Proxy for IS-IS
   Authors : Tony Li
 Sarah Chen
 Vivek Ilangovan
 Gyan S. Mishra
Filename: draft-ietf-lsr-isis-area-proxy-03.txt
Pages   : 19
Date: 2020-08-05

Abstract:
  Link state routing protocols have hierarchical abstraction already
  built into them.  However, when lower levels are used for transit,
  they must expose their internal topologies to each other, leading to
  scale issues.

  To avoid this, this document discusses extensions to the IS-IS
  routing protocol that would allow level 1 areas to provide transit,
  yet only inject an abstraction of the level 1 topology into level 2.
  Each level 1 area is represented as a single level 2 node, thereby
  enabling greater scale.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-area-proxy/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-03
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-area-proxy-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-isis-area-proxy-03


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


_



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. 

Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

[bruno.decraene]

Hi Peter,

> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak
> Sent: Thursday, September 3, 2020 9:55 AM
> 
> Hi Shraddha,
> 
> On 03/09/2020 05:39, Shraddha Hegde wrote:
> > Peter,
> >
> > In order to make the document clearer on this point, I would like the text
> below to be added
> > to section 11 to make it explicit that setting the L-bit is valid for 
> > flex-algo for
> ISIS.
> >
> > =
> > Section 11.
> >
> > “The ASLA TLV in ISIS supports the L-Bit as described in section 4.2 of
> > [draft-ietf-isis-te-app]. When the L-bit is set, applications MUST use
> > legacy advertisements for that link. Flex algorithm application MUST
> support
> > sending and receiving link attributes with ASLA TLV having L-bit set.
> 
> 
> I can add the above, 

Yes please. (It's not clear to me whether "can add" means "will add" or "could 
add". So better safe than sorry).

Also in §5.1:

" 1: Min Unidirectional Link Delay as defined in [RFC8570],
 section 4.2, encoded in the Application Specific Link
 Attributes Sub-TLV [I-D.ietf-isis-te-app]."

It could be read as the delay (value) needs to be encoded in the ASLA 
Attributes Sub-TLV, while when the L-bit is set, the delay (value) is encoded 
in the RFC8570 sub-TLV.
So in order to avoid interop issues, I'd appreciate if you could clarify.
May be :s/in/as per
Or :s/./or in the RFC8570 Sub-TLV when the ASLA L-Flag is set.
Or whatever change at your preference. 

Then same comment for Metric-Type 2 (TE Metric), in the next sentence.


Thank you,
Regards,
--Bruno


> although, it's clear from the
> draft-ietf-isis-te-app that L-bit with legacy advertisement MAY be used
> for any app.
> 
> >
> > Note that earlier versions of this document did not mandate use of ASLA
> TLVs
> > and hence may not inter-operate with early implementations that use
> legacy advertisements."
> 
> it is not true that "earlier versions of this document" did not mandate
> ASLA.
> 
> https://tools.ietf.org/html/draft-ietf-lsr-flex-algo-00, which only
> supported the include/exclude Admin Groups, clearly stated:
> 
> 
> 9.  Advertisement of Link Attributes for Flex-Algorithm
> 
> Various link include or exclude rules can be part of the Flex-
> Algorithm definition.  These rules use Admin Groups (AG) as defined
> in [RFC7308] and [RFC5305], or Extended Administrative Groups (EAG)
> as defined in [RFC7308].
> 
> To advertise a link affinity in a form of the AG or EAG that is used
> during Flex-Algorithm calculation, an Application Specific Link
> Attributes sub-TLV as described in [I-D.ietf-isis-te-app], or sub-TLV
> of Extended Link TLV as described in
> [I-D.ietf-ospf-te-link-attr-reuse] MUST be used.  The advertisement
> MUST indicate that it is usable by the Flex-Algorithm application.
> 
> 
> thanks,
> Peter
> 
> 
> 
> > 
> >
> >
> > Rgds
> > Shraddha
> >
> >
> > Juniper Business Use Only
> >
> > -Original Message-
> > From: Peter Psenak 
> > Sent: Wednesday, September 2, 2020 2:43 PM
> > To: Shraddha Hegde ;
> olivier.dug...@orange.com; tony...@tony.li; Robert Raszuk
> 
> > Cc: Christian Hopps ; draft-ietf-lsr-flex-
> algo@ietf.org; Les Ginsberg (ginsberg)
> ; lsr@ietf.org; lsr-...@ietf.org;
> Acee Lindem (acee) 
> > Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo
> >
> > [External Email. Be cautious of content]
> >
> >
> > Hi Shraddha,
> >
> > please see inline:
> >
> >
> > On 02/09/2020 06:45, Shraddha Hegde wrote:
> >> Peter,
> >>
> >> It is worthwhile to note the history of the flex-algo draft and the
> >> te-app draft and how many  backward incompatible changes have been
> >> introduced in the course of the flex-algo draft.
> >>
> >> The original drafts of flex-algo did not mention the te-app draft and
> >> was completely based on legacy advertisements.
> >> Two years ago, after the working group adopted the original drafts
> >> without the ASLA TLV, the text was changed to require the ASLA TLV.
> >
> > draft-ietf-lsr-flex-algo-00, which was the initial version of the WG
> document already mandated the ASLA usage. I don't believe we have to go
> back to the individual drafts that predated the WG version.
> >
> >>
> >>
> >> ASLA TLV had the L-Bit and it was always valid to advertise link
> >> attributes for flex-algo with L-bit set which means the link
> >> attributes could still be sent in legacy TLVs.
> >> In a conversation last year, you had agreed that advertising link
> >> attributes with L-bit set is valid for Flex-algo.
> >
> >
> > what we say in flex-algo draft in section 11 is:
> >
> >  "Link attribute advertisements that are to be used during Flex-
> >  Algorithm calculation MUST use the Application-Specific Link
> >  Attribute (ASLA) advertisements defined in [I-D.ietf-isis-te-app] or
> >  [I-D.ietf-ospf-te-link-attr-reuse]."
> >
> > ietf-isis-te-app clearly allows the app specific value of the attribute to 
> > be
> advertised in legacy 

Re: [Lsr] New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt

[bruno.decraene]

Ron, all,

>From a use case standpoint, I have a use case for having both SR-MPLS and IP 
>flexalgo in the same network.

>From a protocol standpoint, I think that the functionality could be equally 
>met by advertising SR-MPLS SID as per RFC 8667 but using a label 3 (implicit 
>null) to instruct the LER/LSR to not use a label in the forwarding plane. 
>(while still advertising a label in the control plane because we have to).
I feel that this would be less change in the protocol (no new tlv), a good fit 
for network requiring both MPLS and IP flex algo, and would not require 
implementations/network operator to duplicate the "prefix sub-TLV" [1] on both 
advertisements (IP based and SR-MPLS based).

That would still requires a protocol extension/STD track RFC as RFC 8667 does 
not allow for this. That would still require change to implementations as only 
the signalling is different while the feature/behavior is the same (i.e. no 
magic).

Regards,
--Bruno

[1] aka "Sub-TLVs for TLVs 135, 235, 236, and 237 (Extended IP reachability, MT 
IP. Reach, IPv6 IP. Reach, and MT IPv6 IP. Reach TLVs)"


> -Original Message-
> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Ron Bonica
> Sent: Tuesday, September 29, 2020 3:38 PM
> To: lsr@ietf.org
> Subject: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-
> 00.txt
> 
> 
> Please review and comment
> 
>Ron
> 
> 
> 
> Juniper Business Use Only
> 
> > -Original Message-
> > From: internet-dra...@ietf.org 
> > Sent: Tuesday, September 29, 2020 9:36 AM
> > To: Parag Kaneriya ; Shraddha Hegde
> > ; Ron Bonica ; Rajesh M
> > ; William Britto A J 
> > Subject: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt
> >
> > [External Email. Be cautious of content]
> >
> >
> > A new version of I-D, draft-bonica-lsr-ip-flexalgo-00.txt
> > has been successfully submitted by Ron Bonica and posted to the IETF
> > repository.
> >
> > Name:   draft-bonica-lsr-ip-flexalgo
> > Revision:   00
> > Title:  IGP Flexible Algorithms (Flexalgo) In IP Networks
> > Document date:  2020-09-29
> > Group:  Individual Submission
> > Pages:  14
> > URL:https://urldefense.com/v3/__https://www.ietf.org/id/draft-
> bonica-
> > lsr-ip-flexalgo-00.txt__;!!NEt6yMaO-gk!X7PVDP-
> > FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck80Zbjoij$
> > Status:
> > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-
> bonica-lsr-
> > ip-flexalgo/__;!!NEt6yMaO-gk!X7PVDP-
> > FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck8x7e5ZqI$
> > Htmlized:
> > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-
> > bonica-lsr-ip-flexalgo__;!!NEt6yMaO-gk!X7PVDP-
> > FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck82w_6CyU$
> > Htmlized:
> https://urldefense.com/v3/__https://tools.ietf.org/html/draft-
> > bonica-lsr-ip-flexalgo-00__;!!NEt6yMaO-gk!X7PVDP-
> > FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck81_QrJ_p$
> >
> >
> > Abstract:
> >An IGP Flexible Algorithm computes a constraint-based path and maps
> >that path to an identifier.  As currently defined, Flexalgo can only
> >map the paths that it computes to Segment Routing (SR) identifiers.
> >Therefore, Flexalgo cannot be deployed in the absence of SR.
> >
> >This document extends Flexalgo, so that it can map the paths that it
> >computes to IP addresses.  This allows Flexalgo to be deployed in any
> >IP network, even in the absence of SR.
> >
> >
> >
> >
> > Please note that it may take a couple of minutes from the time of
> submission
> > until the htmlized version and diff are available at tools.ietf.org.
> >
> > The IETF Secretariat
> >
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

_

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] New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt

[bruno.decraene]

Peter,

> From: Peter Psenak [mailto:ppse...@cisco.com]
> 
> Bruno,
> 
> On 19/10/2020 18:52, bruno.decra...@orange.com wrote:
> > Ron, all,
> >
> >>From a use case standpoint, I have a use case for having both SR-MPLS and
> IP flexalgo in the same network.
> >
> >>From a protocol standpoint, I think that the functionality could be equally
> met by advertising SR-MPLS SID as per RFC 8667 but using a label 3 (implicit
> null) to instruct the LER/LSR to not use a label in the forwarding plane. 
> (while
> still advertising a label in the control plane because we have to).
> 
> does not work,

I could provide more explanations, but reading your email, it seems to me that 
you understood the proposal.
So it seems to me that the opinion that you really meant is: it works but it 
would be an nasty hack.

Regarding "nasty hack" it could be interesting to have a normative definition. 
This could prove useful in some other contexts. 
BTW, is "max metric" a hack (vs creating a new tlv if you don't want the link 
in the IGP SPF), is "implicit null label" a hack. And for BGP, encoding the 
label in the NLRI...


Coming back to technical comments, note that creating yet another TLV to carry 
IP prefix also brings questions that the draft does not answer or even raise.
- What about the sub-TLVs? Are they shared with the existing registry for 
prefix TLV [1] ? Do we want to exclude some? E.g., Prefix Segment Identifier 
(we would have two algo fields, two ways to signal SIDs...)
- for IPv6, the content and meaning of  "ISIS MT IPv6 Flexalgo Prefix 
Reachability TLV" is essentially the same than the "SRv6 Locator TLV".
- Only the naming and the ordering of the fields are different.
- Why do we need two TLVs to advertise the same thing (essentially a 
Routing Algo)? Duplication means more spec, more code, more features to 
implement, more error and bugs. (and it did not took long: the draft defines 
the MTID field as 8 bits while RFC 5120 defines it a 12 bits.
- What is the functional different between FlexAlgo for SRv6 and 
FlexAlgo for IPv6? Both use the IPv6 destination address in the packet and the 
IPv6 FIB in the router.

Thanks,
Bruno

> as it does not allow you to associate the prefix with
> Flex-algo without advertising the reachability in algo 0. Making the
> prefix reachability in default algo conditional based on the presence of
> the Prefix SID Sub-TLV with Imnplicit Null would be a nasty hack.
> 
> Not to mention that advertising a Prefix SID in pure IP network would be
> ugly.
> 
> thanks,
> Peter
> 
> 
> 
> > I feel that this would be less change in the protocol (no new tlv), a good 
> > fit
> for network requiring both MPLS and IP flex algo, and would not require
> implementations/network operator to duplicate the "prefix sub-TLV" [1] on
> both advertisements (IP based and SR-MPLS based).
> >
> > That would still requires a protocol extension/STD track RFC as RFC 8667
> does not allow for this. That would still require change to implementations as
> only the signalling is different while the feature/behavior is the same (i.e. 
> no
> magic).
> >
> > Regards,
> > --Bruno
> >
> > [1] aka "Sub-TLVs for TLVs 135, 235, 236, and 237 (Extended IP reachability,
> MT IP. Reach, IPv6 IP. Reach, and MT IPv6 IP. Reach TLVs)"
> >
> >
> >> -Original Message-
> >> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Ron Bonica
> >> Sent: Tuesday, September 29, 2020 3:38 PM
> >> To: lsr@ietf.org
> >> Subject: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-
> flexalgo-
> >> 00.txt
> >>
> >>
> >> Please review and comment
> >>
> >> Ron
> >>
> >>
> >>
> >> Juniper Business Use Only
> >>
> >>> -Original Message-
> >>> From: internet-dra...@ietf.org 
> >>> Sent: Tuesday, September 29, 2020 9:36 AM
> >>> To: Parag Kaneriya ; Shraddha Hegde
> >>> ; Ron Bonica ; Rajesh M
> >>> ; William Britto A J 
> >>> Subject: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt
> >>>
> >>> [External Email. Be cautious of content]
> >>>
> >>>
> >>> A new version of I-D, draft-bonica-lsr-ip-flexalgo-00.txt
> >>> has been successfully submitted by Ron Bonica and posted to the IETF
> >>> repository.
> >>>
> >>> Name:   draft-bonica-lsr-ip-flexalgo
> >>> Revision:   00
> >>> Title:  IGP Flexible Algorithms (Flexalgo) In IP Networks
> >>> Document date:  2020-09-29
> >>> Group:  Individual Submission
> >>> Pages:  14
> >>> URL:https://urldefense.com/v3/__https://www.ietf.org/id/draft-
> >> bonica-
> >>> lsr-ip-flexalgo-00.txt__;!!NEt6yMaO-gk!X7PVDP-
> >>> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck80Zbjoij$
> >>> Status:
> >>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-
> >> bonica-lsr-
> >>> ip-flexalgo/__;!!NEt6yMaO-gk!X7PVDP-
> >>> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck8x7e5ZqI$
> >>> Htmlized:
> >>>
> 

Re: [Lsr] New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt

[bruno.decraene]

Peter,

> From: Peter Psenak [mailto:ppse...@cisco.com]
> 
> Bruno,
> 
> please see inline:
> 
> 
> 
> On 20/10/2020 11:43, bruno.decra...@orange.com wrote:
> > Peter,
> >
> >> From: Peter Psenak [mailto:ppse...@cisco.com]
> >>
> >> Bruno,
> >>
> >> On 19/10/2020 18:52, bruno.decra...@orange.com wrote:
> >>> Ron, all,
> >>>
> >>> >From a use case standpoint, I have a use case for having both SR-MPLS
> and
> >> IP flexalgo in the same network.
> >>>
> >>> >From a protocol standpoint, I think that the functionality could be
> equally
> >> met by advertising SR-MPLS SID as per RFC 8667 but using a label 3
> (implicit
> >> null) to instruct the LER/LSR to not use a label in the forwarding plane.
> (while
> >> still advertising a label in the control plane because we have to).
> >>
> >> does not work,
> >
> > I could provide more explanations, but reading your email, it seems to me
> that you understood the proposal.
> > So it seems to me that the opinion that you really meant is: it works but it
> would be an nasty hack.
> >
> > Regarding "nasty hack" it could be interesting to have a normative
> definition. This could prove useful in some other contexts.
> > BTW, is "max metric" a hack (vs creating a new tlv if you don't want the 
> > link
> in the IGP SPF), is "implicit null label" a hack. And for BGP, encoding the 
> label
> in the NLRI...
> 
> max-metric does not solve the problem, as you would need a prefix metric
> for non 0 algo anyway.

To clarify, my text was not a technical proposal related to that draft. It was 
referring to your email and questioning what exactly was a hack using some 
examples from the past.
But let's forget about this point, at least for the moment.

> > Coming back to technical comments, note that creating yet another TLV to
> carry IP prefix also brings questions that the draft does not answer or even
> raise.
> > - What about the sub-TLVs? Are they shared with the existing registry for
> prefix TLV [1] ? Do we want to exclude some? E.g., Prefix Segment Identifier
> (we would have two algo fields, two ways to signal SIDs...)
> 
> yes, these are details that needs to be addressed, but should not be a
> problem. Look at locator TLV in SRv6, very similar concept here.
> 
> > - for IPv6, the content and meaning of  "ISIS MT IPv6 Flexalgo Prefix
> Reachability TLV" is essentially the same than the "SRv6 Locator TLV".
> > - Only the naming and the ordering of the fields are different.
> > - Why do we need two TLVs to advertise the same thing (essentially a
> Routing Algo)? Duplication means more spec, more code, more features to
> implement, more error and bugs. (and it did not took long: the draft defines
> the MTID field as 8 bits while RFC 5120 defines it a 12 bits.
> 
> well, locator is a construct that is specific to SRv6. Sure you can
> advertise the prefix in a locator TLV without any SRv6 specific Sub-TLVs
> and achieve the same thing - I have already mentioned that in one of my
> responses, but that is again ugly.

So we agree that reusing the SRv6 locator TLV would work and provide the 
functionality. Good.
Now here comes again the "ugly" argument. If it's now becoming a technical 
argument, in my opinion, it's ugly to define two TLVs in order to advertise the 
same information and to provide the same functionality.

 
> > - What is the functional different between FlexAlgo for SRv6 and
> FlexAlgo for IPv6? Both use the IPv6 destination address in the packet and
> the IPv6 FIB in the router.
> 
> they are functionally the same.

Good to agree on this.
 
> I believe that having a clean encoding is preferable in a long run.

What do you mean by "clean encoding"? The only differences between both TLVs 
are the naming and the ordering of the fields.

> One
> can not advertise a prefix as SRv6 locator as well as IP flex-algo
> prefix (that would be an error), so duplication of data is not an
> issues.

So one should not advertise both TLVs? If so this becomes an error/issue? This 
feels like my point. There is no such issue with a single TLV.

> And having a dedicated TLV for each is better from both
> deployment and implementation perspective.

I can't see how implementing the same functionality twice would be better from 
an implementation perspective, but I leave this to you. I would suspect that 
you may consider only implementing one, not both.
I disagree on the deployment perspective. We would have two TLVs to advertise 
the same information and provide the exactly same functionality.  I can only 
see that this would bring deployment issues. e.g. one vendor implementing TLV A 
while another vendor implementing TLV B; hence no interoperability or a large 
delay to have both vendors implement both TLVs (or at least one vendor 
implementing both, presumably the smaller vendor).

Thanks,
--Bruno
 
> thanks,
> Peter
> 
> 
> 
> 
> >
> > Thanks,
> > Bruno
> >
> >> as it does not allow you to associate the prefix with
> >> Flex-algo without advertising the 

Re: [Lsr] Rtgdir last call review of draft-ietf-isis-te-app-13

[bruno.decraene]

Les,

Thanks for your answers.
Comments inline

> From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] 
> Sent: Saturday, May 30, 2020 12:09 AM
> 
> Bruno -
> 
> Thanx for your (as always) meticulous review.
> Responses inline.
> Once we have reached agreement I will send out an updated version.
> 
> > -Original Message-
> > From: Bruno Decraene via Datatracker 
> > Sent: Friday, May 29, 2020 10:18 AM
> > To: rtg-...@ietf.org
> > Cc: last-c...@ietf.org; draft-ietf-isis-te-app@ietf.org; lsr@ietf.org
> > Subject: Rtgdir last call review of draft-ietf-isis-te-app-13
> > 
> > Reviewer: Bruno Decraene
> > Review result: Has Issues
> > 
> >  Hello,
> > 
> > I have been selected as the Routing Directorate reviewer for this draft. The
> > Routing Directorate seeks to review all routing or routing-related drafts as
> > they pass through IETF last call and IESG review, and sometimes on special
> > request. The purpose of the review is to provide assistance to the Routing
> > ADs.
> > For more information about the Routing Directorate, please see
> > http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
> > 
> > Although these comments are primarily for the use of the Routing ADs, it
> > would
> > be helpful if you could consider them along with any other IETF Last Call
> > comments that you receive, and strive to resolve them through discussion or
> > by
> > updating the draft.
> > 
> > Document: draft-ietf-isis-te-app-13
> > Reviewer: Bruno Decraene
> > Review Date: 2020-05-29
> > IETF LC End Date: 2020-05-29
> > Intended Status: Standards Track
> > 
> > Summary:
> > I have some minor concerns about this document that I think should be
> > resolved before publication.
> > 
> > Comments:
> >   Draft is clear.
> > 
> > Minor Issues:
> > 
> > §4.1
> > *2 (for SABM & UDABM fields)
> > OLD: The length SHOULD be the minimum required to send all bits which are
> > set.
> > I'd propose
> > NEW: The length SHOULD be the minimum required to send all the
> > meaningful bits
> > which are set.
> > 
> > Motivation; the 'bits which are sent' are the bits in the SABM field. (they 
> > do
> > include non-meaningful and padding bits)
> > 
> 
> [Les:] The definition of what is "meaningful" and what is "padding"  to me is 
> ambiguous.
> Meaningful could be only those bits which are currently defined in the 
> registry (speaking of SABM here). But if there are 10 bits defined in the 
> registry and I only intend to set Bit 5, I do not need to send all 10 bits - 
> I only need to send one octet - because we state:
> 
> "Bits that are NOT transmitted MUST be treated as if they
   > are set to 0 on receipt.  "
> 
> Also, an implementation written when there were only 4 bits defined in the 
> registry might think that "meaningful" is different than an implementation 
> written when more than 8 bits were defined in the registry. Yet they can 
> still interoperate.
> 
> I believe the current language is best.

[Bruno]
I withdraw my comment. Sorry for the noise.
I had read "bits which are sent", while the text is "bits which are set".


> > 
> > 
> > OLD: Undefined bits MUST be transmitted as 0
> > NEW: Undefined transmitted bits MUST be cleared (0)
> > 
> > Motivation: currently the number of undefined bits is 8*8-3. They SHOULD
> > not be
> > transmitted (beyond the first ones fitting in the first N required octet). 
> > The
> > sentence "Undefined bits MUST be transmitted as 0" could be read as all
> > defined
> > bits MUST be transmitted (as 0).
> > ---
> [Les:] I do not see how that could be a valid interpretation given that we 
> state:
> 
> " The length SHOULD  be the minimum required to send all bits which are set."

[Bruno]
So we have
1) The length SHOULD  be the minimum required to send all bits which are set
2) Undefined bits MUST be transmitted as 0

Given the "MUST"  vs "SHOULD" and "transmitted" (which means "sent"), I do 
believe my proposal is better. But I won't insist.

 
> And (repeating)
> 
> "Bits that are NOT transmitted MUST be treated as if they
   > are set to 0 on receipt.  "
> 
> And again, you assume that "defined bits" is the same for all implementations 
> - which isn't guaranteed as I discussed above.

[Bruno] I don't think that this matter as the behavior is specific to the 
sender.
In addition, the term " Undefined bits" is yours.
 
> 
> > User Defined Application Identifier Bits have no name. I'd propose to call
> > them
> > UDABM[0], UDABM[1]... This may avoid that different implementation use
> > different names and, more problematic, that some implementations starting
> > with
> > 1 (the first, the second) while while some other implementations starts as 
> > 0,
> > creating interop issues (SABM[1] on node A is SABM[0] on node B)
> > ---
> 
> [Les:] What implementations may name bits they assign from the User space is 
> out of scope of this document.
> If I were implementing a non-standard User App I likely would give it a 
> meaningful name both in my code and in any 

Re: [Lsr] New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt

[bruno.decraene]

Les,


From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Monday, August 3, 2020 5:22 PM
To: DECRAENE Bruno TGI/OLN ; tony...@tony.li
Cc: lsr@ietf.org
Subject: RE: [Lsr] New Version Notification for 
draft-ietf-lsr-isis-area-proxy-02.txt

Bruno –

The concept of “Area SID” – at least to me – is “please forward to any node in 
the Area advertising the Area SID”.
[Bruno] How is that different from “anycast”? i.e. your option b?

You, however, seem to be asking for either:

a)The node originating the Proxy LSP to advertise a Node SID for a loopback 
address on that node

OR

b)The node originating the Proxy LSP to advertise an anycast SID which is 
shared by the IERs in the Proxy Area

To do so, it seems to me we need not invent a new type of SID, we can simply 
advertise using the existing Prefix Reachability/Prefix SID sub-TLVs.

So it seems you are not interested in an “Area SID”.

Can you please clarify?

[Bruno] I’m interested in the forwarding behavior defined in the draft: “all of 
the Inside Edge Nodes […] should consume this SID at forwarding time.” How we 
call this, I don’t really care. Could be area SID, or proxy SID or anycast SID… 
but for the external L2 nodes, there is no anycast behavior: just one single 
node/LSP/SID, so calling it anycast could be strange.


For me, the reason to invent a new type of SID and new forms of SID 
advertisements is because we were defining a SID with new functionality i.e., 
send this to another area – which entry point into the area is used should not 
matter.
[Bruno] From the external L2 nodes, the “area” is seen as a single node. “which 
entry point into the area is used ” equals “which interface of the (proxy) node 
is used. I’m not sure that we need a new concept.
From within area internal nodes, we do see the detail of the topology and need 
to advertise & agree on the area SID.
This seems like a property which might be useful – and might be useful outside 
of Area Proxy use cases as well. If however, we (the WG) see no need for this 
type of SID then we should remove these definitions and simply use the existing 
Prefix-SID advertisements.
[Bruno] The property is useful. I’m fine with the name & encoding in current 
and past draft.
I’m simply raising the point that this new advertisement will not be understood 
by vanilla external L2 nodes. Hence unless you upgrade all those external 
nodes, you have regression in the network, at least in the following use case: 
replacing a big chassis with a set of smaller nodes grouped in one area.

One other comment regarding your reference to 
https://tools.ietf.org/html/draft-ietf-spring-mpls-anycast-segments-03 .

https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-02#section-2.1 
already specifies that all inside nodes MUST have the “same SRGB”. So I do not 
see that your reference is relevant – unless you are proposing to change that.
[Bruno] You can safely forget about this reference.
I was trying to say that anycast SID is not new. And no, I’m not proposing to 
change that all node must use the same SRGB. (that been said, sometimes you 
need to use the implementation that are on the market. The concept of index + 
SRGB has only been designed because some nodes could not support a common SRGB.)
--Bruno

   Les

From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
bruno.decra...@orange.com
Sent: Monday, August 03, 2020 1:10 AM
To: tony...@tony.li
Cc: lsr@ietf.org
Subject: Re: [Lsr] New Version Notification for 
draft-ietf-lsr-isis-area-proxy-02.txt

Hi Tony,

From: Tony Li [mailto:tony1ath...@gmail.com] On Behalf Of 
tony...@tony.li
Subject: Re: [Lsr] New Version Notification for 
draft-ietf-lsr-isis-area-proxy-02.txt


Hi Bruno,

Thank you for the clarification.
[Bruno] You are very welcome. Thank you for listening.

 I understand completely what you’re trying to do and I agree that it’s 
valuable.

The downside of your approach is that the Area Leader will now need 
configuration of a new prefix to advertise as the Node SID.
[Bruno] Agreed.
I believe that the Area SID equally needs to be configured, so configuration is 
required in all cases. Given this, the extra effort seems marginal to me.
Not unthinkable.

What do the Inside Nodes do with this prefix, if anything?
[Bruno] good question. 2 options:
-  Drop traffic to control plane (i.e. IP is not supposed to be used)
-  Nothing really new: it’s an anycast IP/SID. There is even a draft 
for the more complex case where the SRGB is different on the anycast nodes . 
https://tools.ietf.org/html/draft-ietf-spring-mpls-anycast-segments-03

Regards,
--Bruno

I am open to this approach, either in addition to, or instead of the approach 
currently in the draft.  I await feedback from the WG.

Regards,
Tony



p.s. The fact that the node SID requires a prefix is just a side effect of the 
IP address space excluding hosts from 

Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02

[bruno.decraene]

Les,

Please see inline.

From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Tuesday, August 4, 2020 4:50 PM
To: DECRAENE Bruno TGI/OLN ; lsr@ietf.org
Subject: RE: draft-ietf-lsr-isis-area-proxy-02

Bruno -

Please see inline.

From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
bruno.decra...@orange.com
Sent: Tuesday, August 04, 2020 5:45 AM
To: lsr@ietf.org
Subject: [Lsr] draft-ietf-lsr-isis-area-proxy-02

Hi,

I may be missing something but the SR Binding SID TLV extension  is not clear 
to me.

1)  It does not seem compliant with RFC 8667

Draft says that the advertisement has: T-flag set, M & A flags cleared, 
SID/Label sub-TLV present, Prefix-SID sub-TLV NOT present


The following extensions to the Binding TLV are defined in order to

   support Area SID:



  A new flag is defined:



 T-flag: The SID directs traffic to an area.  (Bit 5)



 When T-flag is set:



M and A flag MUST be clear



Range and Prefix are ignored



  Section 2.4.4 of RFC 
8667 is altered to say:



 "The Prefix-SID sub-TLV MUST be present in the SID/Label

 Binding TLV when the M-Flag and T-flag are both clear.  The

 Prefix-SID sub-TLV MUST NOT be present when either the M-Flag

 or T-flag are set."



  Regarding the SID/Label sub-TLV Section 2.4.5 of RFC 
8667 is

  altered to say:



 "It MUST be present in the SID/Label Binding TLV when either

 the M-Flag or T-flag is set in the Flags field of the parent

 TLV."

https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-02#page-14



By definition, legacy L2 external  node will support vanilla RFC 8667, which 
says:
"The Prefix-SID sub-TLV MUST be present in the SID/Label Binding TLV when the 
M-Flag is clear."
https://www.rfc-editor.org/rfc/rfc8667.html#name-sid-label-binding-tlv

So it seems that the extension violates the above MUST in RFC8667, as regarding 
the Prefix-SID sub-TLV
-  Area proxy says "MUST NOT be present" (as T-flag is set)
-  RFC 8667 says "MUST be present" (as M-flag is cleared)


In addition to the above, legacy node _will_ interpret the 'Range' and 'Prefix' 
fields. So there is probably a need to specify which values need to be 
advertised for those legacy nodes. A priori range would be one as a single SID 
is advertised. Prefix seems more problematic as you need to find an IP prefix 
to advertise. And please let's avoid SID conflict and Prefix conflict...
[Les:] Format of the Binding TLV when the new T-bit is set is similar to the 
format when the M-bit is set in that Prefix-SID sub-TLV is NOT present.
A legacy node parsing the Binding TLV would be looking for the Prefix-SID 
sub-TLV (M-bit NOT set) and would not find it. The contents of the Binding TLV 
would therefore be unusable to a legacy node.
The correct behaviour for a legacy node would be to (optionally) report an 
"invalid TLV" and to ignore the TLV.
[Bruno]
Clearly, there is a way to advertise the SID without violating a MUST in a RFC. 
e.g. version -00 of this draft
I don't see a reason to define a spec which deliberately violates another spec. 
In the best case, this would report errors forever to the network operator. In 
the worst case, this could fall into a bug.


2)  It's not clear to me whether the segment/SID is global or local.
As per my understanding of the draft-ietf-lsr-isis-area-proxy use case, the 
area-proxy SID would be global (in the external L2): "Area SID which will 
direct traffic to any of the Inside Edge Routers."

But the SID/Label Sub-TLV used by area-proxy has no flag (L-flag) indicating 
whether the SID is global or local. One could argue that if it carries a label 
it's a local SID and if it carries and index it's a global SID. But this has 
not been specified.
It has also no "algorithm" indicating how it needs to be routed global, so at 
minimum would not work with different routing algo/flex algo.
I'm not seeing in RFC 8402 or 8667 any text saying that such SID would be 
global hence globally routed in the L2 domain. (To me, this IS-IS SID was 
local, but arguably also can't find text stating this).

[Les:] There is a subtle difference between the Prefix-SID sub-TLV as defined 
in https://www.rfc-editor.org/rfc/rfc8667.html#section-2.1 and the SID/Label 
sub-TLV defined in https://www.rfc-editor.org/rfc/rfc8667.html#SIDLABELSUBTLV

The Prefix-SID sub-TLV has a flags field which includes V-bit/L-bit to indicate 
whether the variable length field which follows is a 3 byte label (both bits 
set to 1) or a 4 byte index (both bits set to 0).

The SID/Label sub-TLV has no flags field. The length of the sub-TLV indicates 
whether the advertised value has is a label (length = 3)  or an index (length = 
4).

[Bruno] Agreed so far.
Do we agree that 

[Lsr] draft-ietf-lsr-isis-area-proxy-02

[bruno.decraene]

Hi,

I may be missing something but the SR Binding SID TLV extension  is not clear 
to me.


1)  It does not seem compliant with RFC 8667

Draft says that the advertisement has: T-flag set, M & A flags cleared, 
SID/Label sub-TLV present, Prefix-SID sub-TLV NOT present


The following extensions to the Binding TLV are defined in order to

   support Area SID:



  A new flag is defined:



 T-flag: The SID directs traffic to an area.  (Bit 5)



 When T-flag is set:



M and A flag MUST be clear



Range and Prefix are ignored



  Section 2.4.4 of RFC 
8667 is altered to say:



 "The Prefix-SID sub-TLV MUST be present in the SID/Label

 Binding TLV when the M-Flag and T-flag are both clear.  The

 Prefix-SID sub-TLV MUST NOT be present when either the M-Flag

 or T-flag are set."



  Regarding the SID/Label sub-TLV Section 2.4.5 of RFC 
8667 is

  altered to say:



 "It MUST be present in the SID/Label Binding TLV when either

 the M-Flag or T-flag is set in the Flags field of the parent

 TLV."

https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-02#page-14



By definition, legacy L2 external  node will support vanilla RFC 8667, which 
says:
"The Prefix-SID sub-TLV MUST be present in the SID/Label Binding TLV when the 
M-Flag is clear."
https://www.rfc-editor.org/rfc/rfc8667.html#name-sid-label-binding-tlv

So it seems that the extension violates the above MUST in RFC8667, as regarding 
the Prefix-SID sub-TLV

-  Area proxy says "MUST NOT be present" (as T-flag is set)

-  RFC 8667 says "MUST be present" (as M-flag is cleared)


In addition to the above, legacy node _will_ interpret the 'Range' and 'Prefix' 
fields. So there is probably a need to specify which values need to be 
advertised for those legacy nodes. A priori range would be one as a single SID 
is advertised. Prefix seems more problematic as you need to find an IP prefix 
to advertise. And please let's avoid SID conflict and Prefix conflict...


2)  It's not clear to me whether the segment/SID is global or local.
As per my understanding of the draft-ietf-lsr-isis-area-proxy use case, the 
area-proxy SID would be global (in the external L2): "Area SID which will 
direct traffic to any of the Inside Edge Routers."

But the SID/Label Sub-TLV used by area-proxy has no flag (L-flag) indicating 
whether the SID is global or local. One could argue that if it carries a label 
it's a local SID and if it carries and index it's a global SID. But this has 
not been specified.
It has also no "algorithm" indicating how it needs to be routed global, so at 
minimum would not work with different routing algo/flex algo.
I'm not seeing in RFC 8402 or 8667 any text saying that such SID would be 
global hence globally routed in the L2 domain. (To me, this IS-IS SID was 
local, but arguably also can't find text stating this).

At minimum, area-proxy would need to specify whether the SID is global and 
local. And if global, with which hard coded algorithm it is routed. (I would 
assume "0")


Thanks,
Regards,
--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] New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt

[bruno.decraene]

Hi Tony,

From: Tony Li [mailto:tony1ath...@gmail.com] On Behalf Of tony...@tony.li
Subject: Re: [Lsr] New Version Notification for 
draft-ietf-lsr-isis-area-proxy-02.txt


Hi Bruno,

Thank you for the clarification.
[Bruno] You are very welcome. Thank you for listening.

 I understand completely what you’re trying to do and I agree that it’s 
valuable.

The downside of your approach is that the Area Leader will now need 
configuration of a new prefix to advertise as the Node SID.
[Bruno] Agreed.
I believe that the Area SID equally needs to be configured, so configuration is 
required in all cases. Given this, the extra effort seems marginal to me.
Not unthinkable.

What do the Inside Nodes do with this prefix, if anything?
[Bruno] good question. 2 options:

-  Drop traffic to control plane (i.e. IP is not supposed to be used)

-  Nothing really new: it’s an anycast IP/SID. There is even a draft 
for the more complex case where the SRGB is different on the anycast nodes . 
https://tools.ietf.org/html/draft-ietf-spring-mpls-anycast-segments-03

Regards,
--Bruno

I am open to this approach, either in addition to, or instead of the approach 
currently in the draft.  I await feedback from the WG.

Regards,
Tony



p.s. The fact that the node SID requires a prefix is just a side effect of the 
IP address space excluding hosts from addressing. The one, true
way within IS-IS is the system ID, a separate, independent namespace for nodes 
that simply avoids ALL of these problems.  If RFC 8667
encoded node SIDs as their own TLV without the unnecessary prefix that OSPF’s 
style mandates, this would be trivial.




On Jul 31, 2020, at 2:24 AM, 
bruno.decra...@orange.com wrote:

Hi Tony,

Thank you for your reply.
Top posting the description of the use case that I have in mind.

>  First off, the Area SID is 100% optional. If you choose not to use it, then 
> the Proxy LSP should be 100% compatible with a standard L2 node.
Good. But I think that the idea of the Area SID is a good one, and I choose to 
use it. Then I’d like to get it for free ;-)


Please fine below a network topology:



My understanding is that the L2 topology seen by node S is the following


P been the Proxy LSP.

S wants to protect from the failure of link S-C by using TI-LFA. For the 
destination C, it would push 2 (*) node SIDs: P, C
So S needs a Node SID for P:
a)  If P does not redistribute the Node SIDs from its area members, P does 
not seem to advertise any node SID currently. There is a chance that C’s TI-LFA 
implementation would not like it and hence would not install protection for 
this (link, destination)
b)  If P redistributes the Node SIDs from its area members, P advertises 3 
node SIDs (1,2, 3). S could pick any one at random. If it picks 3, the 
forwarding path would be S, A,B, 1, 2, 3, 2 , 1, C,  which is suboptimal.

Two solutions I could think of:
- when redistributing the node SID, P changes the SIDs values and replace them 
with the value of the Area SID. This works for this use case, but it is 
borderline. (e.g. if some a L2 node learn both the original and ‘NATed’ SID, we 
have some SID conflict. Let’s try to avoid this subject).
- P could advertise its own Node-SID with the Area SID value. This is what I’m 
proposing. Both the IP loopback and the Area SID of this Node SID  are likely 
configured by the network operator so this does not seem like a significant 
effort from the implementation.

As you say, this does not involve any protocol extension. But the goal is to 
improve interop with existing/legacy L2 nodes so this may be valuable in the 
draft. This point could be pushed to a deployment consideration section if you 
don’t want any impact on the protocol extension.

Thanks,
--Bruno

(*) Assuming the right metrics on the links. This is not the subject of this 
thread.


From: Tony Li [mailto:tony1ath...@gmail.com] On Behalf Of 
tony...@tony.li
Sent: Thursday, July 30, 2020 7:39 PM
To: DECRAENE Bruno TGI/OLN 
mailto:bruno.decra...@orange.com>>
Cc: lsr@ietf.org
Subject: Re: [Lsr] New Version Notification for 
draft-ietf-lsr-isis-area-proxy-02.txt


Hi Bruno,

Thank you for your comments.




On Jul 30, 2020, at 9:22 AM, 
bruno.decra...@orange.com wrote:

Hi Tony,

Thanks for the updated draft.

“ The Area SID Sub-TLV allows the Area Leader to advertise a SID that
   represents the entirety of the Inside Area to the Outside Area.  This
   sub-TLV is learned by all of the Inside Edge Nodes who should consume
   this SID at forwarding time.”

Excellent, from my perspective.

>  - The Area Segment SID TLV has been replaced by extending the Binding SID 
> TLV.


“When SR is enabled, it may be useful to advertise an Area SID which

   will direct traffic to any of the Inside Edge Routers.  The Binding/

   MT Binding TLVs described in RFC 8667 Section 

[Lsr] draft-ietf-lsr-flex-algo

[bruno.decraene]

Hi all,

I can live with the current text, but I'm just raising the point for discussion 
(better safe than sorry).

"16.1.1.  IGP Algorithm Types Registry

   This document makes the following registrations in the "IGP Algorithm Types" 
registry:

  Type: 128-255.

  Description: Flexible Algorithms.
"
https://tools.ietf.org/html/draft-ietf-lsr-flex-algo-07#section-16.1.1

This is essentially burning half of the registry for flex-algo. Indeed, any 
network operator could use any value, e.g. 222, hence the IETF could never 
define a different usage for this value without creating interop issues for the 
network operator.

We could discuss whether we really need 127 values for this. (i.e. a network 
operator requiring 127 flex algo, typically multiplying its IGP FIB entries by 
127...).
We could also discuss whether this range could be change to the IANA well-known 
"Private Use" [1]. This would allow for alternative private usages in the 
future (e.g. Flexible Alorithms v2).
[1] https://tools.ietf.org/html/rfc8126#section-4.1

It seems to me that the latter would equally work for flex algo, but would 
provide more flexibility :-) for the future.

Regards,
--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] draft-ietf-lsr-flex-algo

[bruno.decraene]

Hi Peter,

Thanks for your reply.

> From: Peter Psenak [mailto:ppse...@cisco.com]
> 
> Hi Bruno,
> 
> please see inline:
> 
> On 30/06/2020 16:53, bruno.decra...@orange.com wrote:
> > Hi all,
> >
> > I can live with the current text, but I'm just raising the point for 
> > discussion
> (better safe than sorry).
> >
> > "16.1.1.  IGP Algorithm Types Registry
> >
> > This document makes the following registrations in the "IGP Algorithm
> Types" registry:
> >
> >Type: 128-255.
> >
> >Description: Flexible Algorithms.
> > "
> > https://tools.ietf.org/html/draft-ietf-lsr-flex-algo-07#section-16.1.1
> >
> > This is essentially burning half of the registry for flex-algo. Indeed, any
> network operator could use any value, e.g. 222, hence the IETF could never
> define a different usage for this value without creating interop issues for 
> the
> network operator.
> 
> what is the real problem? Is the space 2-127 that is free not sufficient
> for other standardized algorithms that may come?
> 
> >
> > We could discuss whether we really need 127 values for this. (i.e. a
> network operator requiring 127 flex algo, typically multiplying its IGP FIB
> entries by 127...).
> 
> above is not necessarily true and more importantly completely irrelevant
> to the number of algos we reserve for FA.
> 
> 
> > We could also discuss whether this range could be change to the IANA well-
> known "Private Use" [1]. This would allow for alternative private usages in
> the future (e.g. Flexible Alorithms v2).
> > [1] https://tools.ietf.org/html/rfc8126#section-4.1
> >
> > It seems to me that the latter would equally work for flex algo, but would
> provide more flexibility :-) for the future.
> 
> I don't think so. We need an allocated range of algos for FA for
> compatibility.

The allocated range of algos for FA would be the same. Just not dedicated to FA.

--Bruno
 
> 
> thanks,
> Peter
> >
> > Regards,
> > --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
> >
> >


_

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] draft-ietf-lsr-flex-algo

[bruno.decraene]

Hi Peter,

> From: Peter Psenak [mailto:ppse...@cisco.com]
> 
> Hi Bruno,
> 
> On 30/06/2020 18:08, bruno.decra...@orange.com wrote:
> > Hi Peter,
> >
> > Thanks for your reply.
> >
> >> From: Peter Psenak [mailto:ppse...@cisco.com]
> >>
> >> Hi Bruno,
> >>
> >> please see inline:
> >>
> >> On 30/06/2020 16:53, bruno.decra...@orange.com wrote:
> >>> Hi all,
> >>>
> >>> I can live with the current text, but I'm just raising the point for
> discussion
> >> (better safe than sorry).
> >>>
> >>> "16.1.1.  IGP Algorithm Types Registry
> >>>
> >>>  This document makes the following registrations in the "IGP Algorithm
> >> Types" registry:
> >>>
> >>> Type: 128-255.
> >>>
> >>> Description: Flexible Algorithms.
> >>> "
> >>> https://tools.ietf.org/html/draft-ietf-lsr-flex-algo-07#section-16.1.1
> >>>
> >>> This is essentially burning half of the registry for flex-algo. Indeed, 
> >>> any
> >> network operator could use any value, e.g. 222, hence the IETF could
> never
> >> define a different usage for this value without creating interop issues for
> the
> >> network operator.
> >>
> >> what is the real problem? Is the space 2-127 that is free not sufficient
> >> for other standardized algorithms that may come?
> >>
> >>>
> >>> We could discuss whether we really need 127 values for this. (i.e. a
> >> network operator requiring 127 flex algo, typically multiplying its IGP FIB
> >> entries by 127...).
> >>
> >> above is not necessarily true and more importantly completely irrelevant
> >> to the number of algos we reserve for FA.
> >>
> >>
> >>> We could also discuss whether this range could be change to the IANA
> well-
> >> known "Private Use" [1]. This would allow for alternative private usages in
> >> the future (e.g. Flexible Alorithms v2).
> >>> [1] https://tools.ietf.org/html/rfc8126#section-4.1
> >>>
> >>> It seems to me that the latter would equally work for flex algo, but
> would
> >> provide more flexibility :-) for the future.
> >>
> >> I don't think so. We need an allocated range of algos for FA for
> >> compatibility.
> >
> > The allocated range of algos for FA would be the same. Just not dedicated
> to FA.
> 
> this would not work. If I have a mix of routers, one set using value 222
> for flex-algo and another set for something else, how are they going to
> interoperate?

My understanding is that the value of the flexalgo is chosen by the network 
operator and configured on the router. 

" We want the mapping between the Flex-Algorithm and it's meaning to be 
flexible and defined by the user."
[...]
" Flexible-Algorithm is a numeric identifier in the range 128-255 that
   is associated via provisioning with the Flexible-Algorithm
   Definition."


IOW, "private or local use only, with the type and
   purpose defined by the local site.  No attempt is made to prevent
   multiple sites from using the same value in different (and
   incompatible) ways.  IANA does not record assignments from registries
   or ranges with this policy (and therefore there is no need for IANA
   to review them) and assignments are not generally useful for broad
   interoperability.  It is the responsibility of the sites making use
   of the Private Use range to ensure that no conflicts occur (within
   the intended scope of use)."

Which is the definition of Private Use by IANA.


> We need a standardized range, using Private Use is not an option here.

Yes we need a standardized range.
I'm not sure that this range needs to be dedicated to FA. But I leave this to 
you/the WG.

And thanks again for your active engagement in the discussion.

-- Bruno

> thanks,
> Peter
> 
> >
> > --Bruno
> >
> >>
> >> thanks,
> >> Peter
> >>>
> >>> Regards,
> >>> --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
> >>> 

[Lsr] draft-li-lsr-isis-area-proxy-06 & draft-przygienda-lsr-flood-reflection-01

[bruno.decraene]

Hi all,

I've quickly read both drafts.
In general, I don't think that I have spent enough time on the subject to 
provide any feedback on the list, but I've been suggested that some feedback is 
better than none. So providing some feedback for what it worth (2 cents).

I think that the use case is valid and worth working on.

In general, I think that a single solution would be better than two or one per 
vendor. Especially since the design choice of using a set of standard routers 
in the area/clos (rather than a proprietary chassis or a proprietary switch 
matrix) is an indication that interoperability is seen as a benefit. Yet the 
outcomes of both solutions are different so maybe they may also be considered 
as independent.

I'm personally fine with the approach chosen in draft-li-lsr-isis-area-proxy, 
which seems a good fit for the use case.
I think that the document could better highlight, to the reader and especially 
to a casual network operator reader, that the use of one proxy LSP/node to 
represent all Inside Edge Router/whole introduces some tradeoff. IOW this is 
not magic/transparent. In particular I'm thinking of router capability TLV and 
more generally (new) TLV: when different inside (edge) nodes advertise 
different capabilities/TLV there is a difficulty in aggregating all for the 
proxy node/LSP. I appreciate that the authors have considered the Segment 
Routing (SR) case, but there are others, both past and future. For existing 
TLV/capabilities, maybe I would favor that the document define the behavior for 
all TLV/capability (along "you fix what you break"). I understand that this is 
a significant work and that different people may have different opinion. In 
particular I'm concerned when both primary and backup area leaders are from 
different implementations and switching from one to another would create a chang
 e in the characteristic of the proxy node, which could impact L2 routing (e.g. 
change in node admin tag). For future TLV/work, I think that the document 
should highlight that the behavior for proxy LSP need to be considered and 
specified.


I've read draft-przygienda-lsr-flood-reflection. It is well written and works.
Regarding flooding:
a) IMHO I'm a bit scared with L2 flooding over tunnel: during L1 IGP 
convergence IP packet may be dropped including L2 LSP over IP tunnels. I don't 
feel that IS-IS is so good today to recover from lost LSP, in term of time 
required. The use of a TCP/SCTP tunnel may help, in which case there would be 
the question of not also using TCP for P2P adjacency, in order to handle flow 
control and congestion control and improve flooding speed. [1] proposes a 
modest improvement on faster recovery of lost LSP but this is also an 
individual document and will not completely remove the issue.
b) the use of configured flood reflector in order to simplify the flooding 
topology may possibly be replaced by an existing flooding graph reduction e.g. 
[2] The properties are a bit different, such as the requirement for new feature 
on all nodes. However given the proposed L1 topology, we could also considerer 
that dynamic flooding would also be useful/used in L1. This would avoid the 
definition of another mechanism to reduce the flooding graph.

Regarding L2 topology:
a) the outcome and the scaling seem different between both drafts. Flood 
reflection keeps all L1/L2 edge nodes in the L2 topology. This allows for 
better description of those nodes capabilities in the L2 LSDB. However the gain 
in term of number of nodes/LSP in the LS2DB seem limited (only the spine nodes 
are hidden, while area proxy hide both spine and leaf nodes). So the main 
benefit seems to be related to flooding graph reduction rather than reduction 
of the L2 topology/LSDB. Yet we already have solution for reducing the flooding 
graph [2].
b) I think that the document should also discuss the TLV/capabilities 
advertised by the Flood Reflector in the L2 topology. In particular when 
Segment Routing is enabled.

[1] 
https://tools.ietf.org/html/draft-decraene-lsr-isis-flooding-speed-03#section-5
[2] https://tools.ietf.org/html/draft-ietf-lsr-dynamic-flooding

Regards,
--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 

Re: [Lsr] Rtgdir last call review of draft-ietf-isis-te-app-13

[bruno.decraene]

Les,

Thanks for the updated draft.
Looks ok to me except the point on interoperability. 

Indeed, I was asking to reinforce the requirement for interoperability with 
existing attributes, as this interop issue is created by this 
specification/extension. But you chose the opposite direction by calling 
existing routers "legacy routers" and by removing the "must" in the below 
sentence from -13 "must be able to co-exist with use  of the legacy 
advertisements by routers which do not support the extensions defined in this 
document.".
IMHO this document was primarily motivated by interoperability issues with 
implementations. This was correctly pointed out in [1], more specifically " 
Existing IS-IS standards do not provide a mechanism to explicitly indicate 
whether or not RSVP has been enabled on a link.  Instead, different RSVP-TE 
implementations have used the presence of certain traffic engineering sub-TLVs 
in IS-IS to infer that RSVP signalling is enabled on a given link."

In such condition, IMHO draft-ietf-isis-te-app should not have the potential to 
create new interop issues in the future, otherwise its net gain with regards to 
existing ("legacy") attributes seems debatable to me.

Moving the requirement for interoperability on the deployment side (i.e., 
network operator) as per -14, may prove difficult or impossible if implementers 
are not willing to accommodate. Given that, as you state it, there motivation 
is what's good for _their_ business, it seems a possibility that such vendor 
would argue that the network operator should just replace all their "older" 
routers with new ones, and as a matter of luck, they do have a very good deal 
to propose. I have seen this movie before (e.g. with LDP & TDP).

I also understand your point as a vendor.
After thinking about it for a while, I'd propose a resolution around indicating 
that interoperability is required but only for implementations supporting both 
new and current attributes. This cover my point for interop and a priori cover 
your point to allow implementation to only support the new attributes.

e.g. with the below text in §6.1
OLD:
Under the conditions defined above, implementations which support the
   extensions defined in this document have the choice of using legacy
   advertisements or application specific advertisements in support of
   SRTE and/or LFA.  This will require implementations to provide
   controls specifying which type of advertisements are to be sent/
   processed on receive for these applications.

NEW:
Under the conditions defined above, implementations which support 
both the legacy advertisements and the extensions defined in this document MUST 
provide controls  specifying which type of
advertisements are to be sent and which type of advertisements are to be 
processed on receive for these applications.

Or possibly much closer to your original text
NEW2
Under the conditions defined above, implementations which support
 both the legacy advertisements and the extensions defined in this document
have the choice of using legacy
   advertisements or application specific advertisements in support of
   SRTE and/or LFA.  Implementations are REQUIRED to provide
   controls specifying which type of advertisements are to be sent/
   processed on receive for these applications.


I would also revert the text in section 6.3 to the one present in version -13.

Thank you
--Bruno

[1] 
https://datatracker.ietf.org/doc/html/draft-hegde-isis-advertising-te-protocols-03#section-1
  
 
> From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] 
> 
> Bruno -
> 
> Thanx again for your review.
> V14 of the draft has been posted to address your comments.
> 
> Please let me know if you believe there are still outstanding issues.
> 
> A few more remarks inline.
> 
> > -Original Message-
> > From: bruno.decra...@orange.com 
> > Sent: Tuesday, June 02, 2020 9:33 AM
> > To: Les Ginsberg (ginsberg) 
> > Cc: last-c...@ietf.org; draft-ietf-isis-te-app@ietf.org; lsr@ietf.org; 
> > rtg-
> > d...@ietf.org
> > Subject: RE: Rtgdir last call review of draft-ietf-isis-te-app-13
> > 
> > Les,
> > 
> > Thanks for your answers.
> > Comments inline
> > 
> > > From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
> > > Sent: Saturday, May 30, 2020 12:09 AM
> > >
> > > Bruno -
> > >
> > > Thanx for your (as always) meticulous review.
> > > Responses inline.
> > > Once we have reached agreement I will send out an updated version.
> > >
> > > > -Original Message-
> > > > From: Bruno Decraene via Datatracker 
> > > > Sent: Friday, May 29, 2020 10:18 AM
> > > > To: rtg-...@ietf.org
> > > > Cc: last-c...@ietf.org; draft-ietf-isis-te-app@ietf.org; 
> > > > lsr@ietf.org
> > > > Subject: Rtgdir last call review of draft-ietf-isis-te-app-13
> > > >
> > > > Reviewer: Bruno Decraene
> > > > Review result: Has Issues
> > > >
> > > >  Hello,
> > > >
> > > > I have been selected as the Routing Directorate reviewer for this draft.
> > The

Re: [Lsr] WG adoption call for draft-li-lsr-isis-area-proxy-06

[bruno.decraene]

Hi Chris, Acee,

I support adoption.
I've provided comments on the draft a couple of days ago.

Regards,
--Bruno

-Original Message-
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps
Sent: Wednesday, June 10, 2020 9:28 PM
To: lsr@ietf.org
Cc: lsr-cha...@ietf.org; lsr-...@ietf.org; Christian Hopps
Subject: [Lsr] WG adoption call for draft-li-lsr-isis-area-proxy-06

This begins a 2 week WG adoption call for the following draft:

  https://datatracker.ietf.org/doc/draft-li-lsr-isis-area-proxy/

The draft would be adopted on the Experimental track.

Please indicate your support or objection by June 24, 2020.

Authors, please respond to the list indicating whether you are aware of any IPR 
that applies to this draft.

Thanks,
Chris and Acee.

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

_

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

[Lsr] FW: New Version Notification for draft-decraene-lsr-isis-flooding-speed-04.txt

[bruno.decraene]

Hi WG,

Following our presentation at the latest LSR interim meeting, we have updated 
the draft as presented and discussed during the meeting.

High level changes are:
o  Adding general introduction on flow control, congestion control, loss 
detection and recovery.
o  Reorganizing sections as per the high level functions: flow control, 
congestion control, loss detection and recovery.
o  Adding a section on congestion control.

Low level diff are: 
https://www.ietf.org/rfcdiff?url2=draft-decraene-lsr-isis-flooding-speed-04

Comments are welcomed.
Thanks,
--Bruno

-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
Sent: Wednesday, June 10, 2020 5:37 PM
To: Gunter Van de Velde; Chris Bowers; Tony Li; Jayesh J; DECRAENE Bruno TGI/OLN
Subject: New Version Notification for 
draft-decraene-lsr-isis-flooding-speed-04.txt


A new version of I-D, draft-decraene-lsr-isis-flooding-speed-04.txt
has been successfully submitted by Bruno Decraene and posted to the
IETF repository.

Name:   draft-decraene-lsr-isis-flooding-speed
Revision:   04
Title:  IS-IS Flooding Parameters advertisement
Document date:  2020-06-10
Group:  Individual Submission
Pages:  15
URL:
https://www.ietf.org/internet-drafts/draft-decraene-lsr-isis-flooding-speed-04.txt
Status: 
https://datatracker.ietf.org/doc/draft-decraene-lsr-isis-flooding-speed/
Htmlized:   
https://tools.ietf.org/html/draft-decraene-lsr-isis-flooding-speed-04
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-decraene-lsr-isis-flooding-speed
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-decraene-lsr-isis-flooding-speed-04

Abstract:
   This document proposes a mechanism that can be used to increase the
   speed at which link state information is exchanged between two
   routers when multiple LSPs need to be flooded, such as in case of a
   node failure.  It also reduces the likelihood of overloading the
   router receiving the LSPs, causing LSPs losses and delayed
   retransmission.  This document defines a new TLV to be advertised in
   SNP and/or Hello messages.  This TLV may carry a set of parameters
   indicating the performance capacity to receive LSPs: the number of
   LSPs which can the received back to back, the minimum delay between
   further two consecutive LSPs and the minimum delay before
   retransmission of an LSP.


  


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



_

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] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

[bruno.decraene]

Another data point about advertising more detailed reachability/unreachability: 
https://tools.ietf.org/html/draft-swallow-isis-detailed-reach-01

(for IPv6 some form of compression may be beneficial).

--Bruno

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Robert Raszuk
Sent: Tuesday, July 28, 2020 11:18 AM
To: Acee Lindem (acee) 
Cc: Aijun Wang ; Zhibo Hu ; Yaqun 
Xiao ; lsr@ietf.org
Subject: Re: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt

Hello Acee,

I would like to question your assessment that signalling unreachable routes is 
unnecessary.

Imagine hierarchical network with areas. Under no failures area 1 advertises to 
area 0 summary LSA with 1.1.1.0/24. That block covers PE's 
loopbacks which within the area are /32s. Those loopbacks are also BGP next 
hops.

Now imagine PE1 with 1.1.1.1/32 fails. Well till BGP 
reconverges all paths advertised by this PE with 1.1.1.1/32 
are still valid as this next hop is still reachable entire network wide. That 
means that traffic is being sent to this failed PE1 for relatively long period 
of time.

It seems natural that without breaking benefits of summarization across areas 
or domains in the above scenario we could continue to advertise 
1.1.1.0/24 - 1.1.1.1/32. That is when I 
see most benefits of advertising unreachability aka negative routing.

Of course said all of the above - if you search your employer's archives - you 
will see a proposal where the above mechanism can be done within BGP itself 
with no touch to the IGP - just using a bit of twisted next hop validation 
steps and BGP native recursion. I am not going to make any judgements here 
which method is better or easier - naturally I personally like BGP one more :).

But I hope this is clear why at least discussion on the subject is important. 
It also illustrates why the below statement is not necessarily correct:

"Note that the unreachability of a given summarized prefix is only relevant if 
it is reachable through another ABR. "

Kind regards,
Robert.


On Mon, Jul 27, 2020 at 7:51 PM Acee Lindem (acee) 
mailto:40cisco@dmarc.ietf.org>> wrote:
Speaking as an LSR Working Group member:

Asking the WG precisely how to advertise prefix unreachability is the wrong 
question - it is analogous to asking whether to use a car or truck to drive off 
the edge of a cliff. Rather than messing up OSPF and IS-IS with these complex 
and unnecessary mechanisms, it would be better to address the requirement in 
your network design. Note that the unreachability of a given summarized prefix 
is only relevant if it is reachable through another ABR. In this case, the 
network design should provide adequate intra-area redundancy to provide 
communications between the ABRs. If this cannot be accomplished, an intra-area 
adjacency should be established over a tunnel between the ABRs in the backbone. 
Contrary to section 6.1, Looping is normally not a problem as ABRs should add 
back hole routes for their advertised summaries.

Acee

On 7/26/20, 9:34 PM, "Lsr on behalf of Aijun Wang" 
mailto:lsr-boun...@ietf.org> on behalf of 
wang...@chinatelecom.cn> wrote:

Hi, LSR experts:

We have uploaded the new version of this PUA(Prefix Unreachable 
Announcement) draft. The main updates are the followings:
1) Describes the solution that using tunnel to redirect traffic among ABRs, 
when all ABRs reaches the PUA limit.
2) Describe fast rerouting to avoid routing black hole.
3) Defining PUA capabilities announcements for OSPFv2/OSPFv3 and ISIS.

There are also some arguments about the current solution for PUA, for 
example:
1) Is it suitable to set the "Prefix Originator" sub-TLV to NULL to 
indicate the prefix is unreachable?
2) if not, what's the consideration? What's the other convincible solution?

Wish to hear comments and suggestions on the above issues. We will also 
have the presentation on the coming IETF LSR meeting.

Best Regards

Aijun Wang
China Telecom

-Original Message-
From: internet-dra...@ietf.org 
[mailto:internet-dra...@ietf.org]
Sent: Monday, July 27, 2020 9:16 AM
To: Zhibo Hu mailto:huzh...@huawei.com>>; Aijun Wang 
mailto:wang...@chinatelecom.cn>>; Yaqun Xiao 
mailto:xiaoya...@huawei.com>>
Subject: New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt


A new version of I-D, draft-wang-lsr-prefix-unreachable-annoucement-03.txt
has been successfully submitted by Aijun Wang and posted to the IETF 
repository.

Name:   draft-wang-lsr-prefix-unreachable-annoucement
Revision:   03
Title:  Prefix Unreachable Announcement
Document date:  2020-07-27
Group:  Individual Submission
Pages:   

Re: [Lsr] Fwd: New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt

[bruno.decraene]

Hi Tony,

Thanks for the updated draft.

“ The Area SID Sub-TLV allows the Area Leader to advertise a SID that
   represents the entirety of the Inside Area to the Outside Area.  This
   sub-TLV is learned by all of the Inside Edge Nodes who should consume
   this SID at forwarding time.”

Excellent, from my perspective.


Ø  - The Area Segment SID TLV has been replaced by extending the Binding SID 
TLV.


“When SR is enabled, it may be useful to advertise an Area SID which

   will direct traffic to any of the Inside Edge Routers.  The Binding/

   MT Binding TLVs described in RFC 8667 Section 
2.4 are used to

   advertise such a SID.



   The following extensions to the Binding TLV are defined in order to

   support Area SID:



  A new flag is defined:



 T-flag: The SID directs traffic to an area.  (Bit 5) »




This works.
However I may have a different deployment environment than the one you have in 
mind. Even if those issues may be mine, allow me to share them with you.
In many WAN networks than I’m used to, there are routers from different 
vendors, platforms, software, generations. Requiring all those routers to 
support the new Binding SID TLV T-Flag will take time. Some platform may even 
be end of engineering (evolutions) so would never support such new features.
In my environment, ideally, I would prefer a solution which do not require any 
new feature on external L2 nodes, while all existing L2 features keep working, 
in particular SR, SR-TE, TI-LFA, SR uloop avoidance… This would require the 
Proxy LSP to be not (significantly) different than the LSP of a vanilla L2 
node. For SR, I think that this would require this Proxy LSP to advertise a 
Prefix/Node SID with the Area SID attached. One drawback is that a Node-SID is 
advertised with an IP address that would need to be provisioned.

Both approaches are not mutually exclusives. I’d be happy enough with an option 
for the Proxy LSP to advertise an Area Node SID with the Area SID attached.

Finally, there is no requirement to make me happy ;-) . The above could also be 
a local implementation knob not mentioned in the draft.

Thanks,
--Bruno

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of tony...@tony.li
Sent: Sunday, July 26, 2020 3:49 AM
To: lsr@ietf.org
Subject: [Lsr] Fwd: New Version Notification for 
draft-ietf-lsr-isis-area-proxy-02.txt


Hi folks,

This version of the draft reflects major changes in line with the discussions 
that we’ve had so far.

To wit:
- The Area Proxy TLV is now moved to be in L2 LSPs and indicates that the 
advertising node is an Inside Node and Area Proxy is active.
- The Area Proxy Router Capability has been removed.
- The Inside Node TLV has been removed.
- The Area Segment SID TLV has been replaced by extending the Binding SID TLV.

We know that some folks disagree with this last point, so we welcome discussion 
on this. We would like to reach consensus as quickly as possible.

Thanks,
Tony



Begin forwarded message:

From: internet-dra...@ietf.org
Subject: New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt
Date: July 25, 2020 at 6:46:05 PM PDT
To: "Vivek Ilangovan" mailto:ilango...@arista.com>>, 
"Sarah Chen" mailto:sarahc...@arista.com>>, "Gyan S. 
Mishra" mailto:gyan.s.mis...@verizon.com>>, "Gyan 
Mishra" mailto:gyan.s.mis...@verizon.com>>, "Yunxia 
Chen" mailto:sarahc...@arista.com>>, "Tony Li" 
mailto:tony...@tony.li>>


A new version of I-D, draft-ietf-lsr-isis-area-proxy-02.txt
has been successfully submitted by Tony Li and posted to the
IETF repository.

Name:   draft-ietf-lsr-isis-area-proxy
Revision:   02
Title: Area Proxy for IS-IS
Document date:2020-07-25
Group:  lsr
Pages:   20
URL:
https://www.ietf.org/internet-drafts/draft-ietf-lsr-isis-area-proxy-02.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-area-proxy/
Htmlized:   https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-02
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-area-proxy
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-isis-area-proxy-02

Abstract:
  Link state routing protocols have hierarchical abstraction already
  built into them.  However, when lower levels are used for transit,
  they must expose their internal topologies to each other, leading to
  scale issues.

  To avoid this, this document discusses extensions to the IS-IS
  routing protocol that would allow level 1 areas to provide transit,
  yet only inject an abstraction of the level 1 topology into level 2.
  Each level 1 area is represented as a single level 2 node, thereby
  enabling greater scale.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at 
tools.ietf.org.

[Lsr] draft-ietf-lsr-isis-area-proxy-02

[bruno.decraene]

Hi authors,

Please find below some feedback for information. Feel free to ignore.

4.4.13.  The Area SID  
https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-02#section-4.4.13

   "The following extensions to the Binding TLV are defined in order to
   support Area SID:

  A new flag is defined:

 T-flag: The SID directs traffic to an area.  (Bit 5)

 When T-flag is set:

M and A flag MUST be clear"

My understanding is that the Area SID is installed in the FIB of all inside 
edge routers. Based on this, I would argue that the  A flag could and SHOULD be 
set

https://www.rfc-editor.org/rfc/rfc8667.html#name-flags-2
"A-Flag: Attached Flag. The originator of the SID/Label Binding TLV MAY set the 
A bit in order to signal that the prefixes and SIDs advertised in the SID/Label 
Binding TLV are directly connected to their originators."
---
4.4.7.  Reachability TLVs   
https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-02#section-4.4.7


   If the Inside Area supports Segment Routing and the selected TLV

   includes a Prefix Segment Identifier sub-TLV (3) 
[RFC8667], then the

   sub-TLV SHOULD be copied as well. The P-Flag SHOULD be set in the

   copy of the sub-TLV to indicate that penultimate hop popping SHOULD

   NOT be performed for this prefix.  The E-Flag SHOULD be reset in the

   copy of the sub-TLV to indicate that an explicit NULL is not

   required. The R-Flag SHOULD simply be copied.




May be it would be more generic to say that those prefix are handled as 
redistributed prefix.
https://www.rfc-editor.org/rfc/rfc8667.html#section-2.1.2 and 
https://www.rfc-editor.org/rfc/rfc8667.html#EANDPFLAGS already defines the 
behaviour for respectively Prefix-SID propagation and P and E flags handling, 
so probably no need to re-specify:
When propagating (from either Level-1 to Level-2 or Level-2 to Level-1) a 
reachability advertisement originated by another IS-IS speaker, the router MUST 
set the P-Flag and MUST clear the E-Flag of the related Prefix-SIDs.
That would also cover for the handling of Prefix Attribute Flags sub-TLV 
RFC7794.

I would argue that the R-Flag MUST be set (rather than simply copied). As per 
https://www.rfc-editor.org/rfc/rfc8667.html#name-r-flag-and-n-flag

Best regards,
--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] Fwd: New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt

[bruno.decraene]

Les,

From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Thursday, July 30, 2020 7:29 PM
To: DECRAENE Bruno TGI/OLN ; tony...@tony.li; 
lsr@ietf.org
Subject: RE: [Lsr] Fwd: New Version Notification for 
draft-ietf-lsr-isis-area-proxy-02.txt

Bruno –

One of the reasons to use the Binding TLV to advertise the Area SID was that it 
has been suggested that other use cases for Area SID – unrelated to Area Proxy 
– may come along.
Therefore tying the advertisement to an Area Proxy TLV seems not the best 
option if we want to allow for these other use cases (admittedly currently 
unknown).

Thoughts??

I have no problem with the format or the name of the IS-IS extension used to 
advertise the Area SID to external L2 nodes. Binding TLV works for me.
I think that the area SID is useful to external L2 nodes, including to nodes 
not supporting this extension. Hence the proposal to (also) advertise it in a 
regular Node SID. I’ll detail the use case in a subsequent email to be sent 
today. Writing it done will also be beneficial to me.

Thanks,
--Bruno


   Les


From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
bruno.decra...@orange.com
Sent: Thursday, July 30, 2020 9:22 AM
To: tony...@tony.li; lsr@ietf.org
Subject: Re: [Lsr] Fwd: New Version Notification for 
draft-ietf-lsr-isis-area-proxy-02.txt

Hi Tony,

Thanks for the updated draft.

“ The Area SID Sub-TLV allows the Area Leader to advertise a SID that
   represents the entirety of the Inside Area to the Outside Area.  This
   sub-TLV is learned by all of the Inside Edge Nodes who should consume
   this SID at forwarding time.”

Excellent, from my perspective.

Ø  - The Area Segment SID TLV has been replaced by extending the Binding SID 
TLV.


“When SR is enabled, it may be useful to advertise an Area SID which

   will direct traffic to any of the Inside Edge Routers.  The Binding/

   MT Binding TLVs described in RFC 8667 Section 
2.4 are used to

   advertise such a SID.



   The following extensions to the Binding TLV are defined in order to

   support Area SID:



  A new flag is defined:



 T-flag: The SID directs traffic to an area.  (Bit 5) »




This works.
However I may have a different deployment environment than the one you have in 
mind. Even if those issues may be mine, allow me to share them with you.
In many WAN networks than I’m used to, there are routers from different 
vendors, platforms, software, generations. Requiring all those routers to 
support the new Binding SID TLV T-Flag will take time. Some platform may even 
be end of engineering (evolutions) so would never support such new features.
In my environment, ideally, I would prefer a solution which do not require any 
new feature on external L2 nodes, while all existing L2 features keep working, 
in particular SR, SR-TE, TI-LFA, SR uloop avoidance… This would require the 
Proxy LSP to be not (significantly) different than the LSP of a vanilla L2 
node. For SR, I think that this would require this Proxy LSP to advertise a 
Prefix/Node SID with the Area SID attached. One drawback is that a Node-SID is 
advertised with an IP address that would need to be provisioned.

Both approaches are not mutually exclusives. I’d be happy enough with an option 
for the Proxy LSP to advertise an Area Node SID with the Area SID attached.

Finally, there is no requirement to make me happy ;-) . The above could also be 
a local implementation knob not mentioned in the draft.

Thanks,
--Bruno

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of 
tony...@tony.li
Sent: Sunday, July 26, 2020 3:49 AM
To: lsr@ietf.org
Subject: [Lsr] Fwd: New Version Notification for 
draft-ietf-lsr-isis-area-proxy-02.txt


Hi folks,

This version of the draft reflects major changes in line with the discussions 
that we’ve had so far.

To wit:
- The Area Proxy TLV is now moved to be in L2 LSPs and indicates that the 
advertising node is an Inside Node and Area Proxy is active.
- The Area Proxy Router Capability has been removed.
- The Inside Node TLV has been removed.
- The Area Segment SID TLV has been replaced by extending the Binding SID TLV.

We know that some folks disagree with this last point, so we welcome discussion 
on this. We would like to reach consensus as quickly as possible.

Thanks,
Tony


Begin forwarded message:

From: internet-dra...@ietf.org
Subject: New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt
Date: July 25, 2020 at 6:46:05 PM PDT
To: "Vivek Ilangovan" mailto:ilango...@arista.com>>, 
"Sarah Chen" mailto:sarahc...@arista.com>>, "Gyan S. 
Mishra" mailto:gyan.s.mis...@verizon.com>>, "Gyan 
Mishra" mailto:gyan.s.mis...@verizon.com>>, "Yunxia 
Chen" mailto:sarahc...@arista.com>>, "Tony Li" 
mailto:tony...@tony.li>>


A new version of I-D, 

Re: [Lsr] New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt

[bruno.decraene]

Hi Tony,

Thank you for your reply.
Top posting the description of the use case that I have in mind.


Ø  First off, the Area SID is 100% optional. If you choose not to use it, then 
the Proxy LSP should be 100% compatible with a standard L2 node.
Good. But I think that the idea of the Area SID is a good one, and I choose to 
use it. Then I’d like to get it for free ;-)


Please fine below a network topology:
[cid:image003.jpg@01D6672D.1946D4F0]


My understanding is that the L2 topology seen by node S is the following
[cid:image004.jpg@01D6672D.1946D4F0]

P been the Proxy LSP.

S wants to protect from the failure of link S-C by using TI-LFA. For the 
destination C, it would push 2 (*) node SIDs: P, C
So S needs a Node SID for P:

a)  If P does not redistribute the Node SIDs from its area members, P does 
not seem to advertise any node SID currently. There is a chance that C’s TI-LFA 
implementation would not like it and hence would not install protection for 
this (link, destination)

b)  If P redistributes the Node SIDs from its area members, P advertises 3 
node SIDs (1,2, 3). S could pick any one at random. If it picks 3, the 
forwarding path would be S, A,B, 1, 2, 3, 2 , 1, C,  which is suboptimal.


Two solutions I could think of:
- when redistributing the node SID, P changes the SIDs values and replace them 
with the value of the Area SID. This works for this use case, but it is 
borderline. (e.g. if some a L2 node learn both the original and ‘NATed’ SID, we 
have some SID conflict. Let’s try to avoid this subject).
- P could advertise its own Node-SID with the Area SID value. This is what I’m 
proposing. Both the IP loopback and the Area SID of this Node SID  are likely 
configured by the network operator so this does not seem like a significant 
effort from the implementation.

As you say, this does not involve any protocol extension. But the goal is to 
improve interop with existing/legacy L2 nodes so this may be valuable in the 
draft. This point could be pushed to a deployment consideration section if you 
don’t want any impact on the protocol extension.

Thanks,
--Bruno

(*) Assuming the right metrics on the links. This is not the subject of this 
thread.


From: Tony Li [mailto:tony1ath...@gmail.com] On Behalf Of tony...@tony.li
Sent: Thursday, July 30, 2020 7:39 PM
To: DECRAENE Bruno TGI/OLN 
Cc: lsr@ietf.org
Subject: Re: [Lsr] New Version Notification for 
draft-ietf-lsr-isis-area-proxy-02.txt


Hi Bruno,

Thank you for your comments.



On Jul 30, 2020, at 9:22 AM, 
bruno.decra...@orange.com wrote:

Hi Tony,

Thanks for the updated draft.

“ The Area SID Sub-TLV allows the Area Leader to advertise a SID that
   represents the entirety of the Inside Area to the Outside Area.  This
   sub-TLV is learned by all of the Inside Edge Nodes who should consume
   this SID at forwarding time.”

Excellent, from my perspective.

>  - The Area Segment SID TLV has been replaced by extending the Binding SID 
> TLV.


“When SR is enabled, it may be useful to advertise an Area SID which

   will direct traffic to any of the Inside Edge Routers.  The Binding/

   MT Binding TLVs described in RFC 8667 Section 
2.4 are used to

   advertise such a SID.



   The following extensions to the Binding TLV are defined in order to

   support Area SID:



  A new flag is defined:



 T-flag: The SID directs traffic to an area.  (Bit 5) »




This works.


Excellent.



However I may have a different deployment environment than the one you have in 
mind. Even if those issues may be mine, allow me to share them with you.
In many WAN networks than I’m used to, there are routers from different 
vendors, platforms, software, generations. Requiring all those routers to 
support the new Binding SID TLV T-Flag will take time. Some platform may even 
be end of engineering (evolutions) so would never support such new features.
In my environment, ideally, I would prefer a solution which do not require any 
new feature on external L2 nodes, while all existing L2 features keep working, 
in particular SR, SR-TE, TI-LFA, SR uloop avoidance… This would require the 
Proxy LSP to be not (significantly) different than the LSP of a vanilla L2 node.


First off, the Area SID is 100% optional. If you choose not to use it, then the 
Proxy LSP should be 100% compatible with a standard L2 node.



I cannot claim that we’ve exhaustively tested our implementation against all of 
the features that you cite, so there may still be corner cases, but our intent 
is to make that doable.  For exaple, the Proxy LSP can still contain a node 
SID, adjacency SID, and prefix SID as before. There’s no change there.



For SR, I think that this would require this Proxy LSP to advertise a 
Prefix/Node SID with the Area SID attached. One drawback is that a Node-SID is 
advertised with an IP address that would need to be provisioned.


That’s certainly 

Re: [Lsr] Second Working Last Call for draft-ietf-lsr-flex-algo

[bruno.decraene]

OK. Crystal clear.

Thanks Peter.

--Bruno

> -Original Message-
> From: Peter Psenak [mailto:ppse...@cisco.com]
> Sent: Thursday, June 17, 2021 4:59 PM
> To: DECRAENE Bruno INNOV/NET ; Acee Lindem
> (acee) ; lsr@ietf.org
> Cc: lsr-...@ietf.org; Christian Hopps ; 
> draft-ietf-lsr-flex-
> algo@ietf.org
> Subject: Re: Second Working Last Call for draft-ietf-lsr-flex-algo
> 
> Hi Bruno,
> 
> On 17/06/2021 16:12, bruno.decra...@orange.com wrote:
> > Hi,
> >
> > I have a question/comment.
> >
> > I think that we all agree that FlexAlgo/Link State computation requires
> > that all node use the same topology to compute their SPF. Otherwise,
> > permanent forwarding loops are probable.
> >
> > https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-16#section-12
> > says
> >
> > “ASLA Admin Group Advertisements to be used by the Flexible Algorithm
> >
> > Application MAY use either the Administrative Group or Extended
> >
> > Administrative Group encodings. »
> >
> > My reading of the above is that the sender of the attribute is free to
> > advertise either Administrative Groups or Extended Administrative Group
> > encoding (or both).
> 
> correct.
> 
> >
> > In order to enforce topology consistency, I’m assuming that there is a
> > non-expressed requirement for the node reading the attribute to be able
> > to read both. (ie. MUST support the reading of both encodings).
> 
> yes, the receiver MUST be able to accept both.
> 
> 
> >
> > Is this a correct assumption?
> >
> > - if so, could this requirement be written in the document. (If we have
> > to choose one, I’d rather have the “MUST” requirement expressed rather
> > than the “MAY”)
> 
> will add to the text.
> 
> thanks,
> Peter
> 
> 
> >
> > - if not, how is the topology made consistent across all nodes?
> >
> > Thank you,
> >
> > Regards,
> >
> > --Bruno
> >
> > *From**:*Lsr [mailto:lsr-boun...@ietf.org] *On Behalf Of *Acee Lindem (acee)
> > *Sent:* Wednesday, June 16, 2021 4:01 PM
> > *To:* lsr@ietf.org
> > *Cc:* lsr-...@ietf.org; Christian Hopps ;
> > draft-ietf-lsr-flex-algo@ietf.org
> > *Subject:* [Lsr] Second Working Last Call for draft-ietf-lsr-flex-algo
> >
> > After the first successful WG last call, the authors discovered that
> > some re-work was needed for OSPF AS External route calculation –
> > specifically with respect to the Flex Algorithm ASBR metrics and
> > calculation. This was fixed and there were clarifications in the IANA
> > section (see versions -14 and -15). The draft has been stable since
> > April and we are now ready to WG last call the updated version.
> >
> > Without further ado, this begins a 2 week WG Last Call, ending on July
> > 1st, 2021, for draft-ietf-lsr-flex-algo
> >
> > https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo/
> >
> > All authors, please indicate by sending an email to the list, whether
> > you aware of any other IPR beyond what is already posted:
> >
> >    [>From
> > https://datatracker.ietf.org/ipr/search/?submit=draft=draft-ietf-lsr-flex-algo]
> >
> > https://datatracker.ietf.org/ipr/3910/
> >
> > https://datatracker.ietf.org/ipr/3248/
> >
> > Thanks,
> >
> > Chris & Acee.
> >
> >
> __
> ___
> >
> > 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.
> >


_

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.

Re: [Lsr] Second Working Last Call for draft-ietf-lsr-flex-algo

[bruno.decraene]

Hi,

I have a question/comment.

I think that we all agree that FlexAlgo/Link State computation requires that 
all node use the same topology to compute their SPF. Otherwise, permanent 
forwarding loops are probable.

https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-16#section-12 
says


“ASLA Admin Group Advertisements to be used by the Flexible Algorithm
   Application MAY use either the Administrative Group or Extended
   Administrative Group encodings. »

My reading of the above is that the sender of the attribute is free to 
advertise either Administrative Groups or Extended Administrative Group 
encoding (or both).

In order to enforce topology consistency, I’m assuming that there is a 
non-expressed requirement for the node reading the attribute to be able to read 
both. (ie. MUST support the reading of both encodings).
Is this a correct assumption?
- if so, could this requirement be written in the document. (If we have to 
choose one, I’d rather have the “MUST” requirement expressed rather than the 
“MAY”)
- if not, how is the topology made consistent across all nodes?

Thank you,
Regards,
--Bruno

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Wednesday, June 16, 2021 4:01 PM
To: lsr@ietf.org
Cc: lsr-...@ietf.org; Christian Hopps ; 
draft-ietf-lsr-flex-algo@ietf.org
Subject: [Lsr] Second Working Last Call for draft-ietf-lsr-flex-algo

After the first successful WG last call, the authors discovered that some 
re-work was needed for OSPF AS External route calculation – specifically with 
respect to the Flex Algorithm ASBR metrics and calculation. This was fixed and 
there were clarifications in the IANA section (see versions -14 and -15). The 
draft has been stable since April and we are now ready to WG last call the 
updated version.


Without further ado, this begins a 2 week WG Last Call, ending on July 1st, 
2021, for draft-ietf-lsr-flex-algo

  https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo/

All authors, please indicate by sending an email to the list, whether you aware 
of any other IPR beyond what is already posted:

  [From 
https://datatracker.ietf.org/ipr/search/?submit=draft=draft-ietf-lsr-flex-algo]

  https://datatracker.ietf.org/ipr/3910/
  https://datatracker.ietf.org/ipr/3248/

Thanks,
Chris & Acee.



_

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] Proposed Errata for RFCs 8919/8920

[bruno.decraene]

Les, Peter,

Thank you for agreeing to clarify the sentence and for the effort put in 
proposing a new text.

Proposed text looks much better to me. I particularly like the either MUST or 
MUST NOT statement.

I have one comment.
In the RFC, the term "advertisement" is used to refer both to sub-TLV [1] and 
to ASLA attribute [2]
[1] https://www.rfc-editor.org/rfc/rfc8919.html#name-legacy-advertisements
[2] https://www.rfc-editor.org/rfc/rfc8919.html#name-advertising-application-spe

As such, I would have a slight preference to be explicit about the type of 
advertisement which is meant. Especially since Gunter, an AD and myself raised 
that exact point, and that OSPF and IS-IS did not seemed aligned on this.

I would propose the following change in RFC 8919 section 4.2 & RFC 8920 section 
5
OLD: Such advertisements MUST
NEW: Such link attribute advertisements MUST

(I'm aware that the previous sentence starts with "Link attributes MAY be 
advertised", which in general should be a clear enough reference. But since we 
are clarifying, IMHO the more straightforward the clarification, the better, 
especially for the OSPF document which seemed to use the alternative 
understanding)


I definitely agree that this wording affects interoperability and must be fixed.
I'm not taking position (and don't care) whether an errata is the appropriate 
way. I'm happy to leave this to the chairs and AD. But my understanding is that 
if the errata is not classified as "Verified", then we'll need a bis document.

Thanks,
Regards,
--Bruno

From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Tuesday, June 15, 2021 5:25 PM
To: lsr@ietf.org
Cc: DECRAENE Bruno INNOV/NET ; Van De Velde, Gunter 
(Nokia - BE/Antwerp) 
Subject: Proposed Errata for RFCs 8919/8920


Folks -



Recent discussions on the list have highlighted some unintentional ambiguity in 
how ASLA advertisements are to be used. Please see 
https://mailarchive.ietf.org/arch/msg/lsr/prSLJDkMUnHm6h7VuCdn_Q7-1vg/



The following proposed Errata address this ambiguity and aligns language in the 
two RFCs.



We welcome comments on the proposed Errata before officially filing them.



  Les and Peter


Errata Explanation

Both RFC 8919 and RFC 8920 define advertising link attributes with zero length 
Standard Application Bit Mask (SABM) and zero length User Defined Application 
Bit Mask (UDABM)
as a means of advertising link attributes that can be used by any application. 
However, the text uses the word "permitted", suggesting that the use of such 
advertisements is "optional".
Such an interpretation could lead to interoperability issues and is not what 
was intended.

The replacement text below makes explicit the specific conditions when such 
advertisements MUST be used and the specific conditions under which they MUST 
NOT be used.

RFC 8919 Section 4.2:

OLD

"If link attributes are advertised associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications,
then any standard application and/or any user-defined application is permitted 
to use that set of link attributes so long as there is not another set of 
attributes
advertised on that same link that is associated with a non-zero-length 
Application Identifier Bit Mask with a matching Application Identifier Bit set."

NEW

"Link attributes MAY be advertised associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications.
Such advertisements MUST be used by standard applications and/or user defined 
applications when no link attribute advertisements with a non-zero-length
Application Identifier Bit Mask and a matching Application Identifier Bit set 
are present for a given link. Otherwise, such advertisements MUST NOT be used."

RFC 8919 Section 6.2

OLD

"Link attribute advertisements associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications are usable
by any application, subject to the restrictions specified in Section 4.2. If 
support for a new application is introduced on any node in a network in the 
presence of such
advertisements, these advertisements are permitted to be used by the new 
application. If this is not what is intended, then existing advertisements MUST 
be readvertised
with an explicit set of applications specified before a new application is 
introduced."


NEW

"Link attribute advertisements associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications are usable
by any application, subject to the restrictions specified in Section 4.2. If 
support for a new application is introduced on any node in a network in the 
presence of such
advertisements, the new application will use these advertisements, when the 
aforementioned restrictions are met. If this is not what is intended, then 
existing
advertisements MUST be readvertised with an 

Re: [Lsr] Last Call: (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard

[bruno.decraene]

Hi Xuesong,

Clarification question: are you talking about interoperability (between two 
nodes) or compliancy (between an implementation and the RFC)?
If the former, could you please spell out the interop issue?

Thanks,
Best regards,
--Bruno

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Gengxuesong (Geng Xuesong)
Sent: Wednesday, May 12, 2021 9:16 AM
To: Les Ginsberg (ginsberg) ; Shraddha Hegde 
; Alvaro Retana 
; Peter Psenak (ppsenak) ; 
lsr@ietf.org
Cc: cho...@chopps.org; draft-ietf-lsr-isis-srv6-extensi...@ietf.org; Van De 
Velde, Gunter (Nokia - BE/Antwerp) 
Subject: Re: [Lsr] Last Call:  
(IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed 
Standard

Hi Les,

Prefix Attributes sub-TLV is necessary when locator is leaked.
So we are not against Prefix Attribute sub-TLV implementation. We just propose 
to keep it optional ("should" rather than "must") for interoperability.

Best
Xuesong

From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Wednesday, May 12, 2021 6:29 AM
To: Shraddha Hegde 
mailto:shraddha=40juniper@dmarc.ietf.org>>;
 Alvaro Retana mailto:aretana.i...@gmail.com>>; Peter 
Psenak (ppsenak) mailto:ppse...@cisco.com>>; 
lsr@ietf.org; Gengxuesong (Geng Xuesong) 
mailto:gengxues...@huawei.com>>
Cc: cho...@chopps.org; 
draft-ietf-lsr-isis-srv6-extensi...@ietf.org;
 Van De Velde, Gunter (Nokia - BE/Antwerp) 
mailto:gunter.van_de_ve...@nokia.com>>
Subject: RE: [Lsr] Last Call:  
(IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed 
Standard

Shraddha/ Xuesong -

Since Prefix Attributes sub-TLV is required for correct operation when a 
Locator is leaked, would it be safe to assume that your implementations either 
do not leak Locators or you advise your customers not to deploy this feature 
with multiple levels?

The problem with allowing the sub-TLV to be optional is that if the sub-TLV is 
omitted you cannot tell whether the Locator has been leaked - so you don't know 
whether you have a problem or not.

The safest thing to do is require prefix-attributes sub-TLV always - then you 
can guarantee that if the prefix is leaked the necessary information will be 
present.
Anything else leaves us vulnerable.

We all appreciate interoperability considerations, but frankly this is a gap 
that needs to be closed to support correct operation.

   Les

From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
Shraddha Hegde
Sent: Tuesday, May 11, 2021 8:21 AM
To: Alvaro Retana mailto:aretana.i...@gmail.com>>; 
Peter Psenak (ppsenak) mailto:ppse...@cisco.com>>; 
lsr@ietf.org
Cc: cho...@chopps.org; 
draft-ietf-lsr-isis-srv6-extensi...@ietf.org;
 Van De Velde, Gunter (Nokia - BE/Antwerp) 
mailto:gunter.van_de_ve...@nokia.com>>
Subject: Re: [Lsr] Last Call:  
(IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed 
Standard

Juniper has an  implementation of SRv6 that does not support Prefix attributes 
sub-tlv in locator TLV.
We would prefer not to change the optional sub-TLV to MUST.

Rgds
Shraddha




Juniper Business Use Only
From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
Alvaro Retana
Sent: Friday, May 7, 2021 7:23 PM
To: Peter Psenak mailto:ppse...@cisco.com>>; 
lsr@ietf.org
Cc: cho...@chopps.org; 
draft-ietf-lsr-isis-srv6-extensi...@ietf.org;
 Van De Velde, Gunter (Nokia - BE/Antwerp) 
mailto:gunter.van_de_ve...@nokia.com>>
Subject: Re: [Lsr] Last Call:  
(IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed 
Standard

[External Email. Be cautious of content]

On May 3, 2021 at 5:17:58 AM, Peter Psenak wrote:

> Technically I agree with you and if everybody agrees, I'm fine to
> enforce the presence of the Prefix Attribute Flags TLV in the Locator TLV.

So...what does everyone else think?

We need to close on this point before the IESG evaluates the document.  I'm 
requesting it to be put on the May/20 telechat, which means that we should have 
a resolution and updated draft by the end of next week.


Thanks!

Alvaro.



On May 3, 2021 at 5:17:58 AM, Peter Psenak 
(ppse...@cisco.com) wrote:
Hi Gunter,

Prefix Attribute Flags Sub-TLV has been defined as an optional Sub-TLV.
The problem you describe is not specific to Locator TLV, same applies to
regular IPv4/v6 prefixes (forget SR MPLS for a while) - if the Prefix
Attribute Flags TLV is not included, one can not tell whether the prefix
has been propagated (L1->L2) or generated as a result of the local
interface attached on the originator. Same applies to redistribution and
R-flag for IPv4 prefix TLVs.

SRv6 Locator TLV has been defined a while back and the Prefix Attribute
Flags Sub-TLV has always been an optional 

Re: [Lsr] Last Call: (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard

[bruno.decraene]

Hi Peter,

> From: Peter Psenak [mailto:ppse...@cisco.com]
> 
> Hi Bruno,
> 
> On 12/05/2021 10:24, bruno.decra...@orange.com wrote:
> > Hi Peter,
> >
> > Thanks for the answer.
> > Please see inline.
> >
> >> From: Peter Psenak [mailto:ppse...@cisco.com]
> >>
> >> Hi Bruno,
> >>
> >>
> >> On 12/05/2021 09:51, bruno.decra...@orange.com wrote:
> >>> Hi Xuesong,
> >>>
> >>> Clarification question: are you talking about interoperability (between
> >>> two nodes) or compliancy (between an implementation and the RFC)?
> >>
> >> I'm afraid the two are related. If we mandate the Prefix Attribute
> >> Sub-TLV inside the Locator TLV, we would have to say that the Locator
> >> TLV without the Prefix Attribute Sub-TLV MUST be ignored.
> >
> > Mandating the advertisement is one thing (if it's useful, not to mention
> required, let's advertise it).
> > Then why would we have to say that the Locator TLV without the Prefix
> Attribute Sub-TLV MUST be ignored ? On the receiver side, a priori, current
> spec allows for both (presence & non-presence), no? That seem like an error
> handling situation that we can choose.
> 
> if we mandate something we need to say what happens when the mandated
> data is not present 

Absolutely. I could not agree more.
I call this error handling.

>- typically we ignore. 
OK, but here we seem free to define "whatever" error handling we want since 
current version of the draft allows for both presence or non-presence.

Thanks,
--Bruno

> If we don't ignore, then we
> are not really mandating it.
>
> thanks,
> Peter
> 
> 
> >
> > Thanks for the discussion,
> > --Bruno
> >
> >> As a result,
> >> implementations that do not send the Prefix Attribute Sub-TLV would not
> >> just be not compliant, but would also not interoperate with the ones
> >> that follow the specification.
> >>
> >> thanks,
> >> Peter
> >>
> >>>
> >>> If the former, could you please spell out the interop issue?
> >>>
> >>> Thanks,
> >>>
> >>> Best regards,
> >>>
> >>> --Bruno
> >>>
> >>> *From:*Lsr [mailto:lsr-boun...@ietf.org] *On Behalf Of *Gengxuesong
> >>> (Geng Xuesong)
> >>> *Sent:* Wednesday, May 12, 2021 9:16 AM
> >>> *To:* Les Ginsberg (ginsberg) ; Shraddha Hegde
> >>> ; Alvaro Retana
> >>> ; Peter Psenak (ppsenak)
> >> ;
> >>> lsr@ietf.org
> >>> *Cc:* cho...@chopps.org; draft-ietf-lsr-isis-srv6-extensi...@ietf.org;
> >>> Van De Velde, Gunter (Nokia - BE/Antwerp)
> >> 
> >>> *Subject:* Re: [Lsr] Last Call:
> >>>  (IS-IS Extension to Support
> >>> Segment Routing over IPv6 Dataplane) to Proposed Standard
> >>>
> >>> Hi Les,
> >>>
> >>> Prefix Attributes sub-TLV is necessary when locator is leaked.
> >>>
> >>> So we are not against Prefix Attribute sub-TLV implementation. We just
> >>> propose to keep it optional (“should” rather than “must”) for
> >>> interoperability.
> >>>
> >>> Best
> >>>
> >>> Xuesong
> >>>
> >>> *From:*Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
> >>> *Sent:* Wednesday, May 12, 2021 6:29 AM
> >>> *To:* Shraddha Hegde  >>> >; Alvaro Retana
> >>> mailto:aretana.i...@gmail.com>>; Peter
> Psenak
> >>> (ppsenak) mailto:ppse...@cisco.com>>;
> >> lsr@ietf.org
> >>> ; Gengxuesong (Geng Xuesong)
> >>> mailto:gengxues...@huawei.com>>
> >>> *Cc:* cho...@chopps.org ;
> >>> draft-ietf-lsr-isis-srv6-extensi...@ietf.org
> >>> ; Van De Velde,
> >>> Gunter (Nokia - BE/Antwerp)  >>> >
> >>> *Subject:* RE: [Lsr] Last Call:
> >>>  (IS-IS Extension to Support
> >>> Segment Routing over IPv6 Dataplane) to Proposed Standard
> >>>
> >>> Shraddha/ Xuesong –
> >>>
> >>> Since Prefix Attributes sub-TLV is required for correct operation when a
> >>> Locator is leaked, would it be safe to assume that your implementations
> >>> either do not leak Locators or you advise your customers not to deploy
> >>> this feature with multiple levels?
> >>>
> >>> The problem with allowing the sub-TLV to be optional is that if the
> >>> sub-TLV is omitted you cannot tell whether the Locator has been leaked
> –
> >>> so you don’t know whether you have a problem or not.
> >>>
> >>> The safest thing to do is require prefix-attributes sub-TLV always –
> >>> then you can guarantee that if the prefix is leaked the necessary
> >>> information will be present.
> >>>
> >>> Anything else leaves us vulnerable.
> >>>
> >>> We all appreciate interoperability considerations, but frankly this is a
> >>> gap that needs to be closed to support correct operation.
> >>>
> >>>      Les
> >>>
> >>> *From:*Lsr mailto:lsr-boun...@ietf.org>> *On
> >>> Behalf Of *Shraddha Hegde
> >>> *Sent:* Tuesday, May 11, 2021 8:21 AM
> >>> *To:* Alvaro Retana  >>> >; Peter Psenak (ppsenak)
> >>> mailto:ppse...@cisco.com>>; lsr@ietf.org
> >>> 
> >>> *Cc:* cho...@chopps.org ;
> >>> 

Re: [Lsr] Last Call: (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard

[bruno.decraene]

Hi Peter,

Thanks for the answer.
Please see inline.

> From: Peter Psenak [mailto:ppse...@cisco.com]
> 
> Hi Bruno,
> 
> 
> On 12/05/2021 09:51, bruno.decra...@orange.com wrote:
> > Hi Xuesong,
> >
> > Clarification question: are you talking about interoperability (between
> > two nodes) or compliancy (between an implementation and the RFC)?
> 
> I'm afraid the two are related. If we mandate the Prefix Attribute
> Sub-TLV inside the Locator TLV, we would have to say that the Locator
> TLV without the Prefix Attribute Sub-TLV MUST be ignored. 

Mandating the advertisement is one thing (if it's useful, not to mention 
required, let's advertise it).
Then why would we have to say that the Locator TLV without the Prefix Attribute 
Sub-TLV MUST be ignored ? On the receiver side, a priori, current spec allows 
for both (presence & non-presence), no? That seem like an error handling 
situation that we can choose.

Thanks for the discussion,
--Bruno

> As a result,
> implementations that do not send the Prefix Attribute Sub-TLV would not
> just be not compliant, but would also not interoperate with the ones
> that follow the specification.
> 
> thanks,
> Peter
> 
> >
> > If the former, could you please spell out the interop issue?
> >
> > Thanks,
> >
> > Best regards,
> >
> > --Bruno
> >
> > *From:*Lsr [mailto:lsr-boun...@ietf.org] *On Behalf Of *Gengxuesong
> > (Geng Xuesong)
> > *Sent:* Wednesday, May 12, 2021 9:16 AM
> > *To:* Les Ginsberg (ginsberg) ; Shraddha Hegde
> > ; Alvaro Retana
> > ; Peter Psenak (ppsenak)
> ;
> > lsr@ietf.org
> > *Cc:* cho...@chopps.org; draft-ietf-lsr-isis-srv6-extensi...@ietf.org;
> > Van De Velde, Gunter (Nokia - BE/Antwerp)
> 
> > *Subject:* Re: [Lsr] Last Call:
> >  (IS-IS Extension to Support
> > Segment Routing over IPv6 Dataplane) to Proposed Standard
> >
> > Hi Les,
> >
> > Prefix Attributes sub-TLV is necessary when locator is leaked.
> >
> > So we are not against Prefix Attribute sub-TLV implementation. We just
> > propose to keep it optional (“should” rather than “must”) for
> > interoperability.
> >
> > Best
> >
> > Xuesong
> >
> > *From:*Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
> > *Sent:* Wednesday, May 12, 2021 6:29 AM
> > *To:* Shraddha Hegde  > >; Alvaro Retana
> > mailto:aretana.i...@gmail.com>>; Peter Psenak
> > (ppsenak) mailto:ppse...@cisco.com>>;
> lsr@ietf.org
> > ; Gengxuesong (Geng Xuesong)
> > mailto:gengxues...@huawei.com>>
> > *Cc:* cho...@chopps.org ;
> > draft-ietf-lsr-isis-srv6-extensi...@ietf.org
> > ; Van De Velde,
> > Gunter (Nokia - BE/Antwerp)  > >
> > *Subject:* RE: [Lsr] Last Call:
> >  (IS-IS Extension to Support
> > Segment Routing over IPv6 Dataplane) to Proposed Standard
> >
> > Shraddha/ Xuesong –
> >
> > Since Prefix Attributes sub-TLV is required for correct operation when a
> > Locator is leaked, would it be safe to assume that your implementations
> > either do not leak Locators or you advise your customers not to deploy
> > this feature with multiple levels?
> >
> > The problem with allowing the sub-TLV to be optional is that if the
> > sub-TLV is omitted you cannot tell whether the Locator has been leaked –
> > so you don’t know whether you have a problem or not.
> >
> > The safest thing to do is require prefix-attributes sub-TLV always –
> > then you can guarantee that if the prefix is leaked the necessary
> > information will be present.
> >
> > Anything else leaves us vulnerable.
> >
> > We all appreciate interoperability considerations, but frankly this is a
> > gap that needs to be closed to support correct operation.
> >
> >     Les
> >
> > *From:*Lsr mailto:lsr-boun...@ietf.org>> *On
> > Behalf Of *Shraddha Hegde
> > *Sent:* Tuesday, May 11, 2021 8:21 AM
> > *To:* Alvaro Retana  > >; Peter Psenak (ppsenak)
> > mailto:ppse...@cisco.com>>; lsr@ietf.org
> > 
> > *Cc:* cho...@chopps.org ;
> > draft-ietf-lsr-isis-srv6-extensi...@ietf.org
> > ; Van De Velde,
> > Gunter (Nokia - BE/Antwerp)  > >
> > *Subject:* Re: [Lsr] Last Call:
> >  (IS-IS Extension to Support
> > Segment Routing over IPv6 Dataplane) to Proposed Standard
> >
> > Juniper has an  implementation of SRv6 that does not support Prefix
> > attributes sub-tlv in locator TLV.
> >
> > We would prefer not to change the optional sub-TLV to MUST.
> >
> > Rgds
> >
> > Shraddha
> >
> > Juniper Business Use Only
> >
> > *From:*Lsr mailto:lsr-boun...@ietf.org>> *On
> > Behalf Of *Alvaro Retana
> > *Sent:* Friday, May 7, 2021 7:23 PM
> > *To:* Peter Psenak mailto:ppse...@cisco.com>>;
> > lsr@ietf.org 
> > *Cc:* cho...@chopps.org ;
> > draft-ietf-lsr-isis-srv6-extensi...@ietf.org

[Lsr] draft-ietf-lsr-flex-algo

[bruno.decraene]

Hi all,

Better safe than sorry, I guess. 

FYI, in -08 (a year ago) draft introduced one single iteration of the FA 
acronym: "The scope of the FA computation is an area"

Do we really want to create that FA acronym for Flex Algo?

FA has already been used for  Forwarding Adjacency (e.g., [1]) and this could 
create some ambiguity (e.g., FA link, enable FA...), especially as the domain 
is the same (IGP routing, TE). 

Alternatively, FX or FxA could be used for FlexAlgo (athough this would not 
match with FAD), or no acronym defined since we did not used one for the first 
3 years.

[1] https://datatracker.ietf.org/doc/html/draft-saad-sr-fa-link

Regards,
--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] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[bruno.decraene]

Acee, Chris,

I’m not aware of non-disclosed IPR.

Thanks,
--Bruno

From: Acee Lindem (acee) [mailto:a...@cisco.com]
Sent: Wednesday, May 12, 2021 11:09 PM
To: lsr@ietf.org
Cc: draft-hegde-lsr-flex-algo-bw-...@ietf.org
Subject: LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, 
Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

Esteemed Members of the LSR WG,

This begins a 2 week WG adoption call for the following draft:

 https://datatracker.ietf.org/doc/draft-hegde-lsr-flex-algo-bw-con/

Please indicate your support or objection by May 27th, 2021.

Authors, please respond to the list indicating whether you are aware of any IPR 
that applies to this draft.

Thanks,
Chris and Acee



_

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] draft-ietf-lsr-flex-algo

[bruno.decraene]

Les, Peter,

Thanks for the clarification. This is crystal clear.
This address my concern. My goal is specification clarity to avoid interop 
issues at the earliest stage, because the latter the misalignment is found the 
bigger the delay and the cost, both for vendors and network operators.

Thank you for working on a revised language and for the errata.

--Bruno
From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Friday, June 4, 2021 7:16 PM
To: DECRAENE Bruno INNOV/NET ; 
draft-ietf-lsr-flex-a...@ietf.org; lsr@ietf.org
Subject: RE: draft-ietf-lsr-flex-algo

Bruno -

The intent of the RFC 8919 language is to say:

1)If there are ASLA advertisements w non-zero SABM/UABM matching the 
application,  these MUST be used
2)If there are no matching ASLA advertisements as per #1, then ASLA 
advertisements w zero length SABM/UABM (if present) MUST be used

There is no intent of making these rules "optional".

Peter and I are working on revised language that will make this more explicit 
(as well as resolving the unintentional discrepancies between the IS-IS/OSPF 
RFCs that you pointed out in an earlier thread).
Once language is agreed upon, these will be filed as Errata.
But it is important to note that this is a clarification - not a change in 
intended behavior.

Hope this is sufficient to address your concern.
Thanx for helping us to improve the quality of the RFCs.

   Les

From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
bruno.decra...@orange.com
Sent: Friday, June 4, 2021 2:03 AM
To: 
draft-ietf-lsr-flex-a...@ietf.org; 
lsr@ietf.org
Subject: [Lsr] draft-ietf-lsr-flex-algo

Hi all,

I think that I may have an issue with the way FlexAlgo [2] uses ASLA [1]

FlexAlgo is distributed routing computation so it's required that all routers 
use exactly the same data to compute the routes/SPF.

FlexAlgo is clear that ASLA MUST be used:

"Link attribute advertisements that are to be used during Flex-

   Algorithm calculation MUST use the Application-Specific Link

   Attribute (ASLA) advertisements defined in 
[RFC8919] or 
[RFC8920],"

However ASLA provides multiple ways to advertise IGP attributes and does not 
seem precise enough in its specification.
"If link attributes are advertised associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications, then any standard application and/or any user-defined application 
is permitted to use that set of link attributes"

My issue is the use of the term "permitted" which
a) is not a normative keyword
b)IMHO translates to MAY hence also MAY NOT. While we need a MUST to ensure 
a consistent SPF.



One example of issue is when FlexAlgo uses a metric different from the IGP 
(e.g. TE-metric) , and one node advertises this TE-metric in an ASLA with 
zero-length Bit Mask.
- If one node uses this TE-metric (since it is permitted to) it includes that 
link in its SPF
- If another node does not use this TE-metric (since it is not required to) it 
prunes that link from its SPF
I think it's self-evident that we would end up with a permanent routing loop.

Ideally, I would probably have preferred ALSA to be specific about the 
behaviour but ASLA is already published as RFC so it's a bit late
So at this point, I think that the burden is on FlexAlgo to specify the precise 
behaviour as a MUST in section 12. [2]

The smallest change from FlexAlgo draft standpoint may be to _require_ the use 
of the ASLA _with the X-Flag set_ . But I'm fine with whatever interoperable 
behaviour (well for me, ideally I'd prefer the behaviour already implemented by 
the implementations that I've deployed ;-) but that would be a selfish 
requirement).

Note that there are existing implementations and this would impact them. That 
been said, we do need the interop behaviour so if there are already 
inconsistent behaviours, some implementations will need to be changed (and 
hence become non interoperable with themselves)

Thanks,
Regards,
--Bruno


[1] https://www.rfc-editor.org/rfc/rfc8919.html
[2] https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-16#section-12


_



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 

Re: [Lsr] RFC 8919 clarification

[bruno.decraene]

Hi Peter,



Thank you for your answer and for your crystal clear email.





As a side note, my reading of RFC 8920 is that this behaviour is different in 
OSPF.

“If link attributes are advertised with zero-length Application Identifier Bit 
Masks for both standard applications and user-defined applications, then any 
standard application and/or any user-defined application is permitted to use 
that set of link attributes. If support for a new application is introduced on 
any node in a network in the presence of such advertisements, these 
advertisements are permitted to be used by the new application. If this is not 
what is intended, then existing advertisements MUST be readvertised with an 
explicit set of applications specified before a new application is 
introduced.An application-specific advertisement (Application Identifier Bit 
Mask with a matching Application Identifier Bit set) for an attribute MUST 
always be preferred over the advertisement of the same attribute with the 
zero-length Application Identifier Bit Masks for both standard applications and 
user-defined applications on the same link.”



Not sure whether there was a technical reason for this difference, but it 
didn’t help be clarify by myself the RFC 8919 formulation.





Thank you,

--Bruno



> -Original Message-

> From: Peter Psenak [mailto:ppse...@cisco.com]

> Sent: Thursday, June 3, 2021 3:28 PM

> To: DECRAENE Bruno INNOV/NET ; lsr@ietf.org

> Subject: Re: [Lsr] RFC 8919 clarification

>

> Hi Bruno,

>

> On 03/06/2021 14:55, bruno.decra...@orange.com wrote:

> > Hi all,

> >

> > In order to (try to) avoid interop issues, I have a clarification

> > question on RFC 8919.

> >

> > “If link attributes are advertised associated with zero-length

> > Application Identifier Bit Masks for both standard applications and

> > user-defined applications, then any standard application and/or any

> > user-defined application is permitted to use that set of link attributes

> > so long as there is not another set of attributes advertised on that

> > same link that is associated with a non-zero-length Application

> > Identifier Bit Mask with a matching Application Identifier Bit set.”

> >

> > https://www.rfc-editor.org/rfc/rfc8919.html#name-application-specific-link-a

> >

> > My reading is that if one ALSA “S1” with a specific application bit set

> > (e.g. X-Flag/FlexAlgo) advertises a set of attributes (A1, A2), then

> > this ALSA (or the set of all ASLA occurrence with the X-Flag set) needs

> > to advertise _/all/_ the attributes used by this application.

>

> right.

>

> >

> > So:

> >

> > - if we have another ALSA “S2” advertising zero-length Application

> > Identifier Bit Masks for both standard applications and user-defined

> > applications, that application (FlexAlgo) is not permitted to fall back

> > to “S2” in order to learn a another attribute (A3). Regardless of

> > whether S2 advertises the L-flag (legacy) or its own Link Attribute

> > sub-sub-TLVs.

>

> yes, that is correct.

>

> >

> > - if we don’t have such S2 ASLA, that application (FlexAlgo) is not

> > permitted to fall back to legacy attributes.

>

> well, if you have S1 as you mentioned above, S2 becomes irrelevant from

> the flex-algo perspective. So you are right, flex-algo is not allowed to

> use legacy advertisement in this case.

>

> >

> > IOW, an ALSA for application X, does not advertise additional/more

> > specific attributes for application X, but _/all/_ the attributes that

> > application X is allowed to read.

>

> correct.

>

>

> > As a consequence, if an attribute is

> > common to N set of applications, it needs to be advertised N times in N

> > ASLA.

>

> depends. If the set of attributes that are common across N applications

> represent the full set of attributes for all these N applications, you

> simply advertise them once with SAMB/UDAMB including the bits for all N

> applications. If the set of attributes for each application is

> different, but there is one attribute that is common, you need to

> include that attribute in ASLA advertisement for every app.

>

>

> thanks,

> Peter

>

>

>

>

>

> >

> > Thanks for correcting/confirming.

> >

> > Thanks,

> >

> > Regards,

> >

> > 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

> 

[Lsr] RFC 8919 clarification

[bruno.decraene]

Hi all,

In order to (try to) avoid interop issues, I have a clarification question on 
RFC 8919.

"If link attributes are advertised associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications, then any standard application and/or any user-defined application 
is permitted to use that set of link attributes so long as there is not another 
set of attributes advertised on that same link that is associated with a 
non-zero-length Application Identifier Bit Mask with a matching Application 
Identifier Bit set."
https://www.rfc-editor.org/rfc/rfc8919.html#name-application-specific-link-a

My reading is that if one ALSA "S1"  with a specific application bit set (e.g. 
X-Flag/FlexAlgo) advertises a set of attributes (A1, A2), then this ALSA (or 
the set of all ASLA occurrence with the X-Flag set) needs to advertise _all_ 
the attributes used by this application.

So:
- if we have another ALSA "S2" advertising zero-length Application Identifier 
Bit Masks for both standard applications and user-defined applications, that 
application (FlexAlgo) is not permitted to fall back to "S2" in order to learn 
a another attribute (A3). Regardless of whether S2 advertises the L-flag 
(legacy) or its own Link Attribute sub-sub-TLVs.
- if we don't have such S2 ASLA, that application (FlexAlgo) is not permitted 
to fall back to legacy attributes.

IOW, an ALSA for application X, does not advertise additional/more specific 
attributes for application X, but _all_ the attributes that application X is 
allowed to read. As a consequence, if an attribute is common to N set of 
applications, it needs to be advertised N times in N ASLA.

Thanks for correcting/confirming.

Thanks,
Regards,
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] RFC 8919 clarification

[bruno.decraene]

Peter,


> From: Peter Psenak [mailto:ppse...@cisco.com]
> 
> Bruno,
> 
> On 03/06/2021 15:41, bruno.decra...@orange.com wrote:
> > Hi Peter,
> >
> > Thank you for your answer and for your crystal clear email.
> >
> > As a side note, my reading of RFC 8920 is that this behaviour is
> > different in OSPF.
> 
> my reading is that it is consistent with the ISIS ASLA RFC.

Ah. Not an issue for our deployment as we are using IS-IS. But ideally I'd like 
to understand why we have a different reading.

RFC8920
If link attributes are advertised with zero-length Application Identifier Bit 
Masks for both standard applications and user-defined applications, then any 
standard application and/or any user-defined application is permitted to use 
that set of link attributes

RFC 8919
If link attributes are advertised associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications, then any standard application and/or any user-defined application 
is permitted to use that set of link attributes so long as there is not another 
set of attributes advertised on that same link that is associated with a 
non-zero-length Application Identifier Bit Mask with a matching Application 
Identifier Bit set.


The difference that I'm seeing is that RFC 8919 seems to add an extra condition 
which is not present in OSPF " so long as there is not another set of 
attributes advertised on that same link that is associated with a 
non-zero-length Application Identifier Bit Mask with a matching Application 
Identifier Bit set."

--

RFC 8920
An application-specific advertisement (Application Identifier Bit Mask with a 
matching Application Identifier Bit set) for an attribute MUST always be 
preferred over the advertisement of the same attribute with the zero-length 
Application Identifier Bit Masks for both standard applications and 
user-defined applications on the same link.


- "for an attribute" seems to indicate that the choice is on a per attribute 
basis, rather than a per ASLA basis.
- "preferred over" seems to say the application (FlexAlgo) reads the attributes 
in both the "default" ALSA and the application specific ASLA. Just in case of 
duplicate, the attribute from the application specific ASLA is prefred. 


Thanks,
--Bruno

> 
> thanks,
> Peter
> 
> 
> >
> > “If link attributes are advertised with zero-length Application
> > Identifier Bit Masks for both standard applications and user-defined
> > applications, then any standard application and/or any user-defined
> > application is permitted to use that set of link attributes. If support
> > for a new application is introduced on any node in a network in the
> > presence of such advertisements, these advertisements are permitted to
> > be used by the new application. If this is not what is intended, then
> > existing advertisements MUST be readvertised with an explicit set of
> > applications specified before a new application is introduced.An
> > application-specific advertisement (Application Identifier Bit Mask with
> > a matching Application Identifier Bit set) for an attribute MUST always
> > be preferred over the advertisement of the same attribute with the
> > zero-length Application Identifier Bit Masks for both standard
> > applications and user-defined applications on the same link.”
> >
> > Not sure whether there was a technical reason for this difference, but
> > it didn’t help be clarify by myself the RFC 8919 formulation.
> >
> > Thank you,
> >
> > --Bruno
> >
> >> -Original Message-
> >
> >> From: Peter Psenak [mailto:ppse...@cisco.com]
> >
> >> Sent: Thursday, June 3, 2021 3:28 PM
> >
> >> To: DECRAENE Bruno INNOV/NET ;
> lsr@ietf.org
> >
> >> Subject: Re: [Lsr] RFC 8919 clarification
> >
> >>
> >
> >> Hi Bruno,
> >
> >>
> >
> >> On 03/06/2021 14:55, bruno.decra...@orange.com wrote:
> >
> >> > Hi all,
> >
> >> >
> >
> >> > In order to (try to) avoid interop issues, I have a clarification
> >
> >> > question on RFC 8919.
> >
> >> >
> >
> >> > “If link attributes are advertised associated with zero-length
> >
> >> > Application Identifier Bit Masks for both standard applications and
> >
> >> > user-defined applications, then any standard application and/or any
> >
> >> > user-defined application is permitted to use that set of link attributes
> >
> >> > so long as there is not another set of attributes advertised on that
> >
> >> > same link that is associated with a non-zero-length Application
> >
> >> > Identifier Bit Mask with a matching Application Identifier Bit set.”
> >
> >> >
> >
> >> > https://www.rfc-editor.org/rfc/rfc8919.html#name-application-specific-link-a
> >
> >> >
> >
> >> > My reading is that if one ALSA “S1” with a specific application bit set
> >
> >> > (e.g. X-Flag/FlexAlgo) advertises a set of attributes (A1, A2), then
> >
> >> > this ALSA (or the set of all ASLA occurrence with the X-Flag set) needs
> >
> >> > to advertise _/all/_ the attributes used by this application.

[Lsr] draft-ietf-lsr-flex-algo

[bruno.decraene]

Hi all,

I think that I may have an issue with the way FlexAlgo [2] uses ASLA [1]

FlexAlgo is distributed routing computation so it's required that all routers 
use exactly the same data to compute the routes/SPF.

FlexAlgo is clear that ASLA MUST be used:

"Link attribute advertisements that are to be used during Flex-

   Algorithm calculation MUST use the Application-Specific Link

   Attribute (ASLA) advertisements defined in 
[RFC8919] or 
[RFC8920],"

However ASLA provides multiple ways to advertise IGP attributes and does not 
seem precise enough in its specification.
"If link attributes are advertised associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications, then any standard application and/or any user-defined application 
is permitted to use that set of link attributes"

My issue is the use of the term "permitted" which

a) is not a normative keyword

b)IMHO translates to MAY hence also MAY NOT. While we need a MUST to ensure 
a consistent SPF.



One example of issue is when FlexAlgo uses a metric different from the IGP 
(e.g. TE-metric) , and one node advertises this TE-metric in an ASLA with 
zero-length Bit Mask.
- If one node uses this TE-metric (since it is permitted to) it includes that 
link in its SPF
- If another node does not use this TE-metric (since it is not required to) it 
prunes that link from its SPF
I think it's self-evident that we would end up with a permanent routing loop.

Ideally, I would probably have preferred ALSA to be specific about the 
behaviour but ASLA is already published as RFC so it's a bit late
So at this point, I think that the burden is on FlexAlgo to specify the precise 
behaviour as a MUST in section 12. [2]

The smallest change from FlexAlgo draft standpoint may be to _require_ the use 
of the ASLA _with the X-Flag set_ . But I'm fine with whatever interoperable 
behaviour (well for me, ideally I'd prefer the behaviour already implemented by 
the implementations that I've deployed ;-) but that would be a selfish 
requirement).

Note that there are existing implementations and this would impact them. That 
been said, we do need the interop behaviour so if there are already 
inconsistent behaviours, some implementations will need to be changed (and 
hence become non interoperable with themselves)

Thanks,
Regards,
--Bruno


[1] https://www.rfc-editor.org/rfc/rfc8919.html
[2] https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-16#section-12


_

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] draft-ietf-lsr-flex-algo

[bruno.decraene]

Hi Robert,

From: Robert Raszuk [mailto:rob...@raszuk.net]


Hi Bruno,

> I think it’s self-evident that we would end up with a permanent routing loop.

Is that so ? Wouldn't it just result in unidirectional link for a given app ? 
Maybe intentional ?

It seems that what you described may cause asymmetric routing but not a routing 
loop. After all packets belonging to an app are consistently using that app's 
topology in each node.

No, I’m only discussing a single link direction.
Different upstream routers would have a different understanding of this link 
direction.
e.g.
A-B-C
+---+

All links have a metric of 10 except A-C with a metric of 100.


B->C is the link that we are discussing. Some nodes e.g. “A” see a TE –metric, 
some node (e.g. “B”) not see a TE-metric
For traffic toward C:
- A is sending to B (A’s path is A-B-C with a metric of 20)
- B is sending to A (B’s path is B-A-C with a metric of 110)
à looping between A and B

Cheers,
Bruno

Cheers,
R.





On Fri, Jun 4, 2021 at 11:03 AM 
mailto:bruno.decra...@orange.com>> wrote:
Hi all,

I think that I may have an issue with the way FlexAlgo [2] uses ASLA [1]

FlexAlgo is distributed routing computation so it’s required that all routers 
use exactly the same data to compute the routes/SPF.

FlexAlgo is clear that ASLA MUST be used:

“Link attribute advertisements that are to be used during Flex-

   Algorithm calculation MUST use the Application-Specific Link

   Attribute (ASLA) advertisements defined in 
[RFC8919] or 
[RFC8920],”

However ASLA provides multiple ways to advertise IGP attributes and does not 
seem precise enough in its specification.
“If link attributes are advertised associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications, then any standard application and/or any user-defined application 
is permitted to use that set of link attributes”

My issue is the use of the term “permitted” which

a) is not a normative keyword

b)IMHO translates to MAY hence also MAY NOT. While we need a MUST to ensure 
a consistent SPF.



One example of issue is when FlexAlgo uses a metric different from the IGP 
(e.g. TE-metric) , and one node advertises this TE-metric in an ASLA with 
zero-length Bit Mask.
- If one node uses this TE-metric (since it is permitted to) it includes that 
link in its SPF
- If another node does not use this TE-metric (since it is not required to) it 
prunes that link from its SPF
I think it’s self-evident that we would end up with a permanent routing loop.

Ideally, I would probably have preferred ALSA to be specific about the 
behaviour but ASLA is already published as RFC so it’s a bit late
So at this point, I think that the burden is on FlexAlgo to specify the precise 
behaviour as a MUST in section 12. [2]

The smallest change from FlexAlgo draft standpoint may be to _require_ the use 
of the ASLA _with the X-Flag set_ . But I’m fine with whatever interoperable 
behaviour (well for me, ideally I’d prefer the behaviour already implemented by 
the implementations that I’ve deployed ;-) but that would be a selfish 
requirement).

Note that there are existing implementations and this would impact them. That 
been said, we do need the interop behaviour so if there are already 
inconsistent behaviours, some implementations will need to be changed (and 
hence become non interoperable with themselves)

Thanks,
Regards,
--Bruno


[1] https://www.rfc-editor.org/rfc/rfc8919.html
[2] https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-16#section-12


_



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

_

Ce message et ses pieces jointes peuvent contenir des 

Re: [Lsr] draft-ietf-lsr-flex-algo

[bruno.decraene]

From: Robert Raszuk [mailto:rob...@raszuk.net]
Sent: Friday, June 4, 2021 3:35 PM
To: DECRAENE Bruno INNOV/NET 
Cc: draft-ietf-lsr-flex-a...@ietf.org; lsr@ietf.org
Subject: Re: [Lsr] draft-ietf-lsr-flex-algo


Ok you meant domain wide not locally ... but there is already strong normative 
MUST in Flex Algo as the user of ASLA so no loop will happen.

The "permitted" from ASLA RFC is just to indicate what applications may use 
such attribute with zero-length
   Application Identifier Bit Masks as opposed to rest of the sentence which 
you did not quote which reads:

 ...so long as there is not another set of attributes

   advertised on that same link that is associated with a non-zero-

   length Application Identifier Bit Mask with a matching Application

   Identifier Bit set.



So context of "permitted" is not in the sense use or not use ASLA, but in the 
sense when both use zero length or none zero length app id is present.



Agreed that ASLA MUST be used.

Now ASLA allows two ways to advertise attributes (so both ways _are_ ALSA):

a) inside an ASLA with the X-flag set (attribute specifically for FlexAlgo)

b) inside an ASLA with all flags cleared (attribute that every application MAY 
use, so a priori including FlexAlgo)



My point is that for case “b”, “MAY” does not seem strong enough to ensure 
consistency along the SPT. I gave an example in my original email, you may 
refer to it.

A priori we need FlexAlgo to choose and specify whether the second signalling 
(“b”) MUST or MUST NOT be used. We just need to write this down. If we all 
agree on the choice, that’s easy. If we don’t, that’s harder but even more 
necessary for interop.



Alternatively, I’m wrong and that’s even better.



--Bruno





Thx



On Fri, Jun 4, 2021 at 2:56 PM 
mailto:bruno.decra...@orange.com>> wrote:
Hi Robert,

From: Robert Raszuk [mailto:rob...@raszuk.net]

Hi Bruno,

> I think it’s self-evident that we would end up with a permanent routing loop.

Is that so ? Wouldn't it just result in unidirectional link for a given app ? 
Maybe intentional ?

It seems that what you described may cause asymmetric routing but not a routing 
loop. After all packets belonging to an app are consistently using that app's 
topology in each node.

No, I’m only discussing a single link direction.
Different upstream routers would have a different understanding of this link 
direction.
e.g.
A-B-C
+---+

All links have a metric of 10 except A-C with a metric of 100.


B->C is the link that we are discussing. Some nodes e.g. “A” see a TE –metric, 
some node (e.g. “B”) not see a TE-metric
For traffic toward C:
- A is sending to B (A’s path is A-B-C with a metric of 20)
- B is sending to A (B’s path is B-A-C with a metric of 110)
--> looping between A and B

Cheers,
Bruno

Cheers,
R.





On Fri, Jun 4, 2021 at 11:03 AM 
mailto:bruno.decra...@orange.com>> wrote:
Hi all,

I think that I may have an issue with the way FlexAlgo [2] uses ASLA [1]

FlexAlgo is distributed routing computation so it’s required that all routers 
use exactly the same data to compute the routes/SPF.

FlexAlgo is clear that ASLA MUST be used:

“Link attribute advertisements that are to be used during Flex-

   Algorithm calculation MUST use the Application-Specific Link

   Attribute (ASLA) advertisements defined in 
[RFC8919] or 
[RFC8920],”

However ASLA provides multiple ways to advertise IGP attributes and does not 
seem precise enough in its specification.
“If link attributes are advertised associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications, then any standard application and/or any user-defined application 
is permitted to use that set of link attributes”

My issue is the use of the term “permitted” which

a) is not a normative keyword

b)IMHO translates to MAY hence also MAY NOT. While we need a MUST to ensure 
a consistent SPF.



One example of issue is when FlexAlgo uses a metric different from the IGP 
(e.g. TE-metric) , and one node advertises this TE-metric in an ASLA with 
zero-length Bit Mask.
- If one node uses this TE-metric (since it is permitted to) it includes that 
link in its SPF
- If another node does not use this TE-metric (since it is not required to) it 
prunes that link from its SPF
I think it’s self-evident that we would end up with a permanent routing loop.

Ideally, I would probably have preferred ALSA to be specific about the 
behaviour but ASLA is already published as RFC so it’s a bit late
So at this point, I think that the burden is on FlexAlgo to specify the precise 
behaviour as a MUST in section 12. [2]

The smallest change from FlexAlgo draft standpoint may be to _require_ the use 
of the ASLA _with the X-Flag set_ . But I’m fine with whatever interoperable 
behaviour (well for me, ideally I’d prefer the behaviour already 

Re: [Lsr] draft-ietf-lsr-flex-algo

[bruno.decraene]

From: Robert Raszuk [mailto:rob...@raszuk.net]
Sent: Friday, June 4, 2021 4:50 PM
To: DECRAENE Bruno INNOV/NET 
Cc: draft-ietf-lsr-flex-a...@ietf.org; lsr@ietf.org
Subject: Re: [Lsr] draft-ietf-lsr-flex-algo


To me this "permitted" is only about applying ASLA to all apps (no bit mask) 
except specific apps IDs matching their ID if present in the bit mask.
It is not about applying ASLA itself or not applying it at all.

[BD] I think that I agree but I don’t see how this relates to my comment.
Let’s come back to my example:
when FlexAlgo uses a metric different from the IGP (e.g. TE-metric) , and one 
node advertises this TE-metric in an ASLA with zero-length Bit Mask.
The question is: does FlexAlgo use this TE-metric (and hence the link)? Or not.
Is this already specified as a MUST or does extra text needs to be written?


   If link attributes are advertised associated with zero-length

   Application Identifier Bit Masks for both standard applications and

   user-defined applications, then any standard application and/or any

   user-defined application is permitted to use that set of link

   attributes so long as there is not another set of attributes

   advertised on that same link that is associated with a non-zero-

   length Application Identifier Bit Mask with a matching Application

   Identifier Bit set.



Is there any shipping implementation which reads this the way you interpret it 
and chooses not to apply it at all ?



[BD] I’ll refrain from speaking about implementations.

I’m not sure how much implementations have to do with a comment/question on the 
specification. The reference is the specification. Again, if this is so obvious 
that everyone agree on the behaviour, let’s write down the result in the spec 
or point me to an existing text in the spec.



Thanks,

Bruno



Thx

R.

On Fri, Jun 4, 2021 at 4:12 PM 
mailto:bruno.decra...@orange.com>> wrote:


From: Robert Raszuk [mailto:rob...@raszuk.net]
Sent: Friday, June 4, 2021 3:35 PM
To: DECRAENE Bruno INNOV/NET 
mailto:bruno.decra...@orange.com>>
Cc: 
draft-ietf-lsr-flex-a...@ietf.org; 
lsr@ietf.org
Subject: Re: [Lsr] draft-ietf-lsr-flex-algo


Ok you meant domain wide not locally ... but there is already strong normative 
MUST in Flex Algo as the user of ASLA so no loop will happen.

The "permitted" from ASLA RFC is just to indicate what applications may use 
such attribute with zero-length
   Application Identifier Bit Masks as opposed to rest of the sentence which 
you did not quote which reads:

 ...so long as there is not another set of attributes

   advertised on that same link that is associated with a non-zero-

   length Application Identifier Bit Mask with a matching Application

   Identifier Bit set.



So context of "permitted" is not in the sense use or not use ASLA, but in the 
sense when both use zero length or none zero length app id is present.



Agreed that ASLA MUST be used.

Now ASLA allows two ways to advertise attributes (so both ways _are_ ALSA):

a) inside an ASLA with the X-flag set (attribute specifically for FlexAlgo)

b) inside an ASLA with all flags cleared (attribute that every application MAY 
use, so a priori including FlexAlgo)



My point is that for case “b”, “MAY” does not seem strong enough to ensure 
consistency along the SPT. I gave an example in my original email, you may 
refer to it.

A priori we need FlexAlgo to choose and specify whether the second signalling 
(“b”) MUST or MUST NOT be used. We just need to write this down. If we all 
agree on the choice, that’s easy. If we don’t, that’s harder but even more 
necessary for interop.



Alternatively, I’m wrong and that’s even better.



--Bruno





Thx



On Fri, Jun 4, 2021 at 2:56 PM 
mailto:bruno.decra...@orange.com>> wrote:
Hi Robert,

From: Robert Raszuk [mailto:rob...@raszuk.net]

Hi Bruno,

> I think it’s self-evident that we would end up with a permanent routing loop.

Is that so ? Wouldn't it just result in unidirectional link for a given app ? 
Maybe intentional ?

It seems that what you described may cause asymmetric routing but not a routing 
loop. After all packets belonging to an app are consistently using that app's 
topology in each node.

No, I’m only discussing a single link direction.
Different upstream routers would have a different understanding of this link 
direction.
e.g.
A-B-C
+---+

All links have a metric of 10 except A-C with a metric of 100.


B->C is the link that we are discussing. Some nodes e.g. “A” see a TE –metric, 
some node (e.g. “B”) not see a TE-metric
For traffic toward C:
- A is sending to B (A’s path is A-B-C with a metric of 20)
- B is sending to A (B’s path is B-A-C with a metric of 110)
--> looping between A and B

Cheers,
Bruno

Cheers,
R.





On Fri, Jun 4, 2021 at 11:03 AM 
mailto:bruno.decra...@orange.com>> wrote:
Hi all,

I think that I may have an issue with the 

[Lsr] draft-decraene-lsr-isis-flooding-speed & IETF 111

[bruno.decraene]

Hi chairs, WG,

Over the last two years, we have presented and the WG discussed 
draft-decraene-lsr-isis-flooding-speed at IETF 105 and "107"
IETF 105: https://datatracker.ietf.org/meeting/105/proceedings#lsrNote: 
that the presentation is in first slot/video but a large part of the discussion 
is in the second one.
IETF 107/interim: 
https://datatracker.ietf.org/meeting/interim-2020-lsr-02/materials/agenda-interim-2020-lsr-02-lsr-01-07.html

The goal is to improve flooding performance and robustness to make it both 
faster when the receiver have free cycles, and slower when the receiver is 
congested.

In addition to technical discussions, a feedback was that implementation and 
tests/evaluation would be good in order to evaluate the proposal.

We are reporting that we have an implementation of [1] based on the open source 
Free Range Routing implementation.
We are now ready to report the evaluation to the WG. We have a lot of data so 
ideally would need around an hour in order to cover the whole picture.

We have requested a slot for IETF 111 LSR meeting. If the IETF 111 slot is 
short, we'd like to request for an interim meeting. In order to keep the 
context, the sooner/closer to IETF 111 seems the better.

Since we have an implementation, we have requested for a code point, in order 
to avoid squatting on one. This is currently under review by the designed 
experts.

Finally, given the two-years work, the specification, the implementation and 
extensive evaluation, we'd like to ask for WG adoption.

Thanks,
Regards,
--Bruno


[1] https://datatracker.ietf.org/doc/html/draft-decraene-lsr-isis-flooding-speed


_

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] draft-decraene-lsr-isis-flooding-speed & IETF 111

[bruno.decraene]

Les,

Faster flooding may be achieved without protocol extension. But if we are at 
changing flooding, it would be reasonable to try to make it good (rather than 
just faster than today).
In particular some goals are:
- faster flooding when the receiver has free cycles
- slower flooding when the receiver is busy/congested (either by flooding, or 
any CPU computation including not coming from IS-IS)
- avoiding/minimizing the parameters that the network operator is been asked to 
tune
- avoiding/minimizing the loss of LSPs
- robust to a wide variety of conditions (good ones and bad ones)

You seem to agree on changing the flooding behaviour on both the sender and the 
receiver so that they can better cooperate. That’s protocol extension to me 
(and IMHO much bigger than the sending of info in one TLV)

Bruno

From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Friday, July 9, 2021 7:49 PM
To: DECRAENE Bruno INNOV/NET ; lsr-cha...@ietf.org
Cc: lsr@ietf.org
Subject: RE: draft-decraene-lsr-isis-flooding-speed & IETF 111

Bruno –

Neither of us has presented anything new of substance in the last few IETFs.
There were two presentations recently - one by Arista and one by Huawei – each 
of which simply demonstrated that it is possible to flood faster - and that in 
order to do so it is helpful to send acks faster - both points on which there 
is no disagreement.

To have a productive discussion we both need to present new data - which is why 
having the discussion as part of the meeting at which the presentations occur 
makes sense to me.

We removed the example(sic) algorithm from our draft because it was only an 
example, is not normative, and we did not want the discussion of our approach 
to be bogged down in a debate on the specifics of the example algorithm.
Based on your response, seems like we were right to remove the algorithm. 

Regarding WG adoption, one of the premises of our draft is that faster flooding 
can be achieved w/o protocol extensions and so there is no need for a draft at 
all. I am sure we do not yet agree on this - but I do hope that makes clear why 
adopting either draft at this time is premature.

   Les


From: bruno.decra...@orange.com 
mailto:bruno.decra...@orange.com>>
Sent: Friday, July 9, 2021 9:15 AM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
lsr-cha...@ietf.org
Cc: lsr@ietf.org
Subject: RE: draft-decraene-lsr-isis-flooding-speed & IETF 111

Les,

> From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
[…]
> I also think it would be prudent to delay WG adoption

For how long exactly would it be “prudent to delay WG adoption”? (in addition 
to the past two years)
Until what condition?

It’s been two years now since draft-decraene-lsr-isis-flooding-speed brought 
this subject to the WG (and even more in private discussions).
Two years during which we have presented our work to the WG, discussed your 
comments/objections, been asked to provide more data and consequently worked 
harder to implement it and obtain evaluation results.
What’s precisely the bar before a call for WG adoption be initiated?
We have data proving the benefit, so after those two years, what are your clear 
and precise _technical_ objections to the mechanism proposed in 
draft-decraene-lsr-isis-flooding-speed?

Coming back to draft-decraene-lsr-isis-flooding-speed,
we have a specification and the flow control part is stable.
We have an implementation and many evaluations demonstrating that flow control 
alone is very effective in typical conditions.
we have an additional congestion control part which is still been refined but 
this part is a local behavior which don’t necessarily needs to be standardized 
and which is mostly useful when the receivers of the LSP is not CPU-bound which 
does not seem to be the case from what we have seen. (in most of the cases, 
receivers are CPU bound. In fact, we needed to artificially create I/O 
congestion in order to evaluate the congestion control part) .


Regarding your draft, in the latest version of your draft, published yesterday, 
you have removed the specification of your proposed congestion control 
algorithm… Based on this, I don’t see how technical discussion and comparison 
of the specification can be achieved.
You have an implementation. This is good to know and we are ready to evaluate 
it under the same conditions than our implementation, so that we can compare 
the data. Could you please send us an image? We may be able to have data for 
the interim.

--Bruno

From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Friday, July 9, 2021 5:00 PM
To: DECRAENE Bruno INNOV/NET 
mailto:bruno.decra...@orange.com>>; 
lsr-cha...@ietf.org; 
lsr@ietf.org
Subject: RE: draft-decraene-lsr-isis-flooding-speed & IETF 111

As is well known, there are two drafts in this problem space:

Re: [Lsr] draft-decraene-lsr-isis-flooding-speed & IETF 111

[bruno.decraene]

Les,

> From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
[...]
> I also think it would be prudent to delay WG adoption

For how long exactly would it be "prudent to delay WG adoption"? (in addition 
to the past two years)
Until what condition?

It's been two years now since draft-decraene-lsr-isis-flooding-speed brought 
this subject to the WG (and even more in private discussions).
Two years during which we have presented our work to the WG, discussed your 
comments/objections, been asked to provide more data and consequently worked 
harder to implement it and obtain evaluation results.
What's precisely the bar before a call for WG adoption be initiated?
We have data proving the benefit, so after those two years, what are your clear 
and precise _technical_ objections to the mechanism proposed in 
draft-decraene-lsr-isis-flooding-speed?

Coming back to draft-decraene-lsr-isis-flooding-speed,
we have a specification and the flow control part is stable.
We have an implementation and many evaluations demonstrating that flow control 
alone is very effective in typical conditions.
we have an additional congestion control part which is still been refined but 
this part is a local behavior which don't necessarily needs to be standardized 
and which is mostly useful when the receivers of the LSP is not CPU-bound which 
does not seem to be the case from what we have seen. (in most of the cases, 
receivers are CPU bound. In fact, we needed to artificially create I/O 
congestion in order to evaluate the congestion control part) .


Regarding your draft, in the latest version of your draft, published yesterday, 
you have removed the specification of your proposed congestion control 
algorithm... Based on this, I don't see how technical discussion and comparison 
of the specification can be achieved.
You have an implementation. This is good to know and we are ready to evaluate 
it under the same conditions than our implementation, so that we can compare 
the data. Could you please send us an image? We may be able to have data for 
the interim.

--Bruno

From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Friday, July 9, 2021 5:00 PM
To: DECRAENE Bruno INNOV/NET ; lsr-cha...@ietf.org; 
lsr@ietf.org
Subject: RE: draft-decraene-lsr-isis-flooding-speed & IETF 111

As is well known, there are two drafts in this problem space:

https://datatracker.ietf.org/doc/draft-decraene-lsr-isis-flooding-speed/
and
https://datatracker.ietf.org/doc/draft-ginsberg-lsr-isis-flooding-scale/


Regarding the latter, we also have a working implementation and we also have 
requested a presentation slot for IETF 111 LSR WG meeting.

I agree with Bruno that the time available in the WG meeting will likely be 
inadequate to present full updates for both drafts. In addition, I think it is 
important that the WG have
an opportunity to discuss publicly in an interactive way, the merits of each 
proposal. The likelihood that time will be available in the scheduled WG 
meeting for that discussion as well seems low.

I therefore join w Bruno in suggesting that an interim meeting dedicated to the 
flooding speed topic be organized.
Given the short time available before IETF 111, I would suggest that we look at 
scheduling an interim meeting after IETF 111 - but I leave it to the WG chairs 
to decide when to schedule this.

I also think it would be prudent to delay WG adoption calls for either draft 
until after such an interim meeting is held. In that way the WG can make a more 
informed decision.

   Les

From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
bruno.decra...@orange.com
Sent: Friday, July 9, 2021 2:01 AM
To: lsr-cha...@ietf.org; 
lsr@ietf.org
Subject: [Lsr] draft-decraene-lsr-isis-flooding-speed & IETF 111

Hi chairs, WG,

Over the last two years, we have presented and the WG discussed 
draft-decraene-lsr-isis-flooding-speed at IETF 105 and "107"
IETF 105: https://datatracker.ietf.org/meeting/105/proceedings#lsrNote: 
that the presentation is in first slot/video but a large part of the discussion 
is in the second one.
IETF 107/interim: 
https://datatracker.ietf.org/meeting/interim-2020-lsr-02/materials/agenda-interim-2020-lsr-02-lsr-01-07.html

The goal is to improve flooding performance and robustness to make it both 
faster when the receiver have free cycles, and slower when the receiver is 
congested.

In addition to technical discussions, a feedback was that implementation and 
tests/evaluation would be good in order to evaluate the proposal.

We are reporting that we have an implementation of [1] based on the open source 
Free Range Routing implementation.
We are now ready to report the evaluation to the WG. We have a lot of data so 
ideally would need around an hour in order to cover the whole picture.

We have requested a slot for IETF 111 LSR meeting. If the IETF 111 slot is 
short, we'd like to request for an interim 

Re: [Lsr] AD Review of draft-ietf-lsr-isis-srv6-extensions-11

[bruno.decraene]

Hi Peter,

> From: Peter Psenak [mailto:ppse...@cisco.com]
> Sent: Friday, March 12, 2021 3:13 PM
> 
> Hi Bruno,
> 
> please see inline:
> 
> On 12/03/2021 11:39, bruno.decra...@orange.com wrote:
> > Peter, Alvaro
> >
> >> From: Peter Psenak [mailto:ppse...@cisco.com]
> >> Sent: Thursday, March 11, 2021 11:47 AM
> >
> > [...]
> >
> >>> ...
> >>> 221   4.3.  Maximum H.Encaps MSD Type
> >>>
> >>> 223  The Maximum H.Encaps MSD Type specifies the maximum
> number
> >> of SIDs
> >>> 224  that can be included as part of the "H.Encaps" behavior as
> defined
> >> in
> >>> 225  [I-D.ietf-spring-srv6-network-programming].
> >>>
> >>> [nit] s/included/pushed   That is the terminology used in rfc8986.
> >>
> >> ##PP
> >> fixed.
> >>
> >>>
> >>>
> >>> ...
> >>> 229     If the advertised value is zero or no value is advertised
> >>> 230     then the router can apply H.Encaps only by encapsulating
> >>> 231     the incoming packet in another IPv6 header without SRH
> >>> 232     the same way IPinIP encapsulation is performed.
> >>>
> >>> 234     If the advertised value is non-zero then the router
> supports both
> >>> 235     IPinIP and SRH encapsulation subject to the SID limitation
> >>> 236     specified by the advertised value.
> >>>
> >>> [major] rfc8986 doesn't talk about IPinIP encapsulation, but is does say
> this:
> >>>
> >>>      The push of the SRH MAY be omitted when the SRv6 Policy only
> contains
> >>>      one segment and there is no need to use any flag, tag or TLV.
> >>>
> >>> Suggestion (to replace the last two paragraphs)>
> >>>       If the advertised value is zero or no value is advertised then the
> >>>       headend can apply an SR Policy that only contains one segment, by
> >>>       omitting the SRH push.
> >>>
> >>>       A non-zero SRH Max H.encaps MSD indicates that the headend can
> push
> >>>       an SRH up to the advertised value.
> >>
> >> ##PP
> >> done, but used "insert" instead of "push".
> >
> > In SRv6, "Insert" has been used with a different meaning (SRH insertion
> without IP encapsulation) and hence is very connoted. So I would prefer if
> we could avoid the term "insert", to avoid both misunderstanding and
> ambiguities.
> >
> > I'm not sure how many/which  :s/push/insert  you are referring to as I'm
> seen 3  "push". I'll assume you meant the 3 of them. I would suggest the
> following change, but any other formulation would probably work for me.
> >
> > OLD: The push of the SRH MAY be omitted
> > NEW: The SRH MAY be omitted
> >
> > OLD: by omitting the SRH push.
> > NEW by omitting the SRH.
> >
> > OLD: the headend can push an SRH up to the advertised value.
> > NEW: the headend can perform IP encapsulation with an SRH containing up
> to MSD SIDs.
> > (or may be: up to this number of SIDs)
> 
> not sure which document/version do you look at, but I don't see any
> occurrence of "push" or "insert" in the latest published version (11).

I'm referring to the email (above) that you sent yesterday on the LSR mailing 
list in which you said " ##PP done, but used "insert" instead of "push"."
It's not reflected in the latest published version which date from October 8, 
2020

 > The single "push" I added as a response to Alvaro's comment was at:
> 
> 
> The Maximum H.Encaps MSD Type signals the maximum number of SIDs
> that can be pushed as part of the "H.Encaps" behavior as defined in
> [RFC8986]"
> 
> Please let me know how do you prefer that to be modified.
> 
> 
> >
> >
> > [...]
> >
> >
> >> 245  SRH Max End D Type: 45
> >>
> >> 247  If the advertised value is zero or no value is advertised
> >> 248  then it is assumed that the router cannot apply
> >> 249  "End.DX6" or "End.DT6" behaviors if the outer IPv6 header
> >> 250  contains an SRH.
> >
> > Since I've started, I'll continue to nick pick.
> >
> > "assume" does not seem like the right term when talking about an explicit
> signalling.
> > I would suggest
> > OLD: then it is assumed that the router cannot apply
> > NEW: then the router cannot apply
> 
> fixed them all.

Thanks,
--Bruno

 
> Peter
> >
> >
> > *3 (in §4.1, §4.2, §4.4)
> >
> >
> > Thank you,
> > --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 

Re: [Lsr] When is an IANA Registry Required

[bruno.decraene]

+1
The information needs to be tracked and consolidated. Seems better done by a 
single person than by many persons duplicating the work, not to mention by zero 
person (surely someone else is doing the job).
This may be less important in LSR though, as we have designated experts which 
may already do this work. However:
-IINM, the designated expert is only appointed when there is a registry.
-IMHO there would be value in having the tracking data been public. IANA looks 
good to me. In theory, github may also work.

That also assumes that code point/flags be tracked -hence allocated- soon 
enough, rather than been hidden in a draft or specific implementation.

Thanks,
--Bruno

From: Acee Lindem (acee) [mailto:a...@cisco.com]
Sent: Thursday, March 18, 2021 6:15 PM
To: Les Ginsberg (ginsberg) ; Tony Li 
Cc: Alvaro Retana ; 
draft-ietf-lsr-isis-srv6-extensi...@ietf.org; lsr@ietf.org; John Scudder 
; Christian Hopps ; lsr-cha...@ietf.org
Subject: Re: [Lsr] When is an IANA Registry Required

Speaking as WG member:

Hi Les,
My opinion is there is no harm and some advantage in having IANA registries for 
unique IGP protocol bit flag fields. For the existing fields that don’t have 
registries, there is no burning requirement to go back and define an IANA 
registry until such time as that flag field is extended.

Note that for OSPF, we did add these registries in 
https://www.rfc-editor.org/rfc/rfc4940.txt (thanks to Kireeti).
Thanks,
Acee

From: "Les Ginsberg (ginsberg)" mailto:ginsb...@cisco.com>>
Date: Thursday, March 18, 2021 at 12:44 PM
To: Tony Li mailto:tony...@tony.li>>
Cc: Alvaro Retana mailto:aretana.i...@gmail.com>>, 
"draft-ietf-lsr-isis-srv6-extensi...@ietf.org"
 
mailto:draft-ietf-lsr-isis-srv6-extensi...@ietf.org>>,
 "lsr@ietf.org" mailto:lsr@ietf.org>>, John 
Scudder mailto:j...@juniper.net>>, Christian Hopps 
mailto:cho...@chopps.org>>, 
"lsr-cha...@ietf.org" 
mailto:lsr-cha...@ietf.org>>
Subject: RE: [Lsr] When is an IANA Registry Required
Resent-From: mailto:alias-boun...@ietf.org>>
Resent-To: Acee Lindem mailto:a...@cisco.com>>, Yingzhen Qu 
mailto:yingzhen.i...@gmail.com>>, Christian Hopps 
mailto:cho...@chopps.org>>
Resent-Date: Thursday, March 18, 2021 at 12:44 PM

Tony –

In this context I don’t find the use of a registry of value. The primary issue 
for me for these fields is not managing the bit assignments but understanding 
the functionality – and for that I need to look at the document(s) which have 
that definition. A registry in these cases provides little value and adds 
process and a possibility for inconsistency.

But, I am not expecting that there is anything I can say to change your opinion 
– nor vice versa. So I appreciate that you have made your POV clear and the 
reasons for it – and I am not trying to change your opinion.

I started this thread because I did not think a change in WG policy should be 
made solely based on a single document review comment from one individual – 
even one as highly respected as Alvaro.
Thus far we have a handful of opinions – I am hoping more members of the WG 
will respond to the thread and then we can proceed appropriately.

   Les

From: Tony Li mailto:tony1ath...@gmail.com>> On Behalf 
Of Tony Li
Sent: Thursday, March 18, 2021 8:24 AM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Cc: Alvaro Retana mailto:aretana.i...@gmail.com>>; 
draft-ietf-lsr-isis-srv6-extensi...@ietf.org;
 lsr@ietf.org; John Scudder 
mailto:j...@juniper.net>>; Christian Hopps 
mailto:cho...@chopps.org>>; 
lsr-cha...@ietf.org
Subject: Re: [Lsr] When is an IANA Registry Required


Les,



IMO, there is no need for registries for the first category. The WG has been 
alive for over 20 years, defined many new TLVs with flags fields, and I am not 
aware of any confusion – so if it ain’t broke don’t fix it.


With all due respect Les, you appear to operate with an eidetic memory of all 
things IS-IS, so I think that you discount the confusion that the rest of us 
live in.

If a field has values defined in two documents, then there’s confusion. Even 
just finding both is a challenge.

Regards,
Tony



_

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