Re: [OSPF] Alvaro Retana's No Objection on draft-ietf-ospf-link-overload-13: (with COMMENT)

[Shraddha Hegde]

Alvaro,

You are right. The registration happened in the incorrect registry.
I have corrected the problem in -15 version.
Pls see inline.

From: Alvaro Retana [mailto:aretana.i...@gmail.com]
Sent: Thursday, January 25, 2018 9:54 PM
To: Shraddha Hegde <shrad...@juniper.net>; The IESG <i...@ietf.org>
Cc: Acee Lindem <a...@cisco.com>; draft-ietf-ospf-link-overl...@ietf.org; 
ospf-cha...@ietf.org; ospf@ietf.org
Subject: RE: Alvaro Retana's No Objection on draft-ietf-ospf-link-overload-13: 
(with COMMENT)

On January 25, 2018 at 12:31:16 AM, Shraddha Hegde 
(shrad...@juniper.net<mailto:shrad...@juniper.net>) wrote:

Shraddha:

Hi!

...
(3) Section 4.5. mentions that a "new TLV called Graceful-Link-Shutdown is 
defined" for BGP-LS, but there are no details on the format, etc. The IANA 
Considerations section suggests a value, not for a TLV but for an NLRI Type!
 OK. Refered section 3.1 of RFC 7752 and described the contents of 
the TLV
IANA section seems ok to me. Could you be more specific what needs to change?


BGP-LS Link NLRI Registry [RFC7752] >>>>>>>Registry

i)Graceful-Link-Shutdown TLV - Suggested 1101 >>>>>>>TLV type

Maybe it’s just me and I just don’t understand…which is completely possible.  
There are two points:

(1)

It looks like you’re defining a new Graceful-Link-Shutdown TLV for BGP-LS.  
This TLV (based on the updated description) has no information in it.  How does 
the receiver know which link the sender is referring to?

Note that for the OSPF graceful-link-shutdown sub-TLVs, you are indicating 
where to carry them so that there is an obvious indication of which link is 
being shutdown.  I would like to see explicitly specified how the receiver 
associates this TLV with the appropriate link.  Again, I may be missing the 
details.



(2)

The value for the TLV was reserved by IANA in the "BGP-LS NLRI-Types" registry, 
not in the "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and 
Attribute TLVs” register, which is where I would have assumed a modifier to the 
link would reside.  IOW, according to the registry you are defining a new NLRI 
Type, not a new TLV — and, according to the updated description in the document 
there’s no information in this NLRI.

 The TLV code point registration should be in “BGP-LS Node 
Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs” I have 
corrected this in the document.

Will e-mail to IANA for correction as well.

Does that answer your concerns?

...
(6) 5.1 says that the metrics "MUST be set to MaxLinkMetric...and SHOULD be set 
to MAX-TE-METRIC". Why is there a difference?
 TE is an optional feature so MAX-TE-METRIC needs to be set only when 
TE is enabled on the node.

I think that the use of TE is obvious at the point of setting the metric — IOW, 
if TE is not used then it doesn’t mater what this document says.  But if TE is 
used, then having a MUST makes it clear that MAX-TE-METRIC is the metric to be 
used and that there are no other values or circumstances where a different 
value should be considered.

 Mandating TE metric change with a MUST makes it less flexible.

There would not be an option of following this draft for some applications and 
not following for TE applications. I think that keeping it SHOULD provides that 
flexibility.


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

Re: [OSPF] Benoit Claise's No Objection on draft-ietf-ospf-link-overload-14: (with COMMENT)

[Shraddha Hegde]

Thanks for the review Benoit.
I have addressed Tim's comments in -15 version.
Will post it soon.

Thanks
Shraddha

-Original Message-
From: Benoit Claise [mailto:bcla...@cisco.com] 
Sent: Thursday, January 25, 2018 6:23 PM
To: The IESG 
Cc: draft-ietf-ospf-link-overl...@ietf.org; Acee Lindem ; 
ospf-cha...@ietf.org; a...@cisco.com; ospf@ietf.org; tim.ch...@jisc.ac.uk
Subject: Benoit Claise's No Objection on draft-ietf-ospf-link-overload-14: 
(with COMMENT)

Benoit Claise has entered the following ballot position for
draft-ietf-ospf-link-overload-14: No Objection

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.proofpoint.com/v2/url?u=https-3A__www.ietf.org_iesg_statement_discuss-2Dcriteria.html=DwICaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng=u9tJ1yVc0IA5x8YKUYmU-C7jQHyJB-5jBZMJL972g54=hOCo1D4SsPJ_YaJnjleDIcqoN0CgrQIjm6HkrwwBpHk=
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dospf-2Dlink-2Doverload_=DwICaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng=u9tJ1yVc0IA5x8YKUYmU-C7jQHyJB-5jBZMJL972g54=ujWgF5xik7lwV-N51a0mFcuf6Q7JRXz3ID1DkU2rVmY=



--
COMMENT:
--

As mentioned by Tim, part of the OPS DIR review. It's the authors and 
responsible AD to decide whether to act on those comments.

I believe the document is Ready for publication.  I have only three minor 
comments below, which the authors may choose to act on.

Overall the document reads reasonably well. Not being overly familiar with the 
material, I needed to read it through end-to-end more than once to better 
understand its scope and intent. My first comment would be that perhaps the 
introduction section could be better written; the abstract seemed clear on the 
purpose of the draft, while the introduction felt a little muddled.  Sections 
2, 3 and 4, which detail the motivations and extensions, were much clearer.

Secondly, there are some minor typographic errors throughout the document, 
generally missing (in)definite articles.  While the RFC Editor would pick these 
up, it would be nice for the authors to have a final pass and fix those before 
submission.

Thirdly, the document does not give any advice on the timing of using the 
extensions - how far in advance is it recommended to use the extensions? - or 
on the return to 'normal' state once the maintenance is completed.  So perhaps 
consider adding a short section on this, maybe in Section 5.


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

Re: [OSPF] Ben Campbell's No Record on draft-ietf-ospf-link-overload-13: (with COMMENT)

[Shraddha Hegde]

Ben,

Thanks for the review and comments.
Added a few more details in security consideration which I'll be posting today.
Pls check if it looks good.

Thanks
Shraddha

-Original Message-
From: Ben Campbell [mailto:b...@nostrum.com] 
Sent: Wednesday, January 24, 2018 8:24 AM
To: The IESG 
Cc: draft-ietf-ospf-link-overl...@ietf.org; Acee Lindem ; 
ospf-cha...@ietf.org; a...@cisco.com; ospf@ietf.org
Subject: Ben Campbell's No Record on draft-ietf-ospf-link-overload-13: (with 
COMMENT)

Ben Campbell has entered the following ballot position for
draft-ietf-ospf-link-overload-13: No Record

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.proofpoint.com/v2/url?u=https-3A__www.ietf.org_iesg_statement_discuss-2Dcriteria.html=DwICaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng=9YmNaTz3gKI9_1Oa7kDju4GU3kMo_OSgOCooVbpH1wk=PFC_97HP8RQOw1mw2ADihflHr8rxgfxfrsjz8Hs0S4M=
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dospf-2Dlink-2Doverload_=DwICaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng=9YmNaTz3gKI9_1Oa7kDju4GU3kMo_OSgOCooVbpH1wk=nd0lqbxzhmOwDPEXRfI-RY1XXzDTpSG_XPKJ6dcz0zo=



--
COMMENT:
--

-8: It would be helpful to see a few sentences about how the security 
considerations in 2328 and 5340 apply to the mechanisms in this draft, rather 
than just a "no new considerations" assertion.


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

Re: [OSPF] Opsdir telechat review of draft-ietf-ospf-link-overload-13

[Shraddha Hegde]

Tim,

Thanks for the review and comments.
Pls see inline for responses.

-Original Message-
From: Tim Chown [mailto:tim.ch...@jisc.ac.uk] 
Sent: Monday, January 22, 2018 8:25 PM
To: ops-...@ietf.org
Cc: ospf@ietf.org; draft-ietf-ospf-link-overload@ietf.org
Subject: Opsdir telechat review of draft-ietf-ospf-link-overload-13

Reviewer: Tim Chown
Review result: Ready

Hi,

I have reviewed this document as part of the Operational directorate's ongoing 
effort to review all IETF documents being processed by the IESG.  These 
comments were written with the intent of improving the operational aspects of 
the IETF drafts. Comments that are not addressed in last call may be included 
in AD reviews during the IESG review. Document editors and WG chairs should 
treat these comments just like any other last call comments.

This document defines mechanism(s) to allow OSPF routers to indicate that a 
specific link, rather than a whole node, is entering an imminent maintenance 
state, to allow other devices that understand the protocol extension(s) to more 
gracefully re-route traffic around the affected link.

I believe the document is Ready for publication.  I have only three minor 
comments below, which the authors may choose to act on.

Overall the document reads reasonably well. Not being overly familiar with the 
material, I needed to read it through end-to-end more than once to better 
understand its scope and intent. My first comment would be that perhaps the 
introduction section could be better written; the abstract seemed clear on the 
purpose of the draft, while the introduction felt a little muddled.  Sections 
2, 3 and 4, which detail the motivations and extensions, were much clearer.
 Added more text to introduction section in version -14. Pls check if 
it looks better now.

Secondly, there are some minor typographic errors throughout the document, 
generally missing (in)definite articles.  While the RFC Editor would pick these 
up, it would be nice for the authors to have a final pass and fix those before 
submission.
 Ack. 

Thirdly, the document does not give any advice on the timing of using the 
extensions - how far in advance is it recommended to use the extensions? - or 
on the return to 'normal' state once the maintenance is completed.  So perhaps 
consider adding a short section on this, maybe in Section 5.
 Added below details to section 5

 When a link is ready to carry traffic, the Graceful-Lnk-Shutdown sub-TLV 
should be removed from the Extended Link TLV/Router-Link TLV and the 
corresponding
LSAs MUST be readvertised.

Best wishes,
Tim


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

Re: [OSPF] Alvaro Retana's No Objection on draft-ietf-ospf-link-overload-13: (with COMMENT)

[Shraddha Hegde]

Ketan,

Thanks for comments.
Pls see inline...

-Original Message-
From: Ketan Talaulikar (ketant) [mailto:ket...@cisco.com] 
Sent: Thursday, January 25, 2018 1:58 PM
To: Shraddha Hegde <shrad...@juniper.net>; Alvaro Retana 
<aretana.i...@gmail.com>; The IESG <i...@ietf.org>
Cc: ospf@ietf.org; draft-ietf-ospf-link-overl...@ietf.org; ospf-cha...@ietf.org
Subject: RE: Alvaro Retana's No Objection on draft-ietf-ospf-link-overload-13: 
(with COMMENT)

Hi Shraddha,

A few comments and observations in the ver 14 and apologies for not providing 
some of them earlier, but I had a closer review after looking at Alvaro's 
comments and many improvements have happened recently.

Related to BGP-LS TLV:
For sec 4.5 - please mention the type here since the IANA section would get 
taken off by RFC editor. While you do refer to RFC7752 sec 3.1 for the TLV - I 
think it would be more reader friendly to describe the TLV and the code point 
in this section inline like the OSPF TLVs.
 OK updated in new version

For sec 10, the BGP-LS registry being referred to is wrong and it should be " 
BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs" 
and the suggested codepoint is already taken so I would suggest to request for 
1121. I believe this was pointed out during the early allocation call but seems 
like it got missed out so could you please correct/update?
ok. updated latest version.

https://urldefense.proofpoint.com/v2/url?u=https-3A__www.iana.org_assignments_bgp-2Dls-2Dparameters_bgp-2Dls-2Dparameters.xhtml=DwIFAg=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng=XBYEEARnw7lDAsfkNEsBkAkyVwYGvQ-2jj6E-wcs7TM=EL7ViyIcLwxx16_SC9EcrtseFsVFllPPOAYXwlPcUGk=
 

Suggest making the section describing Maximum TE Metric before the current Sec 
5 - Elements of procedure so the flow is better for the reader.
 We will use 0x so the definition is going away in new 
version.

Sec 5.1 

Instead of using SHOULD for TE metric, it would be better to qualify as " When 
TE is enabled, the TE metric of the link MUST be set to MAX-TE-METRIC 
(0xfffe) and the node MUST re-originate the corresponding TE Link Opaque 
LSAs."
 I think there should be an option of not following procedures 
defined in this document if traffic engineering applications don't need it 
(changing reverse side metric). I can't think of a usecase right now but I 
think this flexibility is needed.


s/ MAX-TE-METRIC (0xfffe).//

s/ The TE metric SHOULD be set / The TE metric of the link SHOULD be set
ack

s/ link and set the metric to MaxLinkMetric / link and set its metric to 
MaxLinkMetric
 ack

s/ The TE metric SHOULD be set to MAX-TE-METRIC (0xfffe) and the TE opaque 
LSA for the link SHOULD be re-originated with new value./ Similarly, when TE is 
enabled, the remote node MUST set the TE metric for the link to MAX-TE-METRIC 
(0xfffe) and MUST re-originate the TE Link Opaque LSA for the link with new 
value.
 ack except the MUST.

A couple of sentences describing the different LSAs that come into play for 
OSPFv3 would be helpful in this section as well. Just as done in sec 3. The 
thing is that the OSPFv3 LSAs and especially it's equivalent TE LSAs are 
different. In fact RFC5329 is not being referred to as NORMATIVE and so does 
that imply we don't want to do similar action with TE metric in case of 
OSPFv3?. So it would be good to specify or clarify that part. Perhaps in 
general at start of sec 5 so the text in the rest of sub-sections are link-type 
specifics and generic to OSPF without naming any LSAs there?

 refered RFC 5329 in section 5

Sec 5.4 Unnumbered interfaces
IMHO this text is very similar to Sec 4.7 which talks about how to identify 
parallel links. Perhaps sec 5.4 should become Sec 4.8 since what is does is 
explain how the correlation of links is done for unnumbered links. Alternately, 
this explanation can be put under Sec 4.3 where the Local/Remote ID TLV is 
specified since this mechanism is going to be common for other use-case of this 
general purpose TLV.
 I think this section is needed as the previous section on Remote 
IPv4 address does not talk about unnumbered interfaces

Thanks,
Ketan

-Original Message-
From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Shraddha Hegde
Sent: 25 January 2018 11:01
To: Alvaro Retana <aretana.i...@gmail.com>; The IESG <i...@ietf.org>
Cc: ospf@ietf.org; draft-ietf-ospf-link-overl...@ietf.org; ospf-cha...@ietf.org
Subject: Re: [OSPF] Alvaro Retana's No Objection on 
draft-ietf-ospf-link-overload-13: (with COMMENT)

Alvaro,

Thanks for the review and comments.
Pls see inline..

Rgds
Shraddha

-Original Message-
From: Alvaro Retana [mailto:aretana.i...@gmail.com]
Sent: Wednesday, January 24, 2018 11:27 PM
To: The IESG <i...@ietf.org>
Cc: draft-ietf-ospf-link-overl...@ietf.org; Acee Lindem <a...@cisco.com>; 
ospf-cha...@ietf.org; ospf@ietf.org

Re: [OSPF] Deborah Brungard's Discuss on draft-ietf-ospf-link-overload-13: (with DISCUSS and COMMENT)

[Shraddha Hegde]

Hi Deborah/Alia,

Thanks for the comments.
We really need a TE metric that can be used as last resort metric.
RFC 5817 is very clear that 0x is a last-resort metric.
Probably prior to 5817, there were no clear statements on
The metric 0x being usable metric and resulted in implementation
Differences.

I do see the conflict with RFC 5817 if this draft sets metric to 0xfffe.
I think all the confusion is not really worth.
While deploying feature in this draft operators have to make sure
All the head-ends are behaving correctly with respect to 0x.

I’ll change the TE metric to 0x in the next revision.
WG,
Let me know in case of any concern.

Rgds
Shraddha

From: Acee Lindem (acee) [mailto:a...@cisco.com]
Sent: Thursday, January 25, 2018 9:06 PM
To: Alia Atlas ; Deborah Brungard 
Cc: The IESG ; OSPF List ; 
draft-ietf-ospf-link-overl...@ietf.org; ospf-cha...@ietf.org; TEAS WG 
(t...@ietf.org) 
Subject: Re: Deborah Brungard's Discuss on draft-ietf-ospf-link-overload-13: 
(with DISCUSS and COMMENT)

Hi Alia,

From: Alia Atlas >
Date: Thursday, January 25, 2018 at 10:30 AM
To: Deborah Brungard >
Cc: The IESG >, OSPF WG List 
>, 
"draft-ietf-ospf-link-overl...@ietf.org"
 
>,
 Acee Lindem >, 
"ospf-cha...@ietf.org" 
>, "TEAS WG 
(t...@ietf.org)" >
Subject: Re: Deborah Brungard's Discuss on draft-ietf-ospf-link-overload-13: 
(with DISCUSS and COMMENT)

More specifically, as Deborah pointed out, in RFC 5817 Section 4.1, it says
"Specifically, the node where graceful shutdown of a link is desired originates 
the TE LSA or IS-
   IS-LSP containing a Link TLV for the link under graceful shutdown
   with the Traffic Engineering metric set to 0x, 0 as
   unreserved bandwidth. "

and draft-ietf-ospf-link-overload-14 conflicts with that by using 0xfffe 
instead.

I’ll defer to Shraddha and the other authors on this one. We did discuss the 
RFC 5817 inconsistency once already and the intension is that TE interface 
would still be used as a last resort TE interface.

Thanks,
Acee


Regards,
Alia

On Thu, Jan 25, 2018 at 10:26 AM, Alia Atlas 
> wrote:
Could a look at the changes in draft-ietf-ospf-link-overload-14 happen?

Also, it would be good to get feedback from TEAS on this document and any 
concerns.

Thanks,
Alia

On Tue, Jan 23, 2018 at 12:01 PM, Deborah Brungard 
> wrote:
Deborah Brungard has entered the following ballot position for
draft-ietf-ospf-link-overload-13: 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://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ospf-link-overload/



--
DISCUSS:
--

This document is defining a MAX-TE-METRIC of 0xfffe. But RFC5817 defined
0x to be used for graceful shutdown. I noted an email exchange between
the author and Acee on this where Acee raised the question why RFC5817's value
was not used. Shraddha replied "We can if we have the Working Group Consensus".
There was no further discussion.

This document was not shared with teas which is responsible for TE (or ccamp
which was originally responsible for RFC5817).

Either this value needs to be changed to RFC5817's value or this TE metric
needs to be removed from this document until agreement with TEAS.


--
COMMENT:

Re: [OSPF] Alvaro Retana's No Objection on draft-ietf-ospf-link-overload-13: (with COMMENT)

[Shraddha Hegde]

Alvaro,

Thanks for the review and comments.
Pls see inline..

Rgds
Shraddha

-Original Message-
From: Alvaro Retana [mailto:aretana.i...@gmail.com] 
Sent: Wednesday, January 24, 2018 11:27 PM
To: The IESG 
Cc: draft-ietf-ospf-link-overl...@ietf.org; Acee Lindem ; 
ospf-cha...@ietf.org; ospf@ietf.org
Subject: Alvaro Retana's No Objection on draft-ietf-ospf-link-overload-13: 
(with COMMENT)

Alvaro Retana has entered the following ballot position for
draft-ietf-ospf-link-overload-13: No Objection

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.proofpoint.com/v2/url?u=https-3A__www.ietf.org_iesg_statement_discuss-2Dcriteria.html=DwICaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng=2yotvig0Pod2iYz1kE1G9Yj72-TdzzWuw-Wi17D6TfU=8uPkIAPxrIiuVMLudgaSbVjvc-3iZNkLaXrmc6GJpZM=
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dospf-2Dlink-2Doverload_=DwICaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng=2yotvig0Pod2iYz1kE1G9Yj72-TdzzWuw-Wi17D6TfU=5Dmkf-qOIfCiHPCyuj-sVNDcS904luv_ECpSb3D5HVM=



--
COMMENT:
--

I debated about filing my first comment as a DISCUSS [1], but decided against 
it because it should be very easy to solve.  The rest are non-blocking comments.

(1) The following should be Normative references: rfc2119 and rfc6987 -- this 
last one because MaxLinkMetric (which is defined there) is extensively used (as 
a MUST) throughout the document.
 OK

(2) Section 3. (Flooding Scope) provides information about the flooding scope, 
but only references for OSPFv2.  It would be nice if the references for OSPFv3 
were included there as well.
 OK

(3) Section 4.5. mentions that a "new TLV called Graceful-Link-Shutdown is 
defined" for BGP-LS, but there are no details on the format, etc.  The IANA 
Considerations section suggests a value, not for a TLV but for an NLRI Type!
 OK. Refered section 3.1 of RFC 7752 and described the contents of 
the TLV
IANA section seems ok to me. Could you be more specific what needs to change?


   BGP-LS Link NLRI Registry [RFC7752]   >>>Registry

   i)Graceful-Link-Shutdown TLV - Suggested 1101 >>>TLV type



(4) Section 5: "The node that has the link to be taken out of service SHOULD 
advertise the Graceful-Link-Shutdown sub-TLV..."  When would the node not 
advertise the sub-TLV?  IOW, why is "MUST" not used?
 Thanks for pointing out. Changed to MUST.

(5) In 5.1: "MAX-TE-METRIC is a constant defined by this draft and set to 
0xfffe."  Assuming that the intent is to define a new architectural 
constant... I would rather see this constant defined separately (in it's own 
section/sub-section with a formal definition) instead of "in passing" while 
describing how to use it (a la MaxLinkMetric in rfc6987).
 OK

(6) 5.1 says that the metrics "MUST be set to MaxLinkMetric...and SHOULD be set 
to MAX-TE-METRIC".  Why is there a difference?
 TE is an optional feature so MAX-TE-METRIC needs to be set only when 
TE is enabled on the node.

(7) s/MAX_METRIC/MaxLinkMetric
 ok.

[1] 
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_iesg_statement_discuss-2Dcriteria.html=DwICaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng=2yotvig0Pod2iYz1kE1G9Yj72-TdzzWuw-Wi17D6TfU=8uPkIAPxrIiuVMLudgaSbVjvc-3iZNkLaXrmc6GJpZM=


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

Re: [OSPF] Eric Rescorla's No Objection on draft-ietf-ospf-link-overload-12: (with COMMENT)

[Shraddha Hegde]

Hi Eric,

Introduction section does have a brief description and refers to 7.1 for 
detailed description of the use case. Moving detailed use case description to 
introduction section will make it cluttered.
Also there are other applications apart from 7.1 which also have a brief 
description in the 
Introduction and refer to application section for detailed description.

Rgds
Shraddha

-Original Message-
From: Eric Rescorla [mailto:e...@rtfm.com] 
Sent: Thursday, January 18, 2018 10:11 PM
To: The IESG 
Cc: draft-ietf-ospf-link-overl...@ietf.org; Acee Lindem ; 
ospf-cha...@ietf.org; a...@cisco.com; ospf@ietf.org
Subject: Eric Rescorla's No Objection on draft-ietf-ospf-link-overload-12: 
(with COMMENT)

Eric Rescorla has entered the following ballot position for
draft-ietf-ospf-link-overload-12: No Objection

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.proofpoint.com/v2/url?u=https-3A__www.ietf.org_iesg_statement_discuss-2Dcriteria.html=DwICaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng=3MyT2IBHmmEmtejJI2o73p3zIjhzSmGtffDprR-DdD0=TufjwL4DRLGVAWd56qU-6DaDDRfPsgeHp8JmN2XrdTE=
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dospf-2Dlink-2Doverload_=DwICaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng=3MyT2IBHmmEmtejJI2o73p3zIjhzSmGtffDprR-DdD0=avFGB5zEal090OxCbLLU5A1NvjlOJREQPCY-yP7GTDk=



--
COMMENT:
--

I think this document would be clearer if the example in S 7.1 were in the 
intro. I was scratching my head a bit at the beginning and then got to 7.1 and 
it made more sense.


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

Re: [OSPF] OSPF Link Overload (aka, Graceful Link Shutdown) MAX-TE-METRIC

[Shraddha Hegde]

Acee,

Pls see inline..

From: Acee Lindem (acee) [mailto:a...@cisco.com]
Sent: Wednesday, January 10, 2018 7:51 AM
To: Shraddha Hegde <shrad...@juniper.net>
Cc: OSPF WG List <ospf@ietf.org>
Subject: OSPF Link Overload (aka, Graceful Link Shutdown) MAX-TE-METRIC

Hi Shraddha,

We noticed that RFC 5817 sets the TE Metric to 0x for graceful TE 
shutdown and the OSPF Link Overload draft uses MAX-TE-METRIC (0xfffe). Two 
Questions:


1.   MAX-TE-METRIC is being defined in the OSPF Link Overload draft – 
correct? It is not a reference from some other RFC or draft?

Yes. This value is introduced in this draft.

The reason was that some implementation treat te-metric 0x as invalid 
value and do not setup paths through them. Using 0x-1 seemed like a 
safe option

2.   Why not just use 0x like RFC 5817?

We can if we have the Working Group Consensus.



Thanks,
Acee

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

Re: [OSPF] Genart last call review of draft-ietf-ospf-link-overload-11

[Shraddha Hegde]

OSPF WG,

WG consensus seems to be graceful-link-shutdown.
I’ll update the draft with graceful-link-shutdown and also add some text
Describing this mechanism can also be used when the real intent is not to 
shutdown
the link.

Let me know if there are any objections.

Rgds
Shraddha

From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Monday, January 8, 2018 11:31 PM
To: Pushpasis Sarkar <pushpasis.i...@gmail.com>; Bruno Decraene 
<bruno.decra...@orange.com>
Cc: Shraddha Hegde <shrad...@juniper.net>; Acee Lindem (acee) <a...@cisco.com>; 
Ketan Talaulikar (ketant) <ket...@cisco.com>; Joel Halpern 
<j...@joelhalpern.com>; gen-...@ietf.org; ospf@ietf.org; i...@ietf.org; 
draft-ietf-ospf-link-overload@ietf.org
Subject: RE: Genart last call review of draft-ietf-ospf-link-overload-11

If the WG consensus is for “GLS” so be it…but I would like to reemphasize two 
things:

1)There are use cases where the intent is NOT to shutdown the link

2)Once the link is shutdown the extension is no longer used since there is no 
longer an adjacency – so to me it makes a lot more sense to pick a name which 
reflects how the link is to be used while it is still up.

   Les



From: Pushpasis Sarkar [mailto:pushpasis.i...@gmail.com]
Sent: Monday, January 08, 2018 9:22 AM
To: Bruno Decraene <bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>>
Cc: Shraddha Hegde <shrad...@juniper.net<mailto:shrad...@juniper.net>>; Acee 
Lindem (acee) <a...@cisco.com<mailto:a...@cisco.com>>; Les Ginsberg (ginsberg) 
<ginsb...@cisco.com<mailto:ginsb...@cisco.com>>; Ketan Talaulikar (ketant) 
<ket...@cisco.com<mailto:ket...@cisco.com>>; Joel Halpern 
<j...@joelhalpern.com<mailto:j...@joelhalpern.com>>; 
gen-...@ietf.org<mailto:gen-...@ietf.org>; ospf@ietf.org<mailto:ospf@ietf.org>; 
i...@ietf.org<mailto:i...@ietf.org>; 
draft-ietf-ospf-link-overload@ietf.org<mailto:draft-ietf-ospf-link-overload@ietf.org>
Subject: Re: Genart last call review of draft-ietf-ospf-link-overload-11

Hi Joel et al,

+1 for 'graceful-link-shutdown'. Another possibility may be 
'link-decommission'..

Thanks and regards
-Pushpasis

On Mon, Jan 8, 2018 at 7:09 PM, 
<bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>> wrote:


From: Shraddha Hegde
How about “graceful-link-shutdown” ?

Looks good to me.

Also, FYI, for BGP sessions, in the GROW WG we used the term “Graceful BGP 
session shutdown” and named the BGP community “GRACEFUL_SHUTDOWN” so this would 
align on the terminology.
https://tools.ietf.org/html/draft-ietf-grow-bgp-gshut-13<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dgrow-2Dbgp-2Dgshut-2D13=DwMGaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng=j5OSxniUADg7fBg9lmrSvsTWGWY_VhCl-Ydi9t0XfFI=R0GJNP0TbKHBFiCCQKwDlB7YVSgmQsq4p7JvCtd_leM=>

Best regards,
--Bruno


Rgds
Shraddha



From: Acee Lindem (acee) [mailto:a...@cisco.com]
Sent: Friday, January 5, 2018 6:50 PM
To: Les Ginsberg (ginsberg) <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>; 
Ketan Talaulikar (ketant) <ket...@cisco.com<mailto:ket...@cisco.com>>; Joel 
Halpern <j...@joelhalpern.com<mailto:j...@joelhalpern.com>>; 
gen-...@ietf.org<mailto:gen-...@ietf.org>
Cc: ospf@ietf.org<mailto:ospf@ietf.org>; i...@ietf.org<mailto:i...@ietf.org>; 
draft-ietf-ospf-link-overload@ietf.org<mailto:draft-ietf-ospf-link-overload@ietf.org>
Subject: Re: Genart last call review of draft-ietf-ospf-link-overload-11

It is not in “maintenance" mode yet as it is still being used. However, it is 
better than “overload”. “pending-maintenance” is a bit long which is why I 
suggested “pending-shutdown” since “shutdown” is term that vendors have used 
for eons to described an interface that is not in service.
Thanks,
Acee

From: "Les Ginsberg (ginsberg)" <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>
Date: Thursday, January 4, 2018 at 11:56 PM
To: "Ketan Talaulikar (ketant)" <ket...@cisco.com<mailto:ket...@cisco.com>>, 
Acee Lindem <a...@cisco.com<mailto:a...@cisco.com>>, "Joel M. Halpern" 
<j...@joelhalpern.com<mailto:j...@joelhalpern.com>>, 
"gen-...@ietf.org<mailto:gen-...@ietf.org>" 
<gen-...@ietf.org<mailto:gen-...@ietf.org>>
Cc: OSPF WG List <ospf@ietf.org<mailto:ospf@ietf.org>>, 
"i...@ietf.org<mailto:i...@ietf.org>" <i...@ietf.org<mailto:i...@ietf.org>>, 
"draft-ietf-ospf-link-overload@ietf.org<mailto:draft-ietf-ospf-link-overload@ietf.org>"
 
<draft-ietf-ospf-link-overload@ietf.org<mailto:draft-ietf-ospf-link-overload@ietf.org>>
Subject: RE: Genart last call review of draft-ietf-ospf-link-overload-1

Re: [OSPF] Genart last call review of draft-ietf-ospf-link-overload-11

[Shraddha Hegde]

How about “graceful-link-shutdown” ?

Rgds
Shraddha



From: Acee Lindem (acee) [mailto:a...@cisco.com]
Sent: Friday, January 5, 2018 6:50 PM
To: Les Ginsberg (ginsberg) ; Ketan Talaulikar (ketant) 
; Joel Halpern ; gen-...@ietf.org
Cc: ospf@ietf.org; i...@ietf.org; draft-ietf-ospf-link-overload@ietf.org
Subject: Re: Genart last call review of draft-ietf-ospf-link-overload-11

It is not in “maintenance" mode yet as it is still being used. However, it is 
better than “overload”. “pending-maintenance” is a bit long which is why I 
suggested “pending-shutdown” since “shutdown” is term that vendors have used 
for eons to described an interface that is not in service.
Thanks,
Acee

From: "Les Ginsberg (ginsberg)" >
Date: Thursday, January 4, 2018 at 11:56 PM
To: "Ketan Talaulikar (ketant)" >, 
Acee Lindem >, "Joel M. Halpern" 
>, 
"gen-...@ietf.org" 
>
Cc: OSPF WG List >, 
"i...@ietf.org" >, 
"draft-ietf-ospf-link-overload@ietf.org"
 
>
Subject: RE: Genart last call review of draft-ietf-ospf-link-overload-11

Ketan –

“maintenance” I could live with.

“GIR” seems to not be generic enough.

   Les


From: Ketan Talaulikar (ketant)
Sent: Thursday, January 04, 2018 8:09 PM
To: Acee Lindem (acee) >; Les Ginsberg 
(ginsberg) >; Joel Halpern 
>; 
gen-...@ietf.org
Cc: ospf@ietf.org; i...@ietf.org; 
draft-ietf-ospf-link-overload@ietf.org
Subject: RE: Genart last call review of draft-ietf-ospf-link-overload-11

Hello,

May I suggest something more generic like “Maintenance Mode” or “Graceful 
Insertion/Removal (GIR) Mode” which could be defined so as to cover the 
multiple scenarios in question (e.g. pending shutdown, down for repairs, last 
resort due to poor link quality, etc.).

Thanks,
Ketan

From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: 05 January 2018 08:14
To: Les Ginsberg (ginsberg) >; 
Joel Halpern >; 
gen-...@ietf.org
Cc: ospf@ietf.org; i...@ietf.org; 
draft-ietf-ospf-link-overload@ietf.org
Subject: Re: [OSPF] Genart last call review of draft-ietf-ospf-link-overload-11

Hi Les,

From: "Les Ginsberg (ginsberg)" >
Date: Thursday, January 4, 2018 at 9:26 PM
To: Acee Lindem >, "Joel M. Halpern" 
>, 
"gen-...@ietf.org" 
>
Cc: OSPF WG List >, 
"i...@ietf.org" >, 
"draft-ietf-ospf-link-overload@ietf.org"
 
>
Subject: RE: Genart last call review of draft-ietf-ospf-link-overload-11


> >Minor issues:

> >I understand the WG likes using the term "overload" for a link

> >being taken

> >out of service.  I think people will learn what we mean.  I do wish

> >we had

> >not chosen to misuse the words in this fashion.  This is much more a

> >graceful-link-close indication (or clsoe-pending indication) than

> >it is an

> >overload indication.

>

> I agree with this comment but I wasn’t sure we’d reach consensus on a

> better alternative. However, after some though and consideration of current

> OSPF router terminology, I’d propose we use the term “Pending-Shutdown”.

> Does anyone not agree that this is a more appropriate moniker for the TLV

> and state?

>

[Les:] I agree with Joel's comment. The use of the term "overload" is 
unfortunate.

But "pending-shutdown" isn’t appealing to me because - at least in most use 
cases - you aren't actually going to shutdown the link. What you are going to 
do is make a link the "link of last resort".

This seems a better choice.

That is not the use case - you are going to take the link down. It is not going 
to be the "link of last resort”, it is the currently the “link of last 

Re: [OSPF] RtgDir review: draft-ietf-ospf-link-overload-9

[Shraddha Hegde]

Martin,

Thanks for the detailed review and comments. 
I have added a new section 4.5 in -11 version on details of remote-ipv4 address 
and the need for it.
If you are talking about some other missing details, pls provide specific 
information.
Sometimes certain details seem trivial and well understood to authors but not 
so for others.

Rgds
Shraddha


-Original Message-
From: Martin Vigoureux [mailto:martin.vigour...@nokia.com] 
Sent: Friday, December 22, 2017 4:21 PM
To: rtg-...@ietf.org
Cc: rtg-...@ietf.org; draft-ietf-ospf-link-overl...@ietf.org; ospf@ietf.org
Subject: RtgDir review: draft-ietf-ospf-link-overload-9

