internet-drafts | 15 Dec 16:11 2014
Picon

I-D Action: draft-ietf-rtgwg-rlfa-node-protection-01.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Routing Area Working Group Working Group of the IETF.

        Title           : Remote-LFA Node Protection and Manageability
        Authors         : Pushpasis Sarkar
                          Hannes Gredler
                          Shraddha Hegde
                          Chris Bowers
                          Stephane Litkowski
                          Harish Raghuveer
	Filename        : draft-ietf-rtgwg-rlfa-node-protection-01.txt
	Pages           : 16
	Date            : 2014-12-15

Abstract:
   The loop-free alternates computed following the current Remote-LFA
   [I-D.ietf-rtgwg-remote-lfa] specification gaurantees only link-
   protection.  The resulting Remote-LFA nexthops (also called PQ-
   nodes), may not gaurantee node-protection for all destinations being
   protected by it.

   This document describes procedures for determining if a given PQ-node
   provides node-protection for a specific destination or not.  The
   document also shows how the same procedure can be utilised for
   collection of complete characteristics for alternate paths.
   Knowledge about the characteristics of all alternate path is
   precursory to apply operator defined policy for eliminating paths not
   fitting constraints.

(Continue reading)

Alia Atlas | 12 Dec 01:00 2014
Picon

AD review comments on draft-ietf-rtgwg-remote-lfa-08

I have done my usual AD review of this draft before progressing it.
Thanks for the hard work on this!

I have a number of different comments on the draft, as given below.
None of them are sufficient for me to be concerned about starting the 
IETF Last Call, but please address them as soon as possible.

Assuming an updated draft will appear and a quiet IETF Last Call, I expect
this to be on the IESG telechat in early Jan.


Minor Comments:

1) In Sec 2, 3rd paragraph, in the sentence: 
"The single node in both S's P-space and E's Q-space is C; thus node C is selected as the repair tunnel's end-point."
it should be "S's extended P-space"

2) In Sec 2, it says: "The non-failure traffic distribution is not disrupted by the provision of such a tunnel since it is only used for repair traffic and MUST NOT be used for normal traffic."
This is obviously correct and good - but I think it would be very useful to clarify that OAM traffic to test the rLFA may transit the tunnel at any time.  Otherwise, the MUST NOT could cause some confusion - depending on how one thinks about "normal traffic".

3) In Sec 3:  I can't parse "Examples of worse failures are node failures (see Section 6 ), and through the failure of a shared risk link group (SRLG), the through the independent concurrent failure of multiple links, and these are out of scope for this specification."

I think you mean "Examples of worse failures are node failures (see Section 6), the failure of a shared risk link group (SRLG), the independent concurrent failures of multiple links; protecting against such worse failures is out of scope for this specification."  I would add in the failure of broadcast interfaces and NBMA interfaces for completeness, even though that was mentioned in Sec 2.

4) In Sec 4.2: " Provided both these requirements are met, packets forwarded over the repair tunnel will reach their destination and will not loop."  Please change to:
"will not loop after the single link failure".  Of course, looping can happen if a worse failure than protected against occurs - as with LFA.  This could also be mitigated by requiring that the PQ node is downstream of the PLR, as  is mentioned in Sec 4.2.2.

5) In Sec 4.2.1.2: "This may be calculated by computing an SPT at each of S's neighbors (excluding E) and excising the subtree reached via the path N->S->E."  
As described here, a node Y that is reached via N->S->A would be considered to be in S's extended P-space.  I realize that one would assume that Y would be in S's P-space anyway and thus it is safe to not care about this edge case.  However, the ECMP considerations make it more complex so please at a minimum add in the same caveat as in Sec 4.2.1.2  "(including those routers which are members of an ECMP that includes link S-E)" suitably modified.  In the cost-based version in Compute_Extended_P_Space, this is handled by ignoring any potential node from N whose shortest path goes back through S.  It'd be nice if the two methods were consistent.

