Re: [OSPF] Fwd: Last Call: (Advertising L2 Bundle Member Link Attributes in IS-IS) to Proposed Standard

[Acee Lindem (acee)]

Hi Les,

From: "Les Ginsberg (ginsberg)" >
Date: Thursday, May 11, 2017 at 4:35 PM
To: Acee Lindem >, Alia Atlas 
>, OSPF WG List 
>, Routing WG 
>, IDR List 
>
Subject: RE: [OSPF] Fwd: Last Call:  
(Advertising L2 Bundle Member Link Attributes in IS-IS) to Proposed Standard

Acee –

Did you look at the Appendix – which has ASCII art for some example encodings?

No  - I missed these. I was looking more for the format in body rather than 
just field descriptions. However, the examples are also helpful.

Thanks,
Acee



   Les


From: rtgwg [mailto:rtgwg-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Thursday, May 11, 2017 11:58 AM
To: Alia Atlas; OSPF List; rt...@ietf.org; idr@ietf. org
Subject: Re: [OSPF] Fwd: Last Call:  
(Advertising L2 Bundle Member Link Attributes in IS-IS) to Proposed Standard

Hi Alia,
I have reviewed the document and had several conversations with the authors. I 
believe the encodings are adaptable to the OSPF Segment Routing extensions. Of 
course, we’ll use a different identifier than System ID (Used to identify 
LAN-Adj-SID neighors). One comment I have is that it would be nice to have 
ASCII art graphically depicting the format of the new Sub-TLVs.

Thanks,
Acee

From: OSPF > on behalf of 
Alia Atlas >
Date: Wednesday, May 3, 2017 at 2:30 PM
To: OSPF WG List >, Routing WG 
>, IDR List 
>
Subject: [OSPF] Fwd: Last Call:  (Advertising 
L2 Bundle Member Link Attributes in IS-IS) to Proposed Standard

Dear RTGWG, OSPF WG & IDR WG,

I'd like to bring this IETF Last Call to your attention.  The method for 
advertising
L2 bundle information via IS-IS described in this draft may be of interest for 
other
protocols (OSPF,  BGP-LS) that may use it as precedent for how to advertise
such information if there is need in the future and consistency is desired at 
that point.

Regards,
Alia


-- Forwarded message --
From: The IESG >
Date: Wed, May 3, 2017 at 1:52 PM
Subject: Last Call:  (Advertising L2 Bundle 
Member Link Attributes in IS-IS) to Proposed Standard
To: IETF-Announce >
Cc: han...@gredler.at, 
isis-cha...@ietf.org, 
isis...@ietf.org, 
draft-ietf-isis-l2bund...@ietf.org, 
akat...@gmail.com



The IESG has received a request from the IS-IS for IP Internets WG (isis)
to consider the following document:
- 'Advertising L2 Bundle Member Link Attributes in IS-IS'
   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
i...@ietf.org mailing lists by 2017-05-17. 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


   There are deployments where the Layer 3 interface on which IS-IS
   operates is a Layer 2 interface bundle.  Existing IS-IS
   advertisements only support advertising link attributes of the Layer
   3 interface.  If entities external to IS-IS wish to control traffic
   flows on the individual physical links which comprise the Layer 2
   interface bundle link attribute information about the bundle members
   is required.

   This document introduces the ability for IS-IS to advertise the link
   attributes of layer 2 (L2) bundle members.





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-isis-l2bundles/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-isis-l2bundles/ballot/

The following IPR Declarations may be related to this I-D:

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





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

Re: [OSPF] Fwd: Last Call: (Advertising L2 Bundle Member Link Attributes in IS-IS) to Proposed Standard

[Les Ginsberg (ginsberg)]

Acee –

Did you look at the Appendix – which has ASCII art for some example encodings?

   Les


From: rtgwg [mailto:rtgwg-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Thursday, May 11, 2017 11:58 AM
To: Alia Atlas; OSPF List; rt...@ietf.org; idr@ietf. org
Subject: Re: [OSPF] Fwd: Last Call:  
(Advertising L2 Bundle Member Link Attributes in IS-IS) to Proposed Standard

Hi Alia,
I have reviewed the document and had several conversations with the authors. I 
believe the encodings are adaptable to the OSPF Segment Routing extensions. Of 
course, we’ll use a different identifier than System ID (Used to identify 
LAN-Adj-SID neighors). One comment I have is that it would be nice to have 
ASCII art graphically depicting the format of the new Sub-TLVs.

Thanks,
Acee

From: OSPF > on behalf of 
Alia Atlas >
Date: Wednesday, May 3, 2017 at 2:30 PM
To: OSPF WG List >, Routing WG 
>, IDR List 
>
Subject: [OSPF] Fwd: Last Call:  (Advertising 
L2 Bundle Member Link Attributes in IS-IS) to Proposed Standard

Dear RTGWG, OSPF WG & IDR WG,

I'd like to bring this IETF Last Call to your attention.  The method for 
advertising
L2 bundle information via IS-IS described in this draft may be of interest for 
other
protocols (OSPF,  BGP-LS) that may use it as precedent for how to advertise
such information if there is need in the future and consistency is desired at 
that point.

Regards,
Alia


-- Forwarded message --
From: The IESG >
Date: Wed, May 3, 2017 at 1:52 PM
Subject: Last Call:  (Advertising L2 Bundle 
Member Link Attributes in IS-IS) to Proposed Standard
To: IETF-Announce >
Cc: han...@gredler.at, 
isis-cha...@ietf.org, 
isis...@ietf.org, 
draft-ietf-isis-l2bund...@ietf.org, 
akat...@gmail.com



The IESG has received a request from the IS-IS for IP Internets WG (isis)
to consider the following document:
- 'Advertising L2 Bundle Member Link Attributes in IS-IS'
   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
i...@ietf.org mailing lists by 2017-05-17. 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


   There are deployments where the Layer 3 interface on which IS-IS
   operates is a Layer 2 interface bundle.  Existing IS-IS
   advertisements only support advertising link attributes of the Layer
   3 interface.  If entities external to IS-IS wish to control traffic
   flows on the individual physical links which comprise the Layer 2
   interface bundle link attribute information about the bundle members
   is required.

   This document introduces the ability for IS-IS to advertise the link
   attributes of layer 2 (L2) bundle members.





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-isis-l2bundles/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-isis-l2bundles/ballot/

The following IPR Declarations may be related to this I-D:

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





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

Re: [OSPF] Fwd: Last Call: (Advertising L2 Bundle Member Link Attributes in IS-IS) to Proposed Standard

[Acee Lindem (acee)]

Hi Alia,
I have reviewed the document and had several conversations with the authors. I 
believe the encodings are adaptable to the OSPF Segment Routing extensions. Of 
course, we’ll use a different identifier than System ID (Used to identify 
LAN-Adj-SID neighors). One comment I have is that it would be nice to have 
ASCII art graphically depicting the format of the new Sub-TLVs.

Thanks,
Acee

From: OSPF > on behalf of 
Alia Atlas >
Date: Wednesday, May 3, 2017 at 2:30 PM
To: OSPF WG List >, Routing WG 
>, IDR List 
>
Subject: [OSPF] Fwd: Last Call:  (Advertising 
L2 Bundle Member Link Attributes in IS-IS) to Proposed Standard

Dear RTGWG, OSPF WG & IDR WG,

I'd like to bring this IETF Last Call to your attention.  The method for 
advertising
L2 bundle information via IS-IS described in this draft may be of interest for 
other
protocols (OSPF,  BGP-LS) that may use it as precedent for how to advertise
such information if there is need in the future and consistency is desired at 
that point.

Regards,
Alia


-- Forwarded message --
From: The IESG >
Date: Wed, May 3, 2017 at 1:52 PM
Subject: Last Call:  (Advertising L2 Bundle 
Member Link Attributes in IS-IS) to Proposed Standard
To: IETF-Announce >
Cc: han...@gredler.at, 
isis-cha...@ietf.org, 
isis...@ietf.org, 
draft-ietf-isis-l2bund...@ietf.org, 
akat...@gmail.com



The IESG has received a request from the IS-IS for IP Internets WG (isis)
to consider the following document:
- 'Advertising L2 Bundle Member Link Attributes in IS-IS'
   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
i...@ietf.org mailing lists by 2017-05-17. 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


   There are deployments where the Layer 3 interface on which IS-IS
   operates is a Layer 2 interface bundle.  Existing IS-IS
   advertisements only support advertising link attributes of the Layer
   3 interface.  If entities external to IS-IS wish to control traffic
   flows on the individual physical links which comprise the Layer 2
   interface bundle link attribute information about the bundle members
   is required.

   This document introduces the ability for IS-IS to advertise the link
   attributes of layer 2 (L2) bundle members.





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-isis-l2bundles/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-isis-l2bundles/ballot/

The following IPR Declarations may be related to this I-D:

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






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

Re: [OSPF] WG Adoption Poll for "OSPF LLS Extensions for Local Interface ID Advertisement"

[Peter Psenak]

Hi Tony,

On 11/05/17 18:37 , prz wrote:





So, overall I think we agree on scope of the problem that needs to be
addressed so we get a coherent set of standards out


so would you agree to make this a WG document?


Hey Peter,

yes, given the backward compat section addresses all the issues and the
signaling states/transitions are properly
written down as you indicated I see how the idea has merit to be taken
on. I do see some holes in what you suggest
as behavior but that can be discussed through/ironed out.


right.



And yes, from all I gathered so far there seems to be some unnumbered
4203 around and needs to be paid attention to.


agree.

thanks,
Peter



--- tony

.



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

Re: [OSPF] I-D Action: draft-ietf-ospf-segment-routing-extensions-13.txt

[Peter Psenak]

Hi Shraddha,

On 11/05/17 11:30 , Shraddha Hegde wrote:

Peter,

Inter-area/external prefixes with A-flag re-set is the only scenario
I can think of where SRMS SIDs should not do PHP.
Is there any other case?


- Intra-area route, where the downstream neighbor is not the originator 
or the prefix


- Inter-area prefixes, for which the downstream neighbor is not the 
originator or the prefix


- External prefix for which the downstream neighbor is not the 
originator or the prefix


- Inter-area prefixes, where originator is not advertising Extended 
Prefix TLV


- External prefix , where originator is not advertising Extended Prefix TLV

thanks,
Peter








"For all other cases, when SID is coming from SRMS, PHM MUST not be done"

I suggest the text to be more specific to the cases since we do
not have many scenarios to list.

Rgds
Shraddha
-Original Message-
From: Peter Psenak [mailto:ppse...@cisco.com]
Sent: Thursday, May 11, 2017 2:46 PM
To: Shraddha Hegde ; internet-dra...@ietf.org; 
i-d-annou...@ietf.org
Cc: ospf@ietf.org
Subject: Re: [OSPF] I-D Action: 
draft-ietf-ospf-segment-routing-extensions-13.txt

Hi Shraddha

please see inline:

On 11/05/17 08:49 , Shraddha Hegde wrote:

Peter,

It is clearly specified that ABR originating prefixes from other areas
should have NP Bit set.

"The NP-Flag (No-PHP) MUST be set for Prefix-SIDs allocated to inter-
 area prefixes that are originated by the ABR based on intra-area or
 inter-area reachability between areas.  When the inter-area prefix is
 generated based on a prefix which is directly attached to the ABR,
 the NP-Flag SHOULD NOT be set."


The same behavior should apply to mapping server advertised advertisements as 
well.


when SRMS advertises the SID, it can not set the NP-Flag, so we can not apply 
the exact same behavior there.



" As the Mapping Server does not specify the originator of a prefix

  advertisement, it is not possible to determine PHP behavior solely
  based on the Mapping Server advertisement.  However, PHP behavior
  SHOULD be done in following cases:

 The Prefix is intra-area type and the downstream neighbor is the
 originator of the prefix.

 The Prefix is inter-area type and downstream neighbor is an ABR,
 which is advertising prefix reachability and is also generating
 the Extended Prefix TLV with the A-flag set for this prefix as
 described in section 2.1 of [RFC7684]."



While the text above captures the case of directly attached prefixes
it does not cover the Case of re-distributed prefixes for mapping server 
advertisements.


there is a text in the draft right after the above mention text that talks 
about the redistribution case:

"The Prefix is external type and downstream neighbor is an ASBR,
which is advertising prefix reachability and is also generating
the Extended Prefix TLV with the A-flag set for this prefix as
described in section 2.1 of [RFC7684]."




Suggest to add below text.

  "The Prefix is inter-area type and downstream neighbor is an ABR,
  which is advertising prefix reachability and is also generating
  the Extended Prefix TLV with the A-flag re-set for this prefix as
  described in section 2.1 of [RFC7684] then PHP MUST not be done"



the draft says when PHP should be done when the SID is coming from the SRMS. It 
assumes that in all other cases PHP is not done.

If we are going to say when the PHP must not be done for SID coming from SRMS, 
we need to list all cases, not only one of them.

So I would say we either not say anything, or we say:

"For all other cases, when SID is coming from SRMS, PHM MUST not be done"

thanks,
Peter



Rgds
Shraddha

-Original Message-
From: Peter Psenak [mailto:ppse...@cisco.com]
Sent: Wednesday, May 10, 2017 12:33 PM
To: Shraddha Hegde ; internet-dra...@ietf.org;
i-d-annou...@ietf.org
Cc: ospf@ietf.org
Subject: Re: [OSPF] I-D Action:
draft-ietf-ospf-segment-routing-extensions-13.txt

Hi Shraddha,

please see inline:

On 10/05/17 07:34 , Shraddha Hegde wrote:

Authors,

Apologies for being late with this comment in the process of standardization.

The below section 5 describes the PHP for mapping server


" As the Mapping Server does not specify the originator of a prefix
  advertisement, it is not possible to determine PHP behavior solely
  based on the Mapping Server advertisement.  However, PHP behavior
  SHOULD be done in following cases:

 The Prefix is intra-area type and the downstream neighbor is the
 originator of the prefix.

 The Prefix is inter-area type and downstream neighbor is an ABR,
 which is advertising prefix reachability and is also generating
 the Extended Prefix TLV with the A-flag set for this prefix as
 described in section 2.1 of [RFC7684]."


The text says "PHP behavior" should 

Re: [OSPF] I-D Action: draft-ietf-ospf-segment-routing-extensions-13.txt

[Shraddha Hegde]

Peter,

Inter-area/external prefixes with A-flag re-set is the only scenario
I can think of where SRMS SIDs should not do PHP.
Is there any other case?

> "For all other cases, when SID is coming from SRMS, PHM MUST not be done"
I suggest the text to be more specific to the cases since we do 
not have many scenarios to list. 

Rgds
Shraddha
-Original Message-
From: Peter Psenak [mailto:ppse...@cisco.com] 
Sent: Thursday, May 11, 2017 2:46 PM
To: Shraddha Hegde ; internet-dra...@ietf.org; 
i-d-annou...@ietf.org
Cc: ospf@ietf.org
Subject: Re: [OSPF] I-D Action: 
draft-ietf-ospf-segment-routing-extensions-13.txt

Hi Shraddha

please see inline:

On 11/05/17 08:49 , Shraddha Hegde wrote:
> Peter,
>
> It is clearly specified that ABR originating prefixes from other areas 
> should have NP Bit set.
>
> "The NP-Flag (No-PHP) MUST be set for Prefix-SIDs allocated to inter-
> area prefixes that are originated by the ABR based on intra-area or
> inter-area reachability between areas.  When the inter-area prefix is
> generated based on a prefix which is directly attached to the ABR,
> the NP-Flag SHOULD NOT be set."
>
>
> The same behavior should apply to mapping server advertised advertisements as 
> well.

when SRMS advertises the SID, it can not set the NP-Flag, so we can not apply 
the exact same behavior there.

>
> " As the Mapping Server does not specify the originator of a prefix
>>  advertisement, it is not possible to determine PHP behavior solely
>>  based on the Mapping Server advertisement.  However, PHP behavior
>>  SHOULD be done in following cases:
>>
>> The Prefix is intra-area type and the downstream neighbor is the
>> originator of the prefix.
>>
>> The Prefix is inter-area type and downstream neighbor is an ABR,
>> which is advertising prefix reachability and is also generating
>> the Extended Prefix TLV with the A-flag set for this prefix as
>> described in section 2.1 of [RFC7684]."
>
>
> While the text above captures the case of directly attached prefixes 
> it does not cover the Case of re-distributed prefixes for mapping server 
> advertisements.

there is a text in the draft right after the above mention text that talks 
about the redistribution case:

   "The Prefix is external type and downstream neighbor is an ASBR,
   which is advertising prefix reachability and is also generating
   the Extended Prefix TLV with the A-flag set for this prefix as
   described in section 2.1 of [RFC7684]."


>
> Suggest to add below text.
>
>  "The Prefix is inter-area type and downstream neighbor is an ABR,
>  which is advertising prefix reachability and is also generating
>  the Extended Prefix TLV with the A-flag re-set for this prefix as
>  described in section 2.1 of [RFC7684] then PHP MUST not be done"


the draft says when PHP should be done when the SID is coming from the SRMS. It 
assumes that in all other cases PHP is not done.

If we are going to say when the PHP must not be done for SID coming from SRMS, 
we need to list all cases, not only one of them.

So I would say we either not say anything, or we say:

"For all other cases, when SID is coming from SRMS, PHM MUST not be done"

thanks,
Peter


> Rgds
> Shraddha
>
> -Original Message-
> From: Peter Psenak [mailto:ppse...@cisco.com]
> Sent: Wednesday, May 10, 2017 12:33 PM
> To: Shraddha Hegde ; internet-dra...@ietf.org; 
> i-d-annou...@ietf.org
> Cc: ospf@ietf.org
> Subject: Re: [OSPF] I-D Action: 
> draft-ietf-ospf-segment-routing-extensions-13.txt
>
> Hi Shraddha,
>
> please see inline:
>
> On 10/05/17 07:34 , Shraddha Hegde wrote:
>> Authors,
>>
>> Apologies for being late with this comment in the process of standardization.
>>
>> The below section 5 describes the PHP for mapping server
>>
>>
>> " As the Mapping Server does not specify the originator of a prefix
>>  advertisement, it is not possible to determine PHP behavior solely
>>  based on the Mapping Server advertisement.  However, PHP behavior
>>  SHOULD be done in following cases:
>>
>> The Prefix is intra-area type and the downstream neighbor is the
>> originator of the prefix.
>>
>> The Prefix is inter-area type and downstream neighbor is an ABR,
>> which is advertising prefix reachability and is also generating
>> the Extended Prefix TLV with the A-flag set for this prefix as
>> described in section 2.1 of [RFC7684]."
>>
>>
>> The text says "PHP behavior" should be done in following cases.
>> In the second case here it's an ABR re-advertising a prefix and SID 
>> being advertised for this Prefix from a mapping server. If we interpret "PHP 
>> behavior should be done"
>> As the penultimate router removing the label and forwarding the 
>> packet to ABR, It does not work since the inner labels gets exposed at the 
>> ABR.
>
> above texts 

Re: [OSPF] I-D Action: draft-ietf-ospf-segment-routing-extensions-13.txt

[Peter Psenak]

Hi Shraddha

please see inline:

On 11/05/17 08:49 , Shraddha Hegde wrote:

Peter,

It is clearly specified that ABR originating prefixes from other areas should 
have NP
Bit set.

"The NP-Flag (No-PHP) MUST be set for Prefix-SIDs allocated to inter-
area prefixes that are originated by the ABR based on intra-area or
inter-area reachability between areas.  When the inter-area prefix is
generated based on a prefix which is directly attached to the ABR,
the NP-Flag SHOULD NOT be set."


The same behavior should apply to mapping server advertised advertisements as 
well.


when SRMS advertises the SID, it can not set the NP-Flag, so we can not 
apply the exact same behavior there.




" As the Mapping Server does not specify the originator of a prefix

 advertisement, it is not possible to determine PHP behavior solely
 based on the Mapping Server advertisement.  However, PHP behavior
 SHOULD be done in following cases:

The Prefix is intra-area type and the downstream neighbor is the
originator of the prefix.

The Prefix is inter-area type and downstream neighbor is an ABR,
which is advertising prefix reachability and is also generating
the Extended Prefix TLV with the A-flag set for this prefix as
described in section 2.1 of [RFC7684]."



While the text above captures the case of directly attached prefixes it does 
not cover the
Case of re-distributed prefixes for mapping server advertisements.


there is a text in the draft right after the above mention text that 
talks about the redistribution case:


  "The Prefix is external type and downstream neighbor is an ASBR,
  which is advertising prefix reachability and is also generating
  the Extended Prefix TLV with the A-flag set for this prefix as
  described in section 2.1 of [RFC7684]."




Suggest to add below text.

 "The Prefix is inter-area type and downstream neighbor is an ABR,
 which is advertising prefix reachability and is also generating
 the Extended Prefix TLV with the A-flag re-set for this prefix as
 described in section 2.1 of [RFC7684] then PHP MUST not be done"



the draft says when PHP should be done when the SID is coming from the 
SRMS. It assumes that in all other cases PHP is not done.


If we are going to say when the PHP must not be done for SID coming from 
SRMS, we need to list all cases, not only one of them.


So I would say we either not say anything, or we say:

"For all other cases, when SID is coming from SRMS, PHM MUST not be done"

thanks,
Peter



Rgds
Shraddha

-Original Message-
From: Peter Psenak [mailto:ppse...@cisco.com]
Sent: Wednesday, May 10, 2017 12:33 PM
To: Shraddha Hegde ; internet-dra...@ietf.org; 
i-d-annou...@ietf.org
Cc: ospf@ietf.org
Subject: Re: [OSPF] I-D Action: 
draft-ietf-ospf-segment-routing-extensions-13.txt

Hi Shraddha,

please see inline:

On 10/05/17 07:34 , Shraddha Hegde wrote:

Authors,

Apologies for being late with this comment in the process of standardization.

The below section 5 describes the PHP for mapping server


" As the Mapping Server does not specify the originator of a prefix
 advertisement, it is not possible to determine PHP behavior solely
 based on the Mapping Server advertisement.  However, PHP behavior
 SHOULD be done in following cases:

The Prefix is intra-area type and the downstream neighbor is the
originator of the prefix.

The Prefix is inter-area type and downstream neighbor is an ABR,
which is advertising prefix reachability and is also generating
the Extended Prefix TLV with the A-flag set for this prefix as
described in section 2.1 of [RFC7684]."


The text says "PHP behavior" should be done in following cases.
In the second case here it's an ABR re-advertising a prefix and SID
being advertised for this Prefix from a mapping server. If we interpret "PHP 
behavior should be done"
As the penultimate router removing the label and forwarding the packet
to ABR, It does not work since the inner labels gets exposed at the ABR.


above texts clearly specifies that PHP is done only for case where ABR is 
originating a prefix, not propagating it from other area. You can distinguish 
between the two based on the A-flag in the Extended Prefix TLV as specified in 
RFC7684, which the above text mentions.

thanks,
Peter


Request authors to add clarification text around "PHP behavior".

Rgds
Shraddha

-Original Message-
From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of
internet-dra...@ietf.org
Sent: Thursday, May 4, 2017 3:28 PM
To: i-d-annou...@ietf.org
Cc: ospf@ietf.org
Subject: [OSPF] I-D Action:
draft-ietf-ospf-segment-routing-extensions-13.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Open Shortest Path First IGP of the IETF.

  Title   : OSPF Extensions 

Re: [OSPF] WG Adoption Poll for "OSPF LLS Extensions for Local Interface ID Advertisement"

[Peter Psenak]

Hi Tony,

please see inline:

On 10/05/17 17:57 , prz wrote:

On Tue, 09 May 2017 12:54:08 +0200, Peter Psenak  wrote:

Hi Tony,

let me try to clarify.

1. This draft does not change, nor does it conflict with RFC3630 in
any way.


Peter, my bad, I got confused forgetting that the Link ID in 3630 is a
different beast from the 4203 link ID. Thanks for pointing that out.



2. This draft does not change anything in RFC4203 either. It provides
an alternative and more generic way to exchange Link Local Identifier
on the interface. Your are right that in our draft we need to specify
the behavior in case the mechanism described in RFC4203 AND the new
mechanism specified in our draft are both active at the same time. We
will add a new section in a next version that covers this part. I
don't believe it will be too difficult, given that the value of the
Link Local Identifier is the same same in both cases, the only
difference is the the mechanism how it is advertised.



Discussion ongoing ... Your question about 4203 deployment is valid and
needs answers and yes, we need a backward compatibility section explaining

a) @ which OSPF hello states the new signaling is supposed to be present


all hellos, will clarify that in the draft


b) what happens if the value ever changes (tear down adjacency?) or whether
it's a violation