Hello,

I have been selected as the Routing Directorate reviewer for this draft. 
The Routing Directorate seeks to review all routing or routing-related drafts 
as they pass through IETF last call and IESG review, and sometimes on special 
request. The purpose of the review is to provide assistance to the Routing ADs. 
For more information about the Routing Directorate, please see 
​https://urldefense.proofpoint.com/v2/url?u=http-3A__trac.tools.ietf.org_area_rtg_trac_wiki_RtgDir=DwIDaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng=mTTVgQyIphzdQXrtzuyX4FlD9pIHtdk57qE_gp8hgYY=d13HiGqS4KWdv0qkP-fD9NT1jEVnToFuz9wSPpaIzwc=

Although these comments are primarily for the use of the Routing ADs, it would 
be helpful if you could consider them along with any other IETF Last Call 
comments that you receive, and strive to resolve them through discussion or by 
updating the draft.

Document: draft-ietf-ospf-link-overload-9
Reviewer: Martin Vigoureux
Review Date: 2017-12-22
IETF LC End Date: date-if-known
Intended Status: Standard Track

Summary:
This document is basically ready for publication, but has nits (see
Comments) that should be considered prior to publication.

Comments:
So, before accepting this review I took a look at the draft and told myself 
"oh, not long, not apparently complicated.". Then I started reading it...
I have to admit that beyond the apparent simplicity of the objective, I did not 
understand much at first read. So I went on reading the mailing list and 
discovered a field of information and more specifically discussions explaining 
why certain design choices were made.

These are missing in the draft. I think that we should not expect readers and 
implementers to dig into the mailing list to understand the design described in 
a draft.

So I'd like to encourage the authors to add some text which summarizes the 
discussions that happened on the list and which explains why such and such 
design was in the end decided.

Thanks
-m

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

Re: [OSPF] Genart telechat review of draft-ietf-ospf-link-overload-10

[Shraddha Hegde]

Hi Joel,

Thanks for the detailed review and comments.
Pls see inline for replies.

Rgds
Shraddha

-Original Message-
From: Joel Halpern [mailto:j...@joelhalpern.com] 
Sent: Friday, December 22, 2017 5:04 AM
To: gen-...@ietf.org
Cc: ospf@ietf.org; i...@ietf.org; draft-ietf-ospf-link-overload@ietf.org
Subject: Genart telechat review of draft-ietf-ospf-link-overload-10

Reviewer: Joel Halpern
Review result: Almost Ready

I am the assigned Gen-ART reviewer for this draft. The General Area Review Team 
(Gen-ART) reviews all IETF documents being processed by the IESG for the IETF 
Chair. Please wait for direction from your document shepherd or AD before 
posting a new version of the draft.

For more information, please see the FAQ at

.

Document: draft-ietf-ospf-link-overload-10
Reviewer: Joel Halpern
Review Date: 2017-12-21
IETF LC End Date: None
IESG Telechat date: 2018-01-25

Summary: This document is almost ready for publication as a Proposed Standard.

Major issues:
 If a remote IPv4 address is needed in some cases for link identification,
 then does it not follow that for IPv6 usage with OSPFv3, a remote IPv6
 address is also needed?
OSPFv3 already has mechanisms to identify the remote side link as it 
already has
  Interface-ID and Neighbor's Interface ID in its link 
description. I have added a detailed
   Section 4.5 which describes the need for Remote-IPv4 
address in OSPFv2 and also covers why its not needed for OSPFv3. Pls see 
revision -11 for details.

Minor issues:
Why is the remote IPv4 address TLV being defined here?  It is not specific
to link maintenance.  If this is the first place it is needed, could the
text at least be clearer that this is a general purpose sub-TLV, not
specific to the link maintenance indication?
 New section added with the reasoning as described above.

Nits/editorial comments:
Given that this document specifically states that the problem to be solved
is the desire to take a link out of service, I would strongly prefer that
the option being defined by named to match the goal.  The link being
modified is not overloaded.  Could this be renamed the link
pending-maintenance indication or something along those lines?  I realize
the working group knows what it means.  But the point of naming is so that
folks looking later can understand or find the item.
 I think overload is common terminology used for maintenance 
operations. 
Similar feature for taking out Nodes from network is called "overload" in ISIS. 
The same feature 
Is called "stub router" in OSPF. "stub link" has a different meaning in OSPF so 
the best choice
Was to use "link-overload".


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

[OSPF] FW: I-D Action: draft-ietf-ospf-link-overload-10.txt

[Shraddha Hegde]

Acee,

The new version updates your editorial comments and also the OSPFv3 
advertisement.
Authors of the draft would like to request for WG last call and also early IANA 
code point allocations.

Rgds
Shraddha

-Original Message-
From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of internet-dra...@ietf.org
Sent: Monday, November 27, 2017 10:00 AM
To: i-d-annou...@ietf.org
Cc: ospf@ietf.org
Subject: [OSPF] I-D Action: draft-ietf-ospf-link-overload-10.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 WG of the IETF.

Title   : OSPF Link Overload
Authors : Shraddha Hegde
  Pushpasis Sarkar
  Hannes Gredler
  Mohan Nanduri
  Luay Jalil
Filename: draft-ietf-ospf-link-overload-10.txt
Pages   : 14
Date: 2017-11-26

Abstract:
   When a link is being prepared to be taken out of service, the traffic
   needs to be diverted from both ends of the link.  Increasing the
   metric to the highest metric on one side of the link is not
   sufficient to divert the traffic flowing in the other direction.

   It is useful for routers in an OSPFv2 or OSPFv3 routing domain to be
   able to advertise a link as being in an overload state to indicate
   impending maintenance activity on the link.  This information can be
   used by the network devices to re-route the traffic effectively.

   This document describes the protocol extensions to disseminate link-
   overload information in OSPFv2 and OSPFv3.



The IETF datatracker status page for this draft is:
https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dospf-2Dlink-2Doverload_=DwICAg=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng=HM5EVK74ZiRAJ71mTuhLA7ethZoWrqDnLZ3fcAZYlcY=jN3NElqtlD6ZVOns64xdC94BNFql0NvEDcpJQrgAyBY=

There are also htmlized versions available at:
https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dospf-2Dlink-2Doverload-2D10=DwICAg=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng=HM5EVK74ZiRAJ71mTuhLA7ethZoWrqDnLZ3fcAZYlcY=Da3Wl6LFvhE-Jkl8Zno82jXPvtBejMzLPRqGJ4U9VJI=
https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dietf-2Dospf-2Dlink-2Doverload-2D10=DwICAg=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng=HM5EVK74ZiRAJ71mTuhLA7ethZoWrqDnLZ3fcAZYlcY=fJuIEANJfHRJ7WNmS8S_IOrGwC1mJh-WAmeVXPlSSeg=

A diff from the previous version is available at:
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2Dospf-2Dlink-2Doverload-2D10=DwICAg=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng=HM5EVK74ZiRAJ71mTuhLA7ethZoWrqDnLZ3fcAZYlcY=DrvEFxiQdLU09fbEUvzWhYpRSD5VosCuU27Jjntay3E=


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:
https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_internet-2Ddrafts_=DwICAg=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng=HM5EVK74ZiRAJ71mTuhLA7ethZoWrqDnLZ3fcAZYlcY=8QSD4O3-8z8tIFLpm7FQZEL8QmRxvxwbJQRgPaAZji0=

___
OSPF mailing list
OSPF@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ospf=DwICAg=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng=HM5EVK74ZiRAJ71mTuhLA7ethZoWrqDnLZ3fcAZYlcY=CoU7Su8QjhBMR3HAhffLXtUl0lGp9r1vH-hcg8xjqNE=

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

[OSPF] Request for WG last call and Early IANA allocation for draft-ietf-ospf-link-overload-09

[Shraddha Hegde]

Acee/Abhay,

All the review comments received so far from working group have been addressed 
in the latest revision draft-ietf-ospf-link-overload-09.
 Authors of draft-ietf-ospf-link-overload would like to request for WG last 
call and also early code-point allocation from IANA.

Rgds
Shraddha

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

Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-07.txt

[Shraddha Hegde]

Hi Julien,

Thanks for your comments.
RFC 5817  is specific to TE enabled links where as ospf-link-overload is generic
For an IGP topology. One of the goals of this draft is also to automate the 
process
Re-routing traffic in reverse direction. I do not think there is complete 
overlap
Between the two drafts also this draft is not contradicting RFC 5817. I'll add 
a reference to
RFC 5817 for TE related processing.

Rgds
shraddha



-Original Message-
From: Julien Meuric [mailto:julien.meu...@orange.com] 
Sent: Friday, July 28, 2017 2:34 PM
To: Shraddha Hegde <shrad...@juniper.net>
Cc: ospf@ietf.org
Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-07.txt

Hi Shraddha,

Sorry for joining the discussion on -08.

>From your ID:
" It is useful to be able to advertise the impending maintenance activity on 
the link and to have LSP re-routing policies at the ingress to route the LSPs 
away from the link."

>From RFC 5817:
"a Service Provider may desire to gracefully (temporarily or
indefinitely) remove a TE link, a group of TE links, or an entire node for 
administrative reasons such as link maintenance, software/hardware upgrade at a 
node, or significant TE configuration changes."

There is a clear overlap. I am aware that RFC 5817 is informational, but is 
there a technical reason why the work in progress starts from scratch instead 
of building from section 4.1 in the former?

Thanks,

Julien (starting to feel as an old IETFer)


Jul. 27, 2017 - shrad...@juniper.net:
> Acee/OSPF WG,
> 
> I just realized my post on updated draft for -08 version posted on 17-07 was 
> stuck at confirmation stage.
> 
> I think it's useful to have normative language to ensure interoperability. I 
> have updated the "elements of procedure"
> Section accordingly. Please review the -08 version.
> 
> Thanks
> Shraddha
> 
> -Original Message-
> From: Acee Lindem (acee) [mailto:a...@cisco.com]
> Sent: Tuesday, July 25, 2017 3:59 AM
> 
> Hi Shraddha,
> 
> Great - I think we are all in sync.
> 
> What are your thoughts on using “MUST” for the setting the link metrics in 
> sections 5.1, 5.2, 5.3 and 5.5? I checked RFC 6987 (and RFC 3137) and they 
> don't use normative language since setting the link-metrics to 0x is the 
> very definition of OSPF stub router behavior.
> 
> Also, one more reference to RFC 4203.
> 
> *** 438,445 
>  field in the Extended Link TLV carries the Local interface-id instead
>  of the IP address.  The Local/Remote Interface ID sub-TLV MUST be
>  originated when there are multiple parallel unnumbered interfaces
> !between two nodes.  Procedures to obtain interface-id of the remote
> !side are defined in [RFC4203].
>   
>   
>   
> --- 438,445 
>  field in the Extended Link TLV carries the Local interface-id instead
>  of the IP address.  The Local/Remote Interface ID sub-TLV MUST be
>  originated when there are multiple parallel unnumbered interfaces
> !between two nodes.  One of the mechanisms to obtain remote
> !interface-id is described in [RFC4203].
>   
> 
> 
> Thanks,
> Acee
> 
> 
> On 7/10/17, 12:52 AM, "Shraddha Hegde" <shrad...@juniper.net> wrote:
> 
>> All,
>>
>> Link-local flooding was added as an optimization for use-cases that 
>> do not need area level flooding on request from Acee.
>> I agree flooding area level in all cases is a reasonable way forward 
>> as the overhead isn't much.
>>
>> If anyone has objections to removing Link-local scope advertisement, 
>> do let me know.
>>
>> Rgds
>> Shraddha
>>
>>
>> -Original Message-
>> From: Acee Lindem (acee) [mailto:a...@cisco.com]
>> Sent: Thursday, July 6, 2017 2:55 PM
>>
>> Hi Peter, Shradha,
>>
>> On 7/6/17, 3:30 AM, "OSPF on behalf of Peter Psenak (ppsenak)"
>> <ospf-boun...@ietf.org on behalf of ppse...@cisco.com> wrote:
>>
>>> On 06/07/17 05:50 , Ketan Talaulikar (ketant) wrote:
>>>> Hi Shraddha,
>>>>
>>>> Thanks for taking care of some of the comments shared previously.
>>>> Please find below some more that were probably missed or not taken 
>>>> care of.
>>>>
>>>> 1) I see that the use of link-local scope RI LSA has still been 
>>>> retained in this version and not sure why. RI LSA is for node 
>>>> attributes and it's use for signalling of link is not right IMO. 
>>>> Why not use the link-local scope Extended Link LSA instead?
>>>
>>> an alternative would be to always flood area scope Extended Link LSA.
>>> It should not harm anything 

Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-07.txt

[Shraddha Hegde]

Acee/OSPF WG,

I just realized my post on updated draft for -08 version posted on 17-07 was 
stuck at confirmation stage.

I think it's useful to have normative language to ensure interoperability. I 
have updated the "elements of procedure"
Section accordingly. Please review the -08 version.

Thanks
Shraddha

-Original Message-
From: Acee Lindem (acee) [mailto:a...@cisco.com] 
Sent: Tuesday, July 25, 2017 3:59 AM
To: Shraddha Hegde <shrad...@juniper.net>; Peter Psenak (ppsenak) 
<ppse...@cisco.com>; Ketan Talaulikar (ketant) <ket...@cisco.com>
Cc: ospf@ietf.org
Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-07.txt

Hi Shraddha, 

Great - I think we are all in sync.

What are your thoughts on using “MUST” for the setting the link metrics in 
sections 5.1, 5.2, 5.3 and 5.5? I checked RFC 6987 (and RFC 3137) and they 
don't use normative language since setting the link-metrics to 0x is the 
very definition of OSPF stub router behavior.

Also, one more reference to RFC 4203.

*** 438,445 
 field in the Extended Link TLV carries the Local interface-id instead
 of the IP address.  The Local/Remote Interface ID sub-TLV MUST be
 originated when there are multiple parallel unnumbered interfaces
!between two nodes.  Procedures to obtain interface-id of the remote
!side are defined in [RFC4203].
  
  
  
--- 438,445 
 field in the Extended Link TLV carries the Local interface-id instead
 of the IP address.  The Local/Remote Interface ID sub-TLV MUST be
 originated when there are multiple parallel unnumbered interfaces
!between two nodes.  One of the mechanisms to obtain remote
!interface-id is described in [RFC4203].
  


Thanks,
Acee 


On 7/10/17, 12:52 AM, "Shraddha Hegde" <shrad...@juniper.net> wrote:

>All,
>
>Link-local flooding was added as an optimization for use-cases that do 
>not need area level flooding on request from Acee.
>I agree flooding area level in all cases is a reasonable way forward as 
>the overhead isn't much.
>
>If anyone has objections to removing Link-local scope advertisement, do 
>let me know.
>
>Rgds
>Shraddha
>
>
>-Original Message-
>From: Acee Lindem (acee) [mailto:a...@cisco.com]
>Sent: Thursday, July 6, 2017 2:55 PM
>To: Peter Psenak (ppsenak) <ppse...@cisco.com>; Ketan Talaulikar 
>(ketant) <ket...@cisco.com>; Shraddha Hegde <shrad...@juniper.net>
>Cc: ospf@ietf.org
>Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-07.txt
>
>Hi Peter, Shradha,
>
>On 7/6/17, 3:30 AM, "OSPF on behalf of Peter Psenak (ppsenak)"
><ospf-boun...@ietf.org on behalf of ppse...@cisco.com> wrote:
>
>>On 06/07/17 05:50 , Ketan Talaulikar (ketant) wrote:
>>> Hi Shraddha,
>>>
>>> Thanks for taking care of some of the comments shared previously.
>>>Please find below some more that were probably missed or not taken 
>>>care of.
>>>
>>> 1) I see that the use of link-local scope RI LSA has still been 
>>>retained in this version and not sure why. RI LSA is for node 
>>>attributes and it's use for signalling of link is not right IMO. Why 
>>>not use the link-local scope Extended Link LSA instead?
>>
>>an alternative would be to always flood area scope Extended Link LSA.
>>It should not harm anything and could be used by other routers in area 
>>as a "heads-up" that remote link is becoming overloaded.
>
>I think this would be a good way forward as the OSPF Extended Attribute 
>LSA will most likely be advertised for SR in OSPF Service Provider 
>domains anyway. So, just advertising the area-scope for all use cases 
>would seem to be the simplify this approach and get us past this 
>discussion. In fact, the -00 version of the draft had area-scope alone 
>and I, regretfully, had suggested the OSPF RI as possible way to get 
>support either scope.
>
>Thanks,
>Acee
>
>>
>>
>>>
>>> 2) Sec 5.1, why is advertising of MAX-METRIC for the link to be 
>>>overloaded a SHOULD and not a MUST? Isn't this mandatory to ensure 
>>>backward compatibility? What if the router on which overload is 
>>>signalled does not do MAX-METRIC but the implementation on the remote 
>>>side end up doing MAX-METRIC. Would it not result in asymmetric 
>>>metric in a un-intended manner? Please consider changing all SHOULD 
>>>here to MUST to ensure backward compatibility.
>>>
>>> 3) Sec 5.4, can you please make similar change in language related 
>>>to the RFC4203 reference as you've done in other parts in this version?
>>>
>>> Also I don't agree with the rationale you've given for not using LLS 
>>>f

Re: [OSPF] 答复: WG adoption poll for draft-ppsenak-ospf-te-link-attr-reuse

[Shraddha Hegde]

OSPF WG,

There has been a long debate on this draft, probably the most discussed in
OSPF WG.  The major contention point with this draft has been around 

1. Definition of TE and Non-TE applications.
 The draft still uses the terminology of TE and non-TE applications without 
defining
 the meaning of what is considered TE and what is non-TE.
2. There are implementations that make use of TE LSAs for the purpose of 
implementing
[I-D.ietf-rtgwg-lfa-manageability] and
   [I-D.psarkar-rtgwg-rlfa-node-protection]. Normative language is required to 
make sure
   application such as RSVP and LFA do not suddenly become invalid because one 
vendor chooses to
   implement this draft and stops advertising link attributes in TE LSAs.
   
   The backward compatibility section specifies
   "When an OSPF routing domain includes routers using link attributes
   from TE Opaque LSAs for Non-RSVP TE applications such as LFA, OSPF
   routers in that domain should continue to advertise such TE Opaque
   LSAs."
   
   In order to make sure operators do not end up seeing inter-op issues due to 
   different vendors implementing the draft at different times a normative
   language such as below MUST be used.
   
   "Routers in the OSPF Domain MUST continue to advertise TE Opaque LSAs, when 
there are 
   applications that make use of TE Opaque LSAs.In the interest of backward 
compatibility,
   implementations MUST implement appropriate knobs to facilitate advertisement 
of link attributes in
   TE LSAs. Implementations MUST also support processing link attributes 
advertised in TE-LSAs. A separate IETF draft
   MAY be wriiten in future when the deployments are mature enough to move 
completely to the advertisements
   defined in this draft"
   
   
3.  The encodings for the recent addition "Application Specific Values" has 
scope for improvement. Having seperate
Masks for standard and user defined applications does not seem necessary. 

4. Acee's reference to different OSPF LSAs and comparing them to Chicken, egg 
and the
   Rooster describes the problem aptly in one sentence.
   Chicken and egg problem is age old in OSPF and all implementations have 
handled it very well.

   Handling rooster wouldn't have been as difficult but with this draft, 
chicken, egg and the rooster have moved from 
   vendor's backyard to operator's front yard.
   Operator's have to co-ordinate which vendor advertises what attributes in 
which LSA and which node/link
   in the network should have which knobs turned on. 

   Deployment consideration section needs to consider various cases of upgrade 
process.
   There is definitely need for text describing how the advertisements would 
look like if RSVP, LFA-manageability
   and SR-TE are deployed together.
   
   
   These comments on the draft are an effort to make sure existing IETF 
standardized applications
   would not break when new enhancements are introduced.


Rgds
Shraddha

-Original Message-
From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Xuxiaohu
Sent: Monday, July 10, 2017 3:20 PM
To: Abhay Roy ; ospf@ietf.org
Subject: [OSPF] 答复: WG adoption poll for draft-ppsenak-ospf-te-link-attr-reuse

I have read this draft and support the WG adoption.

Xiaohu

> -邮件原件-
> 发件人: OSPF [mailto:ospf-boun...@ietf.org] 代表 Abhay Roy
> 发送时间: 2017年7月4日 2:37
> 收件人: ospf@ietf.org
> 主题: [OSPF] WG adoption poll for draft-ppsenak-ospf-te-link-attr-reuse
> 
> We would like to kick-off a poll for WG adoption of the following 
> document (per Authors request):
> 
> https://datatracker.ietf.org/doc/draft-ppsenak-ospf-te-link-attr-reuse
> 
> Please let us know if you support or have concerns with OSPF WG 
> adopting this work.
> 
> Regards,
> -Abhay
> 
> ___
> 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

Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-07.txt

[Shraddha Hegde]

All,

Link-local flooding was added as an optimization for use-cases that do not need 
area level flooding on request from Acee.
I agree flooding area level in all cases is a reasonable way forward as the 
overhead isn't much.

If anyone has objections to removing Link-local scope advertisement, do let me 
know.

Rgds
Shraddha


-Original Message-
From: Acee Lindem (acee) [mailto:a...@cisco.com] 
Sent: Thursday, July 6, 2017 2:55 PM
To: Peter Psenak (ppsenak) <ppse...@cisco.com>; Ketan Talaulikar (ketant) 
<ket...@cisco.com>; Shraddha Hegde <shrad...@juniper.net>
Cc: ospf@ietf.org
Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-07.txt

Hi Peter, Shradha, 

On 7/6/17, 3:30 AM, "OSPF on behalf of Peter Psenak (ppsenak)"
<ospf-boun...@ietf.org on behalf of ppse...@cisco.com> wrote:

>On 06/07/17 05:50 , Ketan Talaulikar (ketant) wrote:
>> Hi Shraddha,
>>
>> Thanks for taking care of some of the comments shared previously.
>>Please find below some more that were probably missed or not taken 
>>care of.
>>
>> 1) I see that the use of link-local scope RI LSA has still been 
>>retained in this version and not sure why. RI LSA is for node 
>>attributes and it's use for signalling of link is not right IMO. Why 
>>not use the link-local scope Extended Link LSA instead?
>
>an alternative would be to always flood area scope Extended Link LSA. 
>It should not harm anything and could be used by other routers in area 
>as a "heads-up" that remote link is becoming overloaded.

I think this would be a good way forward as the OSPF Extended Attribute LSA 
will most likely be advertised for SR in OSPF Service Provider domains anyway. 
So, just advertising the area-scope for all use cases would seem to be the 
simplify this approach and get us past this discussion. In fact, the -00 
version of the draft had area-scope alone and I, regretfully, had suggested the 
OSPF RI as possible way to get support either scope.

Thanks,
Acee 

>
>
>>
>> 2) Sec 5.1, why is advertising of MAX-METRIC for the link to be 
>>overloaded a SHOULD and not a MUST? Isn't this mandatory to ensure 
>>backward compatibility? What if the router on which overload is 
>>signalled does not do MAX-METRIC but the implementation on the remote 
>>side end up doing MAX-METRIC. Would it not result in asymmetric metric 
>>in a un-intended manner? Please consider changing all SHOULD here to 
>>MUST to ensure backward compatibility.
>>
>> 3) Sec 5.4, can you please make similar change in language related to 
>>the RFC4203 reference as you've done in other parts in this version?
>>
>> Also I don't agree with the rationale you've given for not using LLS 
>>for the link-local signalling. Even if the hello processing were 
>>delegated to the LC, there are already a lot of protocol events which 
>>can happen via hello packets (which includes LLS) that require 
>>signalling update to the control plane OSPF main process. An 
>>implementation aspect such as this should hardly be a good reason to 
>>not use LLS for link-local signalling such as overload.
>
>+1 on the above.
>
>thanks,
>Peter
>
>>
>> Thanks,
>> Ketan
>>
>> -Original Message-
>> From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Shraddha Hegde
>> Sent: 03 July 2017 11:11
>> To: internet-dra...@ietf.org; i-d-annou...@ietf.org
>> Cc: ospf@ietf.org
>> Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-07.txt
>>
>> OSPF WG,
>>
>> New version of the ospf-link-overload draft is posted.
>> Editorial comments received so far have been addressed in this version.
>>
>> There was one comments to move the link-overload sub-TLV to LLS in 
>>hello messages.
>> Many implementations delegate the Hello processing to 
>>linecards/different deamons  Once adjacency is established. Hello 
>>messages are not sent to control plane  post adjacency establishment. 
>>The link-overload information typically needs to be processed  after 
>>adjacency establishment, it introduces unnecessary complexity in hello 
>>processing.
>> We had a discussion among authors on this and feel advertising 
>>link-overload sub-TLV  in the LSAs is the most appropriate mechanism.
>>
>>
>>
>> Rgds
>> Shraddha
>>
>> -Original Message-
>> From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of 
>>internet-dra...@ietf.org
>> Sent: Monday, July 3, 2017 11:01 AM
>> To: i-d-annou...@ietf.org
>> Cc: ospf@ietf.org
>> Subject: [OSPF] I-D Action: draft-ietf-ospf-link-overload-07.txt
>>
>>
>> A New Internet-Draft

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 <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]."
>>
>>
>&g

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 <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 

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

[Shraddha Hegde]

Acee,

>Additionally, there is the undesirable side effect of TE LSAs resulting in 
>inclusion in the TE topology for multiple >implementations


The testing results on 3 implementation shows that local/remote interface ID in 
TE Opaque LSA does not result into links getting included in TE topology. Pls 
refer introduction section of draft 
draft-hegde-isis-advertising-te-protocols-02.

RFC 4203 defines Link local scope TE-Opaque LSA to carry the interface-id and a 
remote ingress node would not be adding links to TE-Topology based on these 
link local LSAs simply because they would never see them.

Rgds
Shraddha

From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Friday, May 5, 2017 1:57 AM
To: OSPF WG List 
Subject: Re: [OSPF] WG Adoption Poll for "OSPF LLS Extensions for Local 
Interface ID Advertisement"

Speaking as a WG member:

I believe we should move forward with this simple mechanism for OSPFv2 
neighbors to learn each other’s interface ID. Both IS-IS and, more importantly, 
OSPFv3 learn the interface ID via their respective hello mechanisms. Just 
because one implementation has repurposed the Generalized MPL (GMPL) extensions 
described in RFC 4302 for interface ID learning is not a reason to preclude 
using the more generally accepted IGP Hello packet learning. Additionally, 
there is the undesirable side effect of TE LSAs resulting in inclusion in the 
TE topology for multiple implementations.

Finally, when the right technical direction is clear and there is rough 
consensus, the OSPF WG MUST NOT be obstructed.

Thanks,
Acee

From: Acee Lindem >
Date: Thursday, May 4, 2017 at 2:45 PM
To: OSPF WG List >
Subject: WG Adoption Poll for "OSPF LLS Extensions for Local Interface ID 
Advertisement"


This draft was presented in Chicago and there was acknowledgment that a 
solution was needed. The authors have asked for WG adoption and we are now 
doing a WG adoption poll. Please indicate your support or objection by May 
20th, 2017.

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

Re: [OSPF] draft-ietf-ospf-link-overload-06 - DR migration

[Shraddha Hegde]

Yes. You are right.

This is a problem specific to BDR taking over the role of DR.
The problem you describe has been around for a while and I have seen people 
using
decent workarounds without requiring protocol changes to solve this problem.

Rgds
Shraddha

From: Alexander Okonnikov [mailto:alexander.okonni...@gmail.com]
Sent: Monday, April 24, 2017 3:33 PM
To: Shraddha Hegde <shrad...@juniper.net>; 
draft-ietf-ospf-link-overl...@ietf.org; ospf@ietf.org
Subject: Re: draft-ietf-ospf-link-overload-06 - DR migration


Hi Shraddha,



For planned link maintenance there still could be traffic disruption. Even if 
router with overloaded link is detached from broadcast link, the latter still 
could be used by other routers on this one. If router with overloaded link was 
DR, traffic between other routers on broadcast link could be disrupted. Am I 
correct?

24.04.2017 12:55, Shraddha Hegde пишет:
Hi Alexander,

The objective of this draft is to re-route the traffic from the link that is 
expected to undergo maintenance
And the case of broadcast links  is explained in sec 5.2 which achieves the 
objective.

The case you described may be relevant for unplanned link-down events which is 
outside the scope of this draft.

Thanks
Shraddha


From: Alexander Okonnikov [mailto:alexander.okonni...@gmail.com]
Sent: Thursday, April 20, 2017 6:50 PM
To: 
draft-ietf-ospf-link-overl...@ietf.org<mailto:draft-ietf-ospf-link-overl...@ietf.org>;
 ospf@ietf.org<mailto:ospf@ietf.org>
Subject: draft-ietf-ospf-link-overload-06 - DR migration

Hi authors,

In case when the node that has the link to be overloaded is DR (for
broadcast/NBMA link case), taking this link out of service could be
disruptive. What if to modify procedure in such manner that when BDR
receives Link-Overload-sub-TLV from DR, it generates Network LSA in
advance, before taking DR role. The node with overloading link then
waits some time (for example, 3 secs) and changes its interface priority
to 0.

Thank you.


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

Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

[Shraddha Hegde]

Acee,

I am OK with changing the wording as you suggested. Will do it in next revision.

Rgds
Shraddha

-Original Message-
From: Acee Lindem (acee) [mailto:a...@cisco.com] 
Sent: Friday, April 21, 2017 7:35 PM
To: Shraddha Hegde <shrad...@juniper.net>; Acee Lindem <acee.lin...@gmail.com>
Cc: ospf@ietf.org
Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt



On 4/21/17, 6:37 AM, "Shraddha Hegde" <shrad...@juniper.net> wrote:

>Acee,
>
>
>> I don’t see any need to reference RFC 4203 since the Sub-TLV is 
>>sufficiently defined here. This is completely orthogonal to the 
>>definition in this draft.
>
>I do not agree with this point. The sub-TLV, local/remote interface id 
>requires the  remote interface-id to be filled and the draft refers to 
>an existing standard on getting this remote interface id. This is the 
>standard mechanism we follow in every draft.

I think we’re back to the circular argument with respect to the gratuitous 
repurposing of TE LSAs standardized under to satisfy GMPLS requirements for 
every purpose. Even in support of your position, the blanket statement is not 
germane to the draft. I might be ok with “One mechanism to learn the remote-id 
is described in ….” However, it appears now that we have broached the subject 
of WG last call, there is much discussion on the draft. 

Thanks,
Acee 

>
>Rgds
>Shraddha
>
>-Original Message-
>From: Acee Lindem (acee) [mailto:a...@cisco.com]
>Sent: Thursday, April 20, 2017 7:07 PM
>To: Shraddha Hegde <shrad...@juniper.net>; Acee Lindem 
><acee.lin...@gmail.com>
>Cc: ospf@ietf.org
>Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt
>
>Hi Shraddha,
>
>On 4/20/17, 12:46 AM, "Shraddha Hegde" <shrad...@juniper.net> wrote:
>
>>Hi Acee,
>>
>>The draft does not mandate use of RFC 4203. There are no MUST 
>>statements associated with the recommendation.
>
>I don’t see any need to reference RFC 4203 since the Sub-TLV is 
>sufficiently defined here. This is completely orthogonal to the 
>definition in this draft.
>>
>>
>>RFC 4203 is a standard and has been around for a while. I do not 
>>understand why there is concern being raised over Referencing an RFC 
>>which has been a standard and deployed in the field for many years.
>>
>>https://www.ietf.org/id/draft-ppsenak-ospf-lls-interface-id-00.txt is 
>>still an independent draft and it does not make sense to refer this 
>>draft in draft-ietf-ospf-link-overload-06 which is ready for WG last 
>>call.
>
>I wasn’t suggesting to reference either document.
>
>Thanks,
>Acee
>
>
>>
>>Rgds
>>Shraddha
>>
>>-Original Message-
>>From: Acee Lindem (acee) [mailto:a...@cisco.com]
>>Sent: Thursday, April 20, 2017 4:02 AM
>>To: Acee Lindem <acee.lin...@gmail.com>; Shraddha Hegde 
>><shrad...@juniper.net>
>>Cc: ospf@ietf.org
>>Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt
>>
>>Hi Shraddha,
>>
>>The only non-editorial comment that I have is that the draft 
>>references RFC 4203 as the way to learn the remote interface ID on an 
>>unnumbered link 
>>(https://www.ietf.org/id/draft-ppsenak-ospf-lls-interface-id-00.txt).
>>As you know, this is a very controversial topic with some of us 
>>wanting this to be in the hello packets consistent with OSPFv3 and 
>>IS-IS as opposed to using a link-scoped TE Opaque LSA as suggested in 
>>the OSPF GMPLS Extensions RFC 
>>(https://www.rfc-editor.org/rfc/rfc4203.txt). I would suggest removing the 
>>reference.
>>
>>Thanks,
>>Acee
>>
>>
>>On 4/19/17, 9:11 AM, "Acee Lindem" <acee.lin...@gmail.com> wrote:
>>
>>>Hi Shraddha,
>>>
>>>I think this version addresses all my comments. I will do a detailed 
>>>review this week and, most likely, start the WG last call. I 
>>>encourage other WG members to do the same.
>>>
>>>Thanks,
>>>Acee
>>>> On Apr 19, 2017, at 9:08 AM, Shraddha Hegde <shrad...@juniper.net>
>>>>wrote:
>>>> 
>>>> Hi Acee,
>>>> 
>>>> New version draft-ietf-ospf-link-overload-06 is posted where the
>>>>remote-ipv4 addr is moved to a new sub-TLV.
>>>> Pls review.
>>>> 
>>>> The authors of the draft believe that draft has undergone multiple 
>>>>revisions/reviews and is ready for WG last call.
>>>> 
>>>> Rgds
>>>> Shraddha
>>>> 
>>>> 
>>>> 

Re: [OSPF] draft-ietf-ospf-link-overload-06 - DR migration

[Shraddha Hegde]

Hi Alexander,

The objective of this draft is to re-route the traffic from the link that is 
expected to undergo maintenance
And the case of broadcast links  is explained in sec 5.2 which achieves the 
objective.

The case you described may be relevant for unplanned link-down events which is 
outside the scope of this draft.

Thanks
Shraddha


From: Alexander Okonnikov [mailto:alexander.okonni...@gmail.com]
Sent: Thursday, April 20, 2017 6:50 PM
To: draft-ietf-ospf-link-overl...@ietf.org; ospf@ietf.org
Subject: draft-ietf-ospf-link-overload-06 - DR migration

Hi authors,

In case when the node that has the link to be overloaded is DR (for
broadcast/NBMA link case), taking this link out of service could be
disruptive. What if to modify procedure in such manner that when BDR
receives Link-Overload-sub-TLV from DR, it generates Network LSA in
advance, before taking DR role. The node with overloading link then
waits some time (for example, 3 secs) and changes its interface priority
to 0.

Thank you.

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

Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

[Shraddha Hegde]

Hi Peter,

Thanks for the detailed review. Pls see inline..

-Original Message-
From: Peter Psenak [mailto:ppse...@cisco.com] 
Sent: Friday, April 21, 2017 1:38 PM
To: Shraddha Hegde <shrad...@juniper.net>; Acee Lindem (acee) <a...@cisco.com>
Cc: ospf@ietf.org
Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

Hi Shraddha,

please find my comments below:

The draft defines two mechanisms:

a) signaling the link overload to the neighbor. The purpose is to advertise the 
link with max-metric from both directions.

b) flooding the Link-Overload sub-TLV inside the area. The purpose is to let 
"LSP ingress routers/controllers can learn of the impending maintenance 
activity"

