Skip to main content

Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)
draft-ietf-mpls-rsvp-unnum-08

Revision differences

Document history

Date Rev. By Action
2003-02-18
08 (System) Ballot writeup text was added
2003-02-18
08 (System) Ballot approval text was added
2002-12-03
08 Scott Bradner 2002-12-03 - rfc ed queue
2002-12-03
08 Scott Bradner State Changes to RFC Ed Queue from Approved-announcement sent by Bradner, Scott
2002-12-03
08 Jacqueline Hargest State Changes to Approved-announcement sent from Approved-announcement to be sent by Hargest, Jacqueline
2002-11-14
08 Scott Bradner
2002-11-14 - rfc ed note from alex & the ID is approved

In section 5 replace

  An unnumbered link has to be a point-to-point …
2002-11-14 - rfc ed note from alex & the ID is approved

In section 5 replace

  An unnumbered link has to be a point-to-point link. An LSR at each
  end of an unnumbered link assigns an identifier to that link. This
  identifier is a non-zero 32-bit number that is unique within the
  scope of the LSR that assigns it. The IS-IS and/or OSPF and RSVP
  modules on an LSR must agree on the identifiers.

with

  An unnumbered link has to be a point-to-point link. An LSR at
  each end of an unnumbered link assigns an identifier to that
  link. This identifier is a non-zero 32-bit number that is unique
  within the scope of the LSR that assigns it. If one is using
  OSPF or ISIS as the IGP in support of traffic engineering, then
  the IS-IS and/or OSPF and RSVP modules on an LSR must agree on
  the identifiers.

In section 5 replace

  In the context of this document the term "Router ID" refers to the
  "Router Address" as defined in [OSPF-TE], or "Traffic Engineering
  Router ID" as defined in [ISIS-TE].

with

  In the context of this document the term "Router ID" means a
  stable IP address of an LSR that is always reachable if there
  is any connectivity to the LSR. This is typically implemented
  as a "loopback address"; the key attribute is that the address
  does not become unusable if an interface on the LSR is down.
  In some case this value will need to be configured. If one is
  using OSPF or ISIS as the IGP in support of traffic engineering,
  then it is RECOMMENDED to set the Router ID to the "Router
  Address" as defined in [OSPF-TE], or "Traffic Engineering Router
  ID" as defined in [ISIS-TE].
2002-11-14
08 Scott Bradner State Changes to Approved-announcement to be sent from IESG Evaluation  :: AD Followup by Bradner, Scott
2002-11-14
08 (System) IESG has approved the document
2002-11-08
08 Scott Bradner 2002-11-08 - discussion between alex, wg chairs & authors
2002-11-02
08 Scott Bradner
2002-11-02 - sent draft rfc ed note to iesg

RFC Editor:
        Please move teh following two references to the normative
section: …
2002-11-02 - sent draft rfc ed note to iesg

RFC Editor:
        Please move teh following two references to the normative
section:
        [OSPF-TE] and [ISIS-TE]
2002-11-02
08 Scott Bradner by Bradner, Scott
2002-11-02
08 Scott Bradner State Changes to IESG Evaluation  :: AD Followup from IESG Evaluation  :: Point Raised - writeup needed by Bradner, Scott
2002-10-31
08 Scott Bradner
2002-10-31 - IESG discussion
OKed but references do need to be normative - Alex
says that this should not delay things all that much
the …
2002-10-31 - IESG discussion
OKed but references do need to be normative - Alex
says that this should not delay things all that much
the change will be done with an RFC Editor note (no new
version needed)
2002-10-31
08 Scott Bradner by Bradner, Scott
2002-10-31
08 Scott Bradner State Changes to IESG Evaluation  :: Point Raised - writeup needed from IESG Evaluation by Bradner, Scott
2002-10-26
08 Scott Bradner 2002-10-25 - on 2002-10-31 IESG agenda
2002-10-26
08 Scott Bradner by sob
2002-10-25
08 Scott Bradner
2002-10-25 - note from loa to ADs & Alex
Alex,

Scott informed us that you've suggested that the isis-te and the
ospf-te references in the …
2002-10-25 - note from loa to ADs & Alex
Alex,

Scott informed us that you've suggested that the isis-te and the
ospf-te references in the rsvp-unnum should be made normative.

We've two issues on this:

1. cr-ldp-unnum and rsvp-unnum should be treated the same way
2. we are concerned that making those references normative will delay
    delay the publication of the draft unnecessarily.
    are the argument for normative references really strong, they were
    included just refer to the router address and router id. it does not
    seem ther right thing to do to create a situation where it becomes
    hard to move documents because of this kind of reference.

Do we have a time schedule for isis-te and ospf-te? Could the references
stay non-normative? Any other way to solve this?

