Re: [Isis-wg] [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions

[Peter Psenak]

Hi Alia,

On 20/02/18 18:35 , Alia Atlas wrote:

Hi Peter,

Thanks very much for the feedback.

On Tue, Feb 20, 2018 at 12:27 PM, Peter Psenak mailto:ppse...@cisco.com>> wrote:

Hi Alia,

1. I see a benefit in having the BIER a way to map to any of the IGP
algorithms. Simply because IGPs already provide paths to all nodes
in the domain and BIER can simply use these paths instead of
computing its own.


Makes sense.

2. Not sure if people plan to deploy the BIER in a model where it
does its own topology related computations, independent of IGPs. If
they do, I'm not objecting that.


That is what I'm hearing as a requirement.

The encoding of the BAR though must be done in a way that it easily
supports both (1) and (2).


There's the rub :-)  The challenge seems to be when there are
BIER-specific constraints and also other more generic constraints.


we should be able to say BIER BAR X means (1) or (2), not both.

thanks,
Peter



Regards,
Alia

my 2c,
Peter




On 19/02/18 22:51 , Alia Atlas wrote:

As the Sponsoring AD for draft-ietf-bier-isis-extensions-07 and
draft-ietf-bier-ospf-extensions-12, I have been following the
discussion
on the mailing list with interest.

I have not seen clear consensus for any change.

Let me be clear on what I see the options are from the
discussion.  Then
I'll elaborate
a bit on how you can express your perspective most usefully.

1) Current Status:  Bier Algorithm (BAR) field is 8 bits.
Currently,
only value 0 is specified.  The drafts do not have an IANA
registry -
with the expectation that one will be created when the first
additional
use is clear.  It is possible that there will be objections from the
IESG to progressing without an IANA registry.  Given the lack of
clarity
for future use-cases and after discussion, I decided not to
force one
after my AD review - but I will not push back against having a
BIER IANA
registry if raised by others.

2) Option B:  Add a BAR sub-type of 8 bits.  This would modify the
current TLVs.
 Define an IANA registry for the BAR type.  The meaning of
the BAR
sub-type derives
 from the BAR type.   We can debate over the registration
policy for
the BAR type.

3) Option C: Change the BAR field to be 16 bits and define an IANA
registry.  Part of the range can be FCFS with Expert Review,
part can be
Specification Required, and part can be IETF Consensus.

4) Option D: At some point in the future, if there is an actual
understood and documented need, a BAR sub-type could be added a
sub-TLV.  The length of the BAR sub-type could be determined
when the
sub-TLV is defined.

Given

a) option D exists
b) there is currently only one defined value for BAR
c) I do not see strong consensus for change to one
particular other
option

I see no current reason for a change and I certainly see
absolutely no
reason for
a delay in progressing the documents.

I do want to be clear about what the WG wants to do on this issue.
Therefore, here is
my following request.

Please send your feedback to the mailing list as follows:

IF you prefer or can accept the current status, please say so.
No more
justification
or reasoning is required. I just don't want the bulk of folks
who are
content to be
overlooked by those suggesting change.

IF you prefer or can accept the current status, but think there
should
be an IANA registry
as is usual for managing code-points, please say so.  No more
justification is needed.

IF you prefer Option B, C, and/or D, please say so with your
explanation.  More technical depth than "'we might need it" would be
helpful; the availability of sub-TLVs already
provides future proofing.

IF you have a clear technical objection to why the Current
Status is not
acceptable,
please express that - with clear details.

IF you feel that additional code-points should be allocated in a BAR
IANA Registry or
have thoughts on the appropriate policy, please say so with your
explanation for what
those should be.

Unless I see clear and strong consensus for something other than the
Current Status,
that will remain.

IF there is clear and strong consensus for Option B, C, or D, or
adding
an IANA registry with particular values, then it will be possible to
have a change u