1. Why do we need two mechanisms? Why is (b) needed, given that (a) results in 
link being advertised with max-metric in both directions?

How is treatement of remote link having max-metric different to the treatment 
of a link that has the Link-Overload sub-TLV? I would understand the difference 
if you say that the link having the Link-Overload sub-TLV must not be used 
during SPF, but nothing like that is mentioned in the draft and I understand 
why.

Is (b) needed to cover the case, where the signaling defined in (a) is not 
understood by the neighbor on the other side of the link? If yes, please state 
it in the draft.
 Metric alone cannot be used as an indication for impending 
maintenance activity. When other nodes like ingress/controller need to 
understand the impending maintenance activity, area level advertisement would 
be needed. Application specific to this is described in sec 7.2

2. For the signaling defined in (a)-  using the Router Information LSA for 
signaling something to the direct neighbor is a very dirty hack. As the name of 
the LSA says, it has been defined to signal capability of the node, which has 
nothing to do with what you are trying to use it for. We have to stop polluting 
the protocol with such hacks. RFC5613 defines a Link-Local Signaling mechanism 
for OSPF and that is the one we should use for siganling between neighbors.
  LLS is a good mechanism to use for signaling link level information 
that are useful before the adjacency is established. Section 2 RFC 5613  states 
that the LLS is not expected to be used for use-cases which cause routing 
changes. Link-overload does result into routing changes and is best handled 
using link local scope LSAs.

thanks,
Peter



On 19/04/17 15:08 , Shraddha Hegde wrote:
> Hi Acee,
>
> New version draft-ietf-ospf-link-overload-06 is posted where the remote-ipv4 
> addr is moved to a new sub-TLV.
> Pls review.
>
> The authors of the draft believe that draft has undergone multiple 
> revisions/reviews and is ready for WG last call.
>
> Rgds
> Shraddha
>
>
> -Original Message-
> From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Acee Lindem 
> (acee)
> Sent: Saturday, March 18, 2017 2:28 AM
> Cc: ospf@ietf.org
> Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt
>
> Hi Shraddha, et al,
>
> With respect to section 4.1, I agree that matching link endpoints in
> OSPFv2 requires more information. However, this is a general problem 
> and the remote address should be a separate OSPFv2 Link Attribute LSA 
> TLV rather than overloading the link overload TLV ;^)
>
> Thanks,
> Acee
>
> On 2/23/17, 11:18 AM, "OSPF on behalf of internet-dra...@ietf.org"
> <ospf-boun...@ietf.org on behalf of internet-dra...@ietf.org> wrote:
>
>>
>> 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 Link Overload
>> Authors : Shraddha Hegde
>>   Pushpasis Sarkar
>>   Hannes Gredler
>>   Mohan Nanduri
>>   Luay Jalil
>>  Filename: draft-ietf-ospf-link-overload-05.txt
>>  Pages   : 13
>>  Date: 2017-02-23
>>
>> Abstract:
>>When a link is being prepared to be taken out of service, the traffic
>>needs to be diverted from both ends of the link.  Increasing the
>>metric to the highest metric on one side of the link is not
>>sufficient to divert the traffic flowing in the other direction.
>>
>>It is useful for routers in an OSPFv2 or OSPFv3 routing domain to be
>>able to advertise a link being in an overload state to indicate
>>impending maintenance activity on the link.  This information can be
>>used by the network devices to re-route the traffic effectively.
>>
>>This document describes the protocol extensions to di

Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

[Shraddha Hegde]

Acee,


> I don’t see any need to reference RFC 4203 since the Sub-TLV is sufficiently 
> defined here. This is completely orthogonal to the definition in this draft.

I do not agree with this point. The sub-TLV, local/remote interface id requires 
the  remote interface-id to be filled and the draft refers to an existing 
standard on getting this remote interface id. This is the standard mechanism we 
follow in every draft.

Rgds
Shraddha

-Original Message-
From: Acee Lindem (acee) [mailto:a...@cisco.com] 
Sent: Thursday, April 20, 2017 7:07 PM
To: Shraddha Hegde <shrad...@juniper.net>; Acee Lindem <acee.lin...@gmail.com>
Cc: ospf@ietf.org
Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

Hi Shraddha, 

On 4/20/17, 12:46 AM, "Shraddha Hegde" <shrad...@juniper.net> wrote:

>Hi Acee,
>
>The draft does not mandate use of RFC 4203. There are no MUST 
>statements associated with the recommendation.

I don’t see any need to reference RFC 4203 since the Sub-TLV is sufficiently 
defined here. This is completely orthogonal to the definition in this draft. 
>
>
>RFC 4203 is a standard and has been around for a while. I do not 
>understand why there is concern being raised over Referencing an RFC 
>which has been a standard and deployed in the field for many years.
>
>https://www.ietf.org/id/draft-ppsenak-ospf-lls-interface-id-00.txt is 
>still an independent draft and it does not make sense to refer this 
>draft in draft-ietf-ospf-link-overload-06 which is ready for WG last call.

I wasn’t suggesting to reference either document.

Thanks,
Acee


>
>Rgds
>Shraddha
>
>-Original Message-
>From: Acee Lindem (acee) [mailto:a...@cisco.com]
>Sent: Thursday, April 20, 2017 4:02 AM
>To: Acee Lindem <acee.lin...@gmail.com>; Shraddha Hegde 
><shrad...@juniper.net>
>Cc: ospf@ietf.org
>Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt
>
>Hi Shraddha,
>
>The only non-editorial comment that I have is that the draft references 
>RFC 4203 as the way to learn the remote interface ID on an unnumbered 
>link 
>(https://www.ietf.org/id/draft-ppsenak-ospf-lls-interface-id-00.txt). 
>As you know, this is a very controversial topic with some of us wanting 
>this to be in the hello packets consistent with OSPFv3 and IS-IS as 
>opposed to using a link-scoped TE Opaque LSA as suggested in the OSPF 
>GMPLS Extensions RFC (https://www.rfc-editor.org/rfc/rfc4203.txt). I 
>would suggest removing the reference.
>
>Thanks,
>Acee
>
>
>On 4/19/17, 9:11 AM, "Acee Lindem" <acee.lin...@gmail.com> wrote:
>
>>Hi Shraddha,
>>
>>I think this version addresses all my comments. I will do a detailed 
>>review this week and, most likely, start the WG last call. I encourage 
>>other WG members to do the same.
>>
>>Thanks,
>>Acee
>>> On Apr 19, 2017, at 9:08 AM, Shraddha Hegde <shrad...@juniper.net>
>>>wrote:
>>> 
>>> Hi Acee,
>>> 
>>> New version draft-ietf-ospf-link-overload-06 is posted where the
>>>remote-ipv4 addr is moved to a new sub-TLV.
>>> Pls review.
>>> 
>>> The authors of the draft believe that draft has undergone multiple 
>>>revisions/reviews and is ready for WG last call.
>>> 
>>> Rgds
>>> Shraddha
>>> 
>>> 
>>> -Original Message-
>>> From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Acee Lindem
>>>(acee)
>>> Sent: Saturday, March 18, 2017 2:28 AM
>>> Cc: ospf@ietf.org
>>> Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt
>>> 
>>> Hi Shraddha, et al,
>>> 
>>> With respect to section 4.1, I agree that matching link endpoints in
>>> OSPFv2 requires more information. However, this is a general problem 
>>>and the remote address should be a separate OSPFv2 Link Attribute LSA 
>>>TLV rather than overloading the link overload TLV ;^)
>>> 
>>> Thanks,
>>> Acee
>>> 
>>> On 2/23/17, 11:18 AM, "OSPF on behalf of internet-dra...@ietf.org"
>>> <ospf-boun...@ietf.org on behalf of internet-dra...@ietf.org> wrote:
>>> 
>>>> 
>>>> 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 Link Overload
>>>>   Authors : Shraddha Hegde
>>>> Pushpasis Sarkar
>>>> Hannes Gredl

Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

[Shraddha Hegde]

Ketan,

OSPF link overload has relevance for TE based applications as well as non-TE 
applications.
So what's the problem in referring a  well-defined mechanism of getting the 
interface-ids?

Can you explain why you are so concerned with referencing a standard RFC 
 which is out there and deployed for so many years?

Rgds
Shraddha

-Original Message-
From: Ketan Talaulikar Talaulikar (ketant) [mailto:ket...@cisco.com] 
Sent: Thursday, April 20, 2017 12:31 PM
To: Shraddha Hegde <shrad...@juniper.net>; Acee Lindem (acee) <a...@cisco.com>; 
Acee Lindem <acee.lin...@gmail.com>
Cc: ospf@ietf.org
Subject: RE: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

Shraddha,

There are also other applications that your draft lists which are TE 
independent and hence the case for not referring to a specific way for 
signalling interface-ids which is TE specific.

I don't understand why you would be so reluctant to remove a reference which is 
not even central to the topic of the draft?

Thanks,
Ketan

-Original Message-----
From: Shraddha Hegde [mailto:shrad...@juniper.net]
Sent: 20 April 2017 12:11
To: Ketan Talaulikar Talaulikar (ketant) <ket...@cisco.com>; Acee Lindem (acee) 
<a...@cisco.com>; Acee Lindem <acee.lin...@gmail.com>
Cc: ospf@ietf.org
Subject: RE: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

Ketan,

We do have traffic engineering applications that require link-overload 
functionality.
Pls refer section 7.2.


Rgds
Shraddha

-Original Message-
From: Ketan Talaulikar Talaulikar (ketant) [mailto:ket...@cisco.com]
Sent: Thursday, April 20, 2017 10:46 AM
To: Shraddha Hegde <shrad...@juniper.net>; Acee Lindem (acee) <a...@cisco.com>; 
Acee Lindem <acee.lin...@gmail.com>
Cc: ospf@ietf.org
Subject: RE: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

Hi Shraddha,

The RFC 4203 describes the usage and application of TE LSAs for GMPLS/TE use 
cases. The OSPF link overload RFC is independent of TE and hence it is a 
concern that an implementation needs to use TE LSAs with link-local scope just 
for signalling the interface-ids for unnumbered links.

Not asking for reference to draft-ppsenak-ospf-lls-interface-id. Just asking to 
remove reference to RFC 4203 since the mechanism for signalling interface-ids 
is orthogonal to the subject of the draft which is generic to OSPF and 
independent of any TE/GMPLS use-case(s).

Thanks,
Ketan

-Original Message-
From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Shraddha Hegde
Sent: 20 April 2017 10:17
To: Acee Lindem (acee) <a...@cisco.com>; Acee Lindem <acee.lin...@gmail.com>
Cc: ospf@ietf.org
Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

Hi Acee,

The draft does not mandate use of RFC 4203. There are no MUST statements 
associated with the recommendation.


RFC 4203 is a standard and has been around for a while. I do not understand why 
there is concern being raised over Referencing an RFC which has been a standard 
and deployed in the field for many years.

https://www.ietf.org/id/draft-ppsenak-ospf-lls-interface-id-00.txt is still an 
independent draft and it does not make sense to refer this draft in 
draft-ietf-ospf-link-overload-06 which is ready for WG last call.

Rgds
Shraddha

-Original Message-
From: Acee Lindem (acee) [mailto:a...@cisco.com]
Sent: Thursday, April 20, 2017 4:02 AM
To: Acee Lindem <acee.lin...@gmail.com>; Shraddha Hegde <shrad...@juniper.net>
Cc: ospf@ietf.org
Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

Hi Shraddha, 

The only non-editorial comment that I have is that the draft references RFC 
4203 as the way to learn the remote interface ID on an unnumbered link 
(https://www.ietf.org/id/draft-ppsenak-ospf-lls-interface-id-00.txt). As you 
know, this is a very controversial topic with some of us wanting this to be in 
the hello packets consistent with OSPFv3 and IS-IS as opposed to using a 
link-scoped TE Opaque LSA as suggested in the OSPF GMPLS Extensions RFC 
(https://www.rfc-editor.org/rfc/rfc4203.txt). I would suggest removing the 
reference.

Thanks,
Acee 


On 4/19/17, 9:11 AM, "Acee Lindem" <acee.lin...@gmail.com> wrote:

>Hi Shraddha,
>
>I think this version addresses all my comments. I will do a detailed 
>review this week and, most likely, start the WG last call. I encourage 
>other WG members to do the same.
>
>Thanks,
>Acee
>> On Apr 19, 2017, at 9:08 AM, Shraddha Hegde <shrad...@juniper.net>
>>wrote:
>> 
>> Hi Acee,
>> 
>> New version draft-ietf-ospf-link-overload-06 is posted where the
>>remote-ipv4 addr is moved to a new sub-TLV.
>> Pls review.
>> 
>> The authors of the draft believe that draft has undergone multiple 
>>revisions/reviews and is ready for WG last call.
>> 
>> Rgds
>> Shraddha
>> 
>>

Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

[Shraddha Hegde]

Ketan,

Pls see inline..

-Original Message-
From: Ketan Talaulikar Talaulikar (ketant) [mailto:ket...@cisco.com] 
Sent: Thursday, April 20, 2017 10:06 AM
To: Acee Lindem (acee) <a...@cisco.com>; Acee Lindem <acee.lin...@gmail.com>; 
Shraddha Hegde <shrad...@juniper.net>
Cc: ospf@ietf.org
Subject: RE: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

Hi Shraddha/Authors,

I would like to share the following comments and feedback on this draft.

1) I did not understand the motivation for the use of link-local scoped RI LSA 
for the link-overload signalling when we have the ability to do so via the TLV 
in the area-scoped Extended Link Attribute LSA. I think it may be a good idea 
(an optimization) to use the TLV in an area-scoped RI LSA to indicate link 
overload for all the router links instead of signalling individually for all 
its links in the Extended Link Attribute LSA - but this is not what the draft 
proposes. So could you explain the reason for the link-local scoped RI LSA TLV 
usage?

  There are many application which may not need an area wide  
indication and a link level indication would be sufficient.
Pls refer section for the applications.

2) The Link Overload TLV is defined with a remote IP address field now. This 
does not seem like a good idea. We have had traditionally certain TLVs in OSPF 
LSAs that describe links i.e. Remote Interface IP address and Link Local/Remote 
Identifiers and cover both numbered and unnumbered links. The 
draft-ppsenak-ospf-te-link-attr-reuse proposed to specifically re-use these 
TLVs so that links may be described correctly in the new extended link 
attribute LSA for generic use-cases such as the Link Overload TLV here. It 
seems rather odd that we are now introducing these fields like remote address 
in individual TLVs and proposing *hacky* encoding of link-ids in the remote IP 
address field for unnumbered links instead of re-using existing well defined 
generic TLVs.
 Pls refer the latest draft draft-ietf-ospf-link-overload-06. New 
sub-tlvs defined for generic use.

3) I am not sure why the reference to use of OSPFv3 extended LSAs for link 
level area-scoped signalling was removed from this version of the draft.
Since OSPFv3 entended LSA hasn't progressed, the WG has decided to 
progress other draft and defer any dependency to a separate document.

4) I also have an objection to the reference of RFC4203 for the procedures for 
obtaining the remote interface-id since that mechanism is outside the scope of 
what this draft is trying to standardize. Specifically, I have a problem since 
it gives an impression that the mechanism described in RFC4203 is *the* 
procedure for obtaining the remote interface-id since that specification is 
very specific to the GMPLS/TE use-cases and it is not a generic/based OSPF 
protocol mechanism. We have proposed an alternate mechanism for doing this in a 
manner consistent with OSPFv3 and ISIS in draft-ppsenak-ospf-lls-interface-id. 
We can debate the need for this mechanism in a separate thread, but the 
reference to RFC4203 does not seem necessary here to me.
This is discussed in other threads.
Thanks,
Ketan

-Original Message-
From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: 20 April 2017 04:02
To: Acee Lindem <acee.lin...@gmail.com>; Shraddha Hegde <shrad...@juniper.net>
Cc: ospf@ietf.org
Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

Hi Shraddha, 