6) In Sec 4.2.2: "As described in [RFC5286], always selecting a PQ node that is downstream with respect to the repairing node, prevents the formation of loops when the failure is worse than expected."  Could you clarify that the PQ node is downstream with respect to the repairing node and the destination - rather than the proxy destination E?  I'm fairly certain that the latter wouldn't work (but don't have an example topology created).  If you disagree, let me know and I'll work on creating one.   This is the constraint that is expressed in Apply_Downstream_Constraint().

7) In Sec 4.3: "The reader is referred to [I-D.psarkar-rtgwg-rlfa-node-protection] for further information on the use of RLFA for node repairs." Can you add "and broadcast or NBMA link repairs"?   Do you feel that is accurate? 

8) In Sec 6: s/"When the failure is a node failure rather than a link failure"/"When the failure is a node failure rather than a point-to-point link failure"

9) In Sec 6: "Alternatively one might choose to assume that the probability of a node failure and microloops forming is sufficiently rare that the case can be ignored."  Can you please clarify from microloops to "microloops forming due to use of alternates"?  We know that in cases where a rLFA is necessary, that neighbor isn't loop-free and so regular microloops due to reconvergence will form.

10) In Sec 7: "In the absence of a protocol to learn the preferred IP address for targeted LDP, an LSR should attempt a targeted LDP session with the Router ID [RFC2328] [RFC5305] [RFC5340], unless it is configured otherwise."  Can you please add in some text for how this would work for IPv6?  I believe that there are current drafts discussing carrying Routable IP addresses (e.g. http://datatracker.ietf.org/doc/draft-ietf-ospf-routable-ip-address/ ).  We know that there is interest in having IPv6 only networks with MPLS - so it'd be good not to create new gaps.

11) In Sec 8.4: "In an MPLS network, this is achieved without any scaleability impact, as the tunnels to the PQ nodes are always present as a  property of an LDP-based deployment."  The targeted LDP sessions don't have a scaleability impact?  That the repair tunnels don't need to be specifically created as new tunnels, I agree with - but this statement is overselling.  Please make the technical point more clearly.

12) In Sec 9:  I feel like here is a good place at least mention the issues with microloops from reconvergence.  Since reconvergence after rLFA is going to result in a local microloop (depending on timing), at least a reference to https://tools.ietf.org/html/draft-litkowski-rtgwg-uloop-delay-03 with a recommendation to consider it is important.  Otherwise, the rLFA repair happens and then traffic microloops and is lost.  The fact that these local microloops occur with real impact much more with rLFA (or any advanced FRR technique) is an important management consideration.

13) Sec 12:  Saying "To prevent their use as an attack vector the repair tunnel endpoints SHOULD be assigned from a set of addresses that are not reachable from outside the routing domain." is basically empty words without more behind Sec 7 default of using Router IDs.  Can you find a reference that talks about a BCP for Router IDs not being reachable addresses outside the routing domain?  Can you describe how to use the IGP extensions?

Nits:

a) In Sec 4.2.1.1: "The exclusion of routers reachable via an ECMP that includes S-E prevents the forwarding subsystem attempting to a repair endpoint via the failed link S-E."
s/attempting to a repair/from attempting to use a repair

b) In Sec 10: "We propose "Remote LFA" as a natural second step."  This is going to be an RFC - so rather than propose, try specify.

Thanks,
Alia

_______________________________________________
rtgwg mailing list
rtgwg <at> ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg
Alia Atlas | 9 Dec 23:46 2014
Picon

routing area design team on dataplane encapsulation considerations

I have chartered a Routing Area Design Team to work on data-plane encapsulation considerations.

I've bcc'd nvo3, sfc, bier, and rtgwg as the most directly relevant.  Please keep any conversation in one place on routing-discussion.