Re: [Isis-wg] [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions

[Peter Psenak]

Hi Alia,

1. I see a benefit in having the BIER a way to map to any of the IGP 
algorithms. Simply because IGPs already provide paths to all nodes in 
the domain and BIER can simply use these paths instead of computing its own.


2. Not sure if people plan to deploy the BIER in a model where it does 
its own topology related computations, independent of IGPs. If they do, 
I'm not objecting that.


The encoding of the BAR though must be done in a way that it easily 
supports both (1) and (2).


my 2c,
Peter



On 19/02/18 22:51 , Alia Atlas wrote:

As the Sponsoring AD for draft-ietf-bier-isis-extensions-07 and
draft-ietf-bier-ospf-extensions-12, I have been following the discussion
on the mailing list with interest.

I have not seen clear consensus for any change.

Let me be clear on what I see the options are from the discussion.  Then
I'll elaborate
a bit on how you can express your perspective most usefully.

1) Current Status:  Bier Algorithm (BAR) field is 8 bits.  Currently,
only value 0 is specified.  The drafts do not have an IANA registry -
with the expectation that one will be created when the first additional
use is clear.  It is possible that there will be objections from the
IESG to progressing without an IANA registry.  Given the lack of clarity
for future use-cases and after discussion, I decided not to force one
after my AD review - but I will not push back against having a BIER IANA
registry if raised by others.

2) Option B:  Add a BAR sub-type of 8 bits.  This would modify the
current TLVs.
Define an IANA registry for the BAR type.  The meaning of the BAR
sub-type derives
from the BAR type.   We can debate over the registration policy for
the BAR type.

3) Option C: Change the BAR field to be 16 bits and define an IANA
registry.  Part of the range can be FCFS with Expert Review, part can be
Specification Required, and part can be IETF Consensus.

4) Option D: At some point in the future, if there is an actual
understood and documented need, a BAR sub-type could be added a
sub-TLV.  The length of the BAR sub-type could be determined when the
sub-TLV is defined.

Given

   a) option D exists
   b) there is currently only one defined value for BAR
   c) I do not see strong consensus for change to one particular other
option

I see no current reason for a change and I certainly see absolutely no
reason for
a delay in progressing the documents.

I do want to be clear about what the WG wants to do on this issue.
Therefore, here is
my following request.

Please send your feedback to the mailing list as follows:

IF you prefer or can accept the current status, please say so.  No more
justification
or reasoning is required. I just don't want the bulk of folks who are
content to be
overlooked by those suggesting change.

IF you prefer or can accept the current status, but think there should
be an IANA registry
as is usual for managing code-points, please say so.  No more
justification is needed.

IF you prefer Option B, C, and/or D, please say so with your
explanation.  More technical depth than "'we might need it" would be
helpful; the availability of sub-TLVs already
provides future proofing.

IF you have a clear technical objection to why the Current Status is not
acceptable,
please express that - with clear details.

IF you feel that additional code-points should be allocated in a BAR
IANA Registry or
have thoughts on the appropriate policy, please say so with your
explanation for what
those should be.

Unless I see clear and strong consensus for something other than the
Current Status,
that will remain.

IF there is clear and strong consensus for Option B, C, or D, or adding
an IANA registry with particular values, then it will be possible to
have a change up through this Weds night - with a 1 week WGLC on that
particular technical change.

My priority is to have the base BIER specifications published as
Proposed Standards so that more BIER implementations and deployment can
be done.  I would like the WG to wrap up the core work (as expressed in
the proposed recharter) so that you all can look
at how to use it.

Given this topic was raised last Weds and given that there are no
technical objections raised to the documents as are, there isn't much
time - so please just respond to this email ASAP.  My deadline for a
decision is 6pm EST on Weds.

Regards,
Alia



___
BIER mailing list
b...@ietf.org
https://www.ietf.org/mailman/listinfo/bier



___
Isis-wg mailing list
Isis-wg@ietf.org
https://www.ietf.org/mailman/listinfo/isis-wg

Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-extensions-04

[Peter Psenak]

Hi Folks,

can we add an errata to RFC 8279, instead of adding the text to both 
IGP drafts that does not really belong there.



thanks,
Peter

On 13/02/18 08:16 , Tony Przygienda wrote:

+1 what Les says as my understanding of the problem we're tackling here ...

--- tony

On Mon, Feb 12, 2018 at 2:06 PM, Les Ginsberg (ginsberg)
mailto:ginsb...@cisco.com>> wrote:

Ice –

__ __