The only non-editorial comment that I have is that the draft references RFC 
4203 as the way to learn the remote interface ID on an unnumbered link 
(https://www.ietf.org/id/draft-ppsenak-ospf-lls-interface-id-00.txt). As you 
know, this is a very controversial topic with some of us wanting this to be in 
the hello packets consistent with OSPFv3 and IS-IS as opposed to using a 
link-scoped TE Opaque LSA as suggested in the OSPF GMPLS Extensions RFC 
(https://www.rfc-editor.org/rfc/rfc4203.txt). I would suggest removing the 
reference.

Thanks,
Acee 


On 4/19/17, 9:11 AM, "Acee Lindem" <acee.lin...@gmail.com> wrote:

>Hi Shraddha,
>
>I think this version addresses all my comments. I will do a detailed 
>review this week and, most likely, start the WG last call. I encourage 
>other WG members to do the same.
>
>Thanks,
>Acee
>> On Apr 19, 2017, at 9:08 AM, Shraddha Hegde <shrad...@juniper.net>
>>wrote:
>> 
>> Hi Acee,
>> 
>> New version draft-ietf-ospf-link-overload-06 is posted where the
>>remote-ipv4 addr is moved to a new sub-TLV.
>> Pls review.
>> 
>> The authors of the draft believe that draft has undergone multiple 
>>revisions/reviews and is ready for WG last call.
>> 
>> Rgds
>> Shraddha
>> 
>> 
>> -Original Message-
>> From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Acee Lindem
>>(acee)
&g

Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

[Shraddha Hegde]

Ketan,

We do have traffic engineering applications that require link-overload 
functionality.
Pls refer section 7.2.


Rgds
Shraddha

-Original Message-
From: Ketan Talaulikar Talaulikar (ketant) [mailto:ket...@cisco.com] 
Sent: Thursday, April 20, 2017 10:46 AM
To: Shraddha Hegde <shrad...@juniper.net>; Acee Lindem (acee) <a...@cisco.com>; 
Acee Lindem <acee.lin...@gmail.com>
Cc: ospf@ietf.org
Subject: RE: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

Hi Shraddha,

The RFC 4203 describes the usage and application of TE LSAs for GMPLS/TE use 
cases. The OSPF link overload RFC is independent of TE and hence it is a 
concern that an implementation needs to use TE LSAs with link-local scope just 
for signalling the interface-ids for unnumbered links.

Not asking for reference to draft-ppsenak-ospf-lls-interface-id. Just asking to 
remove reference to RFC 4203 since the mechanism for signalling interface-ids 
is orthogonal to the subject of the draft which is generic to OSPF and 
independent of any TE/GMPLS use-case(s).

Thanks,
Ketan

-Original Message-
From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Shraddha Hegde
Sent: 20 April 2017 10:17
To: Acee Lindem (acee) <a...@cisco.com>; Acee Lindem <acee.lin...@gmail.com>
Cc: ospf@ietf.org
Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

Hi Acee,

The draft does not mandate use of RFC 4203. There are no MUST statements 
associated with the recommendation.


RFC 4203 is a standard and has been around for a while. I do not understand why 
there is concern being raised over Referencing an RFC which has been a standard 
and deployed in the field for many years.

https://www.ietf.org/id/draft-ppsenak-ospf-lls-interface-id-00.txt is still an 
independent draft and it does not make sense to refer this draft in 
draft-ietf-ospf-link-overload-06 which is ready for WG last call.

Rgds
Shraddha

-Original Message-
From: Acee Lindem (acee) [mailto:a...@cisco.com]
Sent: Thursday, April 20, 2017 4:02 AM
To: Acee Lindem <acee.lin...@gmail.com>; Shraddha Hegde <shrad...@juniper.net>
Cc: ospf@ietf.org
Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

Hi Shraddha, 

The only non-editorial comment that I have is that the draft references RFC 
4203 as the way to learn the remote interface ID on an unnumbered link 
(https://www.ietf.org/id/draft-ppsenak-ospf-lls-interface-id-00.txt). As you 
know, this is a very controversial topic with some of us wanting this to be in 
the hello packets consistent with OSPFv3 and IS-IS as opposed to using a 
link-scoped TE Opaque LSA as suggested in the OSPF GMPLS Extensions RFC 
(https://www.rfc-editor.org/rfc/rfc4203.txt). I would suggest removing the 
reference.

Thanks,
Acee 


On 4/19/17, 9:11 AM, "Acee Lindem" <acee.lin...@gmail.com> wrote:

>Hi Shraddha,
>
>I think this version addresses all my comments. I will do a detailed 
>review this week and, most likely, start the WG last call. I encourage 
>other WG members to do the same.
>
>Thanks,
>Acee
>> On Apr 19, 2017, at 9:08 AM, Shraddha Hegde <shrad...@juniper.net>
>>wrote:
>> 
>> Hi Acee,
>> 
>> New version draft-ietf-ospf-link-overload-06 is posted where the
>>remote-ipv4 addr is moved to a new sub-TLV.
>> Pls review.
>> 
>> The authors of the draft believe that draft has undergone multiple 
>>revisions/reviews and is ready for WG last call.
>> 
>> Rgds
>> Shraddha
>> 
>> 
>> -Original Message-
>> From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Acee Lindem
>>(acee)
>> Sent: Saturday, March 18, 2017 2:28 AM
>> Cc: ospf@ietf.org
>> Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt
>> 
>> Hi Shraddha, et al,
>> 
>> With respect to section 4.1, I agree that matching link endpoints in
>> OSPFv2 requires more information. However, this is a general problem 
>>and the remote address should be a separate OSPFv2 Link Attribute LSA 
>>TLV rather than overloading the link overload TLV ;^)
>> 
>> Thanks,
>> Acee
>> 
>> On 2/23/17, 11:18 AM, "OSPF on behalf of internet-dra...@ietf.org"
>> <ospf-boun...@ietf.org on behalf of internet-dra...@ietf.org> wrote:
>> 
>>> 
>>> 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 Link Overload
>>>   Authors : Shraddha Hegde
>>> Pushpasis Sarkar
>>> Hannes Gredler
>>> Mohan Nanduri
>>>

Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

[Shraddha Hegde]

Hi Acee,

The draft does not mandate use of RFC 4203. There are no MUST statements 
associated with the recommendation.


RFC 4203 is a standard and has been around for a while. I do not understand why 
there is concern being raised over
Referencing an RFC which has been a standard and deployed in the field for many 
years.

https://www.ietf.org/id/draft-ppsenak-ospf-lls-interface-id-00.txt is still an 
independent draft and it does not make sense to refer this draft
in draft-ietf-ospf-link-overload-06 which is ready for WG last call.

Rgds
Shraddha

-Original Message-
From: Acee Lindem (acee) [mailto:a...@cisco.com] 
Sent: Thursday, April 20, 2017 4:02 AM
To: Acee Lindem <acee.lin...@gmail.com>; Shraddha Hegde <shrad...@juniper.net>
Cc: ospf@ietf.org
Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

Hi Shraddha, 

The only non-editorial comment that I have is that the draft references RFC 
4203 as the way to learn the remote interface ID on an unnumbered link 
(https://www.ietf.org/id/draft-ppsenak-ospf-lls-interface-id-00.txt). As you 
know, this is a very controversial topic with some of us wanting this to be in 
the hello packets consistent with OSPFv3 and IS-IS as opposed to using a 
link-scoped TE Opaque LSA as suggested in the OSPF GMPLS Extensions RFC 
(https://www.rfc-editor.org/rfc/rfc4203.txt). I would suggest removing the 
reference.

Thanks,
Acee 


On 4/19/17, 9:11 AM, "Acee Lindem" <acee.lin...@gmail.com> wrote:

>Hi Shraddha,
>
>I think this version addresses all my comments. I will do a detailed 
>review this week and, most likely, start the WG last call. I encourage 
>other WG members to do the same.
>
>Thanks,
>Acee
>> On Apr 19, 2017, at 9:08 AM, Shraddha Hegde <shrad...@juniper.net>
>>wrote:
>> 
>> Hi Acee,
>> 
>> New version draft-ietf-ospf-link-overload-06 is posted where the
>>remote-ipv4 addr is moved to a new sub-TLV.
>> Pls review.
>> 
>> The authors of the draft believe that draft has undergone multiple 
>>revisions/reviews and is ready for WG last call.
>> 
>> Rgds
>> Shraddha
>> 
>> 
>> -Original Message-
>> From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Acee Lindem
>>(acee)
>> Sent: Saturday, March 18, 2017 2:28 AM
>> Cc: ospf@ietf.org
>> Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt
>> 
>> Hi Shraddha, et al,
>> 
>> With respect to section 4.1, I agree that matching link endpoints in
>> OSPFv2 requires more information. However, this is a general problem 
>>and the remote address should be a separate OSPFv2 Link Attribute LSA 
>>TLV rather than overloading the link overload TLV ;^)
>> 
>> Thanks,
>> Acee
>> 
>> On 2/23/17, 11:18 AM, "OSPF on behalf of internet-dra...@ietf.org"
>> <ospf-boun...@ietf.org on behalf of internet-dra...@ietf.org> wrote:
>> 
>>> 
>>> 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 Link Overload
>>>   Authors : Shraddha Hegde
>>> Pushpasis Sarkar
>>> Hannes Gredler
>>> Mohan Nanduri
>>> Luay Jalil
>>> Filename: draft-ietf-ospf-link-overload-05.txt
>>> Pages   : 13
>>> Date: 2017-02-23
>>> 
>>> Abstract:
>>>  When a link is being prepared to be taken out of service, the 
>>> traffic  needs to be diverted from both ends of the link.  
>>> Increasing the  metric to the highest metric on one side of the link 
>>> is not  sufficient to divert the traffic flowing in the other direction.
>>> 
>>>  It is useful for routers in an OSPFv2 or OSPFv3 routing domain to 
>>> be  able to advertise a link being in an overload state to indicate  
>>> impending maintenance activity on the link.  This information can be  
>>> used by the network devices to re-route the traffic effectively.
>>> 
>>>  This document describes the protocol extensions to disseminate 
>>> link-  overload information in OSPFv2 and OSPFv3.
>>> 
>>> 
>>> 
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-ospf-link-overload/
>>> 
>>> There's also a htmlized version available at:
>>> https://tools.ietf.org/html/draft-ietf-ospf-link-overload-05
>>> 
>

Re: [OSPF] FW: New Version Notification for draft-ietf-ospf-link-overload-03.txt

[Shraddha Hegde]

Hi Karsten,

Pls see inline...

-Original Message-
From: Karsten Thomann [mailto:karsten_thom...@linfre.de] 
Sent: Sunday, February 19, 2017 10:51 PM
To: Shraddha Hegde <shrad...@juniper.net>
Cc: ospf@ietf.org
Subject: Re: [OSPF] FW: New Version Notification for 
draft-ietf-ospf-link-overload-03.txt

Shraddha,

thanks for your reply, please see inline.

Regards
Karsten

On Saturday, 18 February 2017 18:39:05 CET Shraddha Hegde wrote:
> Karsten,
> 
> Thank you very much for detailed review.
> Pls see inline..
> 
> Rgds
> Shraddha
> 
> -Original Message-
> From: Karsten Thomann [mailto:karsten_thom...@linfre.de]
> Sent: Thursday, February 16, 2017 1:31 AM
> To: ospf@ietf.org
> Cc: Shraddha Hegde <shrad...@juniper.net>
> Subject: Re: [OSPF] FW: New Version Notification for 
> draft-ietf-ospf-link-overload-03.txt
> 
> Hi Shraddha,
> 
> I have some typos and comments...
> 
> 3.1 [RFC7684] . (space before the point)
> 3.2 Section 4.The (two missing spaces)
> 3.2 ipv4 address.The (two missing spaces)
> 4.2 for OSPFv3.  or in (I think it should be a comma)
> 5 identified in by (would delete "in")
> 6 compatible.It is
> 6 applicable.  .
> 7.1 directions.The link
> 7.2 each link.The
> 7.2 capacity.  and
> 
>  Corrected all the above typos.
> Generally I would clean up the used version of some words as there are 
> many different versions like:
> Sub-TLV, sub-tlv, sub-TLV
>  modified to "sub-TLV ".
> 
> link-overload, Link overload, link overload  modified to 
> Link-Overload for the sub-TLV everywhere
> 
> ipv4, IP4, IPv4
>  modified to IPv4.
> 
> Reference to I-D.ietf-ospf-ospfv3-lsa-extend should be updated to 
> latest version.
>  This citation is going to be removed.
As it isn't removed, I think it will be removed in the 05 version
> 
> Is there a reason why the text for MAX-TE-METRIC wasn't repeated in 5.3?
>  P2MP mode not defined for TE in RFC 3630.
You're correct, but a real description for broadcast networks with more then 2 
routers are also not really descriibed, but I'm fine with the answer.
> 
> The section 7.1 isn't really clear, at least for me, as it sounds like 
> that the service provider is signaling something within the customers L2 
> circuit.
>  Added more description. Pls check if it looks better now.
I'm now able to understand the intention of the use case, but I think it's a 
bit far fetched to use it as a real example.
 This usecase actually came from a real deployment.

In my opinion where an ISP is providing L3 VPN's with CE-PE links with OSPF 
could use it to move traffic from that link in case of maintenance as the 
customer router would also shift the traffic and not only the PE router, how 
the interaction between OSPF and BGP is in that case should be outside the 
scope, but it should be nearer the real world use case.

Another use case where it would be usable without problems should be where the 
ISP is providing an ospf sham link (RFC4577).
It allows the isp to reroute the traffic from the pe undergoing maintenance for 
the customer in both directions, while only configuring it on one pe.

An additional example would be where a customer could remove the traffic from 
all spokes if the hub router (or hub router link) is undergoing maintenance, as 
it only requires the configuration on the hub and not all spokes.
 sure. All are useful usecases and I have added them to the draft.
> 
> Regards
> Karsten
> 
> Am Dienstag, 14. Februar 2017, 03:34:25 schrieb Shraddha Hegde:
> > Hi All,
> > 
> > New version of the ospf-link-overload draft is submitted and has 
> > below changes
> > 
> > > Area level link-overload sub-TLV reverted back to extended link 
> > > opaque LSA.
> > > minor editorial corrections.
> > 
> > Let me know if you have any comments.
> > 
> > Rgds
> > Shraddha
> > 
> > -Original Message-
> > From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
> > Sent: Monday, February 13, 2017 11:39 AM
> > To: Shraddha Hegde <shrad...@juniper.net>; Pushpasis Sarkar 
> > <pushpasis.i...@gmail.com>; Mohan Nanduri <mnand...@microsoft.com>; 
> > Hannes Gredler <han...@gredler.at>; Luay Jalil <luay.ja...@verizon.com> 
> > Subject:
> > New Version Notification for draft-ietf-ospf-link-overload-03.txt
> > 
> > 
> > A new version of I-D, draft-ietf-ospf-link-overload-03.txt
> > has been successfully submitted by Shraddha Hegde and posted to the 
> > IETF repository.
> > 
> > Name:   draft-ietf-ospf-link-overload
> > Revision:   03
> > Title:  OSPF Link Overload
> > Document date:  2017-02-12
> 

Re: [OSPF] FW: New Version Notification for draft-ietf-ospf-link-overload-03.txt

[Shraddha Hegde]

Karsten,

Thank you very much for detailed review.
Pls see inline..

Rgds
Shraddha

-Original Message-
From: Karsten Thomann [mailto:karsten_thom...@linfre.de] 
Sent: Thursday, February 16, 2017 1:31 AM
To: ospf@ietf.org
Cc: Shraddha Hegde <shrad...@juniper.net>
Subject: Re: [OSPF] FW: New Version Notification for 
draft-ietf-ospf-link-overload-03.txt

Hi Shraddha,

I have some typos and comments...

3.1 [RFC7684] . (space before the point)
3.2 Section 4.The (two missing spaces)
3.2 ipv4 address.The (two missing spaces)
4.2 for OSPFv3.  or in (I think it should be a comma)
5 identified in by (would delete "in")
6 compatible.It is
6 applicable.  .
7.1 directions.The link 
7.2 each link.The
7.2 capacity.  and 

 Corrected all the above typos.
Generally I would clean up the used version of some words as there are many 
different versions like:
Sub-TLV, sub-tlv, sub-TLV
 modified to "sub-TLV ".

link-overload, Link overload, link overload
 modified to Link-Overload for the sub-TLV everywhere

ipv4, IP4, IPv4
 modified to IPv4.

Reference to I-D.ietf-ospf-ospfv3-lsa-extend should be updated to latest 
version.
 This citation is going to be removed.

Is there a reason why the text for MAX-TE-METRIC wasn't repeated in 5.3?
 P2MP mode not defined for TE in RFC 3630.

The section 7.1 isn't really clear, at least for me, as it sounds like that 
the service provider is signaling something within the customers L2 circuit.
 Added more description. Pls check if it looks better now.

Regards
Karsten


Am Dienstag, 14. Februar 2017, 03:34:25 schrieb Shraddha Hegde:
> Hi All,
> 
> New version of the ospf-link-overload draft is submitted and has below
> changes
> > Area level link-overload sub-TLV reverted back to extended link opaque
> > LSA.
> > minor editorial corrections.
> 
> Let me know if you have any comments.
> 
> Rgds
> Shraddha
> 
> -Original Message-
> From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
> Sent: Monday, February 13, 2017 11:39 AM
> To: Shraddha Hegde <shrad...@juniper.net>; Pushpasis Sarkar
> <pushpasis.i...@gmail.com>; Mohan Nanduri <mnand...@microsoft.com>; Hannes
> Gredler <han...@gredler.at>; Luay Jalil <luay.ja...@verizon.com> Subject:
> New Version Notification for draft-ietf-ospf-link-overload-03.txt
> 
> 
> A new version of I-D, draft-ietf-ospf-link-overload-03.txt
> has been successfully submitted by Shraddha Hegde and posted to the IETF
> repository.
> 
> Name: draft-ietf-ospf-link-overload
> Revision: 03
> Title:OSPF Link Overload
> Document date:2017-02-12
> Group:ospf
> Pages:11
> URL:   
> https://www.ietf.org/internet-drafts/draft-ietf-ospf-link-overload-03.txt
> Status:
> https://datatracker.ietf.org/doc/draft-ietf-ospf-link-overload/ Htmlized:  
> https://tools.ietf.org/html/draft-ietf-ospf-link-overload-03 Diff: 
>  https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-link-overload-03
> 
> Abstract:
>When a link is being prepared to be taken out of service, the traffic
>needs to be diverted from both ends of the link.  Increasing the
>metric to the highest metric on one side of the link is not
>sufficient to divert the traffic flowing in the other direction.
> 
>It is useful for routers in an OSPFv2 or OSPFv3 routing domain to be
>able to advertise a link being in an overload state to indicate
>impending maintenance activity on the link.  This information can be
>used by the network devices to re-route the traffic effectively.
> 
>This document describes the protocol extensions to disseminate link
>overload information in OSPFv2 and OSPFv3.
> 
> 
> 
> 
> 
> 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.
> 
> The IETF Secretariat
> 
> ___
> 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] draft-ietf-ospf-link-overload-02

[Shraddha Hegde]

Acee/Abhay,


The draft-ietf-ospf-link-overload has been presented multiple times  in OSPF WG 
and is stable since last IETF.
Authors believe it is ready for WG last call and would like to  request the 
draft be moved further.

Rgds
Shraddha

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

Re: [OSPF] WG Adoption Poll for draft-ppsenak-ospf-te-link-attr-reuse

[Shraddha Hegde]

OSPF WG,


draft-ppsenak-ospf-te-link-attr-reuse  describes a problem statement that is 
relevant for non-RSVP applications that
need to look into the TE attributes. 
I do not support the adoption of this draft as the solution described in the 
draft has below problems.

1. The solution proposes to move/duplicate the TE attributes in multiple 
containers within OSPF.
 Having multiple places to hold the same attributes leads to complexity in 
terms of 
>  Having to look at both containers.
   >  Having to provide config interfaces for the operator to define which 
container to advertise the attributes and
   Operational complexity having to manage these configurations
   >  Inter-op issues due to inconsistency in implementations
   > Backward compatibility has to be maintained, so the looking-up 
multiple LSAs for the TE attributes does not go away
  By implementing draft-ppsenak-ospf-te-link-attr-reuse
   >  From experience, it is seen that older devices which cannot be 
upgraded, exist in the network for a very long time
Which means the TE attributes need to be advertised in both TE LSA 
and Extended LINK LSA forever.

2.  Section 5 of the draft describes " Advertisement of Application Specific 
Values" and provides example of SRLG values that are specific to applications.
  The existing SRLG definition is generic enough to solve the said problem 
described in the draft by assigning different SRLG values to a link
  corresponding to each application and having the application look for 
values that are specific to that application. 
   The extended TE metric  vales are specific to links and it is not clear 
in what scenario and use-case it would make sense to advertise
Per-application specific values for the attributes described in section 
5.
   Without clear use-case and scenarios, there is always a risk of 
producing implementations that are not inter-operable.

   

Rgds
Shraddha


-Original Message-
From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Abhay Roy
Sent: Wednesday, October 26, 2016 10:58 AM
To: ospf@ietf.org; draft-ppsenak-ospf-te-link-attr-re...@tools.ietf.org
Subject: [OSPF] WG Adoption Poll for draft-ppsenak-ospf-te-link-attr-reuse

Dear WG,

Authors of draft-ppsenak-ospf-te-link-attr-reuse would like to poll the WG for 
adoption of this document as a WG Draft. Please send your opinions / concerns.

This begins the two week WG adoption poll which will conclude on Nov 9th 2016.

Authors, we need your explicit response on this thread to capture your answer 
on if you are aware of any IPR related to this draft.

Regards,
-Abhay

___
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] New version of draft-ietf-ospf-link-overload-02

[Shraddha Hegde]

All,

New version of the draft "draft-ietf-ospf-link-overload-02" was posted before 
IETF-96
And was also presented at Berlin.
The latest changes include advertising the Link-overload sub-tlv in Link local 
scoped or
Area scoped RI-LSA based on application scenario.

Kindly review and provide inputs.

https://datatracker.ietf.org/doc/draft-ietf-ospf-link-overload/


Rgds
Shraddha


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

Re: [OSPF] OSPF WG Minutes

[Shraddha Hegde]

I guess the below statement needs correction

Abhay Roy: MRT draft has normative reference on link overload LSA
which is stuck at the moment.

Should be

Abhay Roy: MRT draft has normative reference on  "ospfv3 extended LSA"
which is stuck at the moment.

Abhay, can you confirm?

Rgds
Shraddha

-Original Message-
From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Monday, July 25, 2016 10:11 PM
To: OSPF WG List 
Subject: [OSPF] OSPF WG Minutes

Note that the OSPF WG minutes for IETF 96 have been posted. Please unicast me 
with any additions or correction.

https://www.ietf.org/proceedings/96/minutes/minutes-96-ospf

Thanks to Les Ginsberg for taking the minutes.

Thanks,
Acee 

___
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

Re: [OSPF] "OSPF Link Overhead" - draft-ietf-ospf-link-overload-01

[Shraddha Hegde]

Acee,

If I understood your comment correctly, you are proposing that there are 
usecases for "link overload" feature
Where only link local information flooding would suffice so that alternate 
should be provided in the document.
I agree with you, will update the document and resubmit soon.

Rgds
Shraddha

-Original Message-
From: Acee Lindem (acee) [mailto:a...@cisco.com] 
Sent: Monday, June 27, 2016 7:32 PM
To: Acee Lindem (acee) ; draft-ietf-ospf-link-overl...@ietf.org
Cc: OSPF WG List 
Subject: Re: [OSPF] "OSPF Link Overhead" - draft-ietf-ospf-link-overload-01

Speaking as WG co-chair:

I think we can move towards WG last call with this addition. Note that the 
document needs to be refreshed as it will expire soon.

Thanks,
Acee 

On 6/27/16, 10:00 AM, "OSPF on behalf of Acee Lindem (acee)"
 wrote:

>Speaking as WG member:
>
>One area of mild contention with this draft has been whether the 
>advertisement that the link is being taken out of service needs to be 
>advertised beyond the link endpoint router (which will take the 
>appropriate action of advertising the maximum link metric in the 
>reverse direction). We have gotten somewhat entangled into use case 
>discussions and whether or not this is really necessary.
>
>What I’d like to propose is that offer the alternative of advertising 
>the OSPF RI LSA with link-scope (fully supported by RFC 7770). This 
>way, the advertisement could be restricted to the local link in 
>situations where the knowledge doesn’t really need to go anywhere else. 
>Note that the current text doesn’t prevent this so this is merely a 
>matter of describing the use case.
>
>Thanks,
>Acee
>
>___
>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

Re: [OSPF] WG Adoption Call for "OSPF Stub Neighbors"

[Shraddha Hegde]

Hi,

I have a few concerns on the necessity of this draft.

1.  Necessity of protocol change
The draft proposes to add the default route as part of router LSA but it is not 
clear why this is required.
The draft in sec 5.2 vaguely talks about without clarifying the real issue

"We are introducing a new type of default route with a local behavior.
   The current use of default route as type 3 or as type 5 cannot solve
   some of the use cases and more specifically in the Data center
   topologies."

If the spoke nodes are connecting only to the HUB (which is what hub and spoke 
topology is)then there is no way spoke would be learning OSPF routes 
from other than the HUB. It doesn't look necessary to advertise default routes 
in route LSAs

2. The draft doesn't talk about the other possible hub and spoke topologies 
like hierarchical hub and spoke,
  Multiple interfaces connecting to one Hub, A group of spoke nodes 
connecting to hub etc.  There should be a section on topology
  Restrictions to identify what topologies this draft intends to support.

3.  The draft proposes to advertise router-capability for this feature but it 
is not clear how this information is used. 
   
4. The draft talks in-length about the normal LSA and modified LSA but it is 
not clear how to distinguish between the two.

5. The document uses first person language in many places which is not 
appropriate for an internet draft.

6. I am in agreement with Anton on the p2mp use case which is completely missed 
from the draft

IMHO, the draft needs more work before being adopted by WG.


Rgds
Shraddha



-Original Message-
From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Tuesday, January 26, 2016 10:09 PM
To: OSPF WG List 
Subject: [OSPF] WG Adoption Call for "OSPF Stub Neighbors"

This draft was has gone through some refinements after being presented in 
Hawaii and in Yokohama there was some support of this protocol extension.
Here is a URL for you convenience.

https://datatracker.ietf.org/doc/draft-raza-ospf-stub-neighbor/

Please indicate your support (or concerns) for adopting this as a WG Document. 
The WG Adoption call will end in 2 weeks.

Thanks,
Acee


___
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

Re: [OSPF] Alvaro's DISCUSS on OSPF Admin Tags

[Shraddha Hegde]

Ok.

Rgds
shraddha

From: Acee Lindem (acee) [mailto:a...@cisco.com]
Sent: Tuesday, November 17, 2015 6:07 PM
To: Shraddha Hegde <shrad...@juniper.net>; Alia Atlas <akat...@gmail.com>
Cc: OSPF WG List <ospf@ietf.org>; OSPF ADs <ospf-...@tools.ietf.org>
Subject: Re: [OSPF] Alvaro's DISCUSS on OSPF Admin Tags

Hi Shraddha,

After considering Alvaro’s DISCUSS, I don’t think this restriction is 
necessary. I’d remove the paragraph.

Thanks,
Acee

From: Shraddha Hegde <shrad...@juniper.net<mailto:shrad...@juniper.net>>
Date: Monday, November 16, 2015 at 11:06 PM
To: Acee Lindem <a...@cisco.com<mailto:a...@cisco.com>>, Alia Atlas 
<akat...@gmail.com<mailto:akat...@gmail.com>>
Cc: OSPF WG List <ospf@ietf.org<mailto:ospf@ietf.org>>, OSPF ADs 
<ospf-...@tools.ietf.org<mailto:ospf-...@tools.ietf.org>>
Subject: RE: [OSPF] Alvaro's DISCUSS on OSPF Admin Tags

Hi Alia/Acee,

  Do you suggest to remove the  last paragraph in section 3.2.1 or remove the 
normative language?

Rgds
Shraddha

From: Acee Lindem (acee) [mailto:a...@cisco.com]
Sent: Tuesday, November 17, 2015 12:13 AM
To: Alia Atlas <akat...@gmail.com<mailto:akat...@gmail.com>>; Shraddha Hegde 
<shrad...@juniper.net<mailto:shrad...@juniper.net>>
Cc: OSPF WG List <ospf@ietf.org<mailto:ospf@ietf.org>>; OSPF ADs 
<ospf-...@tools.ietf.org<mailto:ospf-...@tools.ietf.org>>
Subject: Re: [OSPF] Alvaro's DISCUSS on OSPF Admin Tags

Hi Alia, Shraddha,

From: Alia Atlas <akat...@gmail.com<mailto:akat...@gmail.com>>
Date: Monday, November 16, 2015 at 1:00 PM
To: Shraddha Hegde <shrad...@juniper.net<mailto:shrad...@juniper.net>>
Cc: Acee Lindem <a...@cisco.com<mailto:a...@cisco.com>>, OSPF WG List 
<ospf@ietf.org<mailto:ospf@ietf.org>>, OSPF ADs 
<ospf-...@tools.ietf.org<mailto:ospf-...@tools.ietf.org>>
Subject: Re: [OSPF] Alvaro's DISCUSS on OSPF Admin Tags

Hi Shraddha & Acee,

On Mon, Nov 16, 2015 at 12:52 PM, Shraddha Hegde 
<shrad...@juniper.net<mailto:shrad...@juniper.net>> wrote:
Hi Acee/Alia,

Pls see inline..

From: Acee Lindem (acee) [mailto:a...@cisco.com<mailto:a...@cisco.com>]
Sent: Wednesday, November 11, 2015 2:11 AM
To: Alia Atlas <akat...@gmail.com<mailto:akat...@gmail.com>>
Cc: Shraddha Hegde <shrad...@juniper.net<mailto:shrad...@juniper.net>>; OSPF WG 
List <ospf@ietf.org<mailto:ospf@ietf.org>>; OSPF ADs 
<ospf-...@tools.ietf.org<mailto:ospf-...@tools.ietf.org>>
Subject: Re: [OSPF] Alvaro's DISCUSS on OSPF Admin Tags

Hi Alia, Shraddha,

From: Alia Atlas <akat...@gmail.com<mailto:akat...@gmail.com>>
Date: Sunday, November 8, 2015 at 1:59 AM
To: Acee Lindem <a...@cisco.com<mailto:a...@cisco.com>>
Cc: Shraddha Hegde <shrad...@juniper.net<mailto:shrad...@juniper.net>>, OSPF WG 
List <ospf@ietf.org<mailto:ospf@ietf.org>>, OSPF ADs 
<ospf-...@tools.ietf.org<mailto:ospf-...@tools.ietf.org>>
Subject: Re: [OSPF] Alvaro's DISCUSS on OSPF Admin Tags

Hi Acee,

Thanks very much for reading through and pulling out the relevant questions.
I'd like to see this conversation resolve quickly.

On Sat, Nov 7, 2015 at 9:58 AM, Acee Lindem (acee) 
<a...@cisco.com<mailto:a...@cisco.com>> wrote:
Hi Shraddha,

I’ve read through this discussion and I’m wondering why we just can’t
remove this normative text with respect to the interpretation of OSPF Node
Admin tags?

   1. Since the tags are advertised by a single node, why is do they have
to be unordered? It seems there should be a reason for this even if this
semantic is retained.

I can understand this restriction in terms of implementation complexity &
assumptions.  A router that receives the tag list might want to store them in
numerical order or such for easier searching.  If the tag order matters, there
can be rather different requirements in terms of how the listener uses the
information.

Perhaps the answer is that we don’t see a use case for maintaining tag order 
given that they may come from multiple sources it adds a lot of complexity to 
try and maintain order. Note that the order independence is also in RFC 5130 
(IS-IS prefix admin tags) - see section 4.

 The restriction of keeping the tag set unordered ensures that the 
vendor policy implementations will use node tags as a set and not as an ordered 
list.
   Since there are no standards defined for policy module, 
its hard for the operators  to guess how the vendor policy implementations 
behave.
   I think the explicit mention of the tag ordering ensures 
there is no ambiguity in interpreting the tags.

 Ok - this makes sense to me.  Let's keep that restriction.

I’m ok with this as well. There is precedence with non-order dependence with 
the IS-IS Admin Tags (Section 4 in RFC 

Re: [OSPF] Alvaro's DISCUSS on OSPF Admin Tags

[Shraddha Hegde]

Hi Acee/Alia,

Pls see inline..

From: Acee Lindem (acee) [mailto:a...@cisco.com]
Sent: Wednesday, November 11, 2015 2:11 AM
To: Alia Atlas <akat...@gmail.com>
Cc: Shraddha Hegde <shrad...@juniper.net>; OSPF WG List <ospf@ietf.org>; OSPF 
ADs <ospf-...@tools.ietf.org>
Subject: Re: [OSPF] Alvaro's DISCUSS on OSPF Admin Tags

Hi Alia, Shraddha,

From: Alia Atlas <akat...@gmail.com<mailto:akat...@gmail.com>>
Date: Sunday, November 8, 2015 at 1:59 AM
To: Acee Lindem <a...@cisco.com<mailto:a...@cisco.com>>
Cc: Shraddha Hegde <shrad...@juniper.net<mailto:shrad...@juniper.net>>, OSPF WG 
List <ospf@ietf.org<mailto:ospf@ietf.org>>, OSPF ADs 
<ospf-...@tools.ietf.org<mailto:ospf-...@tools.ietf.org>>
Subject: Re: [OSPF] Alvaro's DISCUSS on OSPF Admin Tags

Hi Acee,

Thanks very much for reading through and pulling out the relevant questions.
I'd like to see this conversation resolve quickly.

On Sat, Nov 7, 2015 at 9:58 AM, Acee Lindem (acee) 
<a...@cisco.com<mailto:a...@cisco.com>> wrote:
Hi Shraddha,

I’ve read through this discussion and I’m wondering why we just can’t
remove this normative text with respect to the interpretation of OSPF Node
Admin tags?

   1. Since the tags are advertised by a single node, why is do they have
to be unordered? It seems there should be a reason for this even if this
semantic is retained.

I can understand this restriction in terms of implementation complexity &
assumptions.  A router that receives the tag list might want to store them in
numerical order or such for easier searching.  If the tag order matters, there
can be rather different requirements in terms of how the listener uses the
information.

Perhaps the answer is that we don’t see a use case for maintaining tag order 
given that they may come from multiple sources it adds a lot of complexity to 
try and maintain order. Note that the order independence is also in RFC 5130 
(IS-IS prefix admin tags) - see section 4.

 The restriction of keeping the tag set unordered ensures that the 
vendor policy implementations will use node tags as a set and not as an ordered 
list.
   Since there are no standards defined for policy module, 
its hard for the operators  to guess how the vendor policy implementations 
behave.
   I think the explicit mention of the tag ordering ensures 
there is no ambiguity in interpreting the tags.


   2. Why can’t they be advertised in multiple flooding scopes? There
could be one set of tags applicable at the area scope and another
applicable at the AS wide scope.

I agree that I don't see implementation complexity logic driving this.  Perhaps
it allows for storing tags per device in a flat structure instead of requiring 
that
they are stored per area?

I wouldn’t think so.


Regardless, this feels like it has more impact on operational complexity of
having to define the same meaning for different tags for different areas.

This restriction of a single flooding scope wouldn’t preclude this.
 Tags are independent characteristics of a node. It’s perfectly valid 
to advertise same tag in different areas so operator need not
   Define different tags having same meaning for different 
areas.
   Since tags are independent characteristics it is well 
defined whether that characteristic need to be seen by AS wide nodes
   Or area wide nodes.

Thanks,
Acee




Regards,
Alia

In essence, since the tags are purely opaque, it seems you could simply
remove the last 2-3 paragraphs of section 3.2.1 and the last paragraph of
section 3.2.2 as these seem to be rather arbitrary restrictions.

Thanks,
Acee

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

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

Re: [OSPF] Alvaro's DISCUSS on OSPF Admin Tags

[Shraddha Hegde]

Hi Alia/Acee,

  Do you suggest to remove the  last paragraph in section 3.2.1 or remove the 
normative language?

Rgds
Shraddha

From: Acee Lindem (acee) [mailto:a...@cisco.com]
Sent: Tuesday, November 17, 2015 12:13 AM
To: Alia Atlas <akat...@gmail.com>; Shraddha Hegde <shrad...@juniper.net>
Cc: OSPF WG List <ospf@ietf.org>; OSPF ADs <ospf-...@tools.ietf.org>
Subject: Re: [OSPF] Alvaro's DISCUSS on OSPF Admin Tags

Hi Alia, Shraddha,

From: Alia Atlas <akat...@gmail.com<mailto:akat...@gmail.com>>
Date: Monday, November 16, 2015 at 1:00 PM
To: Shraddha Hegde <shrad...@juniper.net<mailto:shrad...@juniper.net>>
Cc: Acee Lindem <a...@cisco.com<mailto:a...@cisco.com>>, OSPF WG List 
<ospf@ietf.org<mailto:ospf@ietf.org>>, OSPF ADs 
<ospf-...@tools.ietf.org<mailto:ospf-...@tools.ietf.org>>
Subject: Re: [OSPF] Alvaro's DISCUSS on OSPF Admin Tags

Hi Shraddha & Acee,

On Mon, Nov 16, 2015 at 12:52 PM, Shraddha Hegde 
<shrad...@juniper.net<mailto:shrad...@juniper.net>> wrote:
Hi Acee/Alia,

Pls see inline..

From: Acee Lindem (acee) [mailto:a...@cisco.com<mailto:a...@cisco.com>]
Sent: Wednesday, November 11, 2015 2:11 AM
To: Alia Atlas <akat...@gmail.com<mailto:akat...@gmail.com>>
Cc: Shraddha Hegde <shrad...@juniper.net<mailto:shrad...@juniper.net>>; OSPF WG 
List <ospf@ietf.org<mailto:ospf@ietf.org>>; OSPF ADs 
<ospf-...@tools.ietf.org<mailto:ospf-...@tools.ietf.org>>
Subject: Re: [OSPF] Alvaro's DISCUSS on OSPF Admin Tags

Hi Alia, Shraddha,

From: Alia Atlas <akat...@gmail.com<mailto:akat...@gmail.com>>
Date: Sunday, November 8, 2015 at 1:59 AM
To: Acee Lindem <a...@cisco.com<mailto:a...@cisco.com>>
Cc: Shraddha Hegde <shrad...@juniper.net<mailto:shrad...@juniper.net>>, OSPF WG 
List <ospf@ietf.org<mailto:ospf@ietf.org>>, OSPF ADs 
<ospf-...@tools.ietf.org<mailto:ospf-...@tools.ietf.org>>
Subject: Re: [OSPF] Alvaro's DISCUSS on OSPF Admin Tags

Hi Acee,

Thanks very much for reading through and pulling out the relevant questions.
I'd like to see this conversation resolve quickly.

On Sat, Nov 7, 2015 at 9:58 AM, Acee Lindem (acee) 
<a...@cisco.com<mailto:a...@cisco.com>> wrote:
Hi Shraddha,

I’ve read through this discussion and I’m wondering why we just can’t
remove this normative text with respect to the interpretation of OSPF Node
Admin tags?

   1. Since the tags are advertised by a single node, why is do they have
to be unordered? It seems there should be a reason for this even if this
semantic is retained.

I can understand this restriction in terms of implementation complexity &
assumptions.  A router that receives the tag list might want to store them in
numerical order or such for easier searching.  If the tag order matters, there
can be rather different requirements in terms of how the listener uses the
information.

Perhaps the answer is that we don’t see a use case for maintaining tag order 
given that they may come from multiple sources it adds a lot of complexity to 
try and maintain order. Note that the order independence is also in RFC 5130 
(IS-IS prefix admin tags) - see section 4.

 The restriction of keeping the tag set unordered ensures that the 
vendor policy implementations will use node tags as a set and not as an ordered 
list.
   Since there are no standards defined for policy module, 
its hard for the operators  to guess how the vendor policy implementations 
behave.
   I think the explicit mention of the tag ordering ensures 
there is no ambiguity in interpreting the tags.

 Ok - this makes sense to me.  Let's keep that restriction.

I’m ok with this as well. There is precedence with non-order dependence with 
the IS-IS Admin Tags (Section 4 in RFC 5140).



   2. Why can’t they be advertised in multiple flooding scopes? There
could be one set of tags applicable at the area scope and another
applicable at the AS wide scope.

I agree that I don't see implementation complexity logic driving this.  Perhaps
it allows for storing tags per device in a flat structure instead of requiring 
that
they are stored per area?

I wouldn’t think so.


Regardless, this feels like it has more impact on operational complexity of
having to define the same meaning for different tags for different areas.

This restriction of a single flooding scope wouldn’t preclude this.
 Tags are independent characteristics of a node. It’s perfectly valid 
to advertise same tag in different areas so operator need not
   Define different tags having same meaning for different 
areas.
   Since tags are independent characteristics it is well 
defined whether that characteristic need to be seen by AS wide nodes
   Or area wide nodes.

This sounds like an assumption on the meaning for tags that the

Re: [OSPF] IPR Poll on "OSPF Link Overload"

[Shraddha Hegde]

I am not aware of any IPR other than disclosed by juniper.

Rgds
Shraddha

-Original Message-
From: Acee Lindem (acee) [mailto:a...@cisco.com] 
Sent: Monday, October 26, 2015 5:46 AM
To: draft-ietf-ospf-link-overl...@ietf.org
Cc: OSPF WG List 
Subject: IPR Poll on "OSPF Link Overload" 

Authors,
Please indicate whether you are aware of any relevant IPR and if so, whether it 
has been disclosed.
Thanks,
Acee

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

[OSPF] Regarding draft-ppsenak-ospf-te-link-attr-reuse-00

[Shraddha Hegde]

Hi All,


draft-ppsenak-ospf-te-link-attr-reuse-00 proposes moving and/or copying TLVs 
from the TE Opaque LSA to the Extended Link Opaque LSA. The draft lists the 
problems that the draft is trying to solve.  I have reproduced that list of 
problems below, with each problem followed by what I believe to be a better and 
simpler solution.

   1.  Whenever the link is advertised in a TE Opaque LSA, the link
   becomes a part of the TE topology, which may not match IP routed
   topology.  By making the link part of the TE topology, remote
   nodes may mistakenly believe that the link is available for MPLS
   TE or GMPLS, when, in fact, MPLS is not enabled on the link.

To address this issue, we simply need to define a new sub-TLV in the TE Link 
LSA  to say whether MPLS/GMPLS/RSVP is enabled on the link instead of moving 
the TLVs around into different LSAs.

   2.  The TE Opaque LSA carries link attributes that are not used or
   required by MPLS TE or GMPLS.  There is no mechanism in TE Opaque
   LSA to indicate which of the link attributes should be passed to
   MPLS TE application and which should be used by OSPFv2 and other
   applications.

OSPF database is a container and OSPF can use any of the LSAS for its own use 
including the TE LSAs.  As far as the TE database goes, it contains data from 
TE LSAs as well as non-TE LSAs (Network LSA) today so the reasoning described 
here doesn't make sense.

   3.  Link attributes used for non-TE purposes is partitioned across
   multiple LSAs - the TE Opaque LSA and the Extended Link Opaque
   LSA.  This partitioning will require implementations to lookup
   multiple LSAs to extract link attributes for a single link,
   bringing needless complexity to the OSPFv2 implementations.

There will be nodes in the network which will run older software which send 
these attributes via TE LSAs so the problem of looking into the TE LSAs for TE 
related information doesn't get solved with this draft.  Rather it makes it 
more complicated. With this draft, the multiple LSA lookup will only increase.  
An implementation will first have to find if Extended link LSA contains the 
required info,  if not it will need to look up the info in TE.LSA.

Looking up multiple LSAs for information is an implementation issue and I am 
sure there will be implementations that will handle this  gracefully so that it 
doesn't cause
delays in critical paths. It doesn't seem reasonable to come up with protocol 
extensions to solve implementation issues.


Rgds
Shraddha





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

Re: [OSPF] Alvaro Retana's Discuss on draft-ietf-ospf-node-admin-tag-07: (with DISCUSS and COMMENT)

[Shraddha Hegde]

Resending the mail as the previous mail content got removed.

Alvaro,

  Thanks for the discussion.
I am sorry that we are not able to reach conclusion quickly.

Nevertheless,I'll try to clarify based on my understanding of your comments.

If the same tag value is flooded with multiple scopes, then it will be declared 
conflicting (for all scopes).
Yes.
.
  If there are policies that are dependent on those tags then they won't be 
applied

  The conflicting tag won't be considered. Lets say a node had 
advertised 10 tags. Lets say 10th tag is conflicting and is arriving
   In different scopes. Only 9 tags will be sent to policy. 
   If you saying just because one tag is conflicting the 
whole set of tags for that node is ignored, then that's not the case.

 -- including policies that rely on more than one tag being present (including 
the one declared conflicting, of course).  The point of that question was to 
point out that by invalidating a tag the policies that will be applied won't 
always depend just on the remaining tags..

 Again I don't understand your statement. Why can't the policy be 
applied on only 9 tags in above example. If the policy fails because of the 
absence of 10th flag then it's an issue with the advertising router being 
nod-ABR and having advertised different tags in different scopes.

Do you mean to say we should not restrict same tag being advertised in 
different scopes?
I am not sure If we can change that at this stage of the document since WG as 
well as others who reviewed the document so far are OK with that restriction 
being there.

-

Again, the point was that by not allowing the tags to be tied to changes in 
topology you are not necessarily doing much to limit instability.
True, the topology may become unstable and the tags advertised will mirror that 
-- the root cause being the topology instability.  But I think there can be 
valid applications that could follow topology changes that won't mirror 
instability (if the network itself is stable).  Also, you focused on one thing 
(topology instability), leaving other reasons for tag instability without 
mention -- this last part was why I suggested that you might want to focus on 
the problem you really want to resolve and maybe talk about rate limiting.

 Personally, I do not think we need to talk about rate limiting of 
node-admin tags since we already have rate limiting for the LSA origination.
Would like to hear others opinion on this.

Rgds
Shraddha

-Original Message-
From: Shraddha Hegde [mailto:shrad...@juniper.net] 
Sent: Tuesday, October 20, 2015 9:27 AM
To: Alvaro Retana (aretana) <aret...@cisco.com>; The IESG <i...@ietf.org>
Cc: Acee Lindem (acee) <a...@cisco.com>; 
draft-ietf-ospf-node-admin-tag...@ietf.org; 
draft-ietf-ospf-node-admin-tag.sheph...@ietf.org; 
draft-ietf-ospf-node-admin-...@ietf.org; ospf-cha...@ietf.org; ospf@ietf.org
Subject: RE: Alvaro Retana's Discuss on draft-ietf-ospf-node-admin-tag-07: 
(with DISCUSS and COMMENT)

Alvaro,

I'll try to clarify based on my understanding of your comments.

If the same tag value is flooded with multiple scopes, then it will be declared 
conflicting (for all scopes).
Yes.

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

Re: [OSPF] draft-ietf-ospf-two-part-metric : Max metric handling

[Shraddha Hegde]

Acee,

>Explain to me how it is not longer a safe last resort metric if it is greater 
>than 0x? Show me a viable topology?


  8fff10
   -E -
 8fff|\
D8fff   10   \
|   |_F---G
| 10   \ 10
A---B-C
   10 10



In the above topology D’s interface cost is set to 8fff. F’s network-to-router 
cost is also set to 8fff.

The path from A to C in normal operation is A->B->C.
Let’s say B-> C link should be replaced . Setting B->C interface cost 0x 
will not move the traffic away from that link
Since the cost  to reach C via other path is

A->D->F->G->C
 Is
10 + 8fff + 8fff + 10 + 10 + 10=  1202E

0x1202E is greater than 0x.

In the absence of two-part metric the cost would be 10 + 8fff +10+10+10 = 0x902f
And the traffic would be diverted.

Did I miss something? Or misunderstood the two-part metric?

Rgds
Shraddha



From: Acee Lindem (acee) [mailto:a...@cisco.com]
Sent: Monday, October 19, 2015 4:07 PM
To: Shraddha Hegde <shrad...@juniper.net>; 
draft-ietf-ospf-two-part-met...@ietf.org
Cc: OSPF WG List <ospf@ietf.org>
Subject: Re: draft-ietf-ospf-two-part-metric : Max metric handling

Hi Shraddha,

From: Shraddha Hegde <shrad...@juniper.net<mailto:shrad...@juniper.net>>
Date: Monday, October 19, 2015 at 1:53 AM
To: Acee Lindem <a...@cisco.com<mailto:a...@cisco.com>>, 
"draft-ietf-ospf-two-part-met...@ietf.org<mailto:draft-ietf-ospf-two-part-met...@ietf.org>"
 
<draft-ietf-ospf-two-part-met...@ietf.org<mailto:draft-ietf-ospf-two-part-met...@ietf.org>>
Cc: OSPF WG List <ospf@ietf.org<mailto:ospf@ietf.org>>
Subject: RE: draft-ietf-ospf-two-part-metric : Max metric handling

Hi Acee,

It was a mistake to think 0x added to 0x will make it 0x .
The metric will be 0x1fffe which is still much greater than 0x.

If an operator has assigned  metric of 0x for a link  thinking that this 
will be the last resort  link
Since there is no metric beyond 0x.
This assumption will be broken when two part metric is introduced. As there can 
be node-node paths with metric
Larger than ox, so 0x is no longer a safe last resort metric.

Explain to me how it is not longer a safe last resort metric if it is greater 
than 0x? Show me a viable topology?



Introducing two-part metric for broadcast links into the network has 
operational impact and I think it should be stated explicitly in the draft.

We will cover stub router operation in the next revision.

Thanks,
Acee


Rgds
Shraddha

From: Acee Lindem (acee) [mailto:a...@cisco.com]
Sent: Saturday, October 17, 2015 5:36 AM
To: Shraddha Hegde <shrad...@juniper.net<mailto:shrad...@juniper.net>>; 
draft-ietf-ospf-two-part-met...@ietf.org<mailto:draft-ietf-ospf-two-part-met...@ietf.org>
Cc: OSPF WG List <ospf@ietf.org<mailto:ospf@ietf.org>>
Subject: Re: draft-ietf-ospf-two-part-metric : Max metric handling

Hi Shraddha,

Even if we set both metrics to 0x, the link metric is 0x1FFE. This is far 
from 0xff. Hence, I don’t really understand your concern of this changing 
the behavior.

Thanks,
Acee

From: Shraddha Hegde <shrad...@juniper.net<mailto:shrad...@juniper.net>>
Date: Tuesday, October 13, 2015 at 12:30 AM
To: Acee Lindem <a...@cisco.com<mailto:a...@cisco.com>>, 
"draft-ietf-ospf-two-part-met...@ietf.org<mailto:draft-ietf-ospf-two-part-met...@ietf.org>"
 
<draft-ietf-ospf-two-part-met...@ietf.org<mailto:draft-ietf-ospf-two-part-met...@ietf.org>>
Cc: OSPF WG List <ospf@ietf.org<mailto:ospf@ietf.org>>
Subject: RE: draft-ietf-ospf-two-part-metric : Max metric handling

Acee,

Yes, the metric change for the stub router scenario needs to be updated.

This draft is changing the maximum possible metric for a path between two 
adjacent nodes from 0x to ox.
This breaks the existing assumption that 0x is the max_metric i.e last 
resort metric. From operational
Perspective it’s better to mention this point explicitly  in the draft.

Rgds
Shraddha

From: Acee Lindem (acee) [mailto:a...@cisco.com]
Sent: Thursday, October 08, 2015 3:03 PM
To: Shraddha Hegde <shrad...@juniper.net<mailto:shrad...@juniper.net>>; 
draft-ietf-ospf-two-part-met...@ietf.org<mailto:draft-ietf-ospf-two-part-met...@ietf.org>
Cc: OSPF WG List <ospf@ietf.org<mailto:ospf@ietf.org>>
Subject: Re: draft-ietf-ospf-two-part-metric : Max metric handling

Hi Shraddha,
Since RFC 2328 and RFC 5340 don’t explicitly call out the case of 0x, I 
don’t see why this should be handled. Perhaps, we should state both metric 
SHOULD be set to 0x in the stub router case.
Thanks,
Acee

From: Shraddha Hegde <shrad...@juniper.net<mailto:shrad...@juniper.net>>
Da

Re: [OSPF] Alvaro Retana's Discuss on draft-ietf-ospf-node-admin-tag-07: (with DISCUSS and COMMENT)

[Shraddha Hegde]

Alvaro,

I'll try to clarify based on my understanding of your comments.

If the same tag value is flooded with multiple scopes, then it will be declared 
conflicting (for all scopes).
Yes.
.
  If there are policies that are dependent on those tags then they won't be 
applied
 The conflicting tag won't be considered. Lets say a node had 
advertised 10 tags. Lets say 10th tag is conflicting and is arriving
   In different scopes. Only 9 tags will be sent to policy. 
   If you saying just because one tag is conflicting the 
whole set of tags for that node is ignored, then that's not the case.

 -- including policies that rely on more than one tag being present (including 
the one declared conflicting, of course).  The point of that question was to 
point out that by invalidating a tag the policies that will be applied won't 
always depend just on the remaining tags..

 Again I don't understand your statement. Why can't the policy be 
applied on only 9 tags in above example. If the policy fails because of the 
absence of 10th flag then it's an issue with the advertising router being 
nod-ABR and having advertised different tags in different scopes.

Do you mean to say we should not restrict same tag being advertised in 
different scopes?
I am not sure If we can change that at this stage of the document since WG as 
well as others who reviewed the document so far are OK with that restriction 
being there.

-

Again, the point was that by not allowing the tags to be tied to changes in 
topology you are not necessarily doing much to limit instability.
True, the topology may become unstable and the tags advertised will mirror that 
-- the root cause being the topology instability.  But I think there can be 
valid applications that could follow topology changes that won't mirror 
instability (if the network itself is stable).  Also, you focused on one thing 
(topology instability), leaving other reasons for tag instability without 
mention -- this last part was why I suggested that you might want to focus on 
the problem you really want to resolve and maybe talk about rate limiting.

 Personally, I do not think we need to talk about rate limiting of 
node-admin tags since we already have rate limiting for the LSA origination.
Would like to hear others opinion on this.

Rgds
Shraddha

-Original Message-
From: Alvaro Retana (aretana) [mailto:aret...@cisco.com] 
Sent: Monday, October 19, 2015 6:09 PM
To: Shraddha Hegde <shrad...@juniper.net>; The IESG <i...@ietf.org>
Cc: Acee Lindem (acee) <a...@cisco.com>; 
draft-ietf-ospf-node-admin-tag...@ietf.org; 
draft-ietf-ospf-node-admin-tag.sheph...@ietf.org; 
draft-ietf-ospf-node-admin-...@ietf.org; ospf-cha...@ietf.org; ospf@ietf.org
Subject: Re: Alvaro Retana's Discuss on draft-ietf-ospf-node-admin-tag-07: 
(with DISCUSS and COMMENT)

On 10/18/15, 11:53 PM, "Shraddha Hegde" <shrad...@juniper.net> wrote:

Shraddha:


Hi!

I'm either completely missing the point, not explaining myself correctly, or 
both.  We seem to be going around in circles.. :-(

I'm going to clear the DISCUSS.. I trust the responsible AD and hope that the 
WG had the appropriate discussions.  There are still some comments below.

Alvaro.

. . .
>
>From section 2 (updated text): "The choice of what scope at which to 
>flood the group tags is a matter of local policy."  And form the new
>3.2.1: "The meaning of a per-node administrative tag is defined by the 
>network local policy and is controlled via the configuration."
>Apparently not. :-(
>
>BTW, I noticed that in -08 you also added:
>
>   ... If a node
>   administrative tag is received in different scopes, the conflicting
>   tag SHOULD not be used and this situation SHOULD be logged as an
>   error including the tag with conflicting scopes and the
>   originator(s).
>
>
>[I know this was put in to answer the SecDir review related to what 
>should be done if the same value was received with different flooding 
>scopes.]
>
>Which is the "conflicting tag"?  Does it mean that for all scopes that 
>specific value is not to be used?
>From section 2 (updated text): "The choice of what scope at which to 
>flood the group tags is a matter of local policy."  And form the new
>3.2.1: "The meaning of a per-node administrative tag is defined by the 
>network local policy and is controlled via the configuration."
>Apparently not. :-(
>
>BTW, I noticed that in -08 you also added:
>
>   ... If a node
>   administrative tag is received in different scopes, the conflicting
>   tag SHOULD not be used and this situation SHOULD be logged as an
>   error including the tag with conflicting scopes and t

Re: [OSPF] draft-ietf-ospf-two-part-metric : Max metric handling

[Shraddha Hegde]

Hi Acee,

It was a mistake to think 0x added to 0x will make it 0x .
The metric will be 0x1fffe which is still much greater than 0x.

If an operator has assigned  metric of 0x for a link  thinking that this 
will be the last resort  link
Since there is no metric beyond 0x.
This assumption will be broken when two part metric is introduced. As there can 
be node-node paths with metric
Larger than ox, so 0x is no longer a safe last resort metric.

Introducing two-part metric for broadcast links into the network has 
operational impact and I think it should be stated explicitly in the draft.

Rgds
Shraddha

From: Acee Lindem (acee) [mailto:a...@cisco.com]
Sent: Saturday, October 17, 2015 5:36 AM
To: Shraddha Hegde <shrad...@juniper.net>; 
draft-ietf-ospf-two-part-met...@ietf.org
Cc: OSPF WG List <ospf@ietf.org>
Subject: Re: draft-ietf-ospf-two-part-metric : Max metric handling

Hi Shraddha,

Even if we set both metrics to 0x, the link metric is 0x1FFE. This is far 
from 0xff. Hence, I don’t really understand your concern of this changing 
the behavior.

Thanks,
Acee

From: Shraddha Hegde <shrad...@juniper.net<mailto:shrad...@juniper.net>>
Date: Tuesday, October 13, 2015 at 12:30 AM
To: Acee Lindem <a...@cisco.com<mailto:a...@cisco.com>>, 
"draft-ietf-ospf-two-part-met...@ietf.org<mailto:draft-ietf-ospf-two-part-met...@ietf.org>"
 
<draft-ietf-ospf-two-part-met...@ietf.org<mailto:draft-ietf-ospf-two-part-met...@ietf.org>>
Cc: OSPF WG List <ospf@ietf.org<mailto:ospf@ietf.org>>
Subject: RE: draft-ietf-ospf-two-part-metric : Max metric handling

Acee,

Yes, the metric change for the stub router scenario needs to be updated.

This draft is changing the maximum possible metric for a path between two 
adjacent nodes from 0x to ox.
This breaks the existing assumption that 0x is the max_metric i.e last 
resort metric. From operational
Perspective it’s better to mention this point explicitly  in the draft.

Rgds
Shraddha

From: Acee Lindem (acee) [mailto:a...@cisco.com]
Sent: Thursday, October 08, 2015 3:03 PM
To: Shraddha Hegde <shrad...@juniper.net<mailto:shrad...@juniper.net>>; 
draft-ietf-ospf-two-part-met...@ietf.org<mailto:draft-ietf-ospf-two-part-met...@ietf.org>
Cc: OSPF WG List <ospf@ietf.org<mailto:ospf@ietf.org>>
Subject: Re: draft-ietf-ospf-two-part-metric : Max metric handling

Hi Shraddha,
Since RFC 2328 and RFC 5340 don’t explicitly call out the case of 0x, I 
don’t see why this should be handled. Perhaps, we should state both metric 
SHOULD be set to 0x in the stub router case.
Thanks,
Acee

From: Shraddha Hegde <shrad...@juniper.net<mailto:shrad...@juniper.net>>
Date: Tuesday, October 6, 2015 at 5:58 AM
To: 
"draft-ietf-ospf-two-part-met...@ietf.org<mailto:draft-ietf-ospf-two-part-met...@ietf.org>"
 
<draft-ietf-ospf-two-part-met...@ietf.org<mailto:draft-ietf-ospf-two-part-met...@ietf.org>>
Cc: OSPF WG List <ospf@ietf.org<mailto:ospf@ietf.org>>
Subject: draft-ietf-ospf-two-part-metric : Max metric handling

Authors,

As per my understanding of the draft, SPF calculation uses sum of metric from 
the interface cost and the network to router cost advertised by the neighbor.
Handling of MAX metric is not described in the draft.  Since the metric will be 
sum of 2 16 bit numbers it can exceed the normal 0x metric value and the 
draft should talk about how to handle these cases.

Rgds
Shraddha


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

Re: [OSPF] Stephen Farrell's No Objection on draft-ietf-ospf-node-admin-tag-07: (with COMMENT)

[Shraddha Hegde]

Hi Stephen,

Pls see inline..

-Original Message-
From: Stephen Farrell [mailto:stephen.farr...@cs.tcd.ie] 
Sent: Thursday, October 15, 2015 6:09 PM
To: The IESG 
Cc: draft-ietf-ospf-node-admin-...@ietf.org; ospf-cha...@ietf.org; 
a...@cisco.com; ospf@ietf.org
Subject: Stephen Farrell's No Objection on draft-ietf-ospf-node-admin-tag-07: 
(with COMMENT)

Stephen Farrell has entered the following ballot position for
draft-ietf-ospf-node-admin-tag-07: No Objection

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://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ospf-node-admin-tag/



--
COMMENT:
--


- I think Alavaro and Brian make some good points. I'll be interested in how 
that discussion turns out.

- Good to see that you recognise that even opaque tag values can expose 
sensitive information (the attacker isn't limited in how they are allowed 
interpret what they see). However, given that we recognise that confidentiality 
ought be provided sometimes, isn't there an onus on us to actually provide some 
usable way to get that service? If so, then who is looking at that problem? If 
not, then why is that acceptable? (This isn't a discuss as I don't think there 
is any PII or similar information being transferred, and the confidentiality 
requirement here really relates to network topology etc. But please do correct 
me if one of these tags could be PII-like and I'll make this a discuss if 
that's better.)

 OSPF in itself does not have  ways to provide confidentiality but in 
cases where it is needed OSPF can run on top of IPSEC tunnels which can encrypt 
the OSPF control packets. IPSEC mechanisms can also be applied to OSPF packets 
using RFC 4552 for OSPFv3. Adding below text to the draft.

Node administrative tags may be used by operators to indicate geographical 
location or other sensitive information.
 As indicated in  and  OSPF 
authentication mechanisms do not provide 
 confidentiality and the information carried in node administrative tags could 
be leaked to an IGP snooper.
Confidentiality for the OSPF control packets can be achieved by either running 
OSPF on top of IP Security (IPSEC) tunnels or 
by applying IPSEC based security mechanisms as described in 
___
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf

Re: [OSPF] Alvaro Retana's Discuss on draft-ietf-ospf-node-admin-tag-07: (with DISCUSS and COMMENT)

[Shraddha Hegde]

Alvaro,

Thanks for reviewing the document.
As indicated in other thread, we need rules/regulation on how to interpret the 
tags and how to use them to get interoperable implementations.

> Although , the actual values of node admin tags do not need to be 
> standardized and is left to the operator's discretion to allocate values and 
> assign meanings to it, It's necessary to layout certain rules/regulations and 
> guidelines on how the tags can be used and how
they cannot be used. That will help in getting interoperable implementations 
from vendors and avoid surprises in the field.
For ex:  We have a statement administrative tag order has no meaning. If this 
document does not specify such a statement, there I every possibility some 
implementation will have policies that will look at the order in which the tags 
are encoded. Some other implementation which does not care about the order of 
the tag might keep changing it at every LSA refresh so it's hard to get them to 
interoperate.

Added below text in section 3.2.1
" This section describes general rules/ regulations 
and guidelines for using and interpreting an administrative tag which will
 facilitate interoperable implementations by vendors."



Related to the DISCUSS:  Section 3.2 says that the "meaning of the Node 
administrative tags is generally opaque to OSPF", are there cases where the 
meaning is not opaque?  Even if the application is well known there is no 
indication that the tag is not opaque.  Yes, this is a nit with the word 
"generally".
 There are no known cases where OSPF needs to look into the tags but 
I do not rule out the possibility in future where OSPF uses tags for some of 
its functionality

All the references related to rfc4970 should be changed to 
draft-ietf-ospf-rfc4970bis.
 Is it OK to reference drafts as Normative refrence?

Rgds
Shraddha

-Original Message-
From: Alvaro Retana [mailto:aret...@cisco.com] 
Sent: Tuesday, October 13, 2015 7:51 PM
To: The IESG 
Cc: a...@cisco.com; draft-ietf-ospf-node-admin-tag...@ietf.org; 
draft-ietf-ospf-node-admin-tag.sheph...@ietf.org; 
draft-ietf-ospf-node-admin-...@ietf.org; ospf-cha...@ietf.org; ospf@ietf.org
Subject: Alvaro Retana's Discuss on draft-ietf-ospf-node-admin-tag-07: (with 
DISCUSS and COMMENT)

Alvaro Retana has entered the following ballot position for
draft-ietf-ospf-node-admin-tag-07: 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://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ospf-node-admin-tag/



--
DISCUSS:
--

Section 3.2. (Elements of procedure) says that the "interpretation of tag 
values is specific to the administrative domain of a particular network 
operator", which makes them opaque and obviously locally significant.  I then 
have an issue with the following text, which tries to (using rfc2119
keywords) specify how to interpret the tags, which doesn't make sense to me 
given the text above:

   Each tag MUST be treated as an independent identifier that MAY be
   used in policy to perform a policy action.  Tags carried by the
   administrative tag TLV SHOULD be used to indicate independent
   characteristics of a node.  The administrative tag list within the
   TLV MUST be considered an unordered list.  Whilst policies may be
   implemented based on the presence of multiple tags (e.g., if tag A
   AND tag B are present), they MUST NOT be reliant upon the order of
   the tags (i.e., all policies should be considered commutative
   operations, such that tag A preceding or following tag B does not
   change their outcome).

   To avoid incomplete or inconsistent interpretations of the per-node
   administrative tags the same tag value MUST NOT be advertised by a
   router in RI LSAs of different scopes.  The same tag MAY be
   advertised in multiple RI LSAs of the same scope, for example, OSPF
   Area Border Router (ABR) may advertise the same tag in area-scope RI
   LSAs in multiple areas connected to the ABR.
. . .
   Being part of the RI LSA, the per-node administrative tag TLV must be
   reasonably small and stable.  In particular, but not limited to,
   implementations supporting the per-node administrative tags MUST NOT
   tie advertised tags to changes in the network topology (both within
   and outside the OSPF domain) or reachability of routes.
. . .
   instances of the RI LSA.  The node administrative tags associated
   with a node that originates tags for the purpose of any computation
   or processing at a receiving node SHOULD be a superset of 

Re: [OSPF] draft-ietf-ospf-two-part-metric : Max metric handling

[Shraddha Hegde]

Acee,

Yes, the metric change for the stub router scenario needs to be updated.

This draft is changing the maximum possible metric for a path between two 
adjacent nodes from 0x to ox.
This breaks the existing assumption that 0x is the max_metric i.e last 
resort metric. From operational
Perspective it’s better to mention this point explicitly  in the draft.

Rgds
Shraddha

From: Acee Lindem (acee) [mailto:a...@cisco.com]
Sent: Thursday, October 08, 2015 3:03 PM
To: Shraddha Hegde <shrad...@juniper.net>; 
draft-ietf-ospf-two-part-met...@ietf.org
Cc: OSPF WG List <ospf@ietf.org>
Subject: Re: draft-ietf-ospf-two-part-metric : Max metric handling

Hi Shraddha,
Since RFC 2328 and RFC 5340 don’t explicitly call out the case of 0x, I 
don’t see why this should be handled. Perhaps, we should state both metric 
SHOULD be set to 0x in the stub router case.
Thanks,
Acee

From: Shraddha Hegde <shrad...@juniper.net<mailto:shrad...@juniper.net>>
Date: Tuesday, October 6, 2015 at 5:58 AM
To: 
"draft-ietf-ospf-two-part-met...@ietf.org<mailto:draft-ietf-ospf-two-part-met...@ietf.org>"
 
<draft-ietf-ospf-two-part-met...@ietf.org<mailto:draft-ietf-ospf-two-part-met...@ietf.org>>
Cc: OSPF WG List <ospf@ietf.org<mailto:ospf@ietf.org>>
Subject: draft-ietf-ospf-two-part-metric : Max metric handling

Authors,

As per my understanding of the draft, SPF calculation uses sum of metric from 
the interface cost and the network to router cost advertised by the neighbor.
Handling of MAX metric is not described in the draft.  Since the metric will be 
sum of 2 16 bit numbers it can exceed the normal 0x metric value and the 
draft should talk about how to handle these cases.

Rgds
Shraddha


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

[OSPF] FW: New Version Notification for draft-ietf-ospf-node-admin-tag-07.txt

[Shraddha Hegde]

Hi All,

The below version contains updates to the Operations and Manageability
comments received from David Black.

Rgds
Shraddha

-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
Sent: Saturday, October 10, 2015 12:24 AM
To: Shraddha Hegde <shrad...@juniper.net>; Anton Smirnov <a...@cisco.com>; 
Zhenbin Li <lizhen...@huawei.com>; Li zhenbin <lizhen...@huawei.com>; Bruno 
Decraene <bruno.decra...@orange.com>; Rob Shakir <r...@rob.sh>; r...@rob.sh
Subject: New Version Notification for draft-ietf-ospf-node-admin-tag-07.txt


A new version of I-D, draft-ietf-ospf-node-admin-tag-07.txt
has been successfully submitted by Shraddha Hegde and posted to the IETF 
repository.

Name:   draft-ietf-ospf-node-admin-tag
Revision:   07
Title:  Advertising per-node administrative tags in OSPF
Document date:  2015-10-09
Group:  ospf
Pages:  14
URL:
https://www.ietf.org/internet-drafts/draft-ietf-ospf-node-admin-tag-07.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-ospf-node-admin-tag/
Htmlized:   https://tools.ietf.org/html/draft-ietf-ospf-node-admin-tag-07
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-node-admin-tag-07

Abstract:
   This document describes an extension to OSPF protocol to add an
   optional operational capability, that allows tagging and grouping of
   the nodes in an OSPF domain.  This allows simplification, ease of
   management and control over route and path selection based on
   configured policies.  This document describes an extension to OSPF
   protocol to advertise per-node administrative tags.  The node-tags
   can be used to express and apply locally-defined network policies
   which is a very useful operational capability.  Node tags may be used
   either by OSPF itself or by other applications consuming information
   propagated via OSPF.

   This document describes the protocol extensions to disseminate per-
   node administrative-tags to the OSPFv2 and OSPFv3 protocol.  It
   provides example use cases of administrative node tags.



  


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.

The IETF Secretariat

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

Re: [OSPF] Gen-ART and OPS-Dir review of draft-ietf-ospf-node-admin-tag-06 - Editorial comments and nits

[Shraddha Hegde]

> -- 3.1.  TLV format
> 
>Type : TBA, Suggested value 10
> 
> Please add an RFC Editor Note asking the RFC Editor to replace this 
> with the actual IANA-assigned value.
>  Does the RFC Editor Note go as part of this document.

Yes, e.g.:

**RFC Editor: Please replace above TBA with the actual IANA-assigned value.

 Done.


> -- 4.5.  Explicit routing policy

The discussion of this example appears to warrant revision to reflect the 
preference vs. prohibition discussion around Major Issue [1].

 Request Bruno to update this section once we close on all other 
comments.


Rgds
Shraddha
-Original Message-
From: Black, David [mailto:david.bl...@emc.com] 
Sent: Wednesday, October 07, 2015 8:20 PM
To: Shraddha Hegde <shrad...@juniper.net>; Rob Shakir <r...@rob.sh>; 
a...@cisco.com; bruno.decra...@orange.com; ops-...@ietf.org; General Area 
Review Team (gen-...@ietf.org) <gen-...@ietf.org>; lizhen...@huawei.com
Cc: a...@cisco.com; ospf@ietf.org; i...@ietf.org; Black, David 
<david.bl...@emc.com>
Subject: RE: Gen-ART and OPS-Dir review of draft-ietf-ospf-node-admin-tag-06 - 
Editorial comments and nits

Most of the nits/editorial comments are fine.  Two follow-ups:

> -- 3.1.  TLV format
> 
>Type : TBA, Suggested value 10
> 
> Please add an RFC Editor Note asking the RFC Editor to replace this 
> with the actual IANA-assigned value.
>  Does the RFC Editor Note go as part of this document.

Yes, e.g.:

**RFC Editor: Please replace above TBA with the actual IANA-assigned value.

> -- 4.5.  Explicit routing policy

The discussion of this example appears to warrant revision to reflect the 
preference vs. prohibition discussion around Major Issue [1].

Thanks,
--David

> -Original Message-
> From: Shraddha Hegde [mailto:shrad...@juniper.net]
> Sent: Wednesday, October 07, 2015 3:08 AM
> To: Black, David; Rob Shakir; a...@cisco.com; bruno.decra...@orange.com; 
> ops- d...@ietf.org; General Area Review Team (gen-...@ietf.org); 
> lizhen...@huawei.com
> Cc: a...@cisco.com; ospf@ietf.org; i...@ietf.org
> Subject: RE: Gen-ART and OPS-Dir review of 
> draft-ietf-ospf-node-admin-tag-06
> 
> David,
> 
> Thanks a lot for your detailed review and comments.
> 
> Here are the details of responses. I have also attached the updated document.

[... snip ...]

> --- Nits/editorial comments: 
> 
> -- 1.  Introduction
> 
> The Abstract says that the tags are for "route and path selection"; 
> the Introduction should
> 
> also say that.  Suggestion - at the end of this sentence in the first
> paragraph:
> 
>It is useful to assign a per-node administrative tag to a router in
>the OSPF domain and use it as an attribute associated with the node.
> 
> add the text "for route and path selection".  This will help with the 
> second sentence in
> 
> the second paragraph:
> 
> Modified as per suggestion.
> 
>Path selection is a functional set
>which applies both to TE and non-TE applications and hence new TLV
>for carrying per-node administrative tags is included in Router
>Information LSA [RFC4970] .
> 
> If "path selection" and "functional set" are specific terms with 
> specialized meaning in
> 
> OSPF context, that sentence is fine as-is, otherwise it would read 
> better if it began with:
> 
>Route and path selection functionality applies to both ...
> 
>  Modified as per suggestion.
> 
> This document provides mechanisms to advertise per-node administrative 
> tags in OSPF for route and path selection. Route and path selection 
> functionality applies
> 
> to
> both to TE and non-TE applications and hence new TLV for carrying 
> per-node administrative tags is included in Router Information LSA ...
> 
> 
> 
> -- 3.1.  TLV format
> 
>Type : TBA, Suggested value 10
> 
> Please add an RFC Editor Note asking the RFC Editor to replace this 
> with the actual IANA-
> 
> assigned value.
>  Does the RFC Editor Note go as part of this document.
> 
> -- 3.2.  Elements of procedure
> 
> While it's obvious that tag usage should be confined to the 
> administrative domain that
> 
> understands the tag, it's worth stating.  At the end of this
> sentence:
> 
>Interpretation of tag values is specific to the administrative domain
>of a particular network operator.
> 
> I'd suggest adding:
> 
>, and hence tag values SHOULD NOT be propagated outside the
>administrative domain to which they apply.
> 
>  Modified as per suggestion
> 
> -- 4.4.  Mobile back-haul network service deployment
> 
> Please expand "eNodeB" acronym on first use.
> 
>  Added
> 
> -- 4.5.  Explicit routing poli

Re: [OSPF] Gen-ART and OPS-Dir review of draft-ietf-ospf-node-admin-tag-06: [1] Operational Considerations

[Shraddha Hegde]

David,


   Defining language for local policies is outside the scope of this
   document.  As in case of other policy applications, the pruning
   policies can cause the path to be completely removed from forwarding OLD
   plane, hence are less preferred than the preference policies.
NEW
   plane, and hence have the potential for more severe operational
   impact (e.g., node unreachability due to path removal) by comparison
   to preference policies that only affect path selection.

 That’s more clear. Thanks a lot, I have updated the text in -07

Beyond that, I thought I saw some agreement that Section 4.5 warrants some text 
editing to better reflect this pruning vs. preference distinction - did Bruno 
volunteer to draft that text?

 Bruno started working on section 4.5 yesterday. Lets hope we have 
the changes before deadline.

Thanks
Shraddha 


-Original Message-
From: Black, David [mailto:david.bl...@emc.com] 
Sent: Thursday, October 08, 2015 11:34 PM
To: bruno.decra...@orange.com; Shraddha Hegde <shrad...@juniper.net>
Cc: a...@cisco.com; ospf@ietf.org; i...@ietf.org; Rob Shakir <r...@rob.sh>; 
a...@cisco.com; ops-...@ietf.org; General Area Review Team (gen-...@ietf.org) 
<gen-...@ietf.org>; lizhen...@huawei.com; Black, David <david.bl...@emc.com>
Subject: RE: Gen-ART and OPS-Dir review of draft-ietf-ospf-node-admin-tag-06: 
[1] Operational Considerations

The new Operational Considerations text that Shradda sent out looks good.

I'd like to make one small change to avoid overusing the concept of
preference/preferred:

   Defining language for local policies is outside the scope of this
   document.  As in case of other policy applications, the pruning
   policies can cause the path to be completely removed from forwarding OLD
   plane, hence are less preferred than the preference policies.
NEW
   plane, and hence have the potential for more severe operational
   impact (e.g., node unreachability due to path removal) by comparison
   to preference policies that only affect path selection.

Beyond that, I thought I saw some agreement that Section 4.5 warrants some text 
editing to better reflect this pruning vs. preference distinction - did Bruno 
volunteer to draft that text?

Thanks,
--David

> -Original Message-
> From: bruno.decra...@orange.com [mailto:bruno.decra...@orange.com]
> Sent: Wednesday, October 07, 2015 5:48 AM
> To: Shraddha Hegde; Black, David
> Cc: a...@cisco.com; ospf@ietf.org; i...@ietf.org; Rob Shakir; 
> a...@cisco.com; ops-...@ietf.org; General Area Review Team 
> (gen-...@ietf.org); lizhen...@huawei.com
> Subject: RE: Gen-ART and OPS-Dir review of 
> draft-ietf-ospf-node-admin-tag-06
> 
> Shraddha, David,
> 
> > From: Shraddha Hegde [mailto:shrad...@juniper.net] > Sent: 
> > Wednesday,
> October 07, 2015 9:08 AM
> 
> [...]
> 
> > -- 4.5.  Explicit routing policy
> >
> > In Figure 3:
> > - The link from the leftmost pair of A nodes to the pair of T nodes
> >do not have link weights.
> 
> [Bruno] There is some trade-off between adding more information on the 
> figure and its readability.
> Metrics value on links AT have no impact on routing assuming they have 
> the same value on both planes and that links in the lower/side of the 
> network are higher than link in the upper/core.
> The former is the case for links in the figure, and the latter is 
> rather typical in network, so I had assume that the metrics could be 
> removed in order to improve readability.
> But I agree that from the asci art, this is not that evident.
> Metric would be 10.
> Shraddha, you can either update the  figure or send me the latest xml 
> for update.
> 
> > - The link from the left R node to the left T node does not have a
> >link weight
> 
> [Bruno] Yes. Lack of space in the figure.
> Another option is to add a text to specific the metrics. e.g.
> 
> Proposed NEW:
> Links between T, R and I nodes have a metric of 100.
> Links between A nodes and R and T nodes have a metric of 10.
> Links between A nodes and I nodes have a metric of 201.
> 
> 
> Do you think this would be clearer?
> 
> > - The following example of an explicitly routed policy:
> >
> >   - Traffic from A nodes to I nodes must not go through R and T
> > nodes
> >
> > prevents the leftmost pair of A nodes from sending traffic to the
> > I nodes.  Was this "black hole" intended as part of the example?
> 
> [Bruno]
> In this specific example, the policy would be
> "  - Traffic from A nodes to A nodes should preferably go through R or T
> nodes (rather than through I nodes)
>   - Traffic from A nodes to I nodes must not go through R and T  nodes"
> 
> 
> Indeed, in the latter case, loss of 

Re: [OSPF] Gen-ART and OPS-Dir review of draft-ietf-ospf-node-admin-tag-06

[Shraddha Hegde]

quot;feet."  These
considerations would have to be documented based on the
specific uses made of these tags by specific implementations
and deployments.  All of that appears to be outside the scope
of this draft.

A.1.7.  Has management interoperability been discussed?

No - at a minimum, reporting of tag values ought to be defined
via an OSPF MIB extension or analogous functionality.
This is minor issue [D].

A.1.8.  Are there fault or threshold conditions that should be reported?

Yes, but they're implementation-specific - see response to
A.1.[2,5,6] above.

A.2.  Management Considerations
   Do you anticipate any manageability issues with the specification?

Yes, manageability has been largely ignored.

A.3.  Documentation

   Is an operational considerations and/or manageability section part of
   the document?

No.

   Does the proposed protocol have a significant operational impact on
   the Internet?

Yes, the anticipated uses will.

   Is there proof of implementation and/or operational experience?

Nothing was stated in the draft or shepherd write-up.

As an OPS-Dir member, I'm concerned by the above RFC 5706 answers, and in 
particular 

treating all operational issues as vendor- and/or operator-specific.  One 
possible 

alternative would be to scope the draft down to interoperably specify what's 
needed for 

LFA, as indicated by this answer from the Shepherd write-up:

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

  There is consensus from the WG and others outside the WG that
  this document can progress. It complements work done on LFA 
  manageability in the RTG Working Group.

Another alternative could be Experimental RFC status for the full tag mechanism 
(e.g., to 

figure out what it'll be used for in practice, how and why) rather than 
Proposed Standard.

This is major issue [1].

-Original Message-
From: Black, David [mailto:david.bl...@emc.com] 
Sent: Wednesday, October 07, 2015 4:41 AM
To: Rob Shakir <r...@rob.sh>; a...@cisco.com; bruno.decra...@orange.com; 
ops-...@ietf.org; Shraddha Hegde <shrad...@juniper.net>; General Area Review 
Team (gen-...@ietf.org) <gen-...@ietf.org>; lizhen...@huawei.com
Cc: a...@cisco.com; ospf@ietf.org; i...@ietf.org; Black, David 
<david.bl...@emc.com>
Subject: RE: Gen-ART and OPS-Dir review of draft-ietf-ospf-node-admin-tag-06

Rob,

I think something needs to be said on use of tags for preference in route 
selection vs. prohibition on use of routes, e.g., as Section 4.5 starts out 
with a discussion of preference and then supplies two example policies that are 
prohibitions. 

While Section 4.5 appears to need some attention, that seems to be a bit late 
in the draft to cover this topic - perhaps this would be fodder for an 
"Operational Considerations" section, as suggested in my reply to Bruno.
That could include a statement that route preference policies are a less risky 
use of tags by comparison to route prohibition policies.

Now that I have a better idea of what this draft is intended for, please ignore 
my suggestions to scope it to LFA or make it Experimental.

Thanks,
--David

> -Original Message-
> From: Rob Shakir [mailto:r...@rob.sh]
> Sent: Tuesday, October 06, 2015 1:22 PM
> To: a...@cisco.com; bruno.decra...@orange.com; Black, David; 
> ops-...@ietf.org; shrad...@juniper.net; General Area Review Team 
> (gen-...@ietf.org); lizhen...@huawei.com
> Cc: a...@cisco.com; ospf@ietf.org; Black, David; i...@ietf.org
> Subject: RE: Gen-ART and OPS-Dir review of 
> draft-ietf-ospf-node-admin-tag-06
> 
> 
> On October 6, 2015 at 17:46:41, Black, David (david.bl...@emc.com) wrote:
> > Rob,
> >
> > > Given that we are really selecting candidates from within a set of 
> > > paths
> that
> > > have already been selected by OSPF as valid, and usable - then I’m 
> > > not
> sure
> > > that I can understand the logic behind this sentence from your review:
> "There
> > > appears to be more than enough enabled by this draft to wreak 
> > > serious operational havoc”.
> >
> > Perhaps, I'm not understanding something, but I thought I saw an
> unreachability
> > problem in the example in Section 4.5/Figure 3:
> >
> > - The following example of an explicitly routed policy:
> >
> > - Traffic from A nodes to I nodes must not go through R and T nodes
> >
> > prevents the leftmost pair of A nodes from sending traffic to the I 
> > nodes. Was this "black hole" intended as part of the example?
&g

[OSPF] draft-ietf-ospf-two-part-metric : Max metric handling

[Shraddha Hegde]

Authors,

As per my understanding of the draft, SPF calculation uses sum of metric from 
the interface cost and the network to router cost advertised by the neighbor.
Handling of MAX metric is not described in the draft.  Since the metric will be 
sum of 2 16 bit numbers it can exceed the normal 0x metric value and the 
draft should talk about how to handle these cases.

Rgds
Shraddha


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

Re: [OSPF] OSPF Link Overload - draft-hegde-ospf-link-overload-01

[Shraddha Hegde]

Acee,

I am in the process of revising the draft. Will include details you mentioned.

Rgds
Shraddha

From: Acee Lindem (acee) [mailto:a...@cisco.com]
Sent: Monday, October 05, 2015 7:15 PM
To: Shraddha Hegde <shrad...@juniper.net>; Manav Bhatia <manavbha...@gmail.com>
Cc: OSPF WG List <ospf@ietf.org>; Hannes Gredler <han...@gredler.at>; Jalil, 
Luay <luay.ja...@verizon.com>; Mohan Nanduri <mnand...@microsoft.com>
Subject: Re: [OSPF] OSPF Link Overload - draft-hegde-ospf-link-overload-01

Hi Shraddha,

I think the draft should explain why the existing stub-router support will not 
suffice or this will be a continuing source of confusion. Off the top of my 
head:

Since the metric is only being set to the maximum for the link in maintenance 
mode, the reverse metric needs to be set to maximum as well. Otherwise, 
incoming traffic will continue to use the link in maintenance mode for transit 
traffic destined for on links on the OSPF router that are still fully active 
and supporting transit traffic. In comparison, the stub router [RFC] will 
set the metric to max-metric for all the links and will discourage transit 
traffic for the OSPF router.

Thanks,
Acee

From: Shraddha Hegde <shrad...@juniper.net<mailto:shrad...@juniper.net>>
Date: Wednesday, September 30, 2015 at 12:32 PM
To: Manav Bhatia <manavbha...@gmail.com<mailto:manavbha...@gmail.com>>
Cc: Acee Lindem <a...@cisco.com<mailto:a...@cisco.com>>, OSPF WG List 
<ospf@ietf.org<mailto:ospf@ietf.org>>, Hannes Gredler 
<han...@gredler.at<mailto:han...@gredler.at>>, Luay Jalil 
<luay.ja...@verizon.com<mailto:luay.ja...@verizon.com>>, Mohan Nanduri 
<mnand...@microsoft.com<mailto:mnand...@microsoft.com>>
Subject: RE: [OSPF] OSPF Link Overload - draft-hegde-ospf-link-overload-01

Manav,

The draft is about a link going for maintenance and not about the node going 
for maintenance.
The draft talks about sending a “link overload” TLV associated with the link 
and the other end of the link
Setting metric to high value so that reverse traffic is also diverted away from 
the link.

Rgds
Shraddha

From: Manav Bhatia [mailto:manavbha...@gmail.com]
Sent: Wednesday, September 30, 2015 7:32 PM
To: Shraddha Hegde <shrad...@juniper.net<mailto:shrad...@juniper.net>>
Cc: Acee Lindem (acee) <a...@cisco.com<mailto:a...@cisco.com>>; OSPF WG List 
<ospf@ietf.org<mailto:ospf@ietf.org>>; Hannes Gredler 
<han...@gredler.at<mailto:han...@gredler.at>>; Jalil, Luay 
<luay.ja...@verizon.com<mailto:luay.ja...@verizon.com>>; Mohan Nanduri 
<mnand...@microsoft.com<mailto:mnand...@microsoft.com>>
Subject: Re: [OSPF] OSPF Link Overload - draft-hegde-ospf-link-overload-01

Hi,

I am probably joining the party quite late, so apologies in advance if the 
following has already been discussed and discarded.

Why cant the following be done:

Set the metric of all transit links/connections on an “overloaded” router to 
0x in its Router LSAs. This will result this router to not be included as a 
transit node in its neighbors SPF tree.  Stub links can still be advertised 
with their normal metrics so that they are reachable even when a router is 
“overloaded”.

This way you can mimic IS-IS OL bit.

Cheers, Manav

On Mon, Sep 28, 2015 at 10:43 AM, Shraddha Hegde 
<shrad...@juniper.net<mailto:shrad...@juniper.net>> wrote:
Acee,

Thanks for picking up the draft for adoption.

I believe this draft is very useful in automating the link upgrade process and 
software upgrade process in overlay deployments and
hence support WG adoption as co-author.

I would like to  take this opportunity to discuss  few of the points raised 
during Prague meeting.

1. Whether to keep the "Link overload" advertisement at area level or at link 
level.

In controller based deployments, it's useful to advertise the impending 
maintenance of the link to the controller so that controller can take
Special actions based on the information. The use case is described in sec 5.2 
in  the draft.
The draft advocates increasing the metric to usable high metric on both ends of 
the link. This is for backwards compatibility and to avoid need of flag
Day upgrade on all nodes.

 Controller cannot assign special meaning to the metric  for ex: Metric  
means the link going for maintenance and take different actions based on metric.

For a completely automated upgrade process, controller would need a fine 
grained and specific information that the link is going for maintenance so that 
the services that use the particular link find a different path forcefully 
while keeping the entire process non-disruptive.


2. Use of high metric  on either side of the link  to divert the traffic.

As I already mentioned before, draft advocates raising the reverse metric to a 
high metric  but that is for backwards compat

Re: [OSPF] AD review of draft-ietf-ospf-node-admin-tag-04

[Shraddha Hegde]

Thanks Hannes.

From: Hannes Gredler [mailto:han...@gredler.at]
Sent: Thursday, September 24, 2015 11:30 PM
To: Shraddha Hegde <shrad...@juniper.net>
Cc: Acee Lindem (acee) <a...@cisco.com>; Alia Atlas <akat...@gmail.com>; OSPF 
List <ospf@ietf.org>; draft-ietf-ospf-node-admin-...@ietf.org
Subject: Re: [OSPF] AD review of draft-ietf-ospf-node-admin-tag-04

i can be moved to contributors list as well if it helps.

On 24.09.2015, at 19:27, Shraddha Hegde 
<shrad...@juniper.net<mailto:shrad...@juniper.net>> wrote:
Alia,

Thank you very much for the review and comments.
I have updated the draft and draft-ietf-ospf-node-admin-tag-05 is posted.

Authors list has been reduced to 6 and one author moved to contributor’s list.
Here is the list of other comments and resolutions

1) In the abstract: "This optional operational capability allows to
   express and act upon locally-defined network policy which considers
   node properties conveyed by tags."

   What is the subject that "to express and act upon"?  Is it a router?
   Please clean up.
changed  to
“The node-tags can be used to express and apply locally-defined
network policies which is a very useful operational capability.”


2) In Sec 3.2: "The TLV SHOULD be considered an unordered list."  Perhaps
   "the value contents of the TLV" or something that makes it clearer?
Changed to
“The administrative tag list within the TLV SHOULD be considered
an unordered list.”


3) In Sec 4.3: " [RFC7490] proposed method of"  should be
   "[RFC7490] defines a method of"
 Updated

4) In Sec 5, I'm fairly certain that admin tags can leak additional
   information to an IGP snooper.  It would be useful to have some thoughts
   about that.

Node admin tags may be used by operators to indicate geographical location or 
other
sensitive information.
As indicated in  and  OSPF 
authentication
mechanisms do not provide  confidentiality and the information carried in node 
admin tags could be leaked to an IGP
snooper.

5) In IANA considerations, please duplicated the suggested value (10) that
   was mentioned in Sec 3.1

 Updated

Rgds
Shraddha


From: Acee Lindem (acee) [mailto:a...@cisco.com]
Sent: Wednesday, September 23, 2015 1:01 AM
To: Alia Atlas <akat...@gmail.com<mailto:akat...@gmail.com>>; OSPF List 
<ospf@ietf.org<mailto:ospf@ietf.org>>; 
draft-ietf-ospf-node-admin-...@ietf.org<mailto:draft-ietf-ospf-node-admin-...@ietf.org>
Subject: Re: [OSPF] AD review of draft-ietf-ospf-node-admin-tag-04

Thanks Alias - Speaking as Document Shepherd…

Authors,

Please let me know if you require any assistance - these all seem like good 
comments.

From: OSPF <ospf-boun...@ietf.org<mailto:ospf-boun...@ietf.org>> on behalf of 
Alia Atlas <akat...@gmail.com<mailto:akat...@gmail.com>>
Date: Tuesday, September 22, 2015 at 3:02 PM
To: OSPF WG List <ospf@ietf.org<mailto:ospf@ietf.org>>, 
"draft-ietf-ospf-node-admin-...@ietf.org<mailto:draft-ietf-ospf-node-admin-...@ietf.org>"
 
<draft-ietf-ospf-node-admin-...@ietf.org<mailto:draft-ietf-ospf-node-admin-...@ietf.org>>
Subject: Re: [OSPF] AD review of draft-ietf-ospf-node-admin-tag-04



On Tue, Sep 22, 2015 at 2:58 PM, Alia Atlas 
<akat...@gmail.com<mailto:akat...@gmail.com>> wrote:
As is customary, I have done my AD review of draft-ietf-ospf-node-admin-tag-04
before requesting IETF Last Call.

First, I'd like to thank the working group and Shraddha, Harish, Hannes, Rob,
Anton, Zhenbin, and Bruno for their hard work on the draft.  However, this short
draft has 7 authors, which is a couple over the author limit for RFCs.  
Experience
has shown that it takes much longer to process a draft through AUTH48 and the
other steps necessary (responsiveness to comments, agreement, etc) with a large
number of authors.  While I am willing to be persuaded - on or off list - that 
all 7
of the current authors are actively editing, I would prefer that a smaller 
number be
selected as the active editors.

In some cases, a draft represents a multi-vendor effort requiring a significant 
commitment from more than 5 authors and I’d specifically request a deviation 
from the author limit. I don’t see this to be the case with this draft.



While that discussion is ongoing, here are my technical comments.  In general,
the draft is in good shape but could use some English grammar editing; I have 
not
tried to indicate all the places where "the" is missing, for instance.

1) In the abstract: "This optional operational capability allows to
   express and act upon locally-defined network policy which considers
   node properties conveyed by tags."

   What is the subject that "to express and act upon"?  Is it a router?
   Please clean up.

2) In Sec 3.2: "The TLV SHOULD be considered an unordered list."  Perhaps
   "the val