Erik Nordmark has kindly agreed to lead this design team.  The members of the design
team are:

  Erik Nordmark <nordmark <at> sonic.net>
  Jesse Gross <jgross <at> vmware.com>
  Jon Hudson <jon.hudson <at> gmail.com>
  Larry Kreeger (kreeger) <kreeger <at> cisco.com>
  Pankaj Garg <Garg.Pankaj <at> microsoft.com>
  Pat Thaler <pthaler <at> broadcom.com>
  Tom Herbert <therbert <at> google.com>

The mailing list, rgt-dt-encap-considerations <at> ietf.org, is closed but the archives are
publicly available at:

The Design Team is chartered as follows:

There have been multiple efforts over the years that have resulted in new or modified data plane behaviors involving encapsulations. That includes IETF efforts like MPLS, LISP, and TRILL but also industry efforts like Vxlan and NVGRE.  These collectively can be seen as a source of insight into the properties that data planes need to meet.  The IETF is currently working on potentially new encapsulations in NVO3 and SFC and considering working on BIER. In addition there is work on tunneling in the INT area.

This is a short term design team chartered to collect and construct useful advice to parties working on new or modified data plane behaviors that include additional encapsulations.  The goal is for the group to document useful advice gathered from interacting with ongoing efforts.  An Internet Draft will be produced for IETF92 to capture that advice, which will be discussed in RTGWG.

Data plane encapsulations face a set of common issues such as:

  * How to provide entropy for ECMP
  * Issues around packet size and fragmentation/reassembly
  * OAM - what support is needed in an encapsulation format?
  * Security and privacy.
  * QoS
  * Congestion Considerations
  * IPv6 header protection (non-zero UDP checksum over IPv6 issue)
  * Extensibility - e.g., for evolving OAM, security, and/or congestion control
  * Layering of multiple encapsulations e.g., SFC over NVO3 over BIER

The design team will provide advice on those issues. The intention is that even where we have different encapsulations for different purposes carrying different data, each such encapsulation doesn’t have to reinvent the wheel for the above common issues.

The design team will look across the routing area in particular at SFC, NVO3 and BIER. It will not be involved in comparing or analyzing any particular encapsulation formats proposed in those WGs and BoFs but instead focus on common advice.