no need to tear down the adjacency. Just update anything that uses the 
link ID.




c) what happens if flooded 4203 values (on LSAs) contradict signaling
(e.g. you're holding to the flooded LSA with "old" value) while
neighbor LLS'es a new value


we must set some preference, e.g. LLS value is always preferred.


d) what happens if both signaling types show up on the link


if they are signaling the same value, there is no problem. If values are 
different, we prefer LLS.




Per earlier mails, clarification WHEN the new signaling is supposed to
be used
would be also helpful. 4203 Link ID signaling seems to be used only in
case of unnumbered.


any link, will clarify that in the draft.



So, overall I think we agree on scope of the problem that needs to be
addressed so we get a coherent set of standards out


so would you agree to make this a WG document?

thanks,
Peter



thanks

--- tony


.



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

Re: [OSPF] I-D Action: draft-ietf-ospf-segment-routing-extensions-13.txt

[Erik Auerswald]

Hi Shradda,

really small nit below:

On Thu, May 11, 2017 at 06:49:57AM +, Shraddha Hegde wrote:
> [...]
> Suggest to add below text.
> 
> "The Prefix is inter-area type and downstream neighbor is an ABR,
   ^^^
   If the

> which is advertising prefix reachability and is also generating
> the Extended Prefix TLV with the A-flag re-set for this prefix as
> described in section 2.1 of [RFC7684] then PHP MUST not be done"