Re: [OSPF] OSPF Link Overload - draft-hegde-ospf-link-overload-01

[Shraddha Hegde]

Acee,

Pls see inline..

Rgds
Shraddha

-Original Message-
From: Acee Lindem (acee) [mailto:a...@cisco.com] 
Sent: Tuesday, September 29, 2015 5:18 PM
To: Shraddha Hegde <shrad...@juniper.net>; OSPF WG List <ospf@ietf.org>
Cc: Pushpasis Sarkar <psar...@juniper.net>; Hannes Gredler <han...@gredler.at>; 
'Mohan Nanduri' <mnand...@microsoft.com>; Jalil, Luay <luay.ja...@verizon.com>
Subject: Re: OSPF Link Overload - draft-hegde-ospf-link-overload-01

Hi Shraddha, 

On 9/29/15, 1:07 AM, "Shraddha Hegde" <shrad...@juniper.net> wrote:

>Acee,
>
>Pls see inline...
>
>Rgds
>Shraddha
>
>-Original Message-
>From: Acee Lindem (acee) [mailto:a...@cisco.com]
>Sent: Monday, September 28, 2015 7:02 PM
>To: Shraddha Hegde <shrad...@juniper.net>; OSPF WG List <ospf@ietf.org>
>Cc: Pushpasis Sarkar <psar...@juniper.net>; Hannes Gredler 
><han...@gredler.at>; 'Mohan Nanduri' <mnand...@microsoft.com>; Jalil, 
>Luay <luay.ja...@verizon.com>
>Subject: Re: OSPF Link Overload - draft-hegde-ospf-link-overload-01
>
>Hi Shraddha,
>
>On 9/28/15, 1:13 AM, "Shraddha Hegde" <shrad...@juniper.net> wrote:
>
>>Acee,
>>
>>Thanks for picking up the draft for adoption.
>>
>>I believe this draft is very useful in automating the link upgrade 
>>process and software upgrade process in overlay deployments and hence 
>>support WG adoption as co-author.
>>
>>I would like to  take this opportunity to discuss  few of the points 
>>raised during Prague meeting.
>>
>>1. Whether to keep the "Link overload" advertisement at area level or 
>>at link level.
>>
>>In controller based deployments, it's useful to advertise the 
>>impending maintenance of the link to the controller so that controller 
>>can take Special actions based on the information. The use case is 
>>described in sec 5.2 in  the draft.
>>The draft advocates increasing the metric to usable high metric on 
>>both ends of the link. This is for backwards compatibility and to 
>>avoid need of flag Day upgrade on all nodes.
>
>I’m not sure why anyone would even consider using a mechanism other 
>than the metric to divert IP routed traffic. I don’t think we need to 
>discuss this any further as it only dilutes the discussion of the real 
>questions.
> Agree that it's sufficient to use the metric alone for ip 
>routed traffic. The area level information flooding is needed for TE 
>and controller based applications.
>  The LSPs are not brought down  if there is usable 
>metric on the link. We want to keep the metric (or TE metric) usable
>until traffic is diverted which is the whole purpose of the draft.
>  "Link overload" information is used as a 
>characteristic of the link ("like color")  and flood across area. 
>Ingress node (or controller) uses this information to re-compute
>   And move the LSP to a different path.
>
>>
>> Controller cannot assign special meaning to the metric  for ex: 
>>Metric  means the link going for maintenance and take different 
>>actions based on metric.
>
>Why does the controller care whether the link is out of service due to 
>maintenance or some other reason? In any case, the link is unavailable 
>and TE traffic should be diverted.
> The metric set on the link is still a usable metric (0x) 
>for OSPF and (0xfffe) for TE metric.  The metric needs to be usable 
>metric otherwise the whole process becomes disruptive.