Regards,
Alia
_______________________________________________
rtgwg mailing list
rtgwg <at> ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg
Kamran Raza (skraza | 8 Dec 20:29 2014
Picon

Re: Working Group last call on draft-ietf-rtgwg-lfa-manageability - IPR


I am also aware of the IPR disclosure already pointed by Clarence.

Thanks.

On 2014-12-03, 12:27 PM, "Clarence Filsfils (cfilsfil)"
<cfilsfil <at> cisco.com> wrote:

>Jeff,
>
>I am aware of this disclosure:
>
>https://datatracker.ietf.org/ipr/2196/
>
>Cheers,
>Clarence
>
>
>>> -----Original Message-----
>>> From: rtgwg [mailto:rtgwg-bounces <at> ietf.org] On Behalf Of
>>> stephane.litkowski <at> orange.com
>>> Sent: Wednesday, November 12, 2014 09:24
>>> To: Jeff Tantsura; rtgwg <at> ietf.org
>>> Subject: RE: Working Group last call on
>>> draft-ietf-rtgwg-lfa-manageability - IPR
>>>
>>> Hi Jeff,
>>>
>>> I'm not aware of any IPR related to this draft.
>>>
>>> Stephane
>>>
>>>
>>> -----Original Message-----
>>> From: rtgwg [mailto:rtgwg-bounces <at> ietf.org] On Behalf Of Jeff Tantsura
>>> Sent: Monday, November 10, 2014 21:54
>>> To: rtgwg <at> ietf.org
>>> Subject: Working Group last call on draft-ietf-rtgwg-lfa-manageability
>>> - IPR
>>>
>>> All,
>>>
>>> In parallel to the WGLC for this draft, I want to formally ask the
>>> authors (no additional contributors are listed in the latest version
>>> of the draft) to please respond to this message indicating whether or
>>> not you are aware of any relevant IPR.  The draft will not progress
>>> (pending the results of the WGLC) until we have received a response
>>> from each author.
>>>
>>>
>>> In addition, we wanted to take this opportunity to remind the entire
>>> WG that the duty of disclosure is NOT limited to authors:
>>>
>>>     (c) in order for the working group and the rest of the IETF to have
>>>         the information needed to make an informed decision about the
>>>use
>>>         of a particular technology, all those contributing to the
>>>working
>>>         group's discussions must disclose the existence of any IPR the
>>>         Contributor or other IETF participant believes Covers or may
>>>         ultimately Cover the technology under discussion.  This applies
>>>         to both Contributors and other participants, and applies
>>>whether
>>>         they contribute in person, via email or by other means.  The
>>>         requirement applies to all IPR of the participant, the
>>>         participant's employer, sponsor, or others represented by the
>>>         participants, that is reasonably and personally known to the
>>>         participant.  No patent search is required.
>>>
>>> RFC 3979 also points out disclosure must be "as soon as reasonably
>>> possible":
>>>
>>>     The IPR disclosure required pursuant to section 6.1.1 must be made
>>>as
>>>     soon as reasonably possible after the Contribution is published in
>>>an
>>>     Internet Draft unless the required disclosure is already on file.
>>>
>>> Thank you!
>>>
>>>
>>>
>>> Cheers,
>>> Jeff
>>>
>>> _______________________________________________
>>> rtgwg mailing list
>>> rtgwg <at> ietf.org
>>> https://www.ietf.org/mailman/listinfo/rtgwg
>>>
>>> 
>>>________________________________________________________________________
>>>_________________________________________________
>>>
>>>
>>> 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.
>>>
>>> _______________________________________________
>>> rtgwg mailing list
>>> rtgwg <at> ietf.org
>>> https://www.ietf.org/mailman/listinfo/rtgwg
>>>
>>> 
>>>________________________________________________________________________
>>>_________________________________________________
>>>
>>>
>>> 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.
>>>
>>> .
>>>
Clarence Filsfils | 3 Dec 18:27 2014
Picon

Re: FW: Working Group last call on draft-ietf-rtgwg-lfa-manageability - IPR

Jeff,

I am aware of this disclosure:

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

Cheers,
Clarence

>> -----Original Message-----
>> From: rtgwg [mailto:rtgwg-bounces <at> ietf.org] On Behalf Of
>> stephane.litkowski <at> orange.com
>> Sent: Wednesday, November 12, 2014 09:24
>> To: Jeff Tantsura; rtgwg <at> ietf.org
>> Subject: RE: Working Group last call on
>> draft-ietf-rtgwg-lfa-manageability - IPR
>>
>> Hi Jeff,
>>
>> I'm not aware of any IPR related to this draft.
>>
>> Stephane
>>
>>
>> -----Original Message-----
>> From: rtgwg [mailto:rtgwg-bounces <at> ietf.org] On Behalf Of Jeff Tantsura
>> Sent: Monday, November 10, 2014 21:54
>> To: rtgwg <at> ietf.org
>> Subject: Working Group last call on draft-ietf-rtgwg-lfa-manageability
>> - IPR
>>
>> All,
>>
>> In parallel to the WGLC for this draft, I want to formally ask the
>> authors (no additional contributors are listed in the latest version
>> of the draft) to please respond to this message indicating whether or
>> not you are aware of any relevant IPR.  The draft will not progress
>> (pending the results of the WGLC) until we have received a response
>> from each author.
>>
>>
>> In addition, we wanted to take this opportunity to remind the entire
>> WG that the duty of disclosure is NOT limited to authors:
>>
>>     (c) in order for the working group and the rest of the IETF to have
>>         the information needed to make an informed decision about the use
>>         of a particular technology, all those contributing to the working
>>         group's discussions must disclose the existence of any IPR the
>>         Contributor or other IETF participant believes Covers or may
>>         ultimately Cover the technology under discussion.  This applies
>>         to both Contributors and other participants, and applies whether
>>         they contribute in person, via email or by other means.  The
>>         requirement applies to all IPR of the participant, the
>>         participant's employer, sponsor, or others represented by the
>>         participants, that is reasonably and personally known to the
>>         participant.  No patent search is required.
>>
>> RFC 3979 also points out disclosure must be "as soon as reasonably
>> possible":
>>
>>     The IPR disclosure required pursuant to section 6.1.1 must be made as
>>     soon as reasonably possible after the Contribution is published in an
>>     Internet Draft unless the required disclosure is already on file.
>>
>> Thank you!
>>
>>
>>
>> Cheers,
>> Jeff
>>
>> _______________________________________________
>> rtgwg mailing list
>> rtgwg <at> ietf.org
>> https://www.ietf.org/mailman/listinfo/rtgwg
>>
>> _________________________________________________________________________________________________________________________
>>
>>
>> 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.
>>
>> _______________________________________________
>> rtgwg mailing list
>> rtgwg <at> ietf.org
>> https://www.ietf.org/mailman/listinfo/rtgwg
>>
>> _________________________________________________________________________________________________________________________
>>
>>
>> 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.
>>
>> .
>>
Acee Lindem (acee | 3 Dec 02:16 2014
Picon

FW: New Version Notification for draft-acee-rtg-yang-key-chain-00.txt

FYI - This draft describes the key-chain YANG data model. Key-chains have
been implemented by most networking vendors and are used for routing
protocol authentication. One of the authors will be presenting the draft
in Dallas. 
Thanks,
Acee

On 12/1/14, 10:13 AM, "internet-drafts <at> ietf.org"
<internet-drafts <at> ietf.org> wrote:

>
>A new version of I-D, draft-acee-rtg-yang-key-chain-00.txt
>has been successfully submitted by Acee Lindem and posted to the
>IETF repository.
>
>Name:		draft-acee-rtg-yang-key-chain
>Revision:	00
>Title:		Key Chain YANG Data Model
>Document date:	2014-12-01
>Group:		Individual Submission
>Pages:		17
>URL:            
>http://www.ietf.org/internet-drafts/draft-acee-rtg-yang-key-chain-00.txt
>Status:         
>https://datatracker.ietf.org/doc/draft-acee-rtg-yang-key-chain/
>Htmlized:       
>http://tools.ietf.org/html/draft-acee-rtg-yang-key-chain-00
>
>
>Abstract:
>   This document describes the key chain YANG data model.  Industry
>   standard key chains are lists of keys, send lifetimes, accept
>   lifetimes, and algorithms.  By properly overlapping the send and
>   accept lifetimes of multiple key chain entries, keys and algorithms
>   may be gracefully updated.  By representing them in a YANG data
>   model, key distribution can be automated.  Key chains are commonly
>   used for routing protocol authentication and other applications.  In
>   some applications, the protocols do not directly use the key chain
>   entry keys, but rather a key derivation function is used to derive a
>   short-lived key from the key-chain key.
>
>                  
>        
>
>
>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
>
IETF Secretariat | 25 Nov 23:47 2014
Picon

IPR Disclosure: Juniper's Statement of IPR related to draft-ietf-rtgwg-lfa-manageability-04


Dear Martin Horneffer, Stephane Litkowski, Bruno Decraene, Clarence Filsfils, Kamran Raza, psarkar <at> juniper.net:

 An IPR disclosure that pertains to your Internet-Draft entitled "Operational
management of Loop Free Alternates" (draft-ietf-rtgwg-lfa-manageability) was
submitted to the IETF Secretariat on 2014-11-24 and has been posted on the "IETF
Page of Intellectual Property Rights Disclosures"
(https://datatracker.ietf.org/ipr/2490/). The title of the IPR disclosure is
"Juniper's Statement of IPR related to draft-ietf-rtgwg-lfa-
manageability-04."");

The IETF Secretariat
Ladislav Lhotka | 25 Nov 14:03 2014
Picon

ietf-routing module issues

Hi,

below is a list of open issues regarding YANG modules contained in
draft-ietf-netmod-routing-cfg-16 that I think need further
discussion. I will start a new thread for each in the mailing list
rtg-yang-coord <at> ietf.org (no cross-posting). Therefore, I'd like to ask
folks in NETMOD and Routing Area WGs who are interested in these
discussions to subscribe to that list.

Thanks, Lada

***** :R01: route filters
***** :R02: complex next-hops
***** :R03: assignment of interfaces to routing instances
***** :R04: configuration and state data for IPv6 RA
***** :R05: numeric IDs of state data entries

--

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C
Alvaro Retana (aretana | 21 Nov 19:58 2014
Picon

Moving Forward with MRT (WAS: Re: [mpls] maturity of the MRT technology)

On 11/21/14, 6:49 AM, "Stewart Bryant (stbryant)" <stbryant <at> cisco.com> wrote:

[Stewart: Not directing this e-mail specifically at you…but at the WG.]

[Took off the draft-atlas-mpls-ldp-mrt alias since this is not a discussion specific to that draft.]

[Also took off the mpls alias as I intend to focus the discussion on the rtgwg process/consensus.  Left mpls-chairs as an FYI..we can later circle back to the mpls list.]

. . .
At the end of the day the utility of MRT depends on who is
interested in deploying it, and as far as I know, none of the 
domain wide IPFRR solutions have made it into production networks. 
If there are operators prepared to deploy MRT  in their production 
networks then obviously it is headed for the standards track. 
If it is destined to join the  ranks of the many "possible" domain
wide solutions, then it is clearly still at the informational/
experimental stage of its life.

It is true that MRT has been discussed widely in the WG (and offline)..and that no technical issues exist.

Just as a reminder, the rtgwg charter (in the description of the work related to FRR) reads: "All work in this area should be specifically evaluated by the WG in terms of practicality and applicability to deployed networks.”

Note that this statement doesn’t mean that we need deployments, or even people saying that they want/intend to deploy the technology.  It means that the WG should think of whether a proposal is applicable to deployed networks.  I would like to hear comments specific to this statement.

Thanks!

Alvaro.
_______________________________________________
rtgwg mailing list
rtgwg <at> ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg
Alvaro Retana (aretana | 20 Nov 23:07 2014
Picon

rtgwg Draft Minutes Posted for IETF 91



Thanks to Acee for being our scribe.

Please send any comments/corrections before Dec/5.

Alvaro.
_______________________________________________
rtgwg mailing list
rtgwg <at> ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg
Loa Andersson | 19 Nov 01:08 2014
Picon

maturity of the MRT technology

Working Groups,

We have don an MPLS-RT of draft-atlas-mpls-ldp-mrt, the reviews has been
posted to the mpls wg mailing list.

In his MPLS-RT review Stewart Bryant says:

"I have concerns about whether or not MRT technology has the  maturity
  expected in the standards track. However that decision needs to be
  taken in RTGWG and MPLS needs to follow their and lead in determining
  the fate and track of this draft. This draft should not be published
  ahead of the drafts that define the technology that it is supporting."

He also says that he see no reason not to go ahead and start the poll to
see if we have consensus to adopt the document as an mpls wg document.

The question Stewart ask is valid, and we'd like input from the rtgwg
and rtgwg chairs (copied on this mail). We will also copy both the
poll for adoption and the wglc to the rtgwg mailing list.

/Loa
mpls wg co-chair
--

-- 

Loa Andersson                        email: loa <at> mail01.huawei.com
Senior MPLS Expert                          loa <at> pi.nu
Huawei Technologies (consultant)     phone: +46 739 81 21 64

Gmane