MY understanding is that – in the future – there may be additional
encaps defined for BIER. When that happens, a given BFR may support
multiple encaps. In such a case, it is OK if other BFRs supporting
the same  only support one of the set of encaps – so long as
we have one encap in common we can successfully forward. I believe
that is the case the text change is trying to address – not encap vs
no encap. The original text would have required identical sets of
encaps to be supported by all BFRs for a give  - which is
unnecessarily restrictive.

__ __

Make sense?

__ __

   Les

__ __

__ __

*From:*IJsbrand Wijnands (iwijnand)
*Sent:* Monday, February 12, 2018 1:50 PM


*To:* Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
*Cc:* Acee Lindem (acee) mailto:a...@cisco.com>>;
b...@ietf.org <mailto:b...@ietf.org>; Peter Psenak (ppsenak)
mailto:ppse...@cisco.com>>; isis-wg@ietf.org
<mailto:isis-wg@ietf.org> list mailto:isis-wg@ietf.org>>
*Subject:* Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-04

__ __

Les,

__ __

(If MPLS encapsulation (Section 2.1 of [MPLS_BIER_ENCAPS]) is
   being used, this means that every BFR that is advertising
a label
   for sub-domain S is advertising a label for the
combination of
   sub-domain S and Disposition BitStringLength L.)

__ __

It says, if MPLS encapsulation is used, there is a Label for the
{SD, BSL}. So, if there is non-MPLS (ether) only, there will not be
a Label and the compatibility check will fail. Is that not the same
a router that does not support MPLS BIER, and treated as a non-BIER
router?

__ __

[Les:] I don’t see how this text can be used to mean “multiple
encap types can be supported on the same BFR for a given ”.
???

__ __

Are these not like ships in the night? Like an Prefix can be
reachable over MPLS and IP on the same interface? I do assume you
want to stay with the encapsulation that you where provisioned in
and not move from MPLS into non-MPLS. Why do you need to say you can
support both?

__ __

Thx,

__ __

Ice.

__ __

__ __

On 12 Feb 2018, at 22:16, Les Ginsberg (ginsberg)
mailto:ginsb...@cisco.com>> wrote:

Ice -

From: IJsbrand Wijnands (iwijnand)
Sent: Monday, February 12, 2018 12:58 PM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Cc: Acee Lindem (acee) mailto:a...@cisco.com>>;
b...@ietf.org <mailto:b...@ietf.org>; Peter Psenak (ppsenak)
mailto:ppse...@cisco.com>>; isis-wg@ietf.org
<mailto:isis-wg@ietf.org> list mailto:isis-wg@ietf.org>>
Subject: Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-04

Les,


Perhaps the thread is too long and you have gotten confused. J

Maybe :-), but...


The point being discussed now is support for multiple
encapsulation types (BSL conversion was mentioned in the thread
– but it is NOT the subject being discussed at the moment).

I got that, it was removed after a long debate sometime back.



In latest IS-IS BIER draft we changed:

 > All routers in the flooding scope of the BIER TLVs
MUST advertise the
 > same encapsulation for a given .  A router
discovering
 > encapsulation advertised that is different from its
own MUST report a
 > misconfiguration of a specific .  All received
BIER
 > advertisements associated with the conflicting  pair MUST be
 > ignored.
 >
 > "
 >
 > to
 >
 > "
 >
 > Multiple encapsulations MAY be advertised/supported
for a given
 > .  Clearly, however, there MUST be at least
one encapsulation
 > type in common in order for a BIER encapsulated
packet to be
 > successfully forwarded between two BFRs.
 >

Point has been made that this really belongs in the architecture
RFC, but since it isn’t there it may make sense for the IGP
drafts to me

Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-extensions-04

[Peter Psenak]

Hi Tony,

OSPF does not have the original text, so it does not need the new one.

IMHO, the text in section 5 of ISIS BIER draft suits better to the BIER 
architecture draft than to the IGP extension draft.


thanks,
Peter


On 09/02/18 20:17 , Tony Przygienda wrote:

Sure ;-)  let me ping Peter @ the bottom then ... I don't think any of
the stuff applies to OSPF (was ISIS nits) except we can consider an
encaps paragraph. We basically suggest both to replace in ISIS the
encaps section like this