/Loa
2002-10-25
08 Scott Bradner by sob
2002-10-25
08 Scott Bradner State Changes to IESG Evaluation  -- 0 from Final AD Go-Ahead by sob
2002-10-22
08 Scott Bradner 2002-10-21 - alex
Seems that [OSPF-TE] and [ISIS-TE] should be normative
2002-10-22
08 Scott Bradner by sob
2002-10-22
08 Scott Bradner State Changes to Final AD Go-Ahead  -- 0 from IESG Evaluation  -- AD Evaluation of result by sob
2002-10-21
08 Scott Bradner 2002-10-21 - poked randy & alex on their discusses
2002-10-21
08 Scott Bradner by sob
2002-10-21
08 Scott Bradner 2002-10-21 - note from Loa - new version - ready for IESG
2002-10-21
08 Scott Bradner by sob
2002-10-21
08 Scott Bradner State Changes to IESG Evaluation  -- AD Evaluation of result from IESG Evaluation  -- New ID Needed by sob
2002-10-18
08 (System) New version available: draft-ietf-mpls-rsvp-unnum-08.txt
2002-09-30
08 Scott Bradner fix to new tracker substate
2002-09-30
08 Scott Bradner by sob
2002-09-30
08 Scott Bradner State Changes to IESG Evaluation  -- New ID Needed from IESG Evaluation  -- External Party by sob
2002-09-19
08 Scott Bradner State Changes to IESG Evaluation  -- External Party from AD Evaluation  -- External Party by sob
2002-08-22
08 Scott Bradner
2002-08-22 - on IESG agenda
comments back to mpls WG chairs
1/ in sec 10 - the text "The responsible Internet authority (presently called the …
2002-08-22 - on IESG agenda
comments back to mpls WG chairs
1/ in sec 10 - the text "The responsible Internet authority (presently called the IANA)" should be replaced with "The IANA" (we do not need the semi-political statement)

2/ the IPR text from RFC 2026 sec 10.4(A) and 10.4(B) should be added to the ID

3/ The document uses the notion of "Router ID" that is not
defined. One could read it as OSPF Router ID or TE Router ID, for example, that have completely different name spaces.
2002-08-22
08 Scott Bradner responsible has been changed to Working Group from IESG as a whole
2002-08-22
08 Scott Bradner State Changes to New Version Needed (WG/Author) from Ready for Telechat by sob
2002-08-15
08 Scott Bradner 2002-08-15 - onto IESG agenda
2002-08-15
08 Scott Bradner responsible has been changed to IESG as a whole from IETF Secretary
2002-08-15
08 Scott Bradner
State Changes to Ready for Telechat                                from Last Call Issued  …
State Changes to Ready for Telechat                                from Last Call Issued                                  by sob
2002-07-31
08 Jacqueline Hargest Due date has been changed to 08/13/2002 from
by jhargest
2002-07-31
08 Jacqueline Hargest
State Changes to Last Call Issued                                  from Last Call …
State Changes to Last Call Issued                                  from Last Call Requested                              by jhargest
2002-07-30
08 Scott Bradner 2002-07-30 - last call requested
2002-07-30
08 Scott Bradner responsible has been changed to IETF Secretary from Working Group
2002-07-30
08 Scott Bradner
State Changes to Last Call Requested                              from New Version Needed (WG/Author)  …
State Changes to Last Call Requested                              from New Version Needed (WG/Author)                    by sob
2002-07-30
08 Scott Bradner 2002-07-25 - request to publish from George
2002-07-30
08 Scott Bradner A new comment added
by sob
2002-07-30
08 (System) Last call sent
2002-07-24
07 (System) New version available: draft-ietf-mpls-rsvp-unnum-07.txt
2002-06-05
08 Scott Bradner
2002-06-02 - note to chairs - sob
> acronyms must be expanded in title and abstract
> MUST etc used but not defined (eg. add …
2002-06-02 - note to chairs - sob
> acronyms must be expanded in title and abstract
> MUST etc used but not defined (eg. add reference to RFC 2119)
> s/idenfitier/identifier - sec 4, 4th pp
> s/cooresponding/corresponding/ - sec 7 near end
2002-06-05
08 Scott Bradner A new comment added
by sob
2002-06-05
08 Scott Bradner
State Changes to New Version Needed (WG/Author)                    from Pre AD Evaluation            …
State Changes to New Version Needed (WG/Author)                    from Pre AD Evaluation                                by sob
2002-06-05
08 Scott Bradner 2002-05-31 - request to last call from Loa
2002-06-05
08 Scott Bradner Intended Status has been changed to Proposed Standard from None
2002-06-05
08 Scott Bradner
State Changes to Pre AD Evaluation                                from In WG    …
State Changes to Pre AD Evaluation                                from In WG                                            by sob
2002-05-16
06 (System) New version available: draft-ietf-mpls-rsvp-unnum-06.txt
2002-05-02
08 Scott Bradner 2002-0502 - from george swallow
passwd WG last call - in chair review
2002-04-27
08 Scott Bradner Draft Added by Scott Bradner
2002-03-25
05 (System) New version available: draft-ietf-mpls-rsvp-unnum-05.txt
2002-02-18
04 (System) New version available: draft-ietf-mpls-rsvp-unnum-04.txt
2001-11-29
03 (System) New version available: draft-ietf-mpls-rsvp-unnum-03.txt
2001-09-04
02 (System) New version available: draft-ietf-mpls-rsvp-unnum-02.txt
2001-03-06
01 (System) New version available: draft-ietf-mpls-rsvp-unnum-01.txt
2000-11-08
00 (System) New version available: draft-ietf-mpls-rsvp-unnum-00.txt