Skip to main content

GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs)
RFC 5467

Yes

(Ross Callon)

No Objection

(Dan Romascanu)
(David Ward)
(Jari Arkko)
(Lisa Dusseault)
(Magnus Westerlund)
(Mark Townsley)
(Pasi Eronen)
(Ron Bonica)
(Tim Polk)

Note: This ballot was opened for revision 02 and is now closed.

(Ross Callon; former steering group member) Yes

Yes ()

                            

(Dan Romascanu; former steering group member) No Objection

No Objection ()

                            

(David Ward; former steering group member) No Objection

No Objection ()

                            

(Jari Arkko; former steering group member) No Objection

No Objection ()

                            

(Lisa Dusseault; former steering group member) No Objection

No Objection ()

                            

(Magnus Westerlund; former steering group member) (was Discuss) No Objection

No Objection ()

                            

(Mark Townsley; former steering group member) No Objection

No Objection ()

                            

(Pasi Eronen; former steering group member) No Objection

No Objection ()

                            

(Ron Bonica; former steering group member) No Objection

No Objection ()

                            

(Russ Housley; former steering group member) No Objection

No Objection (2008-10-20)
  Scott Brim raised two concerns in his Gen-ART Review.  In additon,
  Scott pointed out some references that were out of date.  The two
  concerns are repeated below.

  Section 2.1.1 says:
  >
  > The contents of the UPSTREAM_FLOWSPEC Object MUST be constructed
  > using a consistent format and procedures used to construct the
  > FLOWSPEC object that will be used for the LSP, e.g., [RFC2210] or
  > [RFC4328].
  >
  This sentence is a little funky.  Here are two possible changes:

    ... using a format and procedures consistent with those used to
    construct the FLOWSPEC ...

    ... using the same format and procedures used to construct the
    FLOWSPEC ...

  Sections 2.2.1 and 2.3.1 have the same issue.

  Section 2.2.1 says:
  >
  > When an UPSTREAM_TSPEC object is received by an ingress, the
  > ingress MAY determine that the original reservation is
  > insufficient to satisfy the traffic flow. In this case, the
  > ingress MAY issue a Path message with an updated UPSTREAM_FLOWSPEC
  > object to modify the resources requested for the upstream traffic
  > flow. This modification might require the LSP to be re-routed, and
  > in extreme cases might result in the LSP being torn down when
  > sufficient resources are not available.
  >
  I'm ignorant here but since both directions are being set up
  simultaneously, is a teardown appropriate at this point?

(Tim Polk; former steering group member) No Objection

No Objection ()