You still didn’t answer my question. Why would the action for TE LSPs not 
always be to divert the traffic when the TE metric on one of the component 
links is 0xfffe. You still have not convinced me that the additional link 
attribute provides any value add beyond setting the metric to 0x and TE 
Metric to 0xfffe.

 oxfffe is a usable metric it does not mean link is out of 
service.
There may be some links which have been assigned this metric which aren't 
really going down for maintenance. (Well , I have personally seen a deployment 
which used such a weird metric on the link) IMHO we should not assign any 
special meaning to usable metric values.

I would like to repeat myself here that we do not want to use a metric that 
means link is out of service (For ex;0x)
If we do so , the LSP goes down and service is affected.


Thanks,
Acee





>
>> 
>>
>>For a completely automated upgrade process, controller would need a 
>>fine grained and specific information that the link is going for 
>>maintenance so that the services that use the particular link find a 
>>different path 

[OSPF] FW: OSPF Link Overload - draft-hegde-ospf-link-overload-01

[Shraddha Hegde]

Resending to mailing list as I didn't see it delivered in last posting...

Rgds
Shraddha

-Original Message-
From: Shraddha Hegde 
Sent: Monday, September 28, 2015 10:43 AM
To: 'Acee Lindem (acee)' <a...@cisco.com>; OSPF WG List <ospf@ietf.org>
Cc: Pushpasis Sarkar <psar...@juniper.net>; Hannes Gredler <han...@gredler.at>; 
'Mohan Nanduri' <mnand...@microsoft.com>; 'Jalil, Luay' <luay.ja...@verizon.com>
Subject: RE: OSPF Link Overload - draft-hegde-ospf-link-overload-01

Acee,

Thanks for picking up the draft for adoption.

I believe this draft is very useful in automating the link upgrade process and 
software upgrade process in overlay deployments and hence support WG adoption 
as co-author.

I would like to  take this opportunity to discuss  few of the points raised 
during Prague meeting.

1. Whether to keep the "Link overload" advertisement at area level or at link 
level.

In controller based deployments, it's useful to advertise the impending 
maintenance of the link to the controller so that controller can take Special 
actions based on the information. The use case is described in sec 5.2 in  the 
draft. 
The draft advocates increasing the metric to usable high metric on both ends of 
the link. This is for backwards compatibility and to avoid need of flag Day 
upgrade on all nodes.

 Controller cannot assign special meaning to the metric  for ex: Metric  
means the link going for maintenance and take different actions based on 
metric. 

For a completely automated upgrade process, controller would need a fine 
grained and specific information that the link is going for maintenance so that 
the services that use the particular link find a different path forcefully 
while keeping the entire process non-disruptive.


2. Use of high metric  on either side of the link  to divert the traffic.

As I already mentioned before, draft advocates raising the reverse metric to a 
high metric  but that is for backwards compatibility and to avoid Need for 
flag-day upgrade. There were suggestions at the Prague meeting to use lower 
bandwidth advertisements as well as removal of Link characteristics to force 
the services on different path. These mechanisms would be disruptive and 
defeats the purpose of the draft.

3.  Backward compatibility

"Link-overload"  is a new information attached to a link and is very similar to 
a new constraint being added to the link.
This information is non-invasive in the sense that services that do not want to 
look at the new constraint (link overload) May depend only on the metric to 
take specific actions.

Whereas services that have specialized requirement of providing non-disruptive 
upgrades can do so by processing the new constraint.

Section 4 in the draft talks about backwards compatibility.
I'll add more clarifications in the coming days.

Rgds
Shraddha


-Original Message-
From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Saturday, September 26, 2015 6:05 AM
To: OSPF WG List <ospf@ietf.org>
Subject: [OSPF] OSPF Link Overload - draft-hegde-ospf-link-overload-01

In Prague, there was consensus in the room that this use case was not covered 
by existing mechanisms and that it was a problem the WG should solve. There 
were differing opinions as to the exact solution but that should not preclude 
OSPF WG adoption.

Please indicate your support (or concerns) for adopting this as a WG Document. 


Thanks,
Acee 


___
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

Re: [OSPF] OSPF Link Overload - draft-hegde-ospf-link-overload-01

[Shraddha Hegde]

Acee,

Thanks for picking up the draft for adoption.

I believe this draft is very useful in automating the link upgrade process and 
software upgrade process in overlay deployments and
hence support WG adoption as co-author.

I would like to  take this opportunity to discuss  few of the points raised 
during Prague meeting.

1. Whether to keep the "Link overload" advertisement at area level or at link 
level.

In controller based deployments, it's useful to advertise the impending 
maintenance of the link to the controller so that controller can take
Special actions based on the information. The use case is described in sec 5.2 
in  the draft. 
The draft advocates increasing the metric to usable high metric on both ends of 
the link. This is for backwards compatibility and to avoid need of flag
Day upgrade on all nodes.

 Controller cannot assign special meaning to the metric  for ex: Metric  
means the link going for maintenance and take different actions based on 
metric. 

For a completely automated upgrade process, controller would need a fine 
grained and specific information that the link is going for maintenance so that 
the services that use the particular link find a different path forcefully 
while keeping the entire process non-disruptive.


2. Use of high metric  on either side of the link  to divert the traffic.

As I already mentioned before, draft advocates raising the reverse metric to a 
high metric  but that is for backwards compatibility and to avoid 
Need for flag-day upgrade. There were suggestions at the Prague meeting to use 
lower bandwidth advertisements as well as removal of
Link characteristics to force the services on different path. These mechanisms 
would be disruptive and defeats the purpose of the draft.

3.  Backward compatibility

"Link-overload"  is a new information attached to a link and is very similar to 
a new constraint being added to the link.
This information is non-invasive in the sense that services that do not want to 
look at the new constraint (link overload)
May depend only on the metric to take specific actions.

Whereas services that have specialized requirement of providing non-disruptive 
upgrades can do so by processing the new constraint.

Section 4 in the draft talks about backwards compatibility.
I'll add more clarifications in the coming days.

Rgds
Shraddha


-Original Message-
From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Saturday, September 26, 2015 6:05 AM
To: OSPF WG List 
Subject: [OSPF] OSPF Link Overload - draft-hegde-ospf-link-overload-01

In Prague, there was consensus in the room that this use case was not covered 
by existing mechanisms and that it was a problem the WG should solve. There 
were differing opinions as to the exact solution but that should not preclude 
OSPF WG adoption.

Please indicate your support (or concerns) for adopting this as a WG Document. 


Thanks,
Acee 


___
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

Re: [OSPF] AD review of draft-ietf-ospf-rfc4970bis-02

[Shraddha Hegde]

Acee,

I agree that the MT –ID granularity is not required for the informational 
capability TLV as it  “more of” indicates whether router supports the
Feature or not.

Functional capabilities TLV is newly added in 4970bis. My read is that this TLV 
can be used to indicate whether the router
Currently has enabled the feature or not and take protocol actions based on 
this information.
It makes sense to add one functional capability TLV per MT-ID in MT deployments.
When the new features need to use the functional capability  TLV to advertise 
just their capabilities
and do not have additional information, just a functional capability bit should 
suffice and no new sub TLV definitions would be needed.
This looks more elegant and is compact from protocol message length perspective.

Having said that, it may be worthwhile to discuss in WG whether we need to 
consider MT based deployments while
defining the new protocol extensions. In general, there seems to be less 
interest in deploying multi-topology.

Rgds
Shraddha

From: Acee Lindem (acee) [mailto:a...@cisco.com]
Sent: Wednesday, September 23, 2015 4:01 AM
To: Alia Atlas <akat...@gmail.com>; OSPF List <ospf@ietf.org>; 
draft-ietf-ospf-rfc4970...@ietf.org; Shraddha Hegde <shrad...@juniper.net>
Subject: Re: [OSPF] AD review of draft-ietf-ospf-rfc4970bis-02

Hi Alia, Shraddha,

From: OSPF <ospf-boun...@ietf.org<mailto:ospf-boun...@ietf.org>> on behalf of 
Alia Atlas <akat...@gmail.com<mailto:akat...@gmail.com>>
Date: Tuesday, September 22, 2015 at 6:10 PM
To: OSPF WG List <ospf@ietf.org<mailto:ospf@ietf.org>>, 
"draft-ietf-ospf-rfc4970...@ietf.org<mailto:draft-ietf-ospf-rfc4970...@ietf.org>"
 
<draft-ietf-ospf-rfc4970...@ietf.org<mailto:draft-ietf-ospf-rfc4970...@ietf.org>>
Subject: Re: [OSPF] AD review of draft-ietf-ospf-rfc4970bis-02

Minor correction:

On Tue, Sep 22, 2015 at 6:00 PM, Alia Atlas 
<akat...@gmail.com<mailto:akat...@gmail.com>> wrote:
As is customary, I have done my AD review of draft-ietf-ospf-rfc4970bis-02.  
First, let me thank Acee for his work on this draft.

I have two major concerns before asking for an IETF Last Call.  I would like to 
have them
resolved by this Thursday so that the draft can make the Oct 15 IESG telechat.

First, from a process concern, I do not see any active discussion on the OSPF 
mailing list - even to simply say "yes - go forward".  I don't see anything 
about this draft or discussion in minutes for IETF 92 or IETF 93.   I'd prefer 
some indication besides silence and lack of opposition.  I do realize that 
there are some process or protocol-tidying drafts where there isn't
much interest.  However, I am particularly concerned because this is changing 
RFC4970 is a way that should be backwards compatible but might trigger issues.  
 I would encourage WG participants to PLEASE RESPOND!

In IETF 91 minutes, I see a presentation and question from Shraddha about 
making it MT capable.  There was no
answer except take it to the list and no follow-up discussion.

My answer would be that not all capabilities are scoped at an MT level of 
granularity it is incumbent on the definition of those that are to include the 
MT ID in the definition.

Thanks,
Acee





Am I missing anything?

Regards,
Alia


Second, I can see the intent that by creating an Opaque ID and creating a 
special meaning for 0, the draft is making efforts to preserve backwards 
compatibility.  Please add a paragraph or subsection that articulates how and 
why backwards compatibility isn't an issue.  For extra credit, what happens if 
the same TLV information is advertised in multiple RI LSAs (as part of moving 
it from one RI LSA to another)?

Are there any implementations of this draft?  Has backwards compatibility been 
verified at all?

My minor issue is around the IANA considerations; I have detailed comments 
below.

Here are additional comments.

1) In Sec 2: "The first Opaque ID, i.e., 0, should always contain the Router
   Informational Capabilities TLV and, if advertised, the Router
   Functional Capabilities TLV."  and Sec 2.2 "The first instance ID, i.e., 0,
   should always contain the Router Informational Capabilities TLV and,
   if advertised, the Router Functional Capabilities TLV."

   Since I assume this is important for backwards compatibility, should those
   be SHOULD instead of should?

2) In Sec 2.3: "The first defined TLV in the body of an RI LSA is the Router
   Informational Capabilities TLV."

   Surely that is only for the first Opaque ID=0?  Does each subsequent RI LSA
   also need to contain a Router Informational Capabilities TLV??

3) In Sec 4 IANA Considerations:  This section is defining the different IANA 
policies;
when RFC4970 was written, RFC5226 didn't exist.  But since you're doing a bis,
perhaps you can align to the policies in RFC5226 and remove the unnecessary 
text??

4) In Sec

Re: [OSPF] Working Group Last Call for Advertising per-node administrative tags in OSPF - draft-ietf-ospf-node-admin-tag-02

[Shraddha Hegde]

Acee,

Agree with you that the interpretation should be that the node tags for certain 
router is  the super set of all the tags from all node-admin tag TLVs from all 
instances of RI LSA advertised by that router.
Will update the document.

Rgds
Shraddha

-Original Message-
From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Friday, August 21, 2015 5:21 AM
To: Acee Lindem (acee) a...@cisco.com; OSPF WG List ospf@ietf.org
Subject: Re: [OSPF] Working Group Last Call for Advertising per-node 
administrative tags in OSPF - draft-ietf-ospf-node-admin-tag-02

Authors, 

In the “Elements of Procedure” section, please address how multiple instances 
of the TLV will be handled. At a minimum, the following cases must be handled:

 1. Multiple instances of the TLV in the same OSPF(v3) Router Information 
LSA
 2. Multiple instances of the TLV in multiple OSPF(v3) Router Information 
LSA instances
 3. Removal an instance of the TLV in an OSPF(v3) Router Information LSA 
through re-origination
 4. Purge of an OSPF(v3) Router Information LSA containing the node admin 
tags TLV. 

One possible interpretation (and probably the simplest) is that the set of 
valid tags for a given OSPF(v3) router is the superset of the tags in all the 
existing OSPF(v3) Router Information LSAs advertised by that router.

Thanks,
Acee  
  





On 7/23/15, 2:24 PM, OSPF on behalf of Acee Lindem (acee)
ospf-boun...@ietf.org on behalf of a...@cisco.com wrote:

This begins the WG last call for the subject draft. Please send your 
comments to this list prior to 12:00 AM GMT, August 22th, 2015. Note 
that we are doing a 4 week WG last call due to the volume of IETF WG 
last calls made this week and the fact that many WG participants may be 
taking vacation in August.

Thanks,
Acee

___
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

[OSPF] FW: New Version Notification for draft-hegde-rtgwg-virtual-multi-instance-00.txt

[Shraddha Hegde]

Dear OSPF/ ISIS WG members,

The  below internet draft posted in RTGWG provides mechanisms to contain 
flooding information in OSPF and ISIS.
There are no protocol changes but there are rules  and default behaviors 
defined for OSPF and ISIS and needs to be
followed by neighboring routers to interoperate.
Kindly review and provide inputs and suggestions.

https://datatracker.ietf.org/doc/draft-hegde-rtgwg-virtual-multi-instance/

Rgds
Shraddha


-Original Message-
From: rtgwg [mailto:rtgwg-boun...@ietf.org] On Behalf Of Shraddha Hegde
Sent: Wednesday, July 01, 2015 9:13 AM
To: rt...@ietf.org
Cc: Ross Callon rcal...@juniper.net; Salih K A sa...@juniper.net; Mannan 
Venkatesan mannan_venkate...@cable.comcast.com; Alia Atlas 
akat...@juniper.net
Subject: RE: New Version Notification for 
draft-hegde-rtgwg-virtual-multi-instance-00.txt

All,

A new internet draft is posted which provides a mechanism to contain flooding 
information for link state protocols  for specific topologies.

Kindly review and provide your suggestions.


Rgds
Shraddha

-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
Sent: Wednesday, July 01, 2015 9:03 AM
To: Shraddha Hegde; Ross Callon; Alia Atlas; Shraddha Hegde; Alia Atlas; Mannan 
Venkatesan; Ross Callon; Mannan Venkatesan
Subject: New Version Notification for 
draft-hegde-rtgwg-virtual-multi-instance-00.txt


A new version of I-D, draft-hegde-rtgwg-virtual-multi-instance-00.txt
has been successfully submitted by Shraddha Hegde and posted to the IETF 
repository.

Name:   draft-hegde-rtgwg-virtual-multi-instance
Revision:   00
Title:  Virtual multi-instancing for link state protocols
Document date:  2015-06-30
Group:  Individual Submission
Pages:  15
URL:
https://www.ietf.org/internet-drafts/draft-hegde-rtgwg-virtual-multi-instance-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-hegde-rtgwg-virtual-multi-instance/
Htmlized:   
https://tools.ietf.org/html/draft-hegde-rtgwg-virtual-multi-instance-00


Abstract:
   In networks with routers of different capabilities, some routers may
   not be able to participate fully in supporting new features or
   handling large databases and the associated flooding.  In some cases,
   these restrictions can cause severe scalability issues for the
   network in general.  This document proposes virtual multi-instances,
   a generic mechanism for OSPF and IS-IS, that allows groups of routers
   in specific topologies to have a reduced database and reduces the
   topology changes that are seen.  The virtual multi-instances are
   specified so that no software or protocol changes are required in the
   restricted routers.  Due to the potential number of virtual multi-
   instances in a network, the configuration is limited and is not
   specified per virtual instance.



  


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.

The IETF Secretariat

___
rtgwg mailing list
rt...@ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg

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

Re: [OSPF] Advertising per-node administrative tags in OSPF - draft-ietf-ospf-node-admin-tag-02 - IPR Poll

[Shraddha Hegde]

I am not aware of any IPR other than disclosed by Juniper.

Rgds
Shraddha

-Original Message-
From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Thursday, July 23, 2015 2:18 PM
To: draft-ietf-ospf-node-admin-...@tools.ietf.org
Cc: OSPF WG List ospf@ietf.org
Subject: [OSPF] Advertising per-node administrative tags in OSPF - 
draft-ietf-ospf-node-admin-tag-02 - IPR Poll

Draft Authors,
In preparation for WG last call, please indicate whether you are aware of any 
relevant IPR and if so, whether it has been disclosed.
Thanks,
Acee

___
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] FW: New Version Notification for draft-ietf-ospf-node-admin-tag-02.txt

[Shraddha Hegde]

Hi All,
  
   New version of the draft-ietf-ospf-node-admin-tag has been posted for your 
review and comments.
The draft has undergone multiple review/revision cycles  among authors to 
address editorial
comments received from authors as well as WG members.
 There hasn't been any protocol  or significant process change from last 
version.

Rgds
Shraddha


-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
Sent: Monday, June 01, 2015 2:09 PM
To: Shraddha Hegde; Anton Smirnov; Anton Smirnov; Bruno Decraene; Zhenbin Li; 
Rob Shakir; Hannes Gredler; Shraddha Hegde; Harish Raghuveer; Rob Shakir; 
Harish Raghuveer; Huawei Technologies; Bruno Decraene; Hannes Gredler
Subject: New Version Notification for draft-ietf-ospf-node-admin-tag-02.txt


A new version of I-D, draft-ietf-ospf-node-admin-tag-02.txt
has been successfully submitted by Shraddha Hegde and posted to the IETF 
repository.

Name:   draft-ietf-ospf-node-admin-tag
Revision:   02
Title:  Advertising per-node administrative tags in OSPF
Document date:  2015-06-01
Group:  ospf
Pages:  12
URL:
https://www.ietf.org/internet-drafts/draft-ietf-ospf-node-admin-tag-02.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-ospf-node-admin-tag/
Htmlized:   https://tools.ietf.org/html/draft-ietf-ospf-node-admin-tag-02
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-node-admin-tag-02

Abstract:
   This document describes an extension to OSPF protocol [RFC2328] to
   add an optional operational capability, that allows tagging and
   grouping of the nodes in an OSPF domain.  This allows simplification,
   ease of management and control over route and path selection based on
   configured policies.  This document describes an extension to OSPF
   protocol [RFC2328] to advertise per-node administrative tags.  This
   optional operational capability allows to express and act upon
   locally-defined network policy which considers node properties
   conveyed by tags.  Node tags may be used either by OSPF itself or by
   other applications consuming information propagated via OSPF.

   This document describes the protocol extensions to disseminate per-
   node administrative-tags to the OSPFv2 and OSPFv3 protocol.  It
   provides example use cases of administrative node tags.



  


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.

The IETF Secretariat

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

Re: [OSPF] Link Overload references

[Shraddha Hegde]

Thanks Alvaro. Will take care of these.

Rgds
Shraddha

From: Alvaro Retana (aretana) [mailto:aret...@cisco.com]
Sent: Saturday, March 21, 2015 4:50 AM
To: draft-hegde-ospf-link-overl...@tools.ietf.org
Cc: ospf@ietf.org
Subject: Link Overload references

Hi!

Just a quick note to say that the reference to rfc3137 should be updated to 
point to rfc6987.

Also, in rfc6987 we defined the new architectural value of MaxLinkMetric, which 
should be used instead of MAX-METRIC.

Thanks!

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

Re: [OSPF] Comments on draft-ietf-ospf-node-admin-tag-00

[Shraddha Hegde]

Les,

Thanks for the review and comments.
Pls see in-line..

I have some comments in this draft.

---Introduction

---I think the last sentence should be removed. It is providing an example of a 
use case - and as such is more appropriate for Section 5. 

---Also, node-tags are a property of the node - not of the routing protocol 
used to advertise them - I would like to see this point explicitly stated. 
Perhaps something like:

---Per-node administrative tags are used to advertise an attribute of the 
node. As such they are independent of the routing protocol used to advertise 
them. 

Shraddha Will work on the rewording of introduction section.


Section 2
---

This section seems redundant w Section 1. It should be removed.

Shraddha I think this section is needed to explicitly imply that the tags are 
used for TE as well as non-TE applications.

Section 3 - Last Paragraph
--
What is the reason for restricting the # of tags in a single TLV to 64? As OSPF 
TLVs have a 16 bit length field this restriction seems arbitrary.

Shraddha This was suggestion from Acee to restrict it to prevent the RI LSA 
overflowing. Since we have multi instanced RI-LSA this restriction can be 
removed.
   Will update the draft for this.

Figure 1
---
The format of the ASCII art above needs to be corrected to properly indicate 
the field lengths.

Shraddha OK

Section 5
-

I would like to see this section moved to an Appendix. Since this section is 
not normative that would more clearly separate the normative/non-normative 
parts.

ShraddhaUse cases section gives information on the motivation of the draft 
and looks necessary to be in the draft sections than moving it to appendix.

Rgds
Shraddha

-Original Message-
From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Les Ginsberg (ginsberg)
Sent: Monday, February 23, 2015 9:02 PM
To: OSPF List (ospf@ietf.org); draft-ietf-ospf-node-admin-...@tools.ietf.org
Subject: [OSPF] Comments on draft-ietf-ospf-node-admin-tag-00

I have some comments in this draft.

Introduction

I think the last sentence should be removed. It is providing an example of a 
use case - and as such is more appropriate for Section 5. 

Also, node-tags are a property of the node - not of the routing protocol used 
to advertise them - I would like to see this point explicitly stated. Perhaps 
something like:

Per-node administrative tags are used to advertise an attribute of the node. 
As such they are independent of the routing protocol used to advertise them. 




Section 2
---

This section seems redundant w Section 1. It should be removed.

Section 3 - Last Paragraph
--
What is the reason for restricting the # of tags in a single TLV to 64? As OSPF 
TLVs have a 16 bit length field this restriction seems arbitrary.

Figure 1
---
The format of the ASCII art above needs to be corrected to properly indicate 
the field lengths.

Section 5
-

I would like to see this section moved to an Appendix. Since this section is 
not normative that would more clearly separate the normative/non-normative 
parts.

   Les

___
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

Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-ospf-segment-routing-extensions

[Shraddha Hegde]

Les,

Pls consider a case when the post convergence path goes through a different 
node and is well provisioned.

 G---
| |
ABCD
|   |
  EF

When the link between B  C goes down, we don’t want to divert the traffic via 
B-E-E-F-C because it is not well provisioned for the service.
The post convergence path is A-G-D which is well provisioned.
In this case it makes sense to simply avoid protection for the service as the 
nature of the service is such that it can be disconnected and reconnected 
without impacting the end user of the service.


The post convergence paths need to be provisioned at least for one failure if 
that is not the case then the service will remain down
Irrespective of the technology used.


Rgds
Shraddha

-Original Message-
From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] 
Sent: Monday, January 05, 2015 12:07 PM
To: Pushpasis Sarkar; Shraddha Hegde; Peter Psenak (ppsenak); 
draft-ietf-ospf-segment-routing-extensi...@tools.ietf.org; 
draft-ietf-isis-segment-routing-extensi...@tools.ietf.org; Hannes Gredler
Cc: ospf@ietf.org; isis...@ietf.org
Subject: RE: [OSPF] [Isis-wg] Mail regarding 
draft-ietf-ospf-segment-routing-extensions

Pushpasis -

Inline.

-Original Message-
From: Pushpasis Sarkar [mailto:psar...@juniper.net]
Sent: Sunday, January 04, 2015 10:13 PM
To: Les Ginsberg (ginsberg); Shraddha Hegde; Peter Psenak (ppsenak); 
draft-ietf-ospf-segment-routing-extensi...@tools.ietf.org; 
draft-ietf-isis-segment-routing-extensi...@tools.ietf.org; Hannes Gredler
Cc: ospf@ietf.org; isis...@ietf.org
Subject: Re: [OSPF] [Isis-wg] Mail regarding 
draft-ietf-ospf-segment-routing-extensions

Hi Les,


On 1/5/15, 11:23 AM, Les Ginsberg (ginsberg) ginsb...@cisco.com wrote:

Pushpasis -

The key point is that the proposal does not have any lasting impact on 
traffic flow. A simple topology should suffice to illustrate this.


ABCD
  |   |
  EF

(All links have the same cost)

Suppose we wish to have traffic entering at A flow along the path 
A-B-C-D
- but if the link B---C fails we do NOT want traffic to take the path 
B--E--F--C.

You propose to have C advertise an address with two node-sids - one 
which allows protection - call it C(P) - and one which does NOT allow 
protection - call it C(NP).
[Pushpasis] No. My proposal is for D to advertise two node sids, D1 with NP set 
to 0 and D2 with NP set to 1. Applications on that do not need B, or C to 
protect the A-B-C-D path will use D2. B and C will not install backup paths for 
D2. Other apps can use D1 as they are supposed to do otherwise. Wether to 
protect D1 or not is a local decision of B and C.
Hope I could clarify enough :)

[Les:] Whether we talk about C or D doesn’t matter. As you point out below the 
issue you are concerned with is the FIB update time on the intermediate nodes 
relative to the recomputation on the ingress node.