before:

"
All routers in the flooding scope of the BIER TLVs MUST advertise the
same encapsulation for a given .  A router discovering
encapsulation advertised that is different from its own MUST report a
misconfiguration of a specific .  All received BIER
advertisements associated with the conflicting  pair MUST be
ignored.

"

now

"

Multiple encapsulations MAY be advertised/supported for a given
.  Clearly, however, there MUST be at least one encapsulation
type in common in order for a BIER encapsulated packet to be
successfully forwarded between two BFRs.

"

I do think that OSPF would benefit from adding this section to clarify
the issue which is not theoretical now that we have Ethernet.


So Peter, any ETA on outstanding OSPF nits now that we're tying up the
IETF LC?

thanks

--- tony


On Fri, Feb 9, 2018 at 11:12 AM, Greg Shepherd mailto:gjs...@gmail.com>> wrote:

No I didn't. Why would I? These are the changes you and Les worked
out. I assumed you'd share them as needed. If for some reason you're
uncomfortable engaging with the OSPF draft thread and authors with
your proposed changes, let me know and I'll broker the conversation.

Greg

On Fri, Feb 9, 2018 at 11:04 AM, Tony Przygienda
mailto:tonysi...@gmail.com>> wrote:

Les has the diff, I'd expect him to publish any minute to the
list ... The encaps was a real defect, the rest is just
tightening down the language/spec where it was too loose/too
strict.

OSPF still needs update with conversion TLV removed, same
paragraph on encaps could be useful. I hope Greg pinged Peter ...

thanks

tony

On Fri, Feb 9, 2018 at 10:58 AM, Alia Atlas mailto:akat...@gmail.com>> wrote:

On Fri, Feb 9, 2018 at 12:46 PM, Tony Przygienda
mailto:tonysi...@gmail.com>> wrote:

Went last nits with Les, we found one issue (encaps
section was wrong, need to look @ OSPF as well) and
basically tightened language in few places.


K - please get that  out with the details of changes to the
list.  I did my AD review back in Oct and looked at the
differences before issuing
IETF Last Call.

I look forward to reviewing the minor changes.

Regards,
Alia

tony

On Tue, Feb 6, 2018 at 3:45 PM, Greg Shepherd
mailto:gjs...@gmail.com>> wrote:

Thanks Les.

Any other feedback? Looks like the concerns have
been addressed. Speak now.

Cheers,
Greg

On Thu, Feb 1, 2018 at 7:26 AM, Les Ginsberg
(ginsberg) mailto:ginsb...@cisco.com>> wrote:

Greg –

__ __

This thread is outdated.

In V6 of the draft we removed the restriction to
limit IS-IS BIER support to area boundaries – so
Toerless’s comment (and my proposed text) are no
longer relevant.

__ __

Specifically:

__ __

Section 4.1:

__ __

“At present, IS-IS support for a given BIER
domain/sub-domain is 

limited to a single area -
or to the IS-IS L2 sub-domain.”

__ __

The above text was removed.

__ __

Section 4.2

__ __

o  BIER sub-TLVs MUST NOT be included when a
prefix reachability

   advertisement is leaked between levels.

__ __

Was changed to

__ __

o  BIER sub-TLVs MUST be included when a prefix
reachability

   advertisement is leaked between levels.

__ __

This aligns IS-IS and OSPF drafts in this

Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-extensions-04

[Peter Psenak]

Hi Tony,

On 09/02/18 20:04 , Tony Przygienda wrote:

Les has the diff, I'd expect him to publish any minute to the list ...
The encaps was a real defect, the rest is just tightening down the
language/spec where it was too loose/too strict.

OSPF still needs update with conversion TLV removed,


that has been removed already and is NOT anymore in the published 
version 10.


thanks,
Peter




same paragraph on
encaps could be useful. I hope Greg pinged Peter ...

thanks

tony

On Fri, Feb 9, 2018 at 10:58 AM, Alia Atlas mailto:akat...@gmail.com>> wrote:

On Fri, Feb 9, 2018 at 12:46 PM, Tony Przygienda
mailto:tonysi...@gmail.com>> wrote:

