Re: [Idr] 1 Week Final Call for adoption of draft-dong-idr-rtc-hierarchical-rr-02

["Susan Hares" <[e-mail]>]

Bruno:

 

The document has been accepted as a WG document.   I hope that people will
engage you in debating the primary solution version the second solution.   I
expect this evening Jie will respond to this email during his working hours
(this evening). 

 

I agree with many of your points regarding Add-path versus RTC approach.
One question should we allow two solutions – one for people already taking
the heavy weight of add-path and another for the RTC. 

 

AddPath grouping has entered the standard process, but I did not hold it for
this work.  We can append a standard to the AddPath standard if operators
need this feature. 

 

Sue 

 

From: [e-mail] [mailto:[e-mail]] 
Sent: Tuesday, January 06, 2015 11:39 AM
To: Susan Hares
Cc: [e-mail]; [e-mail]; Dongjie (Jimmy)
Subject: RE: [Idr] 1 Week Final Call for adoption of
draft-dong-idr-rtc-hierarchical-rr-02

 

Hi Sue, John, all

 

I support WG adoption.

 

AFAIK, I don’t have a use case for this (so personally I could live without)
but the RTC  RFC has an issue and therefore, from and STD standpoint, IMO
this at least needs to be documented.

 

Regarding the solution, I would a priori prefer the alternate solution (from
Appendix A in v01 / the original solution proposed in v00; ala “Best
External”) rather than the solution currently proposed in v02 (ala “Add
Path”) for the following reasons:

- “Add Path” heavily depend on configuration to be done by the Service
Provider. This add complexity to the provisioning system which would need to
look at the iBGP client’s configuration to see if it itself have an iBGP
client session 

- It looks to me that even the “Add Path” solution requires protocol
extension (not crystal clear but the draft asks for STD track) and
implementation change. So no specific advantage for “Add Path” on this
point.

-The “Best External” solution is IMO more inlined with the current RTC
spec/point of view which is to limit BGP states/path at the cost of a
specific iBGP propagation rule. Looks more coherent to me and easier from an
operational point to have all sessions within the AS behaving along  the
same principles.

 

Specific comment:

- In §3.1 (add path solution)

“The number of RT-Constrain routes to be advertised is a local decision of
operators. »

IMO “add path all” is needed, unless you define a new Add Path mode that you
would need to specify.

 

 

Thanks,

Regards,

Bruno

 

From: Idr [mailto:[e-mail]] On Behalf Of Susan Hares
Sent: Friday, December 19, 2014 2:45 PM
To: [e-mail]
Cc: [e-mail]
Subject: [Idr] 1 Week Final Call for adoption of
draft-dong-idr-rtc-hierarchical-rr-02

 

 

The IDR Chairs intend to adopt the draft-dong-idr-rtc-hierarchical-rr-02 as
a WG draft.  This is a 1 week final call for comments on the adoption of
this draft as WG draft.  The draft can be found at:

 

http://datatracker.ietf.org/doc/draft-dong-idr-rtc-hierarchical-rr/

 

 

Sue Hares and John Scudder

 

 

____________________________________________________________________________
_____________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu
ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
 
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and
delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.