Thanks,
Erik
-- 
Dipl.-Inform. Erik Auerswald http://www.fg-networking.de/
auersw...@fg-networking.de T:+49-631-4149988-0 M:+49-176-64228513

Gesellschaft für Fundamental Generic Networking mbH
Geschäftsführung: Volker Bauer, Jörg Mayer
Gerichtsstand: Amtsgericht Kaiserslautern - HRB: 3630

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

Re: [OSPF] I-D Action: draft-ietf-ospf-segment-routing-extensions-13.txt

[Shraddha Hegde]

Peter,

It is clearly specified that ABR originating prefixes from other areas should 
have NP
Bit set.

"The NP-Flag (No-PHP) MUST be set for Prefix-SIDs allocated to inter-
   area prefixes that are originated by the ABR based on intra-area or
   inter-area reachability between areas.  When the inter-area prefix is
   generated based on a prefix which is directly attached to the ABR,
   the NP-Flag SHOULD NOT be set."


The same behavior should apply to mapping server advertised advertisements as 
well.

" As the Mapping Server does not specify the originator of a prefix
> advertisement, it is not possible to determine PHP behavior solely
> based on the Mapping Server advertisement.  However, PHP behavior
> SHOULD be done in following cases:
>
>The Prefix is intra-area type and the downstream neighbor is the
>originator of the prefix.
>
>The Prefix is inter-area type and downstream neighbor is an ABR,
>which is advertising prefix reachability and is also generating
>the Extended Prefix TLV with the A-flag set for this prefix as
>described in section 2.1 of [RFC7684]."