Went last nits with Les, we found one issue (encaps section was
wrong, need to look @ OSPF as well) and basically tightened
language in few places.


K - please get that  out with the details of changes to the list.  I
did my AD review back in Oct and looked at the differences before
issuing
IETF Last Call.

I look forward to reviewing the minor changes.

Regards,
Alia

tony

On Tue, Feb 6, 2018 at 3:45 PM, Greg Shepherd mailto:gjs...@gmail.com>> wrote:

Thanks Les.

Any other feedback? Looks like the concerns have been
addressed. Speak now.

Cheers,
Greg

On Thu, Feb 1, 2018 at 7:26 AM, Les Ginsberg (ginsberg)
mailto:ginsb...@cisco.com>> wrote:

Greg –

__ __

This thread is outdated.

In V6 of the draft we removed the restriction to limit
IS-IS BIER support to area boundaries – so Toerless’s
comment (and my proposed text) are no longer relevant.

__ __

Specifically:

__ __

Section 4.1:

__ __

“At present, IS-IS support for a given BIER
domain/sub-domain is 

limited to a single area - or to the
IS-IS L2 sub-domain.”

__ __

The above text was removed.

__ __

Section 4.2

__ __

o  BIER sub-TLVs MUST NOT be included when a prefix
reachability

   advertisement is leaked between levels.

__ __

Was changed to

__ __

o  BIER sub-TLVs MUST be included when a prefix
reachability

   advertisement is leaked between levels.

__ __

This aligns IS-IS and OSPF drafts in this regard.

__ __

 Les

__ __

*From:*Greg Shepherd [mailto:gjs...@gmail.com
]
*Sent:* Thursday, February 01, 2018 2:23 AM
*To:* Toerless Eckert mailto:t...@cs.fau.de>>
*Cc:* Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; Tony Przygienda
mailto:tonysi...@gmail.com>>;
Hannes Gredler (han...@gredler.at
) mailto:han...@gredler.at>>; b...@ietf.org
; isis-wg@ietf.org
 list mailto:isis-wg@ietf.org>>; Christian Hopps
mailto:cho...@chopps.org>>


*Subject:* Re: [Bier] WGLC:
draft-ietf-bier-isis-extensions-04

__ __

Have these changes been reflected in the draft? We're in
WGLC but this discussion needs to come to a conclusion
so we can progress. 

__ __

Greg

__ __

On Tue, Jul 25, 2017 at 12:52 PM, Toerless Eckert
mailto:t...@cs.fau.de>> wrote:

Thanks, Less, that would be lovely!

I didn't check the OSPF draft, if its similar state,
explanatory text wold equally be appreciated.


On Sun, Jul 23, 2017 at 11:28:08PM +, Les
Ginsberg (ginsberg) wrote:
 > Toerless -
 >
 > I am thinking to add a statement in Section 4.1 -
something like:
 >
 > "At present, IS-IS support for a given BIER
domain/sub-domain is limited to a single area - or
to the IS-IS L2 sub-domain."
 >
 > If you believe this would be helpful I will spin
a new version (subject to review/agreement from my
co-authors).
 >
 >

Re: [Isis-wg] ISIS SR Flexible Algorithm (Resending with alias correction)

[Peter Psenak]

Hi Tony,

On 20/11/17 22:11 , Tony Przygienda wrote:

So, it seems that there will be a new draft with 242 covering all
algorithms (i.e. no MT specific algo advertisement anymore).


there is no MT specific algo advertisement in the current flex-algo 
draft. MTs are independent to flex-algos.




Then I thought each MT advertises which Flex it supports. Is the
assumption that you can run multiple algorithms per MT? How would you
otherwise have a two-algorithms-to-same-prefix problem?

Is there some kind of conceptual model of FlexAlgo, i.e. how many of
what associated with how  many of the other (MT to algo, algo to
protocol instance etc) ...


There is many to many relationship between MT and Flex-Algo. Single MT 
can use many Flex-Algos and single Flex-Algo can be used on many MTs.


thanks,
Peter



-- tony

On Mon, Nov 20, 2017 at 10:19 AM, Acee Lindem (acee) mailto:a...@cisco.com>> wrote:

Hi Shraddha, Peter, et al,

