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:[email protected]]
Sent: Wednesday, May 10, 2017 12:33 PM
To: Shraddha Hegde <[email protected]>; [email protected];
[email protected]
Cc: [email protected]
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:[email protected]] On Behalf Of
[email protected]
Sent: Thursday, May 4, 2017 3:28 PM
To: [email protected]
Cc: [email protected]
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-exten
sions/
There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ospf-segment-routing-extensions
-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-exte
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
[email protected]
https://www.ietf.org/mailman/listinfo/ospf
_______________________________________________
OSPF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ospf
.
.
_______________________________________________
OSPF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ospf