While the text above captures the case of directly attached prefixes it does 
not cover the
Case of re-distributed prefixes for mapping server advertisements.

Suggest to add below text.

"The Prefix is inter-area type and downstream neighbor is an ABR,
which is advertising prefix reachability and is also generating
the Extended Prefix TLV with the A-flag re-set for this prefix as
described in section 2.1 of [RFC7684] then PHP MUST not be done"
Rgds 
Shraddha

-Original Message-
From: Peter Psenak [mailto:ppse...@cisco.com] 
Sent: Wednesday, May 10, 2017 12:33 PM
To: Shraddha Hegde ; internet-dra...@ietf.org; 
i-d-annou...@ietf.org
Cc: ospf@ietf.org
Subject: Re: [OSPF] I-D Action: 
draft-ietf-ospf-segment-routing-extensions-13.txt

Hi Shraddha,

please see inline:

On 10/05/17 07:34 , Shraddha Hegde wrote:
> Authors,
>
> Apologies for being late with this comment in the process of standardization.
>
> The below section 5 describes the PHP for mapping server
>
>
> " As the Mapping Server does not specify the originator of a prefix
> advertisement, it is not possible to determine PHP behavior solely
> based on the Mapping Server advertisement.  However, PHP behavior
> SHOULD be done in following cases:
>
>The Prefix is intra-area type and the downstream neighbor is the
>originator of the prefix.
>
>The Prefix is inter-area type and downstream neighbor is an ABR,
>which is advertising prefix reachability and is also generating
>the Extended Prefix TLV with the A-flag set for this prefix as
>described in section 2.1 of [RFC7684]."
>
>
> The text says "PHP behavior" should be done in following cases.
> In the second case here it's an ABR re-advertising a prefix and SID 
> being advertised for this Prefix from a mapping server. If we interpret "PHP 
> behavior should be done"
> As the penultimate router removing the label and forwarding the packet 
> to ABR, It does not work since the inner labels gets exposed at the ABR.