The comment on the draft I had was that the conflict case where two
ISIS routers advertise the same multi-homed prefix with a different
algorithm needs to be covered. I wouldn’t try and optimize for this
and would just do whatever is simplest but avoids loops (e.g., log
the situation and prefer the path computed with the lowest numbered
algorithm).

Thanks,
Acee

___
Isis-wg mailing list
Isis-wg@ietf.org 
https://www.ietf.org/mailman/listinfo/isis-wg





___
Isis-wg mailing list
Isis-wg@ietf.org
https://www.ietf.org/mailman/listinfo/isis-wg



___
Isis-wg mailing list
Isis-wg@ietf.org
https://www.ietf.org/mailman/listinfo/isis-wg

Re: [Isis-wg] ISIS SR Flexible Algorithm (Resending with alias correction)

[Peter Psenak]

Hi Acee,

On 20/11/17 19:19 , Acee Lindem (acee) wrote:

Hi Shraddha, Peter, et al,

The comment on the draft I had was that the conflict case where two ISIS
routers advertise the same multi-homed prefix with a different algorithm
needs to be covered. I wouldn’t try and optimize for this and would just
do whatever is simplest but avoids loops (e.g., log the situation and
prefer the path computed with the lowest numbered algorithm).


prefix can have SIDs for many algorithms. Prefix-SID for one algorithm 
is independent and orthogonal to prefix-SID for any other algorithm.


There is no need for all sources of the multi-homed prefix to include 
the same set of Algo-SIDs. Each source can advertise an independent set.


The case is similar to Alg-0 SID, where prefix is advertised from two 
different sources and one source advertise the Alg-0 SID and other does 
not.


thanks,
Peter



Thanks,
Acee


___
Isis-wg mailing list
Isis-wg@ietf.org
https://www.ietf.org/mailman/listinfo/isis-wg

Re: [Isis-wg] [OSPF] IS-IS and OSPF Call for agenda slots @ IETF-100

[Peter Psenak]

Hi Folks,

authors of the following drafts would like to request a slot:

- draft-ietf-ospf-lls-interface-id-00 - 10 mims

- draft-hegdeppsenak-isis-sr-flex-algo-00 - 20 mins

thanks,
Peter


On 19/10/17 15:55 , Christian Hopps wrote:


Hi OSPF and IS-IS,

The preliminary agenda has been posted:

https://datatracker.ietf.org/meeting/100/agenda.html

Our 2.5h joint session of IS-IS and OSPF is tentatively scheduled for
Thursday from 9:30am to 12:00pm (+08).

Please send your requests for a presentation slot, indicating
draft name, speaker, and desired duration (covering presentation and
discussion) to isis-cha...@ietf.org or ospf-cha...@ietf.org.

Thanks,
Abhay, Acee, Chris and Hannes.



___
OSPF mailing list
o...@ietf.org
https://www.ietf.org/mailman/listinfo/ospf



___
Isis-wg mailing list
Isis-wg@ietf.org
https://www.ietf.org/mailman/listinfo/isis-wg

Re: [Isis-wg] WG Adoption poll for draft-hegde-isis-advertising-te-protocols

[Peter Psenak]

Hi Shradha,

please see inline:



On 14/10/17 19:13 , Shraddha Hegde wrote:

Peter,

Pls see inline..

-Original Message-
From: Peter Psenak [mailto:ppse...@cisco.com]
Sent: Friday, October 13, 2017 8:03 PM
To: Shraddha Hegde ; stephane.litkow...@orange.com; 
draft-hegde-isis-advertising-te-protoc...@ietf.org; isis-wg@ietf.org
Subject: Re: [Isis-wg] WG Adoption poll for 
draft-hegde-isis-advertising-te-protocols

Hi Shraddha,

please see inline:

On 13/10/17 15:49 , Shraddha Hegde wrote:

Stephane,

In certain cases MPLS forwarding may not be supported on some legacy linecards.


The problem you are describing is not SR specific, it would apply to LDP as 
well. So the indication should not be about SR, but about MPLS forwarding 
support on interface.

With MPLS being deployed for more then 20 years, I wonder why there was no need 
to solve this issue earlier and why we need to address it now with SR.


