Re: [Lsr] Last Call: (Update to OSPF Terminology) to Proposed Standard

[Adrian Farrel]

Hi,

Just a quick comment in last call for this draft.

Would it be a good idea to also give some steer to future documents?

Something like "It is intended that all future OSPF documents use this
revised terminology even when they reference the RFCs updated by this
document."

That could go in the Abstract and Introduction.

Cheers,
Adrian

-Original Message-
From: IETF-Announce  On Behalf Of The IESG
Sent: 19 April 2023 21:01
To: IETF-Announce 
Cc: lsr@ietf.org; cho...@chopps.org;
draft-ietf-lsr-ospf-terminol...@ietf.org; lsr-cha...@ietf.org
Subject: Last Call:  (Update to OSPF
Terminology) to Proposed Standard


The IESG has received a request from the Link State Routing WG (lsr) to
consider the following document: - 'Update to OSPF Terminology'
   as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-c...@ietf.org mailing lists by 2023-05-03. Exceptionally, comments may
be sent to i...@ietf.org instead. In either case, please retain the
beginning
of the Subject line to allow automated sorting.

Abstract


   This document updates some OSPF terminology to be in line with
   inclusive language used in the industry.  The IETF has designated
   National Institute of Standards and Technology (NIST) "Guidance for
   NIST Staff on Using Inclusive Language in Documentary Standards" for
   its inclusive language guidelines.

   This document updates RFC2328, RFC5340, RFC4222, RFC4811, RFC5243,
   RFC5614, and RFC5838.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-terminology/



No IPR declarations have been submitted directly on this I-D.





___
IETF-Announce mailing list
ietf-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

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

Re: [Lsr] Lars Eggert's Discuss on draft-ietf-lsr-pce-discovery-security-support-11: (with DISCUSS and COMMENT)

[Adrian Farrel]

Yeah, I like that suggestion.
A

-Original Message-
From: Les Ginsberg (ginsberg)  
Sent: 04 October 2022 20:43
To: John Scudder 
Cc: Acee Lindem (acee) ; Lars Eggert ; The 
IESG ; draft-ietf-lsr-pce-discovery-security-supp...@ietf.org; 
lsr-cha...@ietf.org; lsr ; p...@ietf.org; Hannes Gredler 
; JP Vasseur (jvasseur) ; 
meral.shirazip...@polymtl.ca; Adrian Farrel 
Subject: RE: [Lsr] Lars Eggert's Discuss on 
draft-ietf-lsr-pce-discovery-security-support-11: (with DISCUSS and COMMENT)

John -

So you are suggesting that Section 4 of the draft be modified to say:

"This introduction of additional sub-TLVs should be viewed as an exception to 
the [RFC5088][RFC5089] policy, justified by the requirement to discover the 
PCEP security support prior to establishing a PCEP session. The restrictions 
defined in [RFC5089][RFC5089] should still be considered to be in place.
If in the future new advertisements are required, alternative mechanisms such 
as using [RFC6823] or 
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-transport-instance/ should 
be considered."

(or similar...)

I am fine with that.

   Les


> -Original Message-
> From: John Scudder 
> Sent: Tuesday, October 4, 2022 12:31 PM
> To: Les Ginsberg (ginsberg) 
> Cc: Acee Lindem (acee) ; Lars Eggert ;
> The IESG ; draft-ietf-lsr-pce-discovery-security-
> supp...@ietf.org; lsr-cha...@ietf.org; lsr ; p...@ietf.org;
> Hannes Gredler ; JP Vasseur (jvasseur)
> ; meral.shirazip...@polymtl.ca; Adrian Farrel
> 
> Subject: Re: [Lsr] Lars Eggert's Discuss on draft-ietf-lsr-pce-discovery-
> security-support-11: (with DISCUSS and COMMENT)
> 
> Hi Les,
> 
> Thanks, that’s helpful. One comment, regarding
> 
> > Hard for me to justify modifying RFC 5088/5089 simply to add a pointer to
> GENINFO/OSPF-GT even if such an addition might be relevant.
> 
> what I was actually suggesting was that the paragraph in draft-ietf-lsr-pce-
> discovery-security-support could be updated to add the pointer. Since draft-
> ietf-lsr-pce-discovery-security-support formally updates RFCs 5088/5089,
> that would establish at least some mechanism less unreliable than trolling
> through old mailing lists, to help a new implementor find this old history,
> while still not requiring us to do the heavy lift of bis’ing 5088/5089 (which 
> I
> agree would be crazy to do just for this).
> 
> —John
> 
> > On Oct 4, 2022, at 3:24 PM, Les Ginsberg (ginsberg) 
> wrote:
> >
> > John -
> >
> > Thanx for finding the old email thread.
> > Folks also might want to look at this thread:
> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/lsr/Nhe
> zQqKwIvHK_9dDUmW0iuhyjDA/__;!!NEt6yMaO-gk!BsexV0igrfCC6797R-
> 5WEj654ycPt6DwvDJJ9cKMToAWSjm6GzCfKem3ylr0c4DezgdzY3N-mB2epg$
> >
> > In summary, I raised these points when the draft was adopted - but
> eventually agreed to allow the draft to go forward.
> >
> > The intent of the restrictions in RFC5088/5089 is to discourage carrying
> additional "non-routing" information in the IGPs.
> > The practical matter in this case is that trying to advertise the additional
> information using some other mechanism is quite costly and awkward. The
> fact that the additional information are sub-sub-TLVs of the PCED sub-TLV
> speaks to the coupling of the new information with the existing information.
> >
> > I think we want to keep restrictions in place so as to discourage new
> advertisements, but recognize that we compromise when it seems practical.
> This isn’t ideal - and I understand why Lars would want to discuss this - but 
> I
> don't have a cleaner solution.
> > The fact that we introduced PCE advertisements into the IGPs in the first
> place makes it difficult to adhere to the restrictions for PCE related
> advertisements.
> >
> > Section 4 of the draft states:
> >
> > "This introduction of additional sub-TLVs should be viewed as an exception
> to the [RFC5088][RFC5089] policy, justified by the requirement to discover
> the PCEP security support prior to establishing a PCEP session. The
> restrictions defined in [RFC5089][RFC5089] should still be considered to be in
> place."
> >
> > which is an accurate summary.
> >
> > Hard for me to justify modifying RFC 5088/5089 simply to add a pointer to
> GENINFO/OSPF-GT even if such an addition might be relevant.
> >
> >   Les
> >
> >> -Original Message-
> >> From: John Scudder 
> >> Sent: Tuesday, October 4, 2022 11:16 AM
> >> To: Acee Lindem (acee) 
> >> Cc: Lars Eggert ; The IESG ; draft-ietf-
> lsr-
> >> pce-discovery-security-supp...@ietf.org; lsr-cha...@ietf.org; lsr
> >> ; p