If the label stack specifies C(NP) - then while the link B--C is UP 
everything works as desired (primary path to C(NP) on Node B is via 
link B-C).
However, when the link B--C goes down, the network will reconverge and 
in a modest amount of time the new primary path to C(NP) on node B will 
be via link B-E.
[Pushpasis] Yes agreed. But only applications on A will be injecting traffic 
using D2. Once the B-C link-down event reaches router A will stop injecting 
traffic using D2. A path re-compute will be triggered on A. Yes I agree that if 
B converges D2 (not FRR) before A re-compute, there is still chance that some 
small amount of traffic is sent over A-B-E-F-C-D.

[Les:] Well yes - the key point is that you cannot guarantee the timing of when 
B (for example) will reconverge relative to when the ingress node A decides to 
reroute/drop the D2 traffic. Given that B is closer to the failure it is quite 
likely that B will respond more quickly than A - and of course there are many 
other variables which could affect the relative response time of A and B. So 
the sole benefit of what you propose seems to be that in some cases you MIGHT 
not send as much traffic to D2 via the undesired links.

At this point I think you would do well to look at the existing solutions - as 
well as Jeff's post on this thread which provides an excellent framework for 
thinking about solutions. We do have ways of addressing this problem and doing 
so far more robustly than what you are proposing. The ROI for what you propose 
is quite low. For my part I don’t think what you propose is a good idea.

Les


The existence of C(NP) therefore only affects traffic flow during the 
reconvergence period i.e. if we assume B did NOT install a repair path 
for C(NP) traffic will be dropped only until a new primary path is 
calculated. I don’t see the value in this.

As a (somewhat dangerous) aside, the functionality you are looking for 
is more akin to not-via as defined in RFC 6981 - though I am quick to 
add

Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-ospf-segment-routing-extensions

[Shraddha Hegde]

Les,


I agree with the point you made that the requirement of not protecting certain 
services can be met today using the
LFA-manageability draft. Deploying the solution using LFA manageability 
requires that the 

1. Services be represented by different prefixes
2. Come up with a policy that makes sure no backup path is downloaded for the 
prefix
3. Configure  the policy in each node in the network.
4. Repeat the process whenever a new service with similar characteristic comes 
up


The advantage of having an unprotected path to each node is the ease of 
deployment.
LFA-manageability has its own advantage of fine tuning the backup paths and I 
am not denying that.
I am trying to say that for certain use-cases it is easy to have unprotected 
paths in the network for each node
And use those path for services that need such paths.

If someone wants to simply have a unprotected path for certain node and use it 
for all the services
Which don't need protection, that flexibility should be available in the 
protocol. 
That is the reason I am saying that we should have No protection flag in the 
prefix-SID.


Rgds
Shraddha

-Original Message-
From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] 
Sent: Monday, January 05, 2015 3:37 AM
To: Pushpasis Sarkar; Shraddha Hegde; Peter Psenak (ppsenak); 
draft-ietf-ospf-segment-routing-extensi...@tools.ietf.org; 
draft-ietf-isis-segment-routing-extensi...@tools.ietf.org
Cc: ospf@ietf.org; isis...@ietf.org
Subject: RE: [OSPF] [Isis-wg] Mail regarding 
draft-ietf-ospf-segment-routing-extensions

Pushpasis -

I don't agree.

The use of one node-sid vs another has nothing whatever to do with the request 
Shraddha has made i.e. should we introduce a flag indicating whether a 
particular prefix should be protected or not. A node-sid only dictates what 
(intermediate) node traffic should be sent to - not what link(s) are used to 
reach that node.

Adjacency-sids have a different semantic - they identify the link over which 
traffic is to be forwarded. Identifying an adjacency-sid as unprotected means 
traffic will NEVER flow over a different link. There is no equivalent behavior 
w a node-sid - which is what this discussion has been about.

   Les


-Original Message-
From: Pushpasis Sarkar [mailto:psar...@juniper.net]
Sent: Sunday, January 04, 2015 8:51 AM
To: Les Ginsberg (ginsberg); Shraddha Hegde; Peter Psenak (ppsenak); 
draft-ietf-ospf-segment-routing-extensi...@tools.ietf.org; 
draft-ietf-isis-segment-routing-extensi...@tools.ietf.org
Cc: ospf@ietf.org; isis...@ietf.org
Subject: Re: [OSPF] [Isis-wg] Mail regarding 
draft-ietf-ospf-segment-routing-extensions

Hi Les,

I think the requirement Shraddha is referring is about the choice of exact 
node-sid to use while constructing the label-stack for a explicit-LSP on the 
ingress router, which will be typically done after running some CSPF on the 
SPRING topology. And not the IGP on ingress or transit routers.

Thanks
-Pushpasis

On 1/3/15, 3:10 AM, Les Ginsberg (ginsberg) ginsb...@cisco.com wrote:

Shraddha -

IGPs today do NOT perform constraint based SPFs - so I don't know why 
you believe that the primary SPF will meet a set of constraints that an 
LFA calculation will not. In fact , it is the opposite which is true 
because implementations today do support preferences in choosing LFAs 
based on various configured policy - something which is NOT done for primary 
SPF.

If you want a certain class of traffic to avoid a subset of the links 
in the topology then you need to have a way of identifying the links 
(NOT the node addresses) and a way of calculating a path which only 
uses the links which meet the constraints of that class of service.
Identifying a particular prefix as protected or unprotected won't achieve that.

   Les

-Original Message-
From: Shraddha Hegde [mailto:shrad...@juniper.net]
Sent: Friday, January 02, 2015 10:54 AM
To: Les Ginsberg (ginsberg); Peter Psenak (ppsenak); 
draft-ietf-ospf-segment-routing-extensi...@tools.ietf.org;
draft-ietf-isis-segment-routing-extensi...@tools.ietf.org
Cc: ospf@ietf.org; isis...@ietf.org
Subject: RE: [Isis-wg] Mail regarding
draft-ietf-ospf-segment-routing-extensions

Hi Les/Peter,

  When reconvergence happens, the primary path will be calculated 
based on all constriants.
This is not true with the protection path.Protection path is calculated 
locally (LFA/RLFA)  and does not consider the characteristics of the 
services running on that path.
It's easier for some services to pick the unprotected path when the 
nature of the service is that it can be restarted  when there is a 
disconnection.

Rgds
Shraddha
-Original Message-
From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Friday, January 02, 2015 10:06 PM
To: Peter Psenak (ppsenak); Shraddha Hegde; 
draft-ietf-ospf-segment-routing-extensi...@tools.ietf.org;
draft-ietf-isis-segment-routing-extensi...@tools.ietf.org
Cc: ospf@ietf.org; isis

Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-ospf-segment-routing-extensions

[Shraddha Hegde]

Hi Les/Peter,

  When reconvergence happens, the primary path will be calculated based on 
all constriants.
This is not true with the protection path.Protection path is calculated locally 
(LFA/RLFA)  and does not consider the characteristics of
the services running on that path. 
It's easier for some services to pick the unprotected path when the nature of 
the service is that it can be restarted  when there is a disconnection.

Rgds
Shraddha
-Original Message-
From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] 
Sent: Friday, January 02, 2015 10:06 PM
To: Peter Psenak (ppsenak); Shraddha Hegde; 
draft-ietf-ospf-segment-routing-extensi...@tools.ietf.org; 
draft-ietf-isis-segment-routing-extensi...@tools.ietf.org
Cc: ospf@ietf.org; isis...@ietf.org
Subject: RE: [Isis-wg] Mail regarding draft-ietf-ospf-segment-routing-extensions

Peter -

The requirement Shraddha specified was to not allow a particular class of 
service (heavy bandwidth services was the example provided) to use certain 
links in the topology. My point is that advertising a flag for a given prefix 
which says do not calculate a repair path for this prefix does not help 
achieve this. Once the network reconverges following the failure of one of the 
links on which heavy bandwidth services is allowed/preferred it is quite 
likely that the new best path will be over a link on which heavy bandwidth 
services is NOT allowed/preferred. This will happen whether you have the new 
flag or not - so the flag will have no lasting effect. It would only affect 
traffic flow during the brief period during which the network is reconverging.

I think you and I are actually in agreement - I am simply sending a stronger 
negative message - not only do I think the flag is not useful - I think it does 
not achieve the goal Shraddha has in mind.

   Les


-Original Message-
From: Peter Psenak (ppsenak)
Sent: Friday, January 02, 2015 12:18 AM
To: Les Ginsberg (ginsberg); Shraddha Hegde; 
draft-ietf-ospf-segment-routing-extensi...@tools.ietf.org; 
draft-ietf-isis-segment-routing-extensi...@tools.ietf.org
Cc: ospf@ietf.org; isis...@ietf.org
Subject: Re: [Isis-wg] Mail regarding draft-ietf-ospf-segment-routing-extensions

Hi Les,

I believe the idea is not to exclude any particular link, it's actually much 
simpler - do not calculate backup for the prefix if the flag is set.

I'm still not quite sure how useful above is, but technically it is possible.

thanks,
Peter

On 12/30/14 17:22 , Les Ginsberg (ginsberg) wrote:
 Shraddha -

 When performing a best path calculation whether a given link is in the set of 
 best paths (to be protectedED) or not (could be used as a protectING path) is 
 a function of the topology - not the link.  If there is a topology change it 
 is quite likely that a given link will change from being a protectED link to 
 being a protectING link (or vice versa). So what you propose regarding 
 node-SIDs would not work.

 In the use case you mention below if you don't want a certain class of 
 traffic to flow on a given link it requires a link attribute which is 
 persistent across topology changes. There are ways to do that - using 
 Adj-SIDs is one of them. But using node-SIDs in the way you propose is NOT.

 Les

 -Original Message-
 From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Shraddha Hegde
 Sent: Monday, December 29, 2014 10:12 PM
 To: Peter Psenak (ppsenak);
 draft-ietf-ospf-segment-routing-extensi...@tools.ietf.org;
 draft-ietf-isis-segment-routing-extensi...@tools.ietf.org
 Cc: ospf@ietf.org; isis...@ietf.org
 Subject: Re: [OSPF] [Isis-wg] Mail regarding 
 draft-ietf-ospf-segment-routing-extensions

 Peter,

 The requirement here is to get an un-protected path for services which do 
 not want to divert the traffic on protected path in any case.

 can you give an example of such a service and a reasoning why such service 
 would want to avoid local protection along the path?

 Heavy bandwidth services are potential candidates.  The network is well 
 planned and well provisioned for primary path but same is not true for backup 
 paths.
 Diverting heavy bandwidth services along protection path can disrupt the 
 other services on that path, they are better-off un-protected so that an 
 event in the network Would result in disconnection and a retry for such 
 services.

 Rgds
 Shraddha

 -Original Message-
 From: Peter Psenak [mailto:ppse...@cisco.com]
 Sent: Monday, December 29, 2014 4:35 PM
 To: Shraddha Hegde;
 draft-ietf-ospf-segment-routing-extensi...@tools.ietf.org;
 draft-ietf-isis-segment-routing-extensi...@tools.ietf.org
 Cc: ospf@ietf.org; isis...@ietf.org
 Subject: Re: [Isis-wg] Mail regarding 
 draft-ietf-ospf-segment-routing-extensions

 Shraddha,

 On 12/29/14 10:06 , Shraddha Hegde wrote:
 Peter,

 The requirement here is to get an un-protected path for services which do 
 not want to divert the traffic on protected path in any case.

 can you give an example

Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-ospf-segment-routing-extensions

[Shraddha Hegde]

Peter,

If there is a service which has to use un-protected path and while building 
such a path if the node-sids 
Need to be used (one reason could be label stack compression) , then there has 
to be unprotected node-sid that
this service can make use of. 

Prefix -sids could also be used to represent different service endpoints which 
makes it even more relevant to have 
A means of representing  unprotected paths.

Would be good to hear from others on this, especially operators.

Rgds
Shraddha


-Original Message-
From: Peter Psenak [mailto:ppse...@cisco.com] 
Sent: Monday, December 29, 2014 1:35 PM
To: Shraddha Hegde; draft-ietf-ospf-segment-routing-extensi...@tools.ietf.org; 
draft-ietf-isis-segment-routing-extensi...@tools.ietf.org
Cc: ospf@ietf.org; isis...@ietf.org
Subject: Re: [Isis-wg] Mail regarding draft-ietf-ospf-segment-routing-extensions

Shraddha,

node-SID is advertised by the router for the prefix that is directly attached 
to it. Protection for such local prefix does not mean much.

thanks,
Peter

On 12/24/14 11:57 , Shraddha Hegde wrote:
 Authors,
 We have a backup flag in adjacency sid to indicate whether the label 
 is protected or not.
 Similarly. I think we need a flag in prefix-sid as well to indicate 
 whether the node-sid is to be protected or not.
 Any thoughts on this?
 Rgds
 Shraddha


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


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

Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-ospf-segment-routing-extensions

[Shraddha Hegde]

Yes.You are right.

Lets say a prefix sid has a flag p flag. If this is on it means build a path 
and provide protection.
If this is off it means build a path with no protection.
The receivers of the prefix-sid will build forwarding plane based on this flag.

The applications building the paths will either use prefix-sids with p flag on 
or off based on the need of the service.
Rgds
Shraddha


-Original Message-
From: Peter Psenak [mailto:ppse...@cisco.com] 
Sent: Monday, December 29, 2014 1:49 PM
To: Shraddha Hegde; draft-ietf-ospf-segment-routing-extensi...@tools.ietf.org; 
draft-ietf-isis-segment-routing-extensi...@tools.ietf.org
Cc: ospf@ietf.org; isis...@ietf.org
Subject: Re: [Isis-wg] Mail regarding draft-ietf-ospf-segment-routing-extensions

Shraddha,

the problem is that the node that is advertising the node-sid can not advertise 
any data regarding the protection of such prefix, because the prefix is locally 
attached.

thanks,
Peter

On 12/29/14 09:15 , Shraddha Hegde wrote:
 Peter,

 If there is a service which has to use un-protected path and while 
 building such a path if the node-sids Need to be used (one reason 
 could be label stack compression) , then there has to be unprotected node-sid 
 that this service can make use of.

 Prefix -sids could also be used to represent different service 
 endpoints which makes it even more relevant to have A means of representing  
 unprotected paths.

 Would be good to hear from others on this, especially operators.

 Rgds
 Shraddha


 -Original Message-
 From: Peter Psenak [mailto:ppse...@cisco.com]
 Sent: Monday, December 29, 2014 1:35 PM
 To: Shraddha Hegde; 
 draft-ietf-ospf-segment-routing-extensi...@tools.ietf.org; 
 draft-ietf-isis-segment-routing-extensi...@tools.ietf.org
 Cc: ospf@ietf.org; isis...@ietf.org
 Subject: Re: [Isis-wg] Mail regarding 
 draft-ietf-ospf-segment-routing-extensions

 Shraddha,

 node-SID is advertised by the router for the prefix that is directly attached 
 to it. Protection for such local prefix does not mean much.

 thanks,
 Peter

 On 12/24/14 11:57 , Shraddha Hegde wrote:
 Authors,
 We have a backup flag in adjacency sid to indicate whether the 
 label is protected or not.
 Similarly. I think we need a flag in prefix-sid as well to indicate 
 whether the node-sid is to be protected or not.
 Any thoughts on this?
 Rgds
 Shraddha


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


 .


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

Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-ospf-segment-routing-extensions

[Shraddha Hegde]

Peter,


Pls see inline.

Rgds
Shraddha

-Original Message-
From: Peter Psenak [mailto:ppse...@cisco.com] 
Sent: Monday, December 29, 2014 2:02 PM
To: Shraddha Hegde; draft-ietf-ospf-segment-routing-extensi...@tools.ietf.org; 
draft-ietf-isis-segment-routing-extensi...@tools.ietf.org
Cc: ospf@ietf.org; isis...@ietf.org
Subject: Re: [Isis-wg] Mail regarding draft-ietf-ospf-segment-routing-extensions

Shraddha,

I do not see how an originator can set any flag regarding the protection of the 
locally attached prefix.
Shraddha The originator advertises 2 node-sids. One with p flag set and the 
other without the p-flag set.
 
 It's all the routers on the path towards such prefix that need to deal with 
the protection. 
Shraddha The receiving nodes will download protected path for the node-sid 
with p-flag set and download 
Unprotected path for the node-sid with p-flag unset.

Signaling anything from the originator seems useless.
Shraddha  For node-sids it's the others who need to build the forwarding 
plane but it's only the originator who can signal which of
Sid need to be built with protection and which not. 
Other routers on the path cannot signal this information.

With this you have two paths for the node. One is protected and the other is 
unprotected. This meets the requirement of having an un-protected path.

It's very much in parallel to B-flag in adj-sids. It is similar to advertising 
multiple adj-sids one with B-flag on and other with b-flag off , to get 
protected and unprotected
Adj-sids.

thanks,
Peter

On 12/29/14 09:26 , Shraddha Hegde wrote:
 Yes.You are right.

 Lets say a prefix sid has a flag p flag. If this is on it means build a 
 path and provide protection.
 If this is off it means build a path with no protection.
 The receivers of the prefix-sid will build forwarding plane based on this 
 flag.

 The applications building the paths will either use prefix-sids with p flag 
 on or off based on the need of the service.
 Rgds
 Shraddha


 -Original Message-
 From: Peter Psenak [mailto:ppse...@cisco.com]
 Sent: Monday, December 29, 2014 1:49 PM
 To: Shraddha Hegde; 
 draft-ietf-ospf-segment-routing-extensi...@tools.ietf.org; 
 draft-ietf-isis-segment-routing-extensi...@tools.ietf.org
 Cc: ospf@ietf.org; isis...@ietf.org
 Subject: Re: [Isis-wg] Mail regarding 
 draft-ietf-ospf-segment-routing-extensions

 Shraddha,

 the problem is that the node that is advertising the node-sid can not 
 advertise any data regarding the protection of such prefix, because the 
 prefix is locally attached.

 thanks,
 Peter

 On 12/29/14 09:15 , Shraddha Hegde wrote:
 Peter,

 If there is a service which has to use un-protected path and while 
 building such a path if the node-sids Need to be used (one reason 
 could be label stack compression) , then there has to be unprotected 
 node-sid that this service can make use of.

 Prefix -sids could also be used to represent different service 
 endpoints which makes it even more relevant to have A means of representing  
 unprotected paths.

 Would be good to hear from others on this, especially operators.

 Rgds
 Shraddha


 -Original Message-
 From: Peter Psenak [mailto:ppse...@cisco.com]
 Sent: Monday, December 29, 2014 1:35 PM
 To: Shraddha Hegde;
 draft-ietf-ospf-segment-routing-extensi...@tools.ietf.org;
 draft-ietf-isis-segment-routing-extensi...@tools.ietf.org
 Cc: ospf@ietf.org; isis...@ietf.org
 Subject: Re: [Isis-wg] Mail regarding 
 draft-ietf-ospf-segment-routing-extensions

 Shraddha,

 node-SID is advertised by the router for the prefix that is directly 
 attached to it. Protection for such local prefix does not mean much.

 thanks,
 Peter

 On 12/24/14 11:57 , Shraddha Hegde wrote:
 Authors,
 We have a backup flag in adjacency sid to indicate whether the 
 label is protected or not.
 Similarly. I think we need a flag in prefix-sid as well to indicate 
 whether the node-sid is to be protected or not.
 Any thoughts on this?
 Rgds
 Shraddha


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


 .


 .


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

Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-ospf-segment-routing-extensions

[Shraddha Hegde]

Peter,

The requirement here is to get an un-protected path for services which do not 
want to divert the traffic on protected path in any case.
So when the originator of node-sid signals un-protected path requirement, there 
is always an unprotected path.

Regarding the protected path, it is the default behavior as it exists today. 
You get protection if it's available otherwise you don't get protection.

In fact, you can have the new flag to say NP flag meaning non-protected flag 
which can be set for the unprotected path. 
By default it remains off and gives the behavior as it exists today.


Rgds
Shraddha

-Original Message-
From: Peter Psenak [mailto:ppse...@cisco.com] 
Sent: Monday, December 29, 2014 2:26 PM
To: Shraddha Hegde; draft-ietf-ospf-segment-routing-extensi...@tools.ietf.org; 
draft-ietf-isis-segment-routing-extensi...@tools.ietf.org
Cc: ospf@ietf.org; isis...@ietf.org
Subject: Re: [Isis-wg] Mail regarding draft-ietf-ospf-segment-routing-extensions

Shraddha,

I do not see how an originator of the node-sid can mandate a protection for the 
prefix on other routers. What if there is no backup available on a certain node 
along the path?

The parallel with the B-flag in adj-sids is not right - in case of adj-sid the 
originator has the knowledge about the local adjacency protection and as such 
can signal it it it's LSA.

thanks,
Peter


On 12/29/14 09:47 , Shraddha Hegde wrote:
 Peter,


 Pls see inline.

 Rgds
 Shraddha

 -Original Message-
 From: Peter Psenak [mailto:ppse...@cisco.com]
 Sent: Monday, December 29, 2014 2:02 PM
 To: Shraddha Hegde; 
 draft-ietf-ospf-segment-routing-extensi...@tools.ietf.org; 
 draft-ietf-isis-segment-routing-extensi...@tools.ietf.org
 Cc: ospf@ietf.org; isis...@ietf.org
 Subject: Re: [Isis-wg] Mail regarding 
 draft-ietf-ospf-segment-routing-extensions

 Shraddha,

 I do not see how an originator can set any flag regarding the protection of 
 the locally attached prefix.
 Shraddha The originator advertises 2 node-sids. One with p flag set and the 
 other without the p-flag set.

   It's all the routers on the path towards such prefix that need to deal with 
 the protection.
 Shraddha The receiving nodes will download protected path for the 
 node-sid with p-flag set and download Unprotected path for the node-sid with 
 p-flag unset.

 Signaling anything from the originator seems useless.
 Shraddha  For node-sids it's the others who need to build the forwarding 
 plane but it's only the originator who can signal which of
  Sid need to be built with protection and which not. 
 Other routers on the path cannot signal this information.




 With this you have two paths for the node. One is protected and the other is 
 unprotected. This meets the requirement of having an un-protected path.

 It's very much in parallel to B-flag in adj-sids. It is similar to 
 advertising multiple adj-sids one with B-flag on and other with b-flag off , 
 to get protected and unprotected Adj-sids.

 thanks,
 Peter

 On 12/29/14 09:26 , Shraddha Hegde wrote:
 Yes.You are right.

 Lets say a prefix sid has a flag p flag. If this is on it means build a 
 path and provide protection.
 If this is off it means build a path with no protection.
 The receivers of the prefix-sid will build forwarding plane based on this 
 flag.

 The applications building the paths will either use prefix-sids with p flag 
 on or off based on the need of the service.
 Rgds
 Shraddha


 -Original Message-
 From: Peter Psenak [mailto:ppse...@cisco.com]
 Sent: Monday, December 29, 2014 1:49 PM
 To: Shraddha Hegde;
 draft-ietf-ospf-segment-routing-extensi...@tools.ietf.org;
 draft-ietf-isis-segment-routing-extensi...@tools.ietf.org
 Cc: ospf@ietf.org; isis...@ietf.org
 Subject: Re: [Isis-wg] Mail regarding 
 draft-ietf-ospf-segment-routing-extensions

 Shraddha,

 the problem is that the node that is advertising the node-sid can not 
 advertise any data regarding the protection of such prefix, because the 
 prefix is locally attached.

 thanks,
 Peter

 On 12/29/14 09:15 , Shraddha Hegde wrote:
 Peter,

 If there is a service which has to use un-protected path and while 
 building such a path if the node-sids Need to be used (one reason 
 could be label stack compression) , then there has to be unprotected 
 node-sid that this service can make use of.

 Prefix -sids could also be used to represent different service 
 endpoints which makes it even more relevant to have A means of representing 
  unprotected paths.

 Would be good to hear from others on this, especially operators.

 Rgds
 Shraddha


 -Original Message-
 From: Peter Psenak [mailto:ppse...@cisco.com]
 Sent: Monday, December 29, 2014 1:35 PM
 To: Shraddha Hegde;
 draft-ietf-ospf-segment-routing-extensi...@tools.ietf.org;
 draft-ietf-isis-segment-routing-extensi...@tools.ietf.org
 Cc: ospf@ietf.org; isis...@ietf.org
 Subject: Re: [Isis-wg] Mail regarding 
 draft-ietf-ospf-segment-routing

Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-ospf-segment-routing-extensions

[Shraddha Hegde]

Rob,

Pls see inline..

Rgds
Shraddha

-Original Message-
From: Rob Shakir [mailto:r...@rob.sh] 
Sent: Monday, December 29, 2014 2:38 PM
To: Peter Psenak; Shraddha Hegde
Cc: draft-ietf-ospf-segment-routing-extensi...@tools.ietf.org; 
draft-ietf-isis-segment-routing-extensi...@tools.ietf.org; ospf@ietf.org; 
isis...@ietf.org
Subject: Re: [Isis-wg] Mail regarding draft-ietf-ospf-segment-routing-extensions

Peter, Shraddha,

Primarily —  I don’t think that use of the ‘B’ flag in the Adj-SID implies that 
there MUST be a backup route installed, it merely indicates that the Adj-SID 
MAY be subject to re-routing (and hence strict placement on an adjacency may 
not be honoured during link failures).

Shraddha Yes. I agree.

For me, I’m unclear on what the practical use of not requesting backup for a 
{Node,Prefix}-SID could be — its very nature (“the shortest path to X” where X 
is a node/prefix) means that it is not well defined in terms of a route through 
the network, and hence is not well defined in terms of performance. This (to 
me) says that we cannot really rely on such a SID for performance-sensitive 
traffic, and hence must always be able to tolerate events such as FRR paths 
during protection.

Shraddha It is likely that some application wants to use the node-sids when 
the strict path for performance sensitive traffic matches with that of the SPF  
for some segments or for the entire path. 

The fact that AdjSID maps deterministically to a particular link, about which 
the calculating entity (PCE/iLER) can know details of, means that performance 
can be inferred - and hence strict affinity to that path (and/or failure when 
it is not available) is of utility.


Kind regards,
r.


 On 29 Dec 2014, at 08:56, Peter Psenak ppse...@cisco.com wrote:
 
 Shraddha,
 
 I do not see how an originator of the node-sid can mandate a protection for 
 the prefix on other routers. What if there is no backup available on a 
 certain node along the path?
 
 The parallel with the B-flag in adj-sids is not right - in case of adj-sid 
 the originator has the knowledge about the local adjacency protection and as 
 such can signal it it it's LSA.
 
 thanks,
 Peter
 
 
 On 12/29/14 09:47 , Shraddha Hegde wrote:
 Peter,
 
 
 Pls see inline.
 
 Rgds
 Shraddha
 
 -Original Message-
 From: Peter Psenak [mailto:ppse...@cisco.com]
 Sent: Monday, December 29, 2014 2:02 PM
 To: Shraddha Hegde; 
 draft-ietf-ospf-segment-routing-extensi...@tools.ietf.org; 
 draft-ietf-isis-segment-routing-extensi...@tools.ietf.org
 Cc: ospf@ietf.org; isis...@ietf.org
 Subject: Re: [Isis-wg] Mail regarding 
 draft-ietf-ospf-segment-routing-extensions
 
 Shraddha,
 
 I do not see how an originator can set any flag regarding the protection of 
 the locally attached prefix.
 Shraddha The originator advertises 2 node-sids. One with p flag set and 
 the other without the p-flag set.
 
  It's all the routers on the path towards such prefix that need to deal with 
 the protection.
 Shraddha The receiving nodes will download protected path for the 
 node-sid with p-flag set and download Unprotected path for the node-sid with 
 p-flag unset.
 
 Signaling anything from the originator seems useless.
 Shraddha  For node-sids it's the others who need to build the forwarding 
 plane but it's only the originator who can signal which of
 Sid need to be built with protection and which not. 
 Other routers on the path cannot signal this information.
 
 
 
 
 With this you have two paths for the node. One is protected and the other is 
 unprotected. This meets the requirement of having an un-protected path.
 
 It's very much in parallel to B-flag in adj-sids. It is similar to 
 advertising multiple adj-sids one with B-flag on and other with b-flag off , 
 to get protected and unprotected Adj-sids.
 
 thanks,
 Peter
 
 On 12/29/14 09:26 , Shraddha Hegde wrote:
 Yes.You are right.
 
 Lets say a prefix sid has a flag p flag. If this is on it means build a 
 path and provide protection.
 If this is off it means build a path with no protection.
 The receivers of the prefix-sid will build forwarding plane based on this 
 flag.
 
 The applications building the paths will either use prefix-sids with p flag 
 on or off based on the need of the service.
 Rgds
 Shraddha
 
 
 -Original Message-
 From: Peter Psenak [mailto:ppse...@cisco.com]
 Sent: Monday, December 29, 2014 1:49 PM
 To: Shraddha Hegde;
 draft-ietf-ospf-segment-routing-extensi...@tools.ietf.org;
 draft-ietf-isis-segment-routing-extensi...@tools.ietf.org
 Cc: ospf@ietf.org; isis...@ietf.org
 Subject: Re: [Isis-wg] Mail regarding 
 draft-ietf-ospf-segment-routing-extensions
 
 Shraddha,
 
 the problem is that the node that is advertising the node-sid can not 
 advertise any data regarding the protection of such prefix, because the 
 prefix is locally attached.
 
 thanks,
 Peter
 
 On 12/29/14 09:15 , Shraddha Hegde wrote:
 Peter,
 
 If there is a service which has to use

Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-ospf-segment-routing-extensions

[Shraddha Hegde]

Peter,

 The requirement here is to get an un-protected path for services which do not 
 want to divert the traffic on protected path in any case.

 can you give an example of such a service and a reasoning why such service 
 would want to avoid local protection along the path?

Heavy bandwidth services are potential candidates.  The network is well planned 
and well provisioned for primary path but same is not true for backup paths.
Diverting heavy bandwidth services along protection path can disrupt the other 
services on that path, they are better-off un-protected so that an event in the 
network
Would result in disconnection and a retry for such services.

Rgds
Shraddha

-Original Message-
From: Peter Psenak [mailto:ppse...@cisco.com] 
Sent: Monday, December 29, 2014 4:35 PM
To: Shraddha Hegde; draft-ietf-ospf-segment-routing-extensi...@tools.ietf.org; 
draft-ietf-isis-segment-routing-extensi...@tools.ietf.org
Cc: ospf@ietf.org; isis...@ietf.org
Subject: Re: [Isis-wg] Mail regarding draft-ietf-ospf-segment-routing-extensions

Shraddha,

On 12/29/14 10:06 , Shraddha Hegde wrote:
 Peter,

 The requirement here is to get an un-protected path for services which do not 
 want to divert the traffic on protected path in any case.

can you give an example of such a service and a reasoning why such service 
would want to avoid local protection along the path?

thanks,
Peter

 So when the originator of node-sid signals un-protected path requirement, 
 there is always an unprotected path.

 Regarding the protected path, it is the default behavior as it exists today. 
 You get protection if it's available otherwise you don't get protection.

 In fact, you can have the new flag to say NP flag meaning non-protected 
 flag which can be set for the unprotected path.
 By default it remains off and gives the behavior as it exists today.


 Rgds
 Shraddha

 -Original Message-
 From: Peter Psenak [mailto:ppse...@cisco.com]
 Sent: Monday, December 29, 2014 2:26 PM
 To: Shraddha Hegde; 
 draft-ietf-ospf-segment-routing-extensi...@tools.ietf.org; 
 draft-ietf-isis-segment-routing-extensi...@tools.ietf.org
 Cc: ospf@ietf.org; isis...@ietf.org
 Subject: Re: [Isis-wg] Mail regarding 
 draft-ietf-ospf-segment-routing-extensions

 Shraddha,

 I do not see how an originator of the node-sid can mandate a protection for 
 the prefix on other routers. What if there is no backup available on a 
 certain node along the path?

 The parallel with the B-flag in adj-sids is not right - in case of adj-sid 
 the originator has the knowledge about the local adjacency protection and as 
 such can signal it it it's LSA.

 thanks,
 Peter


 On 12/29/14 09:47 , Shraddha Hegde wrote:
 Peter,


 Pls see inline.

 Rgds
 Shraddha

 -Original Message-
 From: Peter Psenak [mailto:ppse...@cisco.com]
 Sent: Monday, December 29, 2014 2:02 PM
 To: Shraddha Hegde;
 draft-ietf-ospf-segment-routing-extensi...@tools.ietf.org;
 draft-ietf-isis-segment-routing-extensi...@tools.ietf.org
 Cc: ospf@ietf.org; isis...@ietf.org
 Subject: Re: [Isis-wg] Mail regarding 
 draft-ietf-ospf-segment-routing-extensions

 Shraddha,

 I do not see how an originator can set any flag regarding the protection of 
 the locally attached prefix.
 Shraddha The originator advertises 2 node-sids. One with p flag set and 
 the other without the p-flag set.

It's all the routers on the path towards such prefix that need to deal 
 with the protection.
 Shraddha The receiving nodes will download protected path for the 
 node-sid with p-flag set and download Unprotected path for the node-sid with 
 p-flag unset.

 Signaling anything from the originator seems useless.
 Shraddha  For node-sids it's the others who need to build the forwarding 
 plane but it's only the originator who can signal which of
   Sid need to be built with protection and which 
 not. Other routers on the path cannot signal this information.




 With this you have two paths for the node. One is protected and the other is 
 unprotected. This meets the requirement of having an un-protected path.

 It's very much in parallel to B-flag in adj-sids. It is similar to 
 advertising multiple adj-sids one with B-flag on and other with b-flag off , 
 to get protected and unprotected Adj-sids.

 thanks,
 Peter

 On 12/29/14 09:26 , Shraddha Hegde wrote:
 Yes.You are right.

 Lets say a prefix sid has a flag p flag. If this is on it means build a 
 path and provide protection.
 If this is off it means build a path with no protection.
 The receivers of the prefix-sid will build forwarding plane based on this 
 flag.

 The applications building the paths will either use prefix-sids with p flag 
 on or off based on the need of the service.
 Rgds
 Shraddha


 -Original Message-
 From: Peter Psenak [mailto:ppse...@cisco.com]
 Sent: Monday, December 29, 2014 1:49 PM
 To: Shraddha Hegde;
 draft-ietf-ospf-segment-routing-extensi...@tools.ietf.org;
 draft-ietf-isis-segment-routing

[OSPF] Mail regarding draft-ietf-ospf-segment-routing-extensions

[Shraddha Hegde]

Authors,


We have a backup flag in adjacency sid to indicate whether the label is 
protected or not.
Similarly. I think we need a flag in prefix-sid as well to indicate whether the 
node-sid is to be protected or not.

Any thoughts on this?

Rgds
Shraddha

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

Re: [OSPF] draft-ietf-ospf-segment-routing-extensions-03

[Shraddha Hegde]

Peter,

An extended link LSA can contain multiple adj-sid labels with s bit set.
During graceful restart , when self generated LSAs are learnt from neighbors,
A handle is required to associate the set label with the bundle.

I think a group-id field along with set label would serve the purpose.

Rgds
Shraddha
-Original Message-
From: Peter Psenak [mailto:ppse...@cisco.com] 
Sent: Sunday, December 14, 2014 4:08 PM
To: Shraddha Hegde; draft-ietf-ospf-segment-routing-extensi...@tools.ietf.org
Cc: OSPF WG List
Subject: Re: draft-ietf-ospf-segment-routing-extensions-03