Since these links should be used for IP forwarding IGPs will advertise these 
links.
It is better to have explicit indication of this rather than use absence of 
adjacency-sid on the link.

With the new SR flag, while the SPF and the SR-Path does not change,
there is an indication To the controller and head-end nodes that the links 
cannot do SR-MPLS forwarding.
The controller or head-end implementations may have mechanisms to
prevent pulling Traffic on SR paths. When Head-end node detects a
prefix-sid path going through such incapable links It may skip
installing SR paths for such prefix-SID and implementations may decide
to use other mechanisms (such as RSVP or IP) at the head-end which would 
prevent Traffic loss.

This is also a useful tool during transition to SR when  certain links
should avoid carrying SR traffic due to operational reasons.


   >  there are standardized mechanisms like affinities that can be used to 
address above mentioned operational issue.

These mechanisms are specific to SR-TE when the paths are built based on 
constraints.
Link color based solution cannot be used when the SR traffic is flowing over 
SPF paths using Node-SIDs.


as we discussed this privately before (and agreed I believe), if we need 
to address this case, it will be about MPLS enablement not about SR. Do 
you agree?


I'm willing to accept the need to advertise the MPLS enablement on the 
link, if people believe the use case is valid. I have some doubts there 
though, due to the long history of this problem.


thanks,
Peter




thanks,
Peter




Rgds
Shraddha

-Original Message-
From: stephane.litkow...@orange.com
[mailto:stephane.litkow...@orange.com]
Sent: Thursday, October 12, 2017 4:03 PM
To: draft-hegde-isis-advertising-te-protoc...@ietf.org;
isis-wg@ietf.org
Subject: RE: [Isis-wg] WG Adoption poll for
draft-hegde-isis-advertising-te-protocols

Hi Authors,

One question, why do you think it is really needed to introduce the SR flag ? 
Couldn't it be deduced from the presence of an Adj-SID and the SR router cap ?
The SR flag unset while the router supports SR looks strange to me. Why do you want to 
prevent "SR forwarding" on a link if the node supports SR ?

" With this information, a centralized
 application can decide to use a different path for that traffic by
 using a different label stack."
In such a case, the usage of a Node-SID may be complex, as the Node-SID may 
cross a link with the SR flag unset. This will force the controller to use 
Adj-SIDs only.
If the controller uses only Adj-SIDs, then an implementation can allow the user 
to prevent the advertisement of Adj-SIDs on a particular link.

Could you clarify the use case here ?


Thanks,



-Original Message-
From: Isis-wg [mailto:isis-wg-boun...@ietf.org] On Behalf Of Christian
Hopps
Sent: Saturday, October 07, 2017 04:43
To: isis-wg@ietf.org
Cc: isis-cha...@ietf.org; isis-...@ietf.org;
draft-hegde-isis-advertising-te-protoc...@ietf.org
Subject: [Isis-wg] WG Adoption poll for
draft-hegde-isis-advertising-te-protocols

Hi Folks,

The authors have requested the IS-IS WG adopt


https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.
org_doc_draft-2Dhegde-2Disis-2Dadvertising-2Dte-2Dprotocols_&d=DwIFAg&
c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdV
KcmMXJ31bpbBaNqzCNrng&m=C2KWg-TNJXOgV_qiX8ZDhjjJW6rn3GhpPaBzHTDjqZ0&s=
lHsxN1TAflKdy5QZ1sKRfmprtswYQGOljhQpvPNoJkE&e=

as a working group document. Please indicate your support or no-support for 
taking on this work.

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

Thanks,
Chris & Hannes.

__
___

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 erre

Re: [Isis-wg] WG Adoption poll for draft-hegde-isis-advertising-te-protocols

[Peter Psenak]

Hi Shraddha,

please see inline:

On 13/10/17 15:49 , Shraddha Hegde wrote:

Stephane,

In certain cases MPLS forwarding may not be supported on some legacy linecards.


The problem you are describing is not SR specific, it would apply to LDP 
as well. So the indication should not be about SR, but about MPLS 
forwarding support on interface.


With MPLS being deployed for more then 20 years, I wonder why there was 
no need to solve this issue earlier and why we need to address it now 
with SR.