Re: [Lsr] Lars Eggert's Discuss on draft-ietf-lsr-pce-discovery-security-support-11: (with DISCUSS and COMMENT)

[Adrian Farrel]

Hi all,

I'm going to say what I can remember before I read the thread. I was PCE 
co-chair as this work went through.

There was a feeling that using the IGPs for carrying "stuff" was not a wise 
idea. It was one thing to exchange information that all participants in the 
protocol needed to perform the functions of the IGP, another to use the IGP for 
information that most of the routers would need to know, and not great to use 
the IGP for sharing information only some of the routers need to know.

The PCE capabilities exchange in the IGP was always a bit of a stretch. 
Learning of the existence of a PCE in a network of routers that all use the PCE 
function might be valuable thing (although there are many other ways to 
discover servers). And it may be helpful, when there are many PCEs available, 
to provide enough information to allow selection between servers. But that 
became a heavy load as more and more optional PCE features were added and the 
amount of information carried by the IGP was set to keep growing. The main 
worry was, of course, not the definition of a few additional bits, but the 
inclusion of additional TLVs.

Since PCEP has a mechanism for PCEs to advertise and negotiate their 
capabilities, and since the main discovery issues were already covered by the 
IGP work, it seemed reasonable to draw a line. We could have asked to take the 
new capabilities one by one, but it seemed like everyone's favourite capability 
was going to be argued as a special case, so we drew a very solid line and said 
"no new sub-TLVs". This rule allowed new flags (since there were plenty of 
unused flags available) and you can see how this has been used in the registry 
with another 8 flags defined by 5 RFCs).

Now, the question with this I-D is about whether the issues of protocol 
security are sufficiently special case to warrant allowing new TLVs in the IGP. 
And, in particular, if the capabilities exchange for security is left to the 
PCEP initialisation steps, are those steps secure enough to prevent downgrade 
attacks.

Cheers,
Adrian

-Original Message-
From: John Scudder  
Sent: 04 October 2022 18:29
To: Lars Eggert 
Cc: The IESG ; 
draft-ietf-lsr-pce-discovery-security-supp...@ietf.org; lsr-cha...@ietf.org; 
lsr ; Acee Lindem ; p...@ietf.org; Hannes Gredler 
; Les Ginsberg (ginsberg) ; 
jvass...@cisco.com; meral.shirazip...@polymtl.ca; Adrian Farrel 

Subject: Re: [Lsr] Lars Eggert's Discuss on 
draft-ietf-lsr-pce-discovery-security-support-11: (with DISCUSS and COMMENT)

Hi Everyone,

+Adrian since he appears to have been the shepherd for RFC 5088, which is the 
root of Lars’ DISCUSS.
+Hannes, Les, JP, Meral as people who may have more context on the question

Since I haven’t seen any replies to this DISCUSS yet I did a little digging. 
The text in question:

   No additional sub-TLVs will be added to the PCED TLV in the future.
   If a future application requires the advertisement of additional PCE
   information in OSPF, this will not be carried in the Router
   Information LSA.

Was introduced in draft-ietf-pce-disco-proto-ospf-07, September 2007. Checking 
in the archives, I see one relevant mail thread: 
https://mailarchive.ietf.org/arch/msg/pce/UERk8vF5e7cFQoblkDAVA74Ojh0/ is the 
beginning, but then it seems to have been indexed wrong so you should continue 
from here: 
https://mailarchive.ietf.org/arch/msg/isis-wg/BpUVKsjr46ha9kbF3jwgKyymEBo/ to 
pick up Les’s reply as well. There are four relevant messages in total, from 
Meral Shirazipour, JP Vasseur, Hannes Gredler, and Les Ginsberg.

Rather than try to summarize I’m going to ask people to go look at the short 
mail thread for themselves. Perhaps this will jog people’s memories enough to 
allow a discussion on why we’re opening a registry for new code points that was 
explicitly defined as being closed.

Thanks,

—John

> On Sep 30, 2022, at 8:27 AM, Lars Eggert via Datatracker  
> wrote:
> 
> 
> Lars Eggert has entered the following ballot position for
> draft-ietf-lsr-pce-discovery-security-support-11: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to 
> https://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!NEt6yMaO-gk!BEvEYiZR6x7lTVrU9AA55g6M1-32P6xLCiZ537k4RWeOwmTjkSrRmf0k6fDyFPdPOpbjt8J-BPa3$
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-lsr-pce-discovery-security-support/__;!!NEt6yMaO-gk!BEvEYiZR6x7lTVrU9AA55g6M1-32P6xLCiZ537k4RWeOwmTjkSrRmf0k6fDyFPdPOpbjt2I779yk$
> 
> 
&g

Re: [Lsr] WG last call for draft-ietf-lsr-ospf-terminology-00

[Adrian Farrel]

Chris, all,

I'm aware that the WG last call has gone by and I'd understand it if my 
comments are therefore put on one side. But rather than wait for IETF last 
call, I thought I'd ask now...

I checked the mailing list and couldn't find any discussion of this point so: 
is there any reason why the term "black hole" is also not being addressed? It 
seems to fall under the NIST guidance ("Avoid terms that use ‘black’ to mean 
something bad or negative") and is present in 5838.

Thanks,
Adrian

On 6/5/22, 5:55 AM, "Christian Hopps"  wrote:

Given the simplicity of this document and having received no objections or 
edits prior to or during the adoption call we'll be moving it immediately to 
WGLC...

This begins a 2 week WG Last Call, ending Jun 19th, 2022, for:

  https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-terminology/

Authors,

  Please indicate to the list, your knowledge of any IPR related to this 
work.

Thanks,
Chris.



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

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

Re: [Lsr] A review of draft-zhu-lsr-isis-sr-vtn-flexalgo-04

[Adrian Farrel]

All looks good.
I'll watch for the updated draft.
Best,
Adrian

-Original Message-
From: Dongjie (Jimmy)  
Sent: 17 May 2022 10:59
To: adr...@olddog.co.uk; lsr@ietf.org
Cc: draft-zhu-lsr-isis-sr-vtn-flexa...@ietf.org
Subject: RE: A review of draft-zhu-lsr-isis-sr-vtn-flexalgo-04

Hi Adrian, 

Thanks a lot for your detailed review. All your comments and suggestions
look good and we will produce a new revision to incorporate them. 

And please see replies to some points inline:

Best regards,
Jie

> -Original Message-
> From: Adrian Farrel [mailto:adr...@olddog.co.uk]
> Sent: Monday, May 16, 2022 7:22 PM
> To: lsr@ietf.org
> Cc: draft-zhu-lsr-isis-sr-vtn-flexa...@ietf.org
> Subject: FW: A review of draft-zhu-lsr-isis-sr-vtn-flexalgo-04
> 
> Hi LSR and draft authors,
> 
> I read this draft, and it seems to me that it provides a useful
transitional
> mechanism. It can obviously only support a relatively small number of VTNs
> (128 due to the limited number of Flex-Algos the network devices can
> support), but it looks to be a worthwhile first step because it can be
achieved
> with a very minor control plane extension.
> 
> Perhaps this document is a good first step while we work on a longer term
> and more scalable control plane solution. It would also give us the chance
to
> determine the level of interest in VTNs.

Indeed, this is exactly the purpose of this document.

> 
> My comments, below, are mainly editorial, but there are a couple of issues
> around the use of the E flag.
> 
> Best,
> Adrian
> 
> (PS. For those of you saying "What's a VTN?" the "Virtual Transport
> Network"
> is a network construct described in the TEAS WG to support Enhanced VPNs
> (https://datatracker.ietf.org/doc/draft-ietf-teas-enhanced-vpn/) and
network
> slicing
> (https://datatracker.ietf.org/doc/draft-ietf-teas-ietf-network-slices/)
> where it maps to a "Network Resource Partition".)
> 
> ===
> 
> As currently defined, I think this document needs to update RFC 8668. This
is
> because that RFC says that other flags in the flag field of the Parent L3
> Neighbor Descriptor in the L2 Bundle Member Attributes TLV "MUST be
> ignored".
> 
> That's easy enough to handle:
> - You add the "updates 8668" element to the XML
> - You add a final paragraph to the Abstract to say
> This document updates RFC 8668 by defining a new flag in the Parent
> L3 Neighbor Descriptor in the L2 Bundle Member Attributes TLV.
> - You add a final paragraph to the Introduction to say
> This document updates [RFC8668] by defining a new flag in the Parent
> L3 Neighbor Descriptor in the L2 Bundle Member Attributes TLV.
> [RFC8668] states that all bit fields not defined in that document
> "MUST be set to zero on transmission and ignored on receipt".
> Section 3 of this document defines a new flag and specifies both
> when it is set and how it should be processed.
> 
> However, a purist might point out that RFC 8668 should be fixed so that:
> 
> - The unused bits are defined as reserved for future use
> - The text should be updated to describe how the bits are set and handled
>   by implementations that don't understand them
> - There should be an IANA registry for the bits
> 
> You're not responsible for fixing RFC 8668, but you could if you want to.
> 
> Making this document an "update" is also important because of the absence
> of an IANA registry -- it is important to provide a way for people to
track the
> bits so that there is no collision when another bit is defined.
> 
> You could use definitely use this document to create the necessary IANA
> registry, even if you are not fixing the other parts of 8668.

Thanks for your suggestion, we will make this document an update of RFC 8668
to help track the new flag.


> 
> ---
> 
> Would be worth expanding "VTN" in the title to read...
>   Using Flex-Algo for Segment Routing based Virtual Transport Networks
> 
> ---
> 
> Abstract
> 
> The first mention of "Flex-Algo" needs to have some explanation of the
> concept. Not many words, but something like...
> 
> OLD
>The topological constraints of a VTN can be defined using Flex-Algo.
> NEW
>The topological constraints of a VTN can be defined using Flex-Algo,
>a mechanism to provide distributed constraint-path computation.
> END

We will add some description about Flex-Algo. 


> ---
> 
> Abstract
> 
> "SR" should be spelled out as "Segment Routing (SR)"
> 
> ---
> 
> Abstract
> 
> s/L2 bundle/L2 bundles/
> 
> ---
> 
> 1.
> 
> The word "traditional" has other meanings in American 

[Lsr] FW: A review of draft-zhu-lsr-isis-sr-vtn-flexalgo-04

[Adrian Farrel]

Hi LSR and draft authors,

I read this draft, and it seems to me that it provides a useful transitional
mechanism. It can obviously only support a relatively small number of VTNs
(128 due to the limited number of Flex-Algos the network devices can
support), but it looks to be a worthwhile first step because it can be
achieved with a very minor control plane extension.

Perhaps this document is a good first step while we work on a longer term
and more scalable control plane solution. It would also give us the chance
to determine the level of interest in VTNs.

My comments, below, are mainly editorial, but there are a couple of issues
around the use of the E flag.

Best,
Adrian

(PS. For those of you saying "What's a VTN?" the "Virtual Transport Network"
is a network construct described in the TEAS WG to support Enhanced VPNs
(https://datatracker.ietf.org/doc/draft-ietf-teas-enhanced-vpn/) and network
slicing
(https://datatracker.ietf.org/doc/draft-ietf-teas-ietf-network-slices/)
where it maps to a "Network Resource Partition".)

===

As currently defined, I think this document needs to update RFC 8668. This
is because that RFC says that other flags in the flag field of the Parent L3
Neighbor Descriptor in the L2 Bundle Member Attributes TLV "MUST be
ignored".

That's easy enough to handle:
- You add the "updates 8668" element to the XML
- You add a final paragraph to the Abstract to say
This document updates RFC 8668 by defining a new flag in the Parent
L3 Neighbor Descriptor in the L2 Bundle Member Attributes TLV.
- You add a final paragraph to the Introduction to say
This document updates [RFC8668] by defining a new flag in the Parent
L3 Neighbor Descriptor in the L2 Bundle Member Attributes TLV. 
[RFC8668] states that all bit fields not defined in that document
"MUST be set to zero on transmission and ignored on receipt".  
Section 3 of this document defines a new flag and specifies both
when it is set and how it should be processed.

However, a purist might point out that RFC 8668 should be fixed so that:

- The unused bits are defined as reserved for future use
- The text should be updated to describe how the bits are set and handled
  by implementations that don't understand them
- There should be an IANA registry for the bits

You're not responsible for fixing RFC 8668, but you could if you want to.

Making this document an "update" is also important because of the absence of
an IANA registry -- it is important to provide a way for people to track the
bits so that there is no collision when another bit is defined.

You could use definitely use this document to create the necessary IANA
registry, even if you are not fixing the other parts of 8668.

---

Would be worth expanding "VTN" in the title to read...
  Using Flex-Algo for Segment Routing based Virtual Transport Networks

---

Abstract

The first mention of "Flex-Algo" needs to have some explanation of the
concept. Not many words, but something like...

OLD
   The topological constraints of a VTN can be defined using Flex-Algo.
NEW
   The topological constraints of a VTN can be defined using Flex-Algo,
   a mechanism to provide distributed constraint-path computation.
END

---

Abstract

"SR" should be spelled out as "Segment Routing (SR)"

---

Abstract

s/L2 bundle/L2 bundles/

---

1.

The word "traditional" has other meanings in American English and we are
now asked to avoid using it.

OLD
   than that can be provided with traditional overlay VPNs.
NEW
   than that could be provided with existing overlay VPNs techniques.
END

---

1.

s/resource-aware SIDs/resource-aware segment identifiers (SIDs)/
s/With segment routing/With a segment routing/
s/Segment Identifiers (SIDs) can be used/SIDs can be used/
s/using control plane/using the control plane/
s/scalable Segment Routing (SR)/scalable SR/
s/a unique Flex-Algo/a unique Flex-Algo [I-D.ietf-lsr-flex-algo]/

---

Section 1 has just one sentence on the purpose and content of this
document.

   This document
   describes a mechanism to build the SR based VTNs using SR Flex-Algo
   and IGP L2 bundle with minor extensions.

This text is fine, but rather limited.
I suggest:
- Make it a separate paragraph so that it stands out.
- Add at least two more sentences describing what is found in this
  document. Probably you can just summarise what the mechanism is.
- Describe the purpose and intended use of the mechanism.

---

1.1

The boilerplate here is slightly wrong. Should read...

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

---

3.

s/can be allocated with a set/can be allocated a set/

---

3.

OLD
   In order to perform constraint
   based path computation for each VTN on network controller and 

Re: [Lsr] A review of draft-ietf-lsr-isis-ttz

[Adrian Farrel]

Hey Huaimo,

 

Wow! What a lot of work on the new revision. Thanks for the effort and the
quick turn-around.

 

The only thing I am struggling with is the metrics in the node abstraction
case. I still can't see how the nodes outside the domain correctly compute
the paths across the virtual node.

 

You are saying, "Some of the routes may not be optimal after the
abstraction." Perhaps this is enough (after all, we don't achieve multi-AS
shortest path routing), but it seems a very big change in behavior compared
to how the area operated without the TTZ. The "suboptimality" may (will?)
attract traffic to the TTZ and will substantially change the balance of
traffic in the network.

 

This ought, at least, to come with advice to operators that they should
carefully reconsider all of their metrics after introducing a TTZ.

 

Cheers,

Adrian

 

 

From: Huaimo Chen  
Sent: 24 February 2021 02:02
To: 'lsr' ; adr...@olddog.co.uk
Cc: draft-ietf-lsr-isis-...@ietf.org
Subject: Re: A review of draft-ietf-lsr-isis-ttz

 

Hi Adrian, 

 

Thank you very much for your valuable comments.

My answers/explanations are inline below with prefix [HC].

 

Best Regards,

Huaimo on behalf of authors

 

 

From: Adrian Farrel mailto:adr...@olddog.co.uk> >

Sent: Saturday, February 13, 2021 3:34 PM

To: 'lsr' mailto:lsr@ietf.org> >

Cc: draft-ietf-lsr-isis-...@ietf.org
<mailto:draft-ietf-lsr-isis-...@ietf.org>  mailto:draft-ietf-lsr-isis-...@ietf.org> >

Subject: A review of draft-ietf-lsr-isis-ttz

 

Hi all,

 

Acee leant on me to do a review of this work (so blame him :-)

 

It's good to see this document adopted and progressing. Particularly

good to see the realistic compromise of making this Experimental.

 

I have a few comments, below.

 

Best,

Adrian

 

===

 

I have a largish issue with the fact that the document offers a choice

of how to aggregate the zone: virtual node or full mesh. Firstly, it is

not helpful to offer options without guidance about which option to pick

if you're an implementer or a deployer. You also need to specify whether

the choice MUST be a configuration option, and how to handle when some

nodes in the zone think one option and the others think the other

option.

[HC]: Added the advantages and disadvantages of two choices into the 

document, which may help an implementer or a deployer.

 

Possibly you can make this part of the experiment (see below for notes

on the experiment).

 

I have some pretty strong opinions on the idea of a single node

abstraction. The main challenge comes when there is a partial failure in

the zone such that the zone is partitioned (or the path between two

zone neighbors across the zone is severely degraded). It is not possible

to represent this in the node model since your only options are:

- drop the connection to a neighbor

- move to represent the zone as two nodes

[HC]: To resolve the partition of a zone is challenging. One possible

solution is that when a zone is partitioned, it is abstracted as two

virtual nodes. One (the first) part of the zone is abstracted as one 

(the first) virtual node, the other (second) part (which is disconnected

from the first part through zone links) is abstracted as another (second)

virtual node. 

 

In fact, both models (node and mesh) are subject to disruption when

there is a connectivity failure within the zone, but if we think about

the mesh model, it doesn't actually need to be advertised as a full

mesh: partial mesh is easily handled. Nevertheless, the use of a single

zone leader to perform the aggregation has problems if the zone is

partitioned in some way - perhaps this is addressed by the partitioned

zone simply electing two distinct leaders and declaring itself as two

zones.

[HC]: When a partial mesh is used, some of routes may not be optimal

after a zone is abstracted as a partial mesh among the zone edges.

When a zone is abstracted as a full mesh of zone edges, the routes

keep unchanged. The routes that are optimal before the abstraction

are still optimal after the abstraction. 

For node model, a zone is abstracted as a single virtual node.

When there is a connectivity failure within the zone, the failure

is not seen from any node outside of the zone. The routes computed

in any node outside of the zone will not change. 

For mesh model, a zone is abstracted as a full mesh of zone edges.

Some of the routes will change. The route changes are consistent.

 

This discussion of faults within the zone seems (to me) to be pretty

important.

 

I am also struggling with metrics and route computation when the zone is

viewed from outside the zone.  4.1.5 tells us about route computation,

but it is not until 4.3.1 that we discover:

   The

   metric to the neighbor is the metric of the shortest path to the edge

   node within the zone.

This text applies to the full mesh case, and we don't have anything

about the nod

Re: [Lsr] A review of draft-ietf-lsr-isis-ttz

[Adrian Farrel]

What you say it true, Tony.

 

Doesn’t mean I like it 

 

A

 

From: Tony Li  On Behalf Of Tony Li
Sent: 17 February 2021 17:55
To: Adrian Farrel 
Cc: lsr ; draft-ietf-lsr-isis-...@ietf.org
Subject: Re: [Lsr] A review of draft-ietf-lsr-isis-ttz

 

 

Hi Adrian,





On Feb 13, 2021, at 12:34 PM, Adrian Farrel mailto:adr...@olddog.co.uk> > wrote:

 

I have some pretty strong opinions on the idea of a single node
abstraction. The main challenge comes when there is a partial failure in
the zone such that the zone is partitioned (or the path between two
zone neighbors across the zone is severely degraded). It is not possible
to represent this in the node model since your only options are:
- drop the connection to a neighbor
- move to represent the zone as two nodes

 

 

I’m not one of the authors and I don’t mean to interfere, but I have to ask 
whether you’re raising the bar here.

 

Partitioned areas have been a sore spot within IS-IS since day one. While we’ve 
frequently discussed alternative solutions (e.g., tunneling through L2 to 
restore L1 continuity), I’m unaware of a practical, deployed solution to the 
problem. We have always addressed this by placing the burden on network 
architects: ensure that your L1 area has enough redundancy to never partition. 
While this seems like it is annoying, it does seem to be doable.

 

While it is certainly fair to call this out as a discussion item, requiring 
that TTZ (and Area Proxy) solve issues that we haven’t been able to solve to 
date seems to be asking for technological breakthroughs as table stakes.

 

Regards,

Tony

 

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

[Lsr] A review of draft-ietf-lsr-isis-ttz

[Adrian Farrel]

Hi all,

Acee leant on me to do a review of this work (so blame him :-)

It's good to see this document adopted and progressing. Particularly
good to see the realistic compromise of making this Experimental.

I have a few comments, below.

Best,
Adrian

===

I have a largish issue with the fact that the document offers a choice
of how to aggregate the zone: virtual node or full mesh. Firstly, it is
not helpful to offer options without guidance about which option to pick
if you're an implementer or a deployer. You also need to specify whether 
the choice MUST be a configuration option, and how to handle when some 
nodes in the zone think one option and the others think the other 
option.

Possibly you can make this part of the experiment (see below for notes
on the experiment).

I have some pretty strong opinions on the idea of a single node
abstraction. The main challenge comes when there is a partial failure in
the zone such that the zone is partitioned (or the path between two
zone neighbors across the zone is severely degraded). It is not possible
to represent this in the node model since your only options are:
- drop the connection to a neighbor
- move to represent the zone as two nodes

In fact, both models (node and mesh) are subject to disruption when
there is a connectivity failure within the zone, but if we think about
the mesh model, it doesn't actually need to be advertised as a full
mesh: partial mesh is easily handled. Nevertheless, the use of a single
zone leader to perform the aggregation has problems if the zone is 
partitioned in some way - perhaps this is addressed by the partitioned
zone simply electing two distinct leaders and declaring itself as two
zones.

This discussion of faults within the zone seems (to me) to be pretty
important.

I am also struggling with metrics and route computation when the zone is
viewed from outside the zone.  4.1.5 tells us about route computation, 
but it is not until 4.3.1 that we discover:
   The
   metric to the neighbor is the metric of the shortest path to the edge
   node within the zone.
This text applies to the full mesh case, and we don't have anything 
about the node model, so we might assume that the metrics on the edge
circuits are unchanged. 

Obviously, this is important, and it feels that something is broken for
the virtual node case. Consider Figure 1.

Without the zone (and assuming link metrics of 1), the cost of the path
R15-R61-R71-R67-R31 is 4, and this route might not be preferred if some
other route R15-x-y-R31 exists with cost 3. However, once we have 
introduced the zone using the virtual node approach, there is an 
available route R15-Rz-R31 that appears to have a preferable metric of
2. I would say that the route R15-x-y-R31 should still be preferred.

This point certainly needs to be called out in the text, and maybe this
gives some input to the choice between models. Perhaps the metrics in
the ISN and ESN TLVs are related to this point, but section 4.2.1 gives
no hint about how to set these values. Actually, I suspect that what is
going on here is that all of the metrics advertised to outside the zone 
are controlled by the zone leader and advertised in the ISN/ESN - but I
don't find that actually stated anywhere.

All this said, I find it notable that this document focusses almost 
completely (sections 4 and 5 - section 4.3 is a very small section) on
the virtual node model. It would be good to provide an example like 
Figure 2, but for the mesh model.

Perhaps rather than deferring this to be an outcome of the experiment,
this document should spend some time comparing the two models *or* it
might even be time to abandon one of the models. 

---

Obviously, at some point before this goes forward for publication,
you'll need to reduce to no more than five front-page authors.

---

I think the Abstract might usefully mention IS-IS. Probably the first
sentence could read:

   This document specifies a topology-transparent zone in an IS-IS area.

---

The document really needs a section to scope the Experiment.

- How is the experiment kept separate and safe from the Internet or
  indeed from any non-participating routers?
- What happens if the boundary of the experiment are breached?
  (To expand on this, what happens if there is a misconfiguration so
   that a Zone Internal Node thinks its neighbor is also in the Zone
   when it is actually unaware of these extensions and should be
   treated as a Zone External Node? This misconfiguration has a node
   that should be a Zone Edge/Border Node acting as a Zone Internal
   Node.)
- How is the success (or failure!) of the experiment assessed?
- Are there plans to bring this back for consideration on the standards
  track if certain criteria are satisfied?
- Is evaluation of the relative merits of node and mesh abstraction part
  of the experiment?

---

Section 1

The WG may have established a different practice, but it used to be
normal to reference RFC 1195 alongside ISO 10589.  

Re: [Lsr] [Bier] PCE Controller & SDN Controller & Netconf/Yang NMS Controller - lines blurred and can the names be used ubiquitously meaning the same

[Adrian Farrel]

Hi again Gyan,

 

I think we’re narrowing down and getting somewhat esoteric for the mailing 
lists we’re spamming.

> Similarly other use cases such as with TEAS TS-Transport slice and being able
> to provision TS and capturing the TS Enhanced VPN RT & resource information
> and leveraging BGP-LS to do the same data gathering & ZTP like controller 
> style
> provisioning. 

Is there a fundamental difference between ZTP & Day N provisioning and path 
computation for traffic engineering provisioning? It’s all determining how to 
configure the network to best carry traffic. 

Gyan> In my mind the fundamental difference would be TE - control plane TEDs and
forwarding plane routing action path computation and instantiation of path 
action
as compare to a NMS type Netconf/Yang configuration snippet push function not
routing or TE related.

 

[Adrian] I think it depends. The protocols are just tools. You could have a 
centralised TE system with a PCE to preform computations, but you can use any 
combinations of protocols to extract information from the network (IGPs, 
BGP-LS, PCEP-LS, Netconf, …) and any combination of protocols to program the 
network devices to install TE paths, reserve resources, and configure traffic 
forwarding rules (PCEP, RSVP-TE, Netconf, …).

 

Cheers,

Adrian

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

Re: [Lsr] [Bier] PCE Controller & SDN Controller & Netconf/Yang NMS Controller - lines blurred and can the names be used ubiquitously meaning the same

[Adrian Farrel]

Hi Gyan,

 

Sorry, I missed this (got caught on a filter cos it was a bit spammed to a lot 
of lists :-).

 

> I have noticed that after reviewing many drafts across many WGs it seems in 
> the

> industry that the lines seem to be blurred between a PCE controller, ODL or

> Openflow SDN Controller and a Netconf/Yang NMS Controller ZTP & Day X

> provisioning.

 

Yes, blurriness our speciality.

 

You my find RFC 7491 useful in this respect, although it is a little dated. 
And, of course, RFC 8283 is a good starting point.

 

> As this is a software sitting on a server you can have a swiss army knife 
> server that

> does everything from PCE path computation to  Netconf/Yang ZTP & Day N 

> provisioning as well as any SDN Controller ODL or Openflow controller type

> functions as well.

 

Yes, and this is one of the risks of PCE as a shiny thing: that it be converted 
from a useful toolkit into some form of god-box. I pontificated on this way 
back in 2014 at http://www.olddog.co.uk/PCEPandOnwards.pdf

 

> How this comes into play and realization of the lines being blurred is the 
> use of

> BGP-LS in building the IGP topological graph of the network which was designed

> for PCEP and PCE & PCC active & passive off line path computation for both

> RSVP-TE or SR-TE path instantiation.  

 

In some senses, BGP-LS didn’t add anything because a PCE could have snooped on 
the IGP. But BGP-LS provides an export mechanism and importantly adds to that 
some policy filters to determine what is exported thus giving the network some 
control over what is exported.

 

FWIW, https://datatracker.ietf.org/doc/draft-dhodylee-pce-pcep-ls/ proposes 
using PCEP for the same function. The argument in favor is that a PCE has to 
implement PCEP anyway, so why not include the LS export as well. The argument 
against is that BGP-LS has wider applicability and that it will typically be 
exported from an ASBR which already supports BGP.

 

> However now BGP-LS can also be used for other functions now such as usage as

> I am a Shepherd reviewing a draft for BGP-LS usage for BIER to use BGP-LS to

> gather the elements internals within BIER using the same BGP-LS data 
> structures

> to populate with BIER specific information to graph the BIER topology.  So 
> here

> we are not doing any path computations as we are using in this use case  for

> NMS type function to gather data for ZTP & Day N provisioning.

> 

> Similarly other use cases such as with TEAS TS-Transport slice and being able

> to provision TS and capturing the TS Enhanced VPN RT & resource information

> and leveraging BGP-LS to do the same data gathering & ZTP like controller 
> style

> provisioning. 

 

Is there a fundamental difference between ZTP & Day N provisioning and path 
computation for traffic engineering provisioning? It’s all determining how to 
configure the network to best carry traffic.

 

> It does seem as though BGP-LS as its a means of "data gathering" "dump truck"

> of anything with the kitchen sink included to build any type of topological 
> graph

> of literally anything under the sun.

 

Remembering Yakov Rekhter saying you could use BGP to transport Shakespeare. 

This is a tension with any protocol BGP-LS, PCEP, etc., etc. Stuff gets added, 
further use gets made.

 

BGP-LS was intended to export routing information “northbound” from the network.

 

> I see that is a nice to leverage but it does in fact blur the lines of NMS 
> Netconf/Yang

> Controller based functionality and  PCE path computation functionality and SDN

> controller based ZTP functionality into a single ubiquitous server that can 
> do all of

> the above and use BGP-LS to accomplish the "kitchen sink" tasks.  It does 
> however

> transform BGP to be an NMS tool but a "tool" and not just the original 
> function

> which it was intended NLRI network reachability.

 

Not sure that BGP-LS is BGP. But I agree that BGP-LS is “an NMS tool”.

I might argue that BGP distributing policies from installation on PEs is an NMS 
protocol.

 

> Am I off base and please let me know as its BGP-LS is being way over 
> leveraged. 

> There are pros & cons to everything but I thought I would bring up to the WG 
> as

> an important discussion point.

 

Who are we to argue with real implementations? Assuming that there is a push 
for implementation and deployment, then the thing to look for is “harm”. Does 
this use of BGP-LS cause harm, sow confusion, risk destabilising the network? 
Should it use a different code point to be distinguishable?

 

I think the argument that “there is already another protocol for doing this” is 
worth examining. But we have to be careful that it doesn’t get us stuck, or 
force everyone to do something they don’t want to do. After all, we could carry 
any protocol message using Netconf/YANG, but we don’t do “RSVP-TE over Netconf”.

 

Best,

Adrian

 

___
Lsr mailing list
Lsr@ietf.org

Re: [Lsr] I-D Action: draft-ietf-lsr-pce-discovery-security-support-02.txt

[Adrian Farrel]

Thanks Qin.

I skimmed the diff and this looks like a good step up. Thanks.

Adrian

-Original Message-
From: Lsr  On Behalf Of Qin Wu
Sent: 03 September 2019 12:03
To: lsr@ietf.org
Subject: Re: [Lsr] I-D Action: 
draft-ietf-lsr-pce-discovery-security-support-02.txt

The v-02 is posted to address remaining comments on the list, thanks Adrain, 
Aijun, Les for comments and input.
The diff is:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-pce-discovery-security-support-02

-Qin
-邮件原件-
发件人: I-D-Announce [mailto:i-d-announce-boun...@ietf.org] 代表 
internet-dra...@ietf.org
发送时间: 2019年9月3日 18:58
收件人: i-d-annou...@ietf.org
抄送: lsr@ietf.org
主题: I-D Action: draft-ietf-lsr-pce-discovery-security-support-02.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   : IGP extension for PCEP security capability support in 
the PCE discovery
Authors : Diego R. Lopez
  Qin Wu
  Dhruv Dhody
  Michael Wang
  Daniel King
Filename: draft-ietf-lsr-pce-discovery-security-support-02.txt
Pages   : 9
Date: 2019-09-03

Abstract:
   When a Path Computation Element (PCE) is a Label Switching Router
   (LSR) participating in the Interior Gateway Protocol (IGP), or even a
   server participating in IGP, its presence and path computation
   capabilities can be advertised using IGP flooding.  The IGP
   extensions for PCE discovery (RFC 5088 and RFC 5089) define a method
   to advertise path computation capabilities using IGP flooding for
   OSPF and IS-IS respectively.  However these specifications lack a
   method to advertise PCEP security (e.g., Transport Layer
   Security(TLS), TCP Authentication Option (TCP-AO)) support
   capability.

   This document proposes new capability flag bits for PCE-CAP-FLAGS
   sub-TLV that can be announced as attribute in the IGP advertisement
   to distribute PCEP security support information.  In addition, this
   document updates RFC 5088 and RFC 5089 to allow advertisement of Key
   ID or Key Chain Name Sub-TLV to support TCP AO security capability.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lsr-pce-discovery-security-support/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-lsr-pce-discovery-security-support-02
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-pce-discovery-security-support-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-pce-discovery-security-support-02


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

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

Re: [Lsr] Solicit feedback on draft-ietf-lsr-pce-discovery-security-support-01

[Adrian Farrel]

Hi Qin,

I didn't see any response to this email, so I thought I should chip in with
some (old, old, old) memories and context.

tl;dr I am generally supportive of this work, but I think a little
fine-tuning is needed.

If I recall correctly, the situation when 5088 and 5089 were produced was
that there was mission creep. The initial idea was to discover the existence
of PCE-capable routers in the network, but it was quickly realised a
specific address might be preferable for reaching the PCE, so there was need
for the PCE Discovery TLV to contain an address, and it was decided to
encode it as a TLV. Then the rot set in and we determined there were some
other useful pieces of information to encode. And then we thought that it
would be helpful to have an array of capability bits.

At this point the IGP working groups started to get worried. As Les and Acee
noted, the concern was that we would be carrying "large" amounts of data in
the IGP that was not directly related to the primary purpose of the IGP
(packet routing) or even the secondary purpose (TE). We had a bit of a fight
on our hands at this stage because the PCE implementers had already built
stuff, and the IGP "purists" were digging in. So we agreed to stabilise with
"this far and no further" and the lines in 5088/9 that say:
   No additional sub-TLVs will be added to the PCED TLV in the future.
   If a future application requires the advertisement of additional PCE
   information in OSPF, this will not be carried in the Router
   Information LSA.
The idea was that it would be OK to define new capability bits, but not to
add more TLVs.

I don't recall being delighted by this outcome at the time, but it certainly
allowed us to move forward. It seemed to me that PCEs were not the only
devices exchanging non-routing information in the IGP, and if there was a
concern about volume of data or convergence time, then this seemed a bigger
problem that needed a more general resolution. On the other hand, IETF
consensus is what it is.

The approach that others have taken in this situation is to add flags as
needed, but to put the additional discovery information in the PCEP Open
message. Thus, at a high level, a PCC can decide whether there is any point
in opening a PCEP session with a PCE, but may have to try the session to
find out exactly what options are available and might, at that time,
discover that the PCE is not suitable.

Looking at your draft, the addition of the two bit flags is easy and
uncontroversial. 

It is the addition of the Key-ID and Key-Chain-Name sub-TLVs that cause you
to want to change the RFCs. And I think you have a special case here because
using the TCP security mechanism, the PCEP Open message would come too late
to exchange the relevant information. That is, you need the security
information to set up the secure TCP session before the PCEP Open messages
can be exchanged.

This point could usefully be made more clear in the document. That is, why
you cannot use the alternate mechanism for exchanging PCE characteristics
and capabilities. After that has been done, I think that it would be
reasonable to allow the approach you are describing subject to LSR WG
consensus. (The alternative, which is perfectly acceptable within the
architecture and within some operational environments, is configuration. But
configuration doesn't work in the larger use cases, and another mechanism
would constitute a third way of exchanging PCE information, and that sounds
ridiculous.)

However, while I think that you should be allowed through the doorway, I
don't think you should leave the door open behind you. That means that you
should update 5088/9 to allow your new sub-TLVs, but you should leave in
place the ruling that no more new sub-TLVs are allowed. I *think* that is
what you're trying to do, but I don't think your Section 4 is the right way
to do that - it is not necessary to make edits to the old documents to make
this change, you can simply say... 
Section 4 of [RFC5088] states that no new sub-TLVs will be added to the PCED
TLV, and no new PCE information will be carried in the Router Information
LSA. This document updates RFC 5088 by allowing the two new sub-TLVs defined
in this document to be carried in the PCED TLV of the for use in the Router
Information LSA.
Section 4 of [RFC5089] states that no new sub-TLVs will be added to the PCED
TLV, and no new PCE information will be carried in the Router CAPABLITY TLV.
This document updates RFC 5089 by allowing the two new sub-TLVs defined in
this document to be carried in the PCED TLV of the for use in the Router
CAPABILITY TLV.

Along the way, we're also going to need to do some work on Section 7. The
whole point of your draft is to exchange information about security
features, and that makes it highly sensitive if it can be attacked. For
example, just toggling the two new capability bits can be a downgrade
attack. And tweaking the content of the new TLVs would, I imagine, enable
man-in-the-middle 

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

[Adrian Farrel]

Hi again.

I'm not sure what you are trying to prove (and unclear whether debating a draft 
that has IETF consensus on the wrong mailing list will solve anything).

If you are saying "What happens if an MPLS label gets corrupted in an in-flight 
packet?" then, yes, packets can be misdelivered." Remind me what happens if an 
IP address gets corrupted in an in-flight IP packet?

Is here such a thing as an MPLS ACL?
Well, yes and no. A router will not process a packet that caries a label that 
is not in its LFIB.
LFIB entries can be set up per interface.

Adrian

-Original Message-
From: Xiejingrong  
Sent: 15 April 2019 15:16
To: adr...@olddog.co.uk; bruno.decra...@orange.com
Cc: lsr@ietf.org
Subject: RE: [Lsr] Status of draft-ietf-isis-encapsulation-cap

Hi Adrian,
thanks for the remind.
I think the use case illustrated in the two diagrams is more attractive and 
easy to understand. 
I feel that, the use of dynamic tunnel inside an IGP will cause some other 
security concerns, as the RFC7510 said: "Corruption of that label could leak 
traffic across VPN boundaries..."
A router advertise a tunnel-attribute like udp-tunnel-end-attribute to allow 
MPLS packets run over, then an unwanted IP packet may send to this tunnel-end 
IP/UDP, and the router can't filter the packet by MPLS label stack (is there 
MPLS ACL?).

Thanks
Jingrong

-Original Message-
From: Adrian Farrel [mailto:adr...@olddog.co.uk] 
Sent: Monday, April 15, 2019 9:46 PM
To: Xiejingrong ; bruno.decra...@orange.com
Cc: lsr@ietf.org
Subject: RE: [Lsr] Status of draft-ietf-isis-encapsulation-cap

Wrong list for this discussion, Jingrong. 
Wrong draft to anchor this discussion to 

But anyway, I think you need to read the whole of draft-ietf-mpls-sr-over-ip 
carefully to see its scope, how it does not compete with SRv6, and how it 
provides a handy migration strategy.

Thanks,
Adrian

-Original Message-
From: Xiejingrong 
Sent: 15 April 2019 14:34
To: adr...@olddog.co.uk; bruno.decra...@orange.com
Cc: lsr@ietf.org
Subject: RE: [Lsr] Status of draft-ietf-isis-encapsulation-cap

Hi Adrian,
Is the intra-AS SR over IP really a key use case for draft-ietf-mpls-sr-over-ip 
?
I saw it says for this use case: "Tunneling MPLS into IP provides a technology 
that enables SR in an IPv4 and/or IPv6 network where the routers do not support 
SRv6 capabilities ..."
SRv6 may have easier tunneling method, and SR-MPLS may not want to add another 
'tunneling' within an IGP network.
Would this draft-ietf-mpls-sr-over-ip be processed better focusing on the clear 
use case 'Tunnel Between SR-MPLS Sites', but without the dependency of the 
heavy IGP extension to support the intra-AS deployment of uncertain 
usecase/cost/tradeoff/ ?

Thanks
Jingrong

-Original Message-
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Adrian Farrel
Sent: Monday, April 15, 2019 9:05 PM
To: bruno.decra...@orange.com
Cc: lsr@ietf.org
Subject: Re: [Lsr] Status of draft-ietf-isis-encapsulation-cap

Nice response, Bruno.
Thanks.
Adrian

-Original Message-
From: bruno.decra...@orange.com 
Sent: 15 April 2019 10:47
To: adr...@olddog.co.uk
Cc: lsr@ietf.org
Subject: RE: [Lsr] Status of draft-ietf-isis-encapsulation-cap

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 

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

[Adrian Farrel]

Wrong list for this discussion, Jingrong. 
Wrong draft to anchor this discussion to 

But anyway, I think you need to read the whole of draft-ietf-mpls-sr-over-ip 
carefully to see its scope, how it does not compete with SRv6, and how it 
provides a handy migration strategy.

Thanks,
Adrian

-Original Message-
From: Xiejingrong  
Sent: 15 April 2019 14:34
To: adr...@olddog.co.uk; bruno.decra...@orange.com
Cc: lsr@ietf.org
Subject: RE: [Lsr] Status of draft-ietf-isis-encapsulation-cap

Hi Adrian,
Is the intra-AS SR over IP really a key use case for draft-ietf-mpls-sr-over-ip 
?
I saw it says for this use case: "Tunneling MPLS into IP provides a technology 
that enables SR in an IPv4 and/or IPv6 network where the routers do not support 
SRv6 capabilities ..."
SRv6 may have easier tunneling method, and SR-MPLS may not want to add another 
'tunneling' within an IGP network.
Would this draft-ietf-mpls-sr-over-ip be processed better focusing on the clear 
use case 'Tunnel Between SR-MPLS Sites', but without the dependency of the 
heavy IGP extension to support the intra-AS deployment of uncertain 
usecase/cost/tradeoff/ ?

Thanks
Jingrong

-Original Message-
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Adrian Farrel
Sent: Monday, April 15, 2019 9:05 PM
To: bruno.decra...@orange.com
Cc: lsr@ietf.org
Subject: Re: [Lsr] Status of draft-ietf-isis-encapsulation-cap

Nice response, Bruno.
Thanks.
Adrian

-Original Message-
From: bruno.decra...@orange.com 
Sent: 15 April 2019 10:47
To: adr...@olddog.co.uk
Cc: lsr@ietf.org
Subject: RE: [Lsr] Status of draft-ietf-isis-encapsulation-cap

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 

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

[Adrian Farrel]

Thanks Xiaohu,

That at least indicates that you would like to see an RFC published.

 

But I wonder whether the WG has given up on this work? Two years is a long time 
to make no advances and to have no demands for publication.

I wonder why no one has cared in the interim.

 

Best,

Adrian

 

From: 徐小虎(义先)  
Sent: 13 April 2019 17:56
To: adr...@olddog.co.uk; lsr@ietf.org
Subject: 回复：[Lsr] Status of draft-ietf-isis-encapsulation-cap

 

I will update the ISIS draft soon.

Xiaohu






来自钉钉专属商务邮箱

--
发件人：Adrian Farrelmailto:adr...@olddog.co.uk> >
日　期：2019年04月13日 23:59:05
收件人：mailto:lsr@ietf.org> >
主　题：[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

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