Shraddha,

the idea is that you can assign the same Adj-SID to multiple links. That way 
you can create multiple sets as you need.

thanks,
Peter


On 12/13/14 19:19 , Shraddha Hegde wrote:
 Authors,

  When there are multiple parallel links between two nodes, it 
 is useful to

 Group them into different bundles and use each bundle for load-balancing
   for different traffic flows.

 What we have in adjacency sid is just a flag to indicate that the 
 label is a set label by setting a flag

 In adj-sid TLV. It serves the purpose when all the parallel links  are 
 in one bundle but not sufficient when

 There can be different bundles and different labels for each of them.

 An identifier for the group, probably group-id is needed to 
 associate the label with the interface group.

 Any thoughts on this?

 Rgds

 Shraddha


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

Re: [OSPF] draft-ietf-ospf-segment-routing-extensions-03

[Shraddha Hegde]

Rob,

Pls see inline..

-Original Message-
From: rob.sha...@bt.com [mailto:rob.sha...@bt.com] 
Sent: Tuesday, December 16, 2014 10:11 PM
To: Shraddha Hegde; ppse...@cisco.com; 
draft-ietf-ospf-segment-routing-extensi...@tools.ietf.org
Cc: ospf@ietf.org
Subject: Re: draft-ietf-ospf-segment-routing-extensions-03

Shraddha,

Is it really up to the neighbor to specify what was previously a bundle?

Shraddha  The graceful restart in OSPF as per RFC  3623 works by learning  
the LSAs from neighbor after the restating router comes up and builds the LSA 
database based on the learnt LSAs.
  The neighbor relays back the LSA generated by the restarting 
router. The Extended link LSA contains the adj-sid Label TLV which
   Has the s bit set indicating the label is a set 
label. If there are multiple such set labels associated with a link, its 
difficult to associate which label was allocated for which bundle.

  If there is a some kind of identifier for the bundle, 
the label can be easily associated.


It is surely the local configuration of the node that determines what the 
bundle is in the first place, and this is persistent over a graceful-restart of 
the session?

Shraddha Yes, IMO local configuration decides which links belong to the 
bundle. This configuration is persistent over graceful restart.
  You MAY want to bundle all the parallel links between 
two nodes into a bundle, in which case the existing protocol operations work 
fine.
   But I think protocol should provide flexibility to 
make multiple bundles, able to assign a link to multiple bundles (if so 
desired) and recovering the label across restart.


Thanks,
r.

[16/12/2014 16:34, Shraddha Hegde shrad...@juniper.net]

Peter,

An extended link LSA can contain multiple adj-sid labels with s bit set.
During graceful restart , when self generated LSAs are learnt from 
neighbors, A handle is required to associate the set label with the 
bundle.

I think a group-id field along with set label would serve the purpose.

Rgds
Shraddha
-Original Message-
From: Peter Psenak [mailto:ppse...@cisco.com]
Sent: Sunday, December 14, 2014 4:08 PM
To: Shraddha Hegde;
draft-ietf-ospf-segment-routing-extensi...@tools.ietf.org
Cc: OSPF WG List
Subject: Re: draft-ietf-ospf-segment-routing-extensions-03

Shraddha,

the idea is that you can assign the same Adj-SID to multiple links. 
That way you can create multiple sets as you need.

thanks,
Peter


On 12/13/14 19:19 , Shraddha Hegde wrote:
 Authors,

  When there are multiple parallel links between two nodes, it 
 is useful to

 Group them into different bundles and use each bundle for load-balancing
   for different traffic flows.

 What we have in adjacency sid is just a flag to indicate that the 
 label is a set label by setting a flag

 In adj-sid TLV. It serves the purpose when all the parallel links  
 are in one bundle but not sufficient when

 There can be different bundles and different labels for each of them.

 An identifier for the group, probably group-id is needed to 
 associate the label with the interface group.

 Any thoughts on this?

 Rgds

 Shraddha



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

[OSPF] draft-ietf-ospf-segment-routing-extensions-03

[Shraddha Hegde]

Authors,

When there are multiple parallel links between two nodes, it is useful 
to
Group them into different bundles and use each bundle for load-balancing  for 
different traffic flows.

What we have in adjacency sid is just a flag to indicate that the label is a 
set label by setting a flag
In adj-sid TLV. It serves the purpose when all the parallel links  are in one 
bundle but not sufficient when
There can be different bundles and different labels for each of them.
An identifier for the group, probably group-id is needed to associate the 
label with the interface group.

Any thoughts on this?

Rgds
Shraddha


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

Re: [OSPF] draft-ietf-ospf-segment-routing-extensions-03

[Shraddha Hegde]

Peter,

snipped


Would this prefix range be propagated from backbone 
 area to non-backbone area?

yes, SRMS range advertisements will be propagated between areas if LSA type 10 
is used for the advertisement.

Shraddha You mean area scope (type 10) LSAs will be flooded across area 
boundary? Or you mean they will be
   Re-originated at the boundary and if AS scope LSA (type 
11) they will be flooded across the boundary?


   Keeping the prefix ranges confined within route types 
 would make it much more simple.

true, but it will make the deployment harder.

Shraddha OK. I see your point.


I think the document needs to capture the information that the prefix range can 
have different route-types covered.
It wasn't clear from reading the document. Probably an elements of  procedure 
section is required for the prefix range TLV
To cover the flooding scope and other aspects.

One more point to be mentioned is that if there is a prefix range TLV that 
covers a certain prefix and there is also a prefix SID
For the same prefix , then the prefix SID should be considered and the SID in 
the prefix range should be ignored.

Rgds
Shraddha

-Original Message-
From: Peter Psenak [mailto:ppse...@cisco.com] 
Sent: Thursday, December 04, 2014 11:15 PM
To: Shraddha Hegde; draft-ietf-ospf-segment-routing-extensi...@tools.ietf.org
Cc: OSPF WG List
Subject: Re: draft-ietf-ospf-segment-routing-extensions-03

Shraddha,

On 12/4/14 17:45 , Shraddha Hegde wrote:

 Peter,


 I would think that we should have route type as in Extended prefix 
 TLV instead of just having a bit indicating inter area

 route-type would be misleading for range, as single range can include 
 prefixes of various types (intra, inter, external). We have discussed 
 this between authors and we agreed route-type is not the right way.

 Shraddha The prefix range TLV is carried in Extended prefix LSA which is 
 based on scope of flooding.
  If we combine intra/inter/external in the prefix 
 range TLV, what scope is used for flooding the extended prefix LSA?

 prefix range is used for SR mapping server to optimize the SID 
 advertisement. Prefix range as such does not need to have a route 
 type, because it is not advertising a reachability. One can use domain 
 wide flooding for certain external prefix, but use regular inter-area 
 distribution for prefix range that is covering the external prefix.


 Shraddha  Combining the different route types in the prefix range TLV looks 
 very complex.
  How practical it is in a real deployment to get a 
 prefix range that covers through intra/inter/external route types?

Imagine you want to advertise a SIDs for a range 192.0.2.1, Prefix Length 32, 
Range Size 255. Out of that range individual /32 prefixes can be of different 
route-types. Prefix range does not have a route-type.




 In my opinion, it is adding unnecessary complexity 
 into the protocol.
If a prefix range covers intra and inter area routes 
 would the IA flag be set?

IA flag has nothing to do with the route-type. IA flag means that the range 
advertisement has bean 'leaked' between areas and is used to prevent redundant 
leaking.

Would this prefix range be propagated from backbone 
 area to non-backbone area?

yes, SRMS range advertisements will be propagated between areas if LSA type 10 
is used for the advertisement.

If some prefix range contains a mix of inter and 
 external how's the inter area prefix SIDs
Propagated into NSSA area and external ones blocked?

that is not a problem. You may not have external prefix in NSSA area, but the 
range can still cover such external prefix. In such case the SID for the 
external prefix will never be used in NSSA area.



   Keeping the prefix ranges confined within route types 
 would make it much more simple.

true, but it will make the deployment harder.

thanks,
Peter

 Rgds
 Shraddha


 -Original Message-
 From: Peter Psenak [mailto:ppse...@cisco.com]
 Sent: Wednesday, December 03, 2014 2:01 PM
 To: Shraddha Hegde; 
 draft-ietf-ospf-segment-routing-extensi...@tools.ietf.org
 Cc: OSPF WG List
 Subject: Re: draft-ietf-ospf-segment-routing-extensions-03

 Shraddha,

 please see inline:

 On 12/3/14 06:10 , Shraddha Hegde wrote:
 Peter,

 Snipped to open points

  Shouldn't each node in broadcast link originate LAN adj-SID 
 and advertise label to all other nodes on the link?

 For the adjacency to DR, Adj-SID Sub-TLV is used. For the adjacency 
 to non-DR LAN Adj-SID Sub-TLV is used. It's done all all nodes on the LAN.

 Shraddha Is there a specific reason to advertise adj-sid for the DR and 
 LAN adj-sid for non-DR?
 Is it because the Neighbor-ID is already part of 
 Extended link TLV and we are saving 4

Re: [OSPF] draft-ietf-ospf-segment-routing-extensions-03

[Shraddha Hegde]

Peter,

Snipped to open points

Shouldn't each node in broadcast link originate LAN adj-SID and
 advertise label to all other nodes on the link?

For the adjacency to DR, Adj-SID Sub-TLV is used. For the adjacency to 
non-DR LAN Adj-SID Sub-TLV is used. It's done all all nodes on the LAN.

Shraddha Is there a specific reason to advertise adj-sid for the DR and LAN 
adj-sid for non-DR?
  Is it because the Neighbor-ID is already part of Extended 
link TLV and we are saving 4 bytes?
 

 I would think that we should have route type as in Extended prefix TLV
 instead of just having a bit indicating inter area

route-type would be misleading for range, as single range can include 
prefixes of various types (intra, inter, external). We have discussed 
this between authors and we agreed route-type is not the right way.

Shraddha The prefix range TLV is carried in Extended prefix LSA which is 
based on scope of flooding.
   If we combine intra/inter/external in the prefix range 
TLV, what scope is used for flooding the extended prefix LSA?


Rgds
Shraddha

-Original Message-
From: Peter Psenak [mailto:ppse...@cisco.com] 
Sent: Tuesday, December 02, 2014 10:39 PM
To: Shraddha Hegde; draft-ietf-ospf-segment-routing-extensi...@tools.ietf.org
Cc: OSPF WG List
Subject: Re: draft-ietf-ospf-segment-routing-extensions-03

Shraddha,

please see inline:

On 12/2/14 17:50 , Shraddha Hegde wrote:
 Authors,
 Some  comments on the draft.

  1. The draft refers to the various use cases in the use case document
 in I-D.filsfils-rtgwg-segment-routing. It's useful to mention the
 section of the use case draft which is applicable for each reference
 instead of giving generic reference.

sure, we can add that.

  2. Section 7.2 LAN Adj-sid sub TLV:

 Based on the description of the text it appears that the LAN AdjSID 
 Sub TLV can contain multiple neighbor-ID /SID pairs based on the nodes 
 attached to a broadcast network. The TLV diagram should depict 
 carrying multiple such pairs.

no. LAN AdjSID Sub TLV only advertises a adj-SID for a single neighbor. 
If you have more non-DR neighbors, you need to advertise multiple LAN Adj-SID 
Sub-TLVs.


 It is used to advertise a SID/Label for an
 adjacency to a non-DR node on a broadcast or NBMA network.
 Does the above statement mean only DR originates the LAN-Adj SIDand
 advertises label to non-DR nodes?

no.

Shouldn't each node in broadcast link originate LAN adj-SID and
 advertise label to all other nodes on the link?

For the adjacency to DR, Adj-SID Sub-TLV is used. For the adjacency to 
non-DR LAN Adj-SID Sub-TLV is used. It's done all all nodes on the LAN.


  3. Adj-Sid sub TLV section 7.1:

 Description of V-flag mentions Prefix-SID,  it should be changed to Adj-SID.

good catch, will correct.


  4. Section 4: Extended prefix range TLV is very similar to Extended
 prefix TLV just that it has additional range associated with it.

yes, that is correct.


 I would think that we should have route type as in Extended prefix TLV
 instead of just having a bit indicating inter area

route-type would be misleading for range, as single range can include 
prefixes of various types (intra, inter, external). We have discussed 
this between authors and we agreed route-type is not the right way.

thanks,
Peter

 Rgds
 Shraddha

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

Re: [OSPF] WG Adoption poll for draft-zzhang-ospf-two-part-metric-05

[Shraddha Hegde]

Support.

Rgds
Shraddha

-Original Message-
From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Abhay Roy
Sent: Monday, November 03, 2014 12:33 PM
To: ospf@ietf.org
Subject: [OSPF] WG Adoption poll for draft-zzhang-ospf-two-part-metric-05

This document has seen some good discussions and a few revisions to cater to 
those suggested changes.

Please indicate your support (or concerns) for adopting this as a WG Document.

Regards,
-Abhay

___
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

Re: [OSPF] Poll for WG adoption of draft-hegde-ospf-node-admin-tag

[Shraddha Hegde]

Dhruv,

Thanks for detailed review and comments.
Pls see in-line for the response.

Rgds
Shraddha

-Original Message-
From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Dhruv Dhody
Sent: Saturday, August 30, 2014 6:22 PM
To: Acee Lindem (acee)
Cc: ospf@ietf.org
Subject: Re: [OSPF] Poll for WG adoption of draft-hegde-ospf-node-admin-tag

Hi,

I have read the document and I support it for WG adoption.

I have following comments, that can be handled later

(1) Section 4.1
OLD:

   The format of the TLVs within the body of an RI LSA is the same as
   the format used by the Traffic Engineering Extensions to OSPF
   [RFC3630].

   The LSA payload consists of one or more nested Type/Length/Value
   (TLV) triplets.  The format of each TLV is:

NEW:

   As per [RFC4970], the format of the TLVs within the body of an RI LSA is the 
same as
   the format used by the Traffic Engineering Extensions to OSPF
   [RFC3630].

   The RI LSA payload consists of one or more nested Type/Length/Value
   (TLV) triplets.  The format of the per-node administrative tag TLV is:

END

Shraddha Accept. Will be updated in the next revision.


Also, it should be stated
- if are more than one instance of this TLV in RI LSA are allowed.

ShraddhaMore than one instance of the TLV can be added in same RI-LSA or in a 
multiple instance as defined
   In  draft-acee-ospf-rfc4970bis-00.txt


- Minimum one tag must be present in the TLV
Shraddha Accept.


- What happens if the implementation does not know the Interpretation of the 
tag value
Shraddha This is mentioned in section 4.2, However will add explicit mention 
regarding the scenario you mentioned.


(2) It should be explicitly stated that - No IANA registry is required to store 
the meaning or interpretation of.the tag values.

Shraddha It's mentioned in the section 4.2 that no well known  tag values 
will be defined by this document.

(3) Backward compatibility - few lines may be added to state that as per 
[RFC4970], unknown TLV would be silently ignored.
Shraddha Accept

Nits
- Avoid using reference in abstract
- Expand LFA on first use
- Administrative Tag TLV or 'per-node Administrative Tag' : consistent naming 
through the document would be nice

Shraddha Accept.

Regards,
Dhruv


On Tue, Aug 26, 2014 at 2:48 AM, Acee Lindem (acee) a...@cisco.com wrote:
 There are situations where node level policy is required and an OSPF 
 advertised admin tag simplifies this. For example, advertisement of 
 remote-LFA eligibility.

 Please indicate your support or objections to adopting this draft as 
 an OSPF WG document.

 Thanks,
 Acee

 ___
 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

Re: [OSPF] draft-atlas-ospf-mrt-02

[Shraddha Hegde]

Hi Acee,

  Defining a new MRT sub TLV to be carried in the OSPFv2 Extended link TLV as 
defined in
https://datatracker.ietf.org/doc/draft-ietf-ospf-segment-routing-extensions/

 Router-Link TLVsas defined in 
https://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv3-lsa-extend

looks to be a good option. We will work on the draft to update.

Rgds
Shraddha

-Original Message-
From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Acee Lindem
Sent: Tuesday, July 15, 2014 1:18 AM
To: Chris Bowers
Cc: OSPF List; Alia Atlas
Subject: Re: [OSPF] draft-atlas-ospf-mrt-02

Hi Chris, Shraddha,  

On Jul 14, 2014, at 3:36 PM, Chris Bowers cbow...@juniper.net wrote:

 (The response to this question ended up off of the list, so I'm posting it to 
 continue the discussion on the list.) 
 
 Russ,
 
 I see your point in link information being carried in Node related LSA.
 
 The link information is carried in Router LSA and it's not extendible to 
 carry any other information.
 Since RI-LSA is modeled as an extension to Router LSA, my idea was to tag the 
 additional link information With new TLV in RI-LSA.
 
 Another approach could have been to define a new LSA type and originate a new 
 LSA for each link which is in-eligible to participate in MRT. A separate LSA 
 for each link to advertise ineligibility looks suboptimal considering the 
 amount of state machine/data structure that needs to be maintained for a 
 separate LSA.
 
 It seems like it might be better to move this bit of information into the 
 TLV where the actual link state is advertised in some way.
 
 Link related information is advertised in OSPF-TE opaque LSAs as well. MRT 
 could run on non-TE enabled networks as well, so it may not be appropriate to 
 use TE LSAs.
 
 Let me know if you think we could stuff-in in existing LSAs or we should go 
 with new LSA altogether.

Do NOT use the OSPF RI LSA for link information. Rather than define a new LSA, 
use the OSPFv2 Extended-Link opaque LSA defined in 
https://datatracker.ietf.org/doc/draft-ietf-ospf-segment-routing-extensions/

Thanks,
Acee



 
 Rgds,
 Shraddha
 
 -Original Message-
 From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Russ White
 Sent: Sunday, July 06, 2014 7:41 AM
 To: 'OSPF List'
 Cc: Alia Atlas
 Subject: [OSPF] draft-atlas-ospf-mrt-02
 
 
 Just one question/comment on this draft -- In section 6.1, MRT-Ineligible 
 Links TLV for OSPFv2, the draft says there should be a new TLV in the router 
 capabilities LSA that advertises links not to be included in the MRT 
 calculation (excluded links). I'm not certain why an option isn't used in the 
 LSA header for this, instead. Two things that seem strange to me:
 
 - The exclusion of a link is a link property, not a router property, so I'm 
 not certain why this would be advertised as a property of the OSPF router.
 This seems to muddy the line between router and properties and link 
 properties in a way that sets the stage for make the router capabilities just 
 another area into which to stuff various bits of information we can't find a 
 home for elsewhere.
 
 - If you modify a specific link state, then you must advertise two TLVs, or 
 rather two LSAs, rather than one. Thus these two pieces of information must 
 be connected in a local database, but advertised separately, with all the 
 coordination/etc. that implies.
 
 It seems like it might be better to move this bit of information into the TLV 
 where the actual link state is advertised in some way.
 
 :-)
 
 Russ
 
 ___
 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

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

Re: [OSPF] Review Request: New Version Notification for draft-hegde-ospf-node-admin-tag-00.txt

[Shraddha Hegde]

Acee Actually, I think separate LSAs is a better alternative.

Shraddha Node-tag is a just another property of the node. OSPFv2/v3 have 
achieved the desired functionality using numerous link/node properties using 
TLVs in TE-LSA so
I don't see an absolute necessity of going with a new LSA. 

Rgds
Shraddha

-Original Message-
From: ospf-boun...@ietf.org [mailto:ospf-boun...@ietf.org] On Behalf Of Acee 
Lindem
Sent: Monday, October 21, 2013 8:55 PM
To: Hannes Gredler
Cc: OSPF List; Rob Shakir; Harish Raghuveer
Subject: Re: [OSPF] Review Request: New Version Notification for 
draft-hegde-ospf-node-admin-tag-00.txt


On Oct 21, 2013, at 11:08 AM, Hannes Gredler wrote:

 On Mon, Oct 21, 2013 at 02:10:04PM +, Acee Lindem wrote:
 | 
 | On Oct 21, 2013, at 9:51 AM, Hannes Gredler wrote:
 | 
 |  On Mon, Oct 21, 2013 at 01:32:54PM +, Acee Lindem wrote:
 |  | Hannes,
 |  |
 |  | On Oct 21, 2013, at 9:26 AM, Hannes Gredler wrote:
 |  |
 |  |  acee,
 |  | 
 |  |  why should we give an upper boundary on things which
 |  |  - might be subject to change and
 |  |  - which have a historic track record of being underestimated.
 |  |
 |  | You don't have to - just request a separate OSPFv2 opaque LSA and
 |  IPv6 OSPFv3 LSA from IANA.
 |  | Another alternative would be to extend the RI LSA to be multi-
 |  instance and relegate the variable length tags to an instance other
 |  than instance 0.
 | 
 |  again the question why i do have to ?
 |  i can perfectly fit in single-digit as well as a few dozens of colors
 |  in a single RI LSA
 |  - what is your concern - except that we may use inappropriate large
 |  space for TE ?
 |  any reasonable implementation SHOULD restrict the node color set,
 |  such
 |  that overwhelming the 64K of RI LSPs is not going to happen.
 | 
 | We don't want a standard that leaves room for 
 | quot;unreasonablequot; implementations ;^). I think the policy in 
 | RFC 4970 is clear. Here is an
 | excerpt:
 
 oh boy - i wish i could let the non-sense disappear just with good 
 standard docs ;-) - but i hear you - so all you're asking for is an 
 upper boundary ? - is 128 low enough to not scare you and be compliant 
 to the below paragraph.

Actually, I think separate LSAs is a better alternative. 



 
 | 3.  Router Information LSA Opaque Usage and Applicability
 | 
 |The purpose of the Router Information (RI) LSA is to advertise
 |information relating to the aggregate OSPF router.  Normally, this
 |should be confined to TLVs with a single value or very few values.
 |It is not meant to be a generic container to carry any and all
 |information.  The intent is to both limit the size of the RI LSA to
 |the point where an OSPF router will always be able to contain the
 |TLVs in a single LSA and to keep the task of determining what has
 |changed between LSA instances reasonably simple.  Hence, discretion
 |and sound engineering judgment will need to be applied when deciding
 |whether newly proposed TLV(s) in support of a new application are
 |advertised in the RI LSA or warrant the creation of an application
 |specific LSA.
 | 
 | 
 | Anyway, this hasn't even been presented or accepted as a WG document. 
 
 which is not a reason why we should not discuss how to iron out the bumpy 
 parts now.

Right.

Thanks,
Acee 


 
 thanks !
 
 /hannes
 
 |  |  the 'per-link' admin-groups serve as a good example here:
 |  |  initially conceived as quot;you won't ever need more than
 |  32quot; we have
 |  |  now arrived at a variable length (unbounded) extension.
 |  | 
 |  |  http://tools.ietf.org/html/draft-osborne-mpls-extended-admin-
 |  groups-00
 |  | 
 |  |  for a humorous take to it, have a look at
 |  |  http://tools.ietf.org/html/rfc1925
 |  |  rule (9) and (10)
 |  | 
 |  |  /hannes
 |  | 
 |  |  On Oct 21, 2013, at 3:12 PM, Acee Lindem wrote:
 |  | 
 |  |  Hi Shraddha,
 |  |  Since the size of the tag data is unbounded, could you either
 |  put it in a separate OSPFv2 opaque LSA and OSPFv3 LSA or limit the
 |  size to some maximum number of tags, e.g., 16?  
 |  |  Thanks,
 |  |  Acee
 |  |  On Oct 21, 2013, at 7:05 AM, Shraddha Hegde wrote:
 |  | 
 |  |  Hi All,
 |  | 
 |  |  We have posted a draft on quot; Advertising per-node
 |  administrative tags in OSPFquot; and would like to hear your views
 |  on it. Please feel free to raise any suggestion/comment on the
 |  content.
 |  | 
 |  |  Rgds
 |  |  Shraddha
 |  | 
 |  |  -Original Message-
 |  |  From: internet-dra...@ietf.org [mailto:internet-
 |  dra...@ietf.org]
 |  |  Sent: Monday, October 21, 2013 4:24 PM
 |  |  To: Harish Raghuveer; Shraddha Hegde; British Telecom; Hannes
 |  Gredler; Rob Shakir
 |  |  Subject: New

Re: [OSPF] Review Request: New Version Notification for draft-hegde-ospf-node-admin-tag-00.txt

[Shraddha Hegde]

The Applicability section of the draft talks about why RI LSA is chosen as 
the node-tag TLV carrier instead of TE LSA.

The point I am trying make here is, if the link-color is carried in a TLV,
Node color could also be carried in TLV and we don't need a new LSA for that.

Rgds
Shraddha

-Original Message-
From: Acee Lindem [mailto:acee.lin...@ericsson.com] 
Sent: Tuesday, October 22, 2013 12:53 AM
To: Shraddha Hegde
Cc: Acee Lindem; Hannes Gredler; OSPF List; Rob Shakir; Harish Raghuveer
Subject: Re: [OSPF] Review Request: New Version Notification for 
draft-hegde-ospf-node-admin-tag-00.txt


On Oct 21, 2013, at 3:12 PM, Shraddha Hegde wrote:

 Acee Actually, I think separate LSAs is a better alternative.
 
 Shraddha Node-tag is a just another property of the node. OSPFv2/v3 
 have achieved the desired functionality using numerous link/node properties 
 using TLVs in TE-LSA so I don't see an absolute necessity of going with a new 
 LSA.

Shraddha - If you think the Router-Information LSA is the same as the TE LSA 
you have not read RFC 4970. 

Acee 


 
 Rgds
 Shraddha
 
 -Original Message-
 From: ospf-boun...@ietf.org [mailto:ospf-boun...@ietf.org] On Behalf 
 Of Acee Lindem
 Sent: Monday, October 21, 2013 8:55 PM
 To: Hannes Gredler
 Cc: OSPF List; Rob Shakir; Harish Raghuveer
 Subject: Re: [OSPF] Review Request: New Version Notification for 
 draft-hegde-ospf-node-admin-tag-00.txt
 
 
 On Oct 21, 2013, at 11:08 AM, Hannes Gredler wrote:
 
 On Mon, Oct 21, 2013 at 02:10:04PM +, Acee Lindem wrote:
 | 
 | On Oct 21, 2013, at 9:51 AM, Hannes Gredler wrote:
 | 
 |  On Mon, Oct 21, 2013 at 01:32:54PM +, Acee Lindem wrote:
 |  | Hannes,
 |  |
 |  | On Oct 21, 2013, at 9:26 AM, Hannes Gredler wrote:
 |  |
 |  |  acee,
 |  | 
 |  |  why should we give an upper boundary on things which
 |  |  - might be subject to change and
 |  |  - which have a historic track record of being underestimated.
 |  |
 |  | You don't have to - just request a separate OSPFv2 opaque LSA and
 |  IPv6 OSPFv3 LSA from IANA.
 |  | Another alternative would be to extend the RI LSA to be multi-
 |  instance and relegate the variable length tags to an instance other
 |  than instance 0.
 | 
 |  again the question why i do have to ?
 |  i can perfectly fit in single-digit as well as a few dozens of colors
 |  in a single RI LSA
 |  - what is your concern - except that we may use inappropriate large
 |  space for TE ?
 |  any reasonable implementation SHOULD restrict the node color set,
 |  such
 |  that overwhelming the 64K of RI LSPs is not going to happen.
 | 
 | We don't want a standard that leaves room for 
 | quot;unreasonablequot; implementations ;^). I think the policy in 
 | RFC 4970 is clear. Here is an
 | excerpt:
 
 oh boy - i wish i could let the non-sense disappear just with good 
 standard docs ;-) - but i hear you - so all you're asking for is an 
 upper boundary ? - is 128 low enough to not scare you and be 
 compliant to the below paragraph.
 
 Actually, I think separate LSAs is a better alternative. 
 
 
 
 
 | 3.  Router Information LSA Opaque Usage and Applicability
 | 
 |The purpose of the Router Information (RI) LSA is to advertise
 |information relating to the aggregate OSPF router.  Normally, this
 |should be confined to TLVs with a single value or very few values.
 |It is not meant to be a generic container to carry any and all
 |information.  The intent is to both limit the size of the RI LSA to
 |the point where an OSPF router will always be able to contain the
 |TLVs in a single LSA and to keep the task of determining what has
 |changed between LSA instances reasonably simple.  Hence, discretion
 |and sound engineering judgment will need to be applied when deciding
 |whether newly proposed TLV(s) in support of a new application are
 |advertised in the RI LSA or warrant the creation of an application
 |specific LSA.
 | 
 | 
 | Anyway, this hasn't even been presented or accepted as a WG document. 
 
 which is not a reason why we should not discuss how to iron out the bumpy 
 parts now.
 
 Right.
 
 Thanks,
 Acee
 
 
 
 thanks !
 
 /hannes
 
 |  |  the 'per-link' admin-groups serve as a good example here:
 |  |  initially conceived as quot;you won't ever need more than
 |  32quot; we have
 |  |  now arrived at a variable length (unbounded) extension.
 |  | 
 |  |  http://tools.ietf.org/html/draft-osborne-mpls-extended-admin-
 |  groups-00
 |  | 
 |  |  for a humorous take to it, have a look at
 |  |  http://tools.ietf.org/html/rfc1925
 |  |  rule (9) and (10)
 |  | 
 |  |  /hannes
 |  | 
 |  |  On Oct 21, 2013, at 3:12 PM, Acee Lindem wrote:
 |  | 
 |  |  Hi Shraddha,
 |  |  Since the size of the tag data is unbounded, could you either
 |  put it in a separate OSPFv2 opaque

Re: [OSPF] OSPF WG Last Call for Hiding Transit-only Networks in OSPF - draft-ietf-ospf-prefix-hiding-02.txt

[Shraddha Hegde]

In case of p2mp networks, type 3 links used to describe the interface address
is omitted to hide the network.

This can cause problems in the next hop calculation in certain cases and in my 
opinion it is better to avoid installing a certain route  (as done in case of 
broadcast networks in this draft) rather than completely omitting it.

Consider a scenario when p2mp interfaces are configured in the NSSA area.

A-B
 | 
 --C

A,B and C are connected over a p2mp network configured in NSSA area.
B  C are ASBRs importing external routes. B  C will have to include 
forwarding address corresponding to interface address when they advertise 
external LSA to A. 
We cannot hide the p2mp network in the above scenario as type 3 stub-links are 
completely omitted, we cannot resolve the forwarding address for the external 
LSAs originated by B  C.

Rgds
Shraddha

-Original Message-
From: ospf-boun...@ietf.org [mailto:ospf-boun...@ietf.org] On Behalf Of Acee 
Lindem
Sent: Wednesday, February 08, 2012 10:37 PM
Cc: OSPF List
Subject: [OSPF] OSPF WG Last Call for Hiding Transit-only Networks in OSPF  - 
draft-ietf-ospf-prefix-hiding-02.txt

As I have heard no objections, I'm beginning the 2 week OSPF Working Group last 
call for draft-ietf-ospf-prefix-hiding-02.txt.
Please review the draft and post your last call comments prior to 12:00 AM PDT 
on February 23nd, 2012. 
Here is a URL for your convenience: 

http://www.ietf.org/id/draft-ietf-ospf-prefix-hiding-02.txt

Thanks,
Acee 

On Jan 26, 2012, at 11:19 AM, Acee Lindem wrote:

 As WG co-chair, I have reviewed this document and believe it is ready for 
 OSPF WG last call. Any other opinions? 
 There is at least one implementation. Here is a URL for you convenience:
 
   http://www.ietf.org/id/draft-ietf-ospf-prefix-hiding-01.txt
 
 There is an IPR disclosure on this draft:
 
   http://datatracker.ietf.org/ipr/1423/
 
 I will start WG last call next week if I don't hear any objections.
 
 Thanks,
 Acee
 
 
 ___
 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

Re: [OSPF] OSPF WG Last Call for Hiding Transit-only Networks in OSPF - draft-ietf-ospf-prefix-hiding-02.txt

[Shraddha Hegde]

My concern is that we would be introducing a new feature which won't work with 
some existing feature!. Could be a pain for operators who already use 
forwarding address for some optimization and want to use network hiding for 
security.

Rgds
Shraddha
-Original Message-
From: Acee Lindem [mailto:acee.lin...@ericsson.com] 
Sent: Thursday, February 09, 2012 8:43 PM
To: Shraddha Hegde
Cc: OSPF List
Subject: Re: [OSPF] OSPF WG Last Call for Hiding Transit-only Networks in OSPF 
 - draft-ietf-ospf-prefix-hiding-02.txt

Hi Shraddha, 

You raise a very good point. 

On Feb 9, 2012, at 4:33 AM, Shraddha Hegde wrote:

 In case of p2mp networks, type 3 links used to describe the interface 
 address is omitted to hide the network.
 
 This can cause problems in the next hop calculation in certain cases and in 
 my opinion it is better to avoid installing a certain route  (as done in case 
 of broadcast networks in this draft) rather than completely omitting it.
 
 Consider a scenario when p2mp interfaces are configured in the NSSA area.
 
 A-B
 | 
 --C
 
 A,B and C are connected over a p2mp network configured in NSSA area.
 B  C are ASBRs importing external routes. B  C will have to include 
 forwarding address corresponding to interface address when they advertise 
 external LSA to A. 
 We cannot hide the p2mp network in the above scenario as type 3 stub-links 
 are completely omitted, we cannot resolve the forwarding address for the 
 external LSAs originated by B  C.

I think there should just be a general statement that a forwarding address MUST 
not be advertised when prefix-hiding is configured on the next-hop interface. 
However, we'll see what the authors have to say. 


Thanks,
Acee



 
 Rgds
 Shraddha
 
 -Original Message-
 From: ospf-boun...@ietf.org [mailto:ospf-boun...@ietf.org] On Behalf 
 Of Acee Lindem
 Sent: Wednesday, February 08, 2012 10:37 PM
 Cc: OSPF List
 Subject: [OSPF] OSPF WG Last Call for Hiding Transit-only Networks in 
 OSPF  - draft-ietf-ospf-prefix-hiding-02.txt
 
 As I have heard no objections, I'm beginning the 2 week OSPF Working Group 
 last call for draft-ietf-ospf-prefix-hiding-02.txt.
 Please review the draft and post your last call comments prior to 12:00 AM 
 PDT on February 23nd, 2012. 
 Here is a URL for your convenience: 
 
 http://www.ietf.org/id/draft-ietf-ospf-prefix-hiding-02.txt
 
 Thanks,
 Acee
 
 On Jan 26, 2012, at 11:19 AM, Acee Lindem wrote:
 
 As WG co-chair, I have reviewed this document and believe it is ready for 
 OSPF WG last call. Any other opinions? 
 There is at least one implementation. Here is a URL for you convenience:
 
  http://www.ietf.org/id/draft-ietf-ospf-prefix-hiding-01.txt
 
 There is an IPR disclosure on this draft:
 
  http://datatracker.ietf.org/ipr/1423/
 
 I will start WG last call next week if I don't hear any objections.
 
 Thanks,
 Acee
 
 
 ___
 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

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