Since these links should be used for IP forwarding IGPs will advertise these 
links.
It is better to have explicit indication of this rather than use absence of 
adjacency-sid on the link.

With the new SR flag, while the SPF and the SR-Path does not change, there is 
an indication
To the controller and head-end nodes that the links cannot do SR-MPLS 
forwarding.
The controller or head-end implementations may have mechanisms to prevent 
pulling
Traffic on SR paths. When Head-end node detects a prefix-sid path going through 
such incapable links
It may skip installing SR paths for such prefix-SID and implementations may 
decide to use other
mechanisms (such as RSVP or IP) at the head-end which would prevent
Traffic loss.

This is also a useful tool during transition to SR when  certain links should 
avoid carrying SR traffic due to operational
reasons.


there are standardized mechanisms like affinities that can be used to 
address above mentioned operational issue.


thanks,
Peter




Rgds
Shraddha

-Original Message-
From: stephane.litkow...@orange.com [mailto:stephane.litkow...@orange.com]
Sent: Thursday, October 12, 2017 4:03 PM
To: draft-hegde-isis-advertising-te-protoc...@ietf.org; isis-wg@ietf.org
Subject: RE: [Isis-wg] WG Adoption poll for 
draft-hegde-isis-advertising-te-protocols

Hi Authors,

One question, why do you think it is really needed to introduce the SR flag ? 
Couldn't it be deduced from the presence of an Adj-SID and the SR router cap ?
The SR flag unset while the router supports SR looks strange to me. Why do you want to 
prevent "SR forwarding" on a link if the node supports SR ?

" With this information, a centralized
application can decide to use a different path for that traffic by
using a different label stack."
In such a case, the usage of a Node-SID may be complex, as the Node-SID may 
cross a link with the SR flag unset. This will force the controller to use 
Adj-SIDs only.
If the controller uses only Adj-SIDs, then an implementation can allow the user 
to prevent the advertisement of Adj-SIDs on a particular link.

Could you clarify the use case here ?


Thanks,



-Original Message-
From: Isis-wg [mailto:isis-wg-boun...@ietf.org] On Behalf Of Christian Hopps
Sent: Saturday, October 07, 2017 04:43
To: isis-wg@ietf.org
Cc: isis-cha...@ietf.org; isis-...@ietf.org; 
draft-hegde-isis-advertising-te-protoc...@ietf.org
Subject: [Isis-wg] WG Adoption poll for 
draft-hegde-isis-advertising-te-protocols

Hi Folks,

The authors have requested the IS-IS WG adopt

 
https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dhegde-2Disis-2Dadvertising-2Dte-2Dprotocols_&d=DwIFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=C2KWg-TNJXOgV_qiX8ZDhjjJW6rn3GhpPaBzHTDjqZ0&s=lHsxN1TAflKdy5QZ1sKRfmprtswYQGOljhQpvPNoJkE&e=

as a working group document. Please indicate your support or no-support for 
taking on this work.

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

Thanks,
Chris & Hannes.

_

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.

___
Isis-wg mailing list
Isis-wg@ietf.org
https://www.ietf.org/mailman/listinfo/isis-wg
.



___
Isis-wg mailing list
Isis-wg@ietf.org
https://www.ietf.org/mailman/listinfo/isis-wg

Re: [Isis-wg] WG Adoption poll for draft-hegde-isis-advertising-te-protocols

[Peter Psenak]

Given the revised text in 
https://www.ietf.org/id/draft-ietf-isis-te-app-01.txt section 6, 
draft-hegde-isis-advertising-te-protocols does not bring any new 
functionality and is not needed.


thanks,
Peter

On 07/10/17 04:42 , Christian Hopps wrote:

Hi Folks,

The authors have requested the IS-IS WG adopt

 https://datatracker.ietf.org/doc/draft-hegde-isis-advertising-te-protocols/

as a working group document. Please indicate your support or no-support
for taking on this work.

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

Thanks,
Chris & Hannes.



___
Isis-wg mailing list
Isis-wg@ietf.org
https://www.ietf.org/mailman/listinfo/isis-wg



___
Isis-wg mailing list
Isis-wg@ietf.org
https://www.ietf.org/mailman/listinfo/isis-wg