above texts clearly specifies that PHP is done only for case where ABR is 
originating a prefix, not propagating it from other area. You can distinguish 
between the two based on the A-flag in the Extended Prefix TLV as specified in 
RFC7684, which the above text mentions.

thanks,
Peter
>
> Request authors to add clarification text around "PHP behavior".
>
> Rgds
> Shraddha
>
> -Original Message-
> From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of 
> internet-dra...@ietf.org
> Sent: Thursday, May 4, 2017 3:28 PM
> To: i-d-annou...@ietf.org
> Cc: ospf@ietf.org
> Subject: [OSPF] I-D Action: 
> draft-ietf-ospf-segment-routing-extensions-13.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Open Shortest Path First IGP of the IETF.
>
>  Title   : OSPF Extensions for Segment Routing
>  Authors : Peter Psenak
>Stefano Previdi
>Clarence Filsfils
>Hannes Gredler
>Rob Shakir
>Wim Henderickx
>Jeff Tantsura
>   Filename: draft-ietf-ospf-segment-routing-extensions-13.txt
>   Pages   : 35
>   Date: 2017-05-04
>
> Abstract:
> Segment Routing (SR) allows a flexible definition of end-to-end paths
> within IGP topologies by encoding paths as sequences of topological
> sub-paths, called "segments".  These segments are advertised by the
> link-state routing protocols (IS-IS and OSPF).
>
> This draft describes the OSPF extensions required for Segment
> Routing.
>
>
>
> The IETF datatracker status page for this