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 <shrad...@juniper.net>; 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 <shrad...@juniper.net>; 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 draft is:
https://datatracker.ietf.org/doc/draft-ietf-ospf-segment-routing-exte
n
sions/
There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ospf-segment-routing-extension
s
-13
https://datatracker.ietf.org/doc/html/draft-ietf-ospf-segment-routing
-
extensions-13
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-segment-routing-ext
e
nsions-13
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/
_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf
_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf
.
.
